| Re: [mdt-ocl.dev] Releng status |
Hello all,
The main problem is that we should keep a p2 repository in the URL defined by our features. Ideally this should be a composite repository which should compose the Helios MDT/OCL 3.0.0 repository and the new Helios MDT/OCL 3.0.1 one. Since I don't know exactly how to do this composed repository (David told me is not difficult, but some "cp" and "mv" command are quicker), I decided to temporarily substitute the Helios 3.0.0 repo by the new Helios 3.0.1. (In any case, I have added to my task list working on this composed repo to improve this temporary trick). I think I've got an idea about why the updates are not working. David told me that udpates only work on "top level features" (EPP Modeling feature, in our case). I suppose that by composition of more specific project repositories the other features are then updated. I believe that our EPP Modeling repository act as an composite repository of other repositories, for instanace, the http://downloads.eclipse.org/modeling/mdt/updates. The problem is that since in Helios the MDT/OCL repository was kept away from the MDT one, now our repository is out of the composition chain. Points to sort out: 1. Our features should require to reference an "stable" (better said "release") repository. This repository should be a composite repository which composes the different repositories of our releases. On the one hand, I've looked at several repositories to see different formats (Window -> Preferences -> Install/Update -> Available Software Sites ) http://download.eclipse.org/releases/helios http://www.eclipse.org/modeling/updates/ http://download.eclipse.org/modeling/tmf/updates/ http://download.eclipse.org/modeling/mdt/updates/releases/ On the other hand, I've looked at other project's features ( EMF and UML) to see which repositories URLS they stablish. They refer http://www.eclipse.org/modeling/updates/ . This makes sense, because they point to an "stable" compose repository which will refer to the different released repositories. However, I believe that our features should point to its own "release" compose repository. There is no need to have a repository which is in_somehow_coupled with the Modeling EPP. I'm also inclined to remove the "releases" segment. It's an extra segment which is not needed for our public repository. Of course, we will internally use the "releases" segment to organize our different repositories (integration, stable, releases, etc), but our unique public repository should be something like as follows http://download.eclipse.org/modeling/mdt/ocl/updates/ which should point to the "updates/releases" which should compose all the released repositories http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0, .../releases/3.1.1/, .../releases/4.0.0 etc A final reflexion is that, the word "repository" is gaining momentum instead of previous "udpate sites". For this reason, I'd also consider using "repository" instead of "updates". The problem is that in Helios, all the repositories use the segment "updates". 2. Make MDT/OCL repository join the Modeling EPP composed repository This can't be done for Helios SR1, I suppose that this could be fixed in Helios SR2 and obviously for Indigo. The first question would be where should the MDT/OCL repository join the composed repository. I remember that Kenn wanted to remove the "MDT man in the middle". So, I suppose this should be for the Modeling EPP repository. The second question is how to do it. As said, no idea about how to do that... 3. What happens with the Indigo's milestones ? should we have any extra consideration ? We will obviously create our repositories in the http://download.eclipse.org/modeling/mdt/ocl/milestones/3.1.0. We will also feed indigos aggregation build with this repository, but do we require extra consideration ? AFAIK no we don't. Our public MDT/OCL repository only compose the "release"s repositories. Thoughts ? Regarding Indigo M2. I'll be on Sunday trying to recover our cbi-integration hudson job. The new hudson server works nicely now, so it will be at least a more "friendly" task. However, If I'm not able to fix the problem during the weekend, I'm inclined to do a "stable" build from our last (and unique) 3.1.0 integration build, in the same way I've created the 3.0.1 R-build from our 3.0.1RC4 M-build. The only problem I think we will have, is that our features will still keep the incorrect repo's URL.I've done minor advances during today. Via bugzillas, I think I know which is the problem about why the integration build is not working in its signing phase. It's about the location where the signing takes places which needs to be a different one (the hudson's workspace can't be used for this task). The problem is that since all the build process is executed from common stuff from org.eclipse.dash.common.releng project, I don't know how to tune this up. I tried to run a local run.sh script (org.eclipse.org/releng/hudson/run.sh) which customized the signing directory (signingDir variable), but this hasn't worked: it's still trying to sign in the job's workspace I'll go on working on this in an hour time. I'm also be pending on the EMF and UML builds, which haven't arrived yet. If I can't finally manage to make the build work tonight, I'll rename and promote our unique Indigo's Integration build, and I'll check that it doesn't create any inconvenience in the Indigos build. Best Regards, Adolfo.
--
|
