Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] feature dependency version incompatibility 
You should still be able to install both features without a problem.

Am 13.06.20 um 18:45 schrieb Homer, Tony:

Thanks for responding, Christoph.

I think I got your point about sensible version ranges, but as you mentioned the features define strict versions.  Conflicting might be the wrong word to use, but the point is that some features specify javax.annotation 1.3.5.qualifier while others specify javax.annotation 1.2.0.qualifier, so AFAIK these features have conflicting dependency requirements and cannot be installed at the same time.  I was hoping someone would tell me that I am mistaken about this (

Tony

On 6/12/20 , 11:06 PM, "cross-project-issues-dev-bounces@xxxxxxxxxxx on behalf of Christoph Läubrich" <cross-project-issues-dev-bounces@xxxxxxxxxxx on behalf of laeubi@xxxxxxxxxxxxxx> wrote:

     Was is selected in the future depends on the version available at build
     time.
     If a never version at runtime is used/allowed depends on the imports in
     the Bundle itself.

     So if proper imports and use clauses are defined it could be that all
     works fine even with different (why they are conflicting?) versions.

     In a perfect world, all bundles would use import package with the lower
     bound of the lowest working version (e.g.  1.2.0) and an upper bound of
     2.0.0 then it would be possible to upgrade up until the next major release.

     The problem is, that features does not support version ranges and thus
     will still reference the version from the build (or the one forced into
     the feature.xml).
     Am 13.06.20 um 07:56 schrieb Homer, Tony:
     > Some 2020-06 features now require javax.annotation 1.3.5 (Jersey Common
     > from Orbit and bundles that depend on it such as Linux Tools Docker)
     > while others (such as org.eclipse.e4.rcp) still require javax.annotation
     > 1.2.0.
     >
     > https://download.eclipse.org/tools/orbit/downloads/drops2/R20200529191137/repository/plugins/org.glassfish.jersey.core.jersey-common_2.30.1.v20200513-1859.jar
     >
     > http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.linuxtools.docker.feature_4.7.0.202006092019.jar
     >
     > http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.e4.rcp_4.16.0.v20200604-0951.jar
     >
     > Is it possible to reconcile these dependency chains without rebuilding
     > the features, so that an eclipse application can use several of these
     > conflicting features from SimRel 2020-06?  As far as I know it is not,
     > but I’d love to learn that I am wrong.
     >
     > e4.rcp does not seem to have any version restriction defined (0.0.0).
     >
     > https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/features/org.eclipse.e4.rcp/feature.xml#n150
     >
     > e4.rcp is resolving javax.annotation from the updates repo at build
     > time, which provides 1.2.0.
     >
     > http://download.eclipse.org/eclipse/updates/4.17-I-builds/I20200612-0650/plugins/javax.annotation_1.2.0.v201602091430.jar
     >
     > What contributes these third-party dependencies to the updates repo?
     >
     > Shouldn’t third-party dependencies be resolved from Orbit instead of
     > from the updates repo?
     >
     > How do I update one of these dependencies that is being provided by the
     > updates repo, such as javax.annotation?
     >
     > In any case, it seems that it must be too late to fix this for 2020-06,
     > but these should get reconciled before 2020-09.
     >
     > I’m interested in helping with this work, but I’ll need the information
     > I asked for above and could use some direction about which project to
     > log the bug in for tracking.
     >
     > Thanks!
     >
     > Tony Homer
     >
     > P.S. Is this an appropriate discussion for cross-project-issues dev?  I
     > don’t want to spam the list so please let me know if this is off-topic
     > and how I should communicate instead.  Thanks!
     >
     >
     > _______________________________________________
     > cross-project-issues-dev mailing list
     > cross-project-issues-dev@xxxxxxxxxxx
     > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
     >
     _______________________________________________
     cross-project-issues-dev mailing list
     cross-project-issues-dev@xxxxxxxxxxx
     To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top