5:13 a.m.
[
https://issues.jboss.org/browse/ISPN-4853?page=com.atlassian.jira.plugin....
]
Andrew Scully commented on ISPN-4853:
-------------------------------------
Ion, Martin, thanks for considering this.
Time for me to try and be persuasive!
I suppose the point I would make is that there is no technical "issue" as such
here, it is just about making the project as easy as possible for people to use.
I have to say that I've used an awful lot of OSGI projects in the last couple of years
and I've never seen any with import version ranges so narrow! Obviously that
doesn't mean that you're "wrong" just because it's different, but it
does have useability consequences.
We tend to avoid running multiple versions of the same bundle if we can, as in our
experience this is just a stop gap. If every bundle we used depended on a specific
version, we would have to ship 10 versions of every jar! Our preferred solution would
probably be to "repackage" the Infinispan bundles as part of our internal build
process so as to widen the import ranges. Obviously this would raise the question,
"why can't they just do that in the first place"!
I would have thought that, at the very least, allowing greater micro versions would be a
step in the right direction (surely non of the JBOSS projects you depend on would make a
breaking consumer change on a micro release?).
Even if you allowed greater micros and removed the blueprint dependency, we would still
have a problem with javax.transaction -- we're installing on Glassfish 4.1 which ships
version with version 1.2. I would have thought you could trust a javax dependency not to
introduce a breaking consumer change in a minor / micro release?
So yes, there are certainly ways for us to work around this, but it would be a bit of a
pain -- a pain that would multiply up for anyone else in the same situation. It would be
easier (from my perspective!) for you to widen the ranges so that the issue simply
disappears.
I understand that you would want to force people to use a tested configuration, this is
certainly the "safe" approach, but it creates all sorts of problems when it
comes to medium / long-term upgradeability, which of course is what OSGI is all about.
Just my two cents!
OSGI metadata import-package version ranges are too narrow
----------------------------------------------------------
Key: ISPN-4853
URL: https://issues.jboss.org/browse/ISPN-4853
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 7.0.0.CR1
Environment: Any OSGI environment (but found on Glassfish / Apache Felix).
Reporter: Andrew Scully
Labels: OSGI, bundle, import, package
The OSGI import-package statement is specifying specific dependencies on a number of
packages, rather than a range. This makes it impossible to install Infinispan 7 in any
OSGI environment that doesn't have the exact versions of the dependencies present.
Normally, the version range for dependencies would range from the major:minor:revision of
the minimum requirement, up to the next major version (exclusive).
I've copied and pasted the "Imported Packages" output below from my Apache
Felix bundle console for the infinispan-core bundle.
The bundle will not resolve because the versions of javax.transaction, JGroups,
jboss-marshalling and jboss-logging are slightly newer than those required.
The org.osgi.service.blueprint dependency is also dubious -- I'm not sure you usually
have a runtime dependency on this package (even if you use Blueprint).
For example, the following statement...
org.jboss.marshalling;version="[1.4.4.Final,1.4.4.Final]"
...should probably be...
org.jboss.marshalling;version="[1.4.4.Final,2)"
...in order to comply with standard semantic versioning policy.
Felix output:
javax.management from org.apache.felix.framework (0)
javax.naming from org.apache.felix.framework (0)
javax.security.auth from org.apache.felix.framework (0)
javax.transaction,version=[1.1.0,1.1.0] -- Cannot be resolved
javax.transaction.xa,version=[1.1.0,1.1.0] -- Cannot be resolved
javax.xml.namespace from org.apache.felix.framework (0)
javax.xml.parsers from org.apache.felix.framework (0)
javax.xml.stream from org.apache.felix.framework (0)
javax.xml.transform from org.apache.felix.framework (0)
javax.xml.transform.dom from org.apache.felix.framework (0)
javax.xml.transform.stream from org.apache.felix.framework (0)
net.jcip.annotations from com.springsource.net.jcip.annotations (62)
org.infinispan.commons,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons (159)
org.infinispan.commons.api,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons
(159)
org.infinispan.commons.configuration,version=[7.0.0.CR1,7.0.0.CR1] from
org.infinispan.commons (159)
org.infinispan.commons.equivalence,version=[7.0.0.CR1,7.0.0.CR1] from
org.infinispan.commons (159)
org.infinispan.commons.executors,version=[7.0.0.CR1,7.0.0.CR1] from
org.infinispan.commons (159)
org.infinispan.commons.hash,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons
(159)
org.infinispan.commons.io,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons
(159)
org.infinispan.commons.logging,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons
(159)
org.infinispan.commons.marshall,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons
(159)
org.infinispan.commons.marshall.jboss,version=[7.0.0.CR1,7.0.0.CR1] from
org.infinispan.commons (159)
org.infinispan.commons.util,version=[7.0.0.CR1,7.0.0.CR1] from org.infinispan.commons
(159)
org.infinispan.commons.util.concurrent,version=[7.0.0.CR1,7.0.0.CR1] from
org.infinispan.commons (159)
org.infinispan.commons.util.concurrent.jdk8backported,version=[7.0.0.CR1,7.0.0.CR1] from
org.infinispan.commons (159)
org.jboss.logging,version=[3.1.2.GA,3.1.2.GA] -- Cannot be resolved
org.jboss.marshalling,version=[1.4.4.Final,1.4.4.Final] -- Cannot be resolved
org.jboss.marshalling.util,version=[1.4.4.Final,1.4.4.Final] -- Cannot be resolved
org.jgroups,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.blocks,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.blocks.mux,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.jmx,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.logging,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.protocols,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.protocols.relay,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.protocols.tom,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.stack,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.jgroups.util,version=[3.5.0.Final,3.5.0.Final] -- Cannot be resolved
org.osgi.service.blueprint,version=[1.0.0,2.0.0) -- Cannot be resolved
org.w3c.dom from org.apache.felix.framework (0)
org.xml.sax from org.apache.felix.framework (0)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
4205
days inactive
4205
days old
infinispan-issues@lists.jboss.org
0 comments
1 participants
participants (1)
-
Andrew Scully (JIRA)