Re: [cross-project-issues-dev] ACTION REQUIRED: Acceleo, Sirius, EMF Com

[Christoph Läubrich <laeubi@xxxxxxxxxxxxxx>]

You have two cases:

1) you don't use 'org.antlr.runtime', then don't add it to your target 
and let the planner do its work as it is only a transitive dependency

2) you use 'org.antlr.runtime', then you don't want a version range in 
your target because that would mean your build is not reproducible, you 
should have the lowest version you support (read used in a version range 
of your import depending on consumer/producer [1]) in the target

Using 0.0.0 is actually only for "unreleased" items where your build is 
part of a larger aggregator and means your build might work today and 
fail tomorrow or a branch/tag is unable to be rebuild later on because 
"something" changed.

[1] 
https://docs.osgi.org/whitepaper/semantic-versioning/060-importer-policy.html


Am 20.11.23 um 13:30 schrieb Ed Merks via cross-project-issues-dev:
> Unfortunately Tycho/PDE have no mechanism to express version ranges, 
> only version="0.0.0" is special, but it maps to the largest available 
> version.
>
> I don't expect orbit to produce qualifier changes any time in the 
> foreseeable future.
>
> On 20.11.2023 11:18, Edward Willink via cross-project-issues-dev wrote:
> > Hi
> >
> > For MoDisco, I successfuly upgraded to use the latest antlr 3.2.0 
> > which is probably the same as all other 3.2.0's.
> >
> > For the OOMPH setup I could happily refer to [3.2.0,3.3.0]
> >
> > But for the Tycho platform I'm a bit worried, since I have to refer to 
> > precisely
> >
> > <unit id="org.antlr.runtime" version="3.2.0.v20230929-1400"/>
> >
> > Ideally someone is clever enough to explain how Tycho can use a 
> > version range when 0.0.0 won't do.
> >
> > Otherwise are we assured that the Orbit's brand new v20230929-1400 is 
> > not going to be incremented every time Orbit has a change?
> >
> >     Regards
> >
> >         Ed Willink
> >
> >
> > On 20/11/2023 09:49, Laurent Goubet via cross-project-issues-dev wrote:
> > > Hello Ed,
> > >
> > > You've raised issues for the Guava versions, but I expect you're 
> > > trying to get rid of all duplicates.
> > >
> > > From what I'm seeing, you've removed the 4.7 version of antlr from 
> > > the latest orbit build - 
> > > https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2023-12/ which only contains antlr 4.13. This version is not used by anyone according to https://download.eclipse.org/staging/2023-12/buildInfo/archive/download.eclipse.org/staging/2023-12/ . Moving from one version of antlr to the next is not a trivial task, so I (and probably the other users of antlr 4.7), would like to avoid that.
> > >
> > > You mention that "The 4.x versions are available as OSGi bundles" 
> > > (https://github.com/eclipse-orbit/orbit-simrel/commit/85f7256abe6b90f023de4bfabb09f1416f100a67). What does that mean?
> > >
> > > Now, what I'm planning to do for Acceleo is to retrieve antlr from 
> > > the older orbit (2023-09), so there will remain older versions of 
> > > that dependency in 2023-12 RC1.
> > >
> > > With how orbit looks now, what is the expectation for dependencies 
> > > such as antlr which are not easily updateable? How do we re-add older 
> > > versions if we need them?
> > >
> > > Regards,
> > > Laurent
> > >
> > > Le 17/11/2023 à 11:46, Ed Merks via cross-project-issues-dev a écrit :
> > > > I now have a first hit list.  Old guava versions will be eliminated:
> > > >
> > > > https://github.com/eclipse-simrel/simrel.build/issues/80
> > > >
> > > > If you do not eliminate all dependencies on older versions of guava 
> > > > via an updated contribution, then I reserve the option, and am 
> > > > likely to excise the option, to disable your contribution, without 
> > > > further notification.
> > > >
> > > > _______________________________________________
> > > > 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
> > > --
> > >
> > > *Laurent Goubet*
> > > Consultant
> > > +33 2 51 13 51 42
> > >
> > > <https://www.obeo.fr/>
> > >
> > > 7 Boulevard Ampère - Carquefou - France
> > > *obeo.fr* <https://www.obeo.fr/> | *twitter* 
> > > <https://twitter.com/obeo_corp> | *linkedin* 
> > > <https://www.linkedin.com/company/obeo>
> > >
> > >
> > > _______________________________________________
> > > cross-project-issues-dev mailing list
> > > cross-project-issues-dev@xxxxxxxxxxx
> > > To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> > On 20/11/2023 09:49, Laurent Goubet via cross-project-issues-dev wrote:
> > > Hello Ed,
> > >
> > > You've raised issues for the Guava versions, but I expect you're 
> > > trying to get rid of all duplicates.
> > >
> > > From what I'm seeing, you've removed the 4.7 version of antlr from 
> > > the latest orbit build - 
> > > https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2023-12/ which only contains antlr 4.13. This version is not used by anyone according to https://download.eclipse.org/staging/2023-12/buildInfo/archive/download.eclipse.org/staging/2023-12/ . Moving from one version of antlr to the next is not a trivial task, so I (and probably the other users of antlr 4.7), would like to avoid that.
> > >
> > > You mention that "The 4.x versions are available as OSGi bundles" 
> > > (https://github.com/eclipse-orbit/orbit-simrel/commit/85f7256abe6b90f023de4bfabb09f1416f100a67). What does that mean?
> > >
> > > Now, what I'm planning to do for Acceleo is to retrieve antlr from 
> > > the older orbit (2023-09), so there will remain older versions of 
> > > that dependency in 2023-12 RC1.
> > >
> > > With how orbit looks now, what is the expectation for dependencies 
> > > such as antlr which are not easily updateable? How do we re-add older 
> > > versions if we need them?
> > >
> > > Regards,
> > > Laurent
> > >
> > > Le 17/11/2023 à 11:46, Ed Merks via cross-project-issues-dev a écrit :
> > > > I now have a first hit list.  Old guava versions will be eliminated:
> > > >
> > > > https://github.com/eclipse-simrel/simrel.build/issues/80
> > > >
> > > > If you do not eliminate all dependencies on older versions of guava 
> > > > via an updated contribution, then I reserve the option, and am 
> > > > likely to excise the option, to disable your contribution, without 
> > > > further notification.
> > > >
> > > > _______________________________________________
> > > > 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
> > > --
> > >
> > > *Laurent Goubet*
> > > Consultant
> > > +33 2 51 13 51 42
> > >
> > > <https://www.obeo.fr/>
> > >
> > > 7 Boulevard Ampère - Carquefou - France
> > > *obeo.fr* <https://www.obeo.fr/> | *twitter* 
> > > <https://twitter.com/obeo_corp> | *linkedin* 
> > > <https://www.linkedin.com/company/obeo>
> > >
> > >
> > > _______________________________________________
> > > cross-project-issues-dev mailing list
> > > cross-project-issues-dev@xxxxxxxxxxx
> > > To unsubscribe from this list, visithttps://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, visithttps://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