Hello Team,
I've been doing some work concerning the composite repositories,
since Kenn announced some cool utilities to doing such stuff (see
http://wiki.eclipse.org/Modeling_Project_Builds/Utilities
<http://wiki.eclipse.org/Modeling_Project_Builds/Utilities#manage-composite.xml>).
I've done some progresses, but I would require some feedback to
contrast some conclusions...
Firstly, I would like to obtain some agreement concerning our
retention policy. I created some lines before taking a break:
http://wiki.eclipse.org/MDT/OCL#Retention_Policy
Secondly, starting from this retention policy, for indigo we
currently have the following P2 repositories.
- One Nightly P2 repo:
http://download.eclipse.org/modeling/mdt/ocl/updates/nightly/3.1.0/
- One Interim P2 repo:
http://download.eclipse.org/modeling/mdt/ocl/updates/interim/3.1.0/
- One Milestones composite p2 repo
http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0/ which
composes several P2 repositories
- http://download.eclipse.org/modeling/mdt/ocl/updates/nightly/3.1.0/M2
- http://download.eclipse.org/modeling/mdt/ocl/updates/nightly/3.1.0/M3
- http://download.eclipse.org/modeling/mdt/ocl/updates/nightly/3.1.0/M4
...
- One Releases composite p2 repo
http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0/
which will probably compose several P2 repositories
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0/SR0
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0/SR1
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0/SR2
- Apart from this, I've also created another composite repository
http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/
which composes the
http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0
one, so that we provide a general p2 repo, which composes the the
current development milestones repository.
- Similarly our mdt/ocl/updates (our public P2 repo URL) should be a
composite P2 repo which composes mdt/ocl/update/releases, which again
is another composite repo which should compose:
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0/
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.2.0/
...
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/4.0.0/
As you may realise there are several bits which should need to be
sort out. Let's have some thoughts about the following questions...
- Do we really need to create a version segment (3.1.0) for nightly
and interim repositories since we only provide a unique repository ?.
- Similarly we could also avoid using the version segment for
milestones repositories. If we comply with our retention policy, as
soon as we need to create our first milestone in a development, those
from the previous releases could be removed.
- If our public Indigo P2 repo, which should compose the 3 official
releases (SR0, SR1, SR2) repositories, is desired to be a composite
repo what about if we use 3.1 rather than 3.1.0. The last version
number seems unnecessary.
- Where should the RC P2 repositories reside ?. In the milestones one
?, In the releases one ?.... Since I'm thinking that the releases
repos are our official public release P2 repos, I think that the
milestones p2 repo is the appropriate.
- What about maintenance p2 repos (those interim repos used during
the maintenance stream which are different to the official SR1 and
SR2 releases)?. We could have an specific "maintenance" folder for them.
With all these considerations and taking into account the retention
policy above our different P2 repositories could be structured as
follows:
- http://download.eclipse.org/modeling/mdt/ocl/updates/nightly/
- http://download.eclipse.org/modeling/mdt/ocl/updates/interim/
- http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/
-
http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0
(composed by /updates/milestones. The 3.1.0 segment could be removed
in Indigo+1, since removing now could be risky. it's widely used by
other releng's stuff, )
-
http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0/MX
(composed by /updates/milestones/3.1.0)
-
http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.1.0/RCX
(composed by /updates/milestones/ 3.1.0)
- http://download.eclipse.org/modeling/mdt/ocl/updates/
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases
(composed by /updates)
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.X
(composed by /updates/releases)
-
http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.X/SR0
(composed by /updates/releases/3.X)
-
http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.X/SR1
(composed by /updates/releases/3.X)
-
http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.X/SR2
(composed by /updates/releases/3.X)
- http://download.eclipse.org/modeling/mdt/ocl/updates/maintenance/
-
http://download.eclipse.org/modeling/mdt/ocl/updates/maintenance/MXXXXXXXX
(composed by /updates/maintenance, note that M represents an M-build,
which is an integration build of the current maintenance branch)
-
http://download.eclipse.org/modeling/mdt/ocl/updates/maintenance/RCX
(composed by /updates/maintenance)
BTW, the only reason to provide a composite repository for our public
official release, is to have a unique URL
(http://download.eclipse.org/modeling/mdt/ocl/updates/) from which
you may access the different releases of the MDT/OCL project. This
URL is that one specified in the different MDT/OCL features and it
should not vary as long as new P2 repositories with different content
of different releases arrive. I'm not sure if this makes sense. An
user could always use an specific URL (for instance
http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1/SR2) to
obtain the features of a concrete release (for instance to decrease
the time of loading the content from the repository). I'm not
expertise enough in P2 to have an ideal solution.
Another discussions is if we should use "repository" rather than
"updates" ;P... This decision has already been taken for instance in
Orbit project
Please, let me know if this makes sense, of course I'll have to look
into the releng stuff to check that this may be done without any pain
(I mean, a lot of investment of my time). Likewise, any improvement
in the retention policy and/or how to organize our P2 repositories is
very welcome.
Best Regards,
Adolfo.
El 23/12/2010 19:14, Adolfo Sánchez-Barbudo Herrera escribió:
Hello Team,
After some days working on the releng, here you have a small report
concerning my progress:
1.
https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/
As commented, the buckminster based build is quite stable. However,
the following are topics in which I've been working on:
- The following https://bugs.eclipse.org/bugs/show_bug.cgi?id=332546
bugzilla exposed a problem in our generated artifacts. I've partly
fixed the problem since every required .zip contains both
lpg.runtime.java and lpg.runtime.java.source bundles. However, the
zip which contains the P2 repository (The all in one Update zip)
only contains the lpg.runtima.java bundle and I haven't been able to
make it contain the source bundle one... Still pending.
- Due to the recent request about making I-builds ( to create an
interim p2 repository with bleeding edge stuff) which should be
feeded by the other dependant project (such EMF) Integration P2
repositores, I've configured hudson and the buckminster stuff so
that depending on the build-type (N,I,S) our build will be feeded by
other dependent project Interim/Integration or Milestones P2
repositories. So that
1) When doing an MDT/OCL N or I-build, EMF, UML, ..., Integration P2
repositories will be used.
2) When doing an MDT/OCL S-build (milestone), EMF, UML, ...,
Milestones P2 repositories will be used instead.
- Due to EMF and UML doesn't produce nightly P2 repositories, I 've
decided to revert to our night-build policy so that now our builds
are run when changes are detected in our CVS and they are based on
the EMF and UML Intergration P2 repsotories. I think that it doesn't
make sense doing a nightly build (which may detect incompatibilities
with our dependent projects), if we are not basing our code in some
kind of nightly P2 repository.
- I wanted to try to use some publishing scripts from EMF releng,
which deal with composite repositories and such. However, since Kenn
told me that Mickal is working on them and in its documentation, I
prefer to wait a little bit.
2. https://hudson.eclipse.org/hudson/job/cbi-mdt-ocl-3.0-integration/
- The job has been fixed, which relies on the maintenance branch and
it should be only used to manually create M-builds (and the final
SR2 build)
- I wanted to create a true M-build with updated content (which
means update ocl.map files, etc). However, I want to clarify this
bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=327823 before
doing any kind of tag on our branch.
3. https://hudson.eclipse.org/hudson/job/cbi-mdt-ocl-3.0/
- This build is supposed to use our maintenance branch code to do a
build. Now, it only differs from the previous job that it uses the
"-forceContextQualifier -fetchTag R3_0_maintenance" extra flags, so
that instead of using the ocl.map file the build is feeded by the
last maintenance branch code. However, I've not been able to fix
this job so far (it complains about not finding an org.eclipse.tests
plugin).
- Tomorrow, I'll try to do a deep study of the logs to see what's
wrong. I don't know why this worked with HEAD, and despite being
identical to the integration job definition it doesn't work
neither.... If I don't find a solution tomorrow, I'll probably give
up trying to fix this, and we will only have availabe the manual
launched build using the ocl.map file.
P.D: I'll also add an entry to Alex's cheatsheet concerning the
M-build.
Best Regards,
Adolfo.
