Ok, I missed this one :)
thanks for the clarification.
Grégoire's question is pretty valid and can look quite cubersome for
every project but in fact there is a simple and easy way : one can get
the updated list of update-sites looking into the indigo.b3aggr model.
We could also generate an HTML report aggregating all the used URL's
now that we have a model for the build ? I won't even need one hour to
come up with a standalone java app doing that... If you tell me you can
easily add this Java app to the aggregation process I'll provide one.
Cédric
Le 07/01/2011 19:21, David M Williams a écrit :
> Any opinion ?
I have one ... as always :)
It is a bad idea to rely on the staging repo, to
contribute
to the staging repo. For several reasons. The largest is that then,
practically
speaking, you build-in a dependency on _everyone_, even if you do
not have a code dependency. That is, the staging repo is sometimes
delayed
or broken for a few days due to some project not being right ... then
once
its fixed, maybe broken due to another project ... even if all the ones
you actually depend on are ready, they may not be in staging yet. (And,
while one project may think ... well, I can wait an extra day or two,
imagine
if everyone did that! :) There's other reasons too ... such as
everything
you need may not be there. That's certainly the case with Orbit
bundles.
But, we all know the dependency chain and timing
is
complicated. I suspect who ever solves it will be up for a Turing Award
:)
But in the mean time, it is being discussed some
in
bugs such as bug
332942.
As another tip, in general, I'd encourage release
engineers (if not everyone) to look to your pre-peq projects to provide
a "zipped p2 repository" ... then, after downloading once, you
can often build over and over again, without the HTTP overhead. If your
pre-req projects do not provide one, you should open a feature request
for them to. Much more efficient overall. For example, EMF provides one
named something like emf-xsd-Update-${emfandxsd.id}.zip,
where 'emfandxsd.id' is the specific build identifier. (Another tip ...
you'll want to build in variables where you can for only those parts of
URLs that change week-to-week :)
One advantage to the zipped repo approach is that,
as far as I know, these always contain one and only one version of what
you need ... so you know once your build works, it will continue to
work
with that zipped repo. I do not know the details or policies of many of
those projects listed in Gregoire original note ... nor do I know
exactly
how Gregoire is pulling from them ... but there is a risk that if you
simply
get "the latest" from a general repo URL such as
http://download.eclipse.org/birt/update-site/4.0-interim/
then "the latest" may not be what you were
expecting. Even if you ultimately do want "the latest", it might
break you at a time you couldn't afford to be broken, or something.
[Oh,
that remind me of another danger of relying on 'staging' ... while you
may get want you want "just in time", you might also be broken
"at the last minute", and you really should have those things
worked out in advance of contributing to the common repo].
Well ... enough of my opinions :) ... others have
had good advice too and I'm sure will continue.
I really think it is a good idea for Gregoire to
explicitly
clarify all the repos he is using and needs. Normally this would be
done
on a project-to-project communication channel, but I can see why
cross-project
list was used for MoDisco ... it appears they use just about everyone
else!
:)
Thanks,
From:
Cédric Brun
<cedric.brun@xxxxxxx>
To:
cross-project-issues-dev@xxxxxxxxxxx
Date:
01/07/2011 11:12 AM
Subject:
Re:
[cross-project-issues-dev]
MoDisco's dependencies
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
Hi,
would that appear like an heresy to retrieve all these bits from the
indigo-staging repository instead of each individual repository ?
It would make your build way simpler + you would be sure that what you
provides in indigo staging has been built with the other indigo
components..
Any opinion ?
Cédric
Le 06/01/2011 20:32, Grégoire Dupé a écrit :
> Hello,
>
> I’m one of the committers of MoDisco.
>
> The build of MoDisco depends of the following projects: Birt, CDO,
Datatools, EMF Compare, EMF, EMF Query, EMF Validation, M2M ATL, M2M
QVT
OML, Acceleo, Jet, MDT OCL, MDT UML2 Tools, Mylyn (WikiText), TMF
Xtext,
Orbit, Eclipse (EP).
>
> And as MoDisco is in the release train, we need to build with the
right version of each project. To check that and to avoid getting
problems
only the day of the milestone build, we have connected our nightly
build
on the following update sites:
>
> Birt: http://download.eclipse.org/birt/update-site/4.0-interim/
> CDO: http://download.eclipse.org/modeling/emf/cdo/updates/4.0-milestones
> Datatools: http://download.eclipse.org/datatools/downloads/drops/M_updates_1.9
> EMF Compare: http://download.eclipse.org/modeling/emf/compare/updates/interim/1.1/
> EMF: http://download.eclipse.org/modeling/emf/emf/updates/2.7milestones
> EMF Query, EMF Validation: http://download.eclipse.org/modeling/emf/updates/milestones/
> M2M ATL: http://download.eclipse.org/modeling/m2m/atl/updates/milestones/3.2/
> M2M QVT OML: http://download.eclipse.org/modeling/m2m/qvtoml/updates/3.1.0/milestones/
> Acceleo: http://download.eclipse.org/modeling/m2t/acceleo/updates/milestones/3.1
> Jet: http://download.eclipse.org/modeling/m2t/updates/releases/
> MDT OCL: http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0
> MDT UML2 Tools: http://download.eclipse.org/modeling/mdt/updates/milestones/
> Mylyn (WikiText): http://download.eclipse.org/tools/mylyn/update/indigo/staging
> TMF Xtext: http://download.eclipse.org/modeling/tmf/updates/
> Orbit: http://download.eclipse.org/tools/orbit/downloads/drops/S20101014084557/repository/
> http://download.eclipse.org/tools/orbit/downloads/drops/S20101204061544/repository/
> Eclipse (EP): http://download.eclipse.org/eclipse/updates/3.7milestones/S-3.7M4-201012081300
>
> We suppose that those update sites always contain up-to-date
versions
of the needed projects, in order to detect build issues far before the
milestone build weeks. Can the releng engineers confirm us that we pick
up the right ones?
>
> Thanks in advance,
> Gregoire Dupe
>
> _______________________________________________
> 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
|