Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Clarification of repo requirements for projects participating in Helios


The requirement on projects is for consistency and meeting adopters expectations. Some adopters may get things from common repo, but others get directly from project sites. So, best to be consistent, I'd think. You mention the Aggregator but there's no hard and fast rule, currently, that everyone use that, and I'm pretty sure the raw p2 mirror command actually will copy both artifacts.

And, while best to be consistent (between projects and repositories) if Buckminster has been doing this, even in Galileo, and it is too much work to change how its done now, you might be a candidate to ask for an exception for this case. (Anthony Hunter is the Tools PMC Planning rep, you could work through him).

Thanks for your comments, and help.





From: Thomas Hallgren <thomas@xxxxxxx>
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: 04/01/2010 04:44 AM
Subject: Re: [cross-project-issues-dev] Clarification of repo requirements        for        projects participating in Helios
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx





Hi David,
I think it is natural that the Helios repository contain both jars and pack.gz files. But I'm not sure why this should be a requirement on each project? After all, the aggregator sees the individual repositories as opaque things and will never copy the actual jar anyway when a pack.gz file is present (this is managed on low lever by p2). The aggregator will also performs integrity checks on the packed jars (it will unpack them using a Java 1.5 unpacker).

We (Buckminster) currently do not provide the jars when a jar.pack.gz exists (in fact, none of the projects built with Buckminster do). We can of course change this, but I fail to see what the reason for such a change would be. Nobody will ever read jars.

The major problem with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306300 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=305939 was that jars was removed without updating the meta-data. That is of course a major bummer since the repository becomes inconsistent. Another concern expressed in those bugs is that pack200 packed files may be corrupt in some way, either unpackable or packed with a Java version that is too high. The aggregator traps this immediately.

Helios must provide both. That's clear. But why impose this change on the individual projects? Isn't the requirement that the update sites must be consumable by Helios aggregator (and thus, by everyone) enough?

Regards,
Thomas Hallgren


On 04/01/2010 02:23 AM, David M Williams wrote:


As everyone knows, we have a requirement that projects participating in Helios provide optimized p2 repositories to deliver their content.  Due to some innovative advances in builds (see
bug 306300 and its predecessor bug 305939) it turns out there's more choices than we imagined in exactly how people could provide those repositories.

So, the Planning Council agreed some clarification was in order. At the
3/21 Planning Council meeting, it was agreed that, for Helios, a project's repositories must contain original jars, and pack.gz files (where original jar means the jar produced by the build, but which has been conditioned for pack200). And, of course, the metadata describing the content, must be accurate and in compliance with P2's expectations and APIs. While innovation is welcome, the Simultaneous Release also needs predictability, and meeting the needs of adopters. So, a large change like the type of repository provided should be worked though the whole system so all projects can all be consistent, and in agreement about what's needed. Maybe next year?

While sort of a separate issue, thinking about all this got me thinking about the common repository and what we do there, so I have also opened a bug to re-discuss the issue on whether or not we should keep both jars and pack.gz files in the common repository. See
bug 307804.

Comments and questions are welcome,




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top