[infinispan-issues] [JBoss JIRA] (ISPN-4853) OSGI metadata import-package version ranges are too narrow

[Andrew Scully (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-4853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012796#comment-13012796 ] 

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)