[
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
|
Is there a definitive wiki page that lists _exactly_ what needs to be in these repos we are discussing? A canonical file system listing would be quite useful. I find it hard to follow when there are assumptions on specific tooling usage..
cheers,
jesse
--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx
On Fri, Apr 2, 2010 at 14:17, David M Williams
<david_williams@xxxxxxxxxx> wrote:
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.
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev