Hi Ed-

Thanks for (yet another) patient explanation, I really appreciate you taking 
the time to write it up.
I took another look at my troubleshooting and it seems that I may have misread 
the log files.
I thought I was seeing a “only one of the following can be installed at once” 
error.
I guess this type of error occurs when “singleton:=true” is present in 
MANIFEST.MF.
However, now that I went back to the log files I see that it was a different 
error which seems to have been caused by my local configuration.

Christoph, now I understand why you were questioning the error and you were 
right, sorry about that!

Alexander, thanks for logging 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=564264 and I’d like to do it for 
2020-09, but I guess it is less urgent than I thought.

Thanks all and apologies for raising a mostly false alarm.
Tony Homer

From: <cross-project-issues-dev-boun...@eclipse.org> on behalf of Ed Merks 
<ed.me...@gmail.com>
Reply-To: Cross project issues <cross-project-issues-dev@eclipse.org>
Date: Sunday, June 14, 2020 at 12:33 AM
To: "cross-project-issues-dev@eclipse.org" 
<cross-project-issues-dev@eclipse.org>
Subject: Re: [cross-project-issues-dev] feature dependency version 
incompatibility


Tony,

Whether or not two plugins can be installed simultaneously depends on whether 
they are declared to be a singleton in the MANIFEST.MF:

  Bundle-SymbolicName: org.eclipse.emf.common;singleton:=true

I believe most (all?) of the Orbit bundles are not singletons.

The repository analyzer reports that I generate for SimRel show information 
about "duplicates".  E.g., in this Installable Units section of the following 
link, there is a "Duplicates" radio button to show only the duplicates:

  
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2020-06/http___download.eclipse.org_releases_2020-06_202006051000.html

There are 44 duplicates for the coming release.  Apparently batik is super 
popular with 5 versions; the platform appears to be using the latest...

One of the goals of SimRel was to reduce this to no duplicates.  But given 
there is really no resource to effectively manage the overall SimRel process, 
that issue is ignored.

It's challenging just to get the teams to fix more serious problems though 
those are stamped out now with only the following two minor (trivially fixable) 
issues as hold-outs:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=553881
https://bugs.eclipse.org/bugs/show_bug.cgi?id=564192

Eliminating duplicates would certainly be very good, but I expect some ocean 
boiling would be involved to actually make that happen.  There's lots of old 
content being contributed...

It is possible to install everything from SimRel into a single beast:

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=483982

That does actually launch and it looks to be in better shape for 2020-06 than 
in the past.  In that beast I can see the two versions:

[cid:image001.png@01D6428B.3B596510]

Regards,
Ed
On 13.06.2020 18:45, Homer, Tony wrote:

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-boun...@eclipse.org on behalf 
of Christoph 
Läubrich"<mailto:cross-project-issues-dev-bounces@eclipse.orgonbehalfofChristophLäubrich>
 <cross-project-issues-dev-boun...@eclipse.org on behalf of 
lae...@laeubi-soft.de><mailto:cross-project-issues-dev-bounces@eclipse.orgonbehalfoflae...@laeubi-soft.de>
 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@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>

    > 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@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>

    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@eclipse.org<mailto:cross-project-issues-dev@eclipse.org>

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@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to