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

Hi Team,

I added some information for discussion to bug 307804 from the IBM team responsible for consuming the repositories produced by the Eclipse teams. Their group has done some extensive investigation, and decided that they cannot use pack2000 for products consuming the Helios release. For this reason they are asking me to make sure any p2 sites I want them to use provide jars.

Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager
IBM Rational Software: Aurora / Modeling Tools
Phone: 613-270-4613



Inactive hide details for Thomas Hallgren ---2010/04/01 04:44:39 AM---Hi David,Thomas Hallgren ---2010/04/01 04:44:39 AM---Hi David,


From:

Thomas Hallgren <thomas@xxxxxxx>

To:

Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

Date:

2010/04/01 04:44 AM

Subject:

Re: [cross-project-issues-dev] Clarification of repo requirements for projects participating in Helios




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


GIF image

GIF image


Back to the top