[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] ECF p2 repos are missing

The URL has to be stable and so does the content.  If the map files identify specific versions in a specific repo (URI) then that repo needs to be at that spot as long as we think that build should be reproducable.  If it is/will not be then we need to rethink our consumption approach.

Keep in mind that with the move to do long-term support we need to be able to rebuild things that are many years old.  That means that the build setup (locations, content, ...) has to be stable.  We do NOT have to maintain every intermediate version that was ever built but all projects need to think very clearly about their repo durability story if their releases are being consumed in a strategic fashion.


On 2010-10-27, at 11:43 AM, Kim Moir wrote:

I've opened a bug to fetch the ECF bundles via p2IU instead of a GET in the map files.


Even with this change, we still require a stable ECF repository URL.  Moving the ECF repository that was consumed in previous releases means that our map files for this release are no longer valid.   In the Eclipse/Equinox project, we archive our old release directories (zips etc)  but retain the p2 release repositories and the associated URL.


Scott Lewis <slewis@xxxxxxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

10/27/2010 09:37 AM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

Re: [p2-dev] ECF p2 repos are missing

Hey Paul,

n 10/27/2010 4:58 AM, Paul Webster wrote:

On Tue, Oct 26, 2010 at 11:23 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
We would like to move to a model where we build all our bundles with our builder, produce a p2 repo, and the ECF filetransfer bundles are consumed by the platform from that repo.  That seems doable to me...as it should be possible for the platform releng to simply read/retrieve the relevant (filetransfer) bundles from out of the repo created by our builder....rather than what we are doing now with map file entries...which is clumsy, error prone all around, and costly for us.

If the platform switches to p2IU map file entries, then they would be able to get either specific versions from a repo, or the latest from the repo ... the URL would still need to be stable, but doesn't have to be as specific (with composite repos) as the curret HTTP GET.  ex:


You could even provide a composite repo specifically for platform consumption.  Promoting a build for the platform to use would just mean mirroring it in.

Sounds great.  Thanks for the clarification.

p2-dev mailing list

p2-dev mailing list