Re: [cross-project-issues-dev] [epp-dev] EPP 2023-03 M3

[Christoph Läubrich <laeubi@xxxxxxxxxxxxxx>]

Maven artifacts are not "wrapped" they are used as-is (unless they have 
no OSGi data but then no one would complain to use another centralized 
source). So there will always be one version of the *same* artifact.

Beside that, managing dependencies and keeping up with updates is an 
inherit task of project management, simrel on the other hand is not a 
dependency management tool!

So if one expects to always use the "latest orbit" why not one can 
assume to use the "latest central" version? It is even simpler, just 
select the dependency in the target editor and press the "Update" button 
and you will use the latest version, no need to wait for an orbit 
release, no need to change urls ...


Am 27.02.23 um 14:20 schrieb Christian Dietrich:
> this is known, but it basically says: instead of using 1 orbit create 
> your own orbit.
> work has to be done in each project
>
> Am 27.02.23 um 14:18 schrieb Ed Merks:
> > I sent this note to cross-projects in January on this topic:
> >
> > https://www.eclipse.org/lists/cross-project-issues-dev/msg19562.html
> >
> > On 27.02.2023 14:09, Michael Keppler wrote:
> > > Am 27.02.2023 um 09:30 schrieb Mickael Istria:
> > > > I agree that Orbit duplicating a bundle that exists in a usable state
> > > > upstream can be the root of many other issues. As we have an example
> > > > here that this has a cost to troubleshot, and that there was probably
> > > > a cost in setting up the Orbit clone;
> > >
> > > There is probably a simple reason: Doing the same as before. If projects
> > > are used to consuming from Orbit since many years, they will probably
> > > continue to do so, unless someone basically stops the process for
> > > accepting new Orbit uploads. Quite honestly, even I had the impression
> > > that both using Orbit and Maven directly are perfectly fine, until this
> > > discussion started.
> > >
> > > That being said, I also have one more concern: Orbit simplified many
> > > projects using the same version of a library, by assuming that new
> > > releases would all use the current Orbit update site at time of release.
> > > If every project has a locally wrapped Maven artifact instead, won't
> > > that lead to everyone consuming another version, depending on when that
> > > entry in the target was last updated? Or is there something in SimRel
> > > infrastructure that magically unifies this somehow? As said before,
> > > multiple versions of a library are generally not a problem, unless we
> > > later notice that some Apache Commons library had a binary incompatible
> > > change in a service release (already happened), which is why I would
> > > expect more real world incompatibilities at runtime.
> > >
> > > Any solution to this version mix?
> > >
> > > Ciao, Michael
> > >
> > > _______________________________________________
> > > 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