On Mon, Feb 27, 2023 at 3:09 PM Michael Keppler <michael.kepp...@gmx.de> 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? Same problem happens with Orbit usage only if e.g. project A builds against Orbit X and project B builds against Orbit Y aggregation will contain multiple different versions of a dependency. So this is not a new issue at all. > 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@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- Aleksandar Kurtakov Red Hat Eclipse Team
_______________________________________________ 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
