Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] MoDisco's dependencies

one can get the updated list of update-sites looking into the indigo.b3aggr model.

That's already what we are doing for MoDisco : I update (manually) the MoDisco build configuration before each milestone to refer to the same update sites as the indigo build model. But the limitation with the indigo build model is that it references only milestones update sites that will be updated only a few hours before the deadline. We would like to be able to do "warm up" builds ahead of time, with the near-final artifacts of each project. For this, we should depend on integration update sites instead.

On Mon, Jan 10, 2011 at 11:40 AM, Cédric Brun <cedric.brun@xxxxxxx> wrote:
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


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx
nbros.mia@xxxxxxxxx
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :.

Back to the top