On Fri, Nov 27, 2020 at 9:54 AM Ed Merks <ed.me...@gmail.com> wrote: > There is a big size difference between the *.jar versus the *.xml.xz, > especially for the content.jar/content.xml.xz: > https://download.eclipse.org/justj/?file=releases/2020-12/202011271000 > We'd not want to lose that I think, because this has a significant impact > on the server traffic... > OK, I'll investigate that. I'm confident we can easily have .xz back in a way or another.
> Because of that separation, goodness knows if what think I contribute will > really come from my repo and not some other repo. [...] E.g., when I > contribute Oomph, I *do not *contribute the http client bundles (as an > example). I do it that way so that I don't contribute conflicting or older > versions of those things. > If I'm not mistaken, current aggregator has never guaranteed anything about provenance and does some dependency resolution against *all* repos already. I'll work on an example to prove me wrong or false and report the results and example. That will either strengthen or invalidate this argument. > But what stops the Tycho resolution mechanism from grabbing potentially > older the ones from the Oomph repository anyway? Nothing I think... > Nothing indeed, unless some other requirements enforces a specific version of the artifact in its dependency chain. But as mentioned, I believe it's the same for current aggregator already. More details to come next week. > I also wonder too if the two different implementations (resolution > algorithms) use to build the repositories really do actually produce the > same repositories? > They're both relying on p2 director so there shouldn't be a too big difference; but we'll diff the output. > The Planning Council ought to speak out and the simrel participant > opinions (if any one has one!), ought to be considered too. > I agree. However, I think there are still technical questions that need an answer before we require Planning Council to voice an opinion.
_______________________________________________ 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
