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.
Jeff
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.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=328837
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.
Kim
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:
plugin@xxxxxxxxxxxxxxx.ecore=p2IU,id=org.eclipse.emf.ecore,version=,repository=http://download.eclipse.org/releases/indigo
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.
Scott
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list p2-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/p2-dev
|