Hi Adolfo
Forgive my lack of response here. It means very little to me. I'm
glad you're dealing with it.
It seems sensible. My only real comment is, is it compatible with
EMF, is it compatible with migration to shared/aggregate MDT
repositories?
ED
On 11/01/2011 17:07, Adolfo Sánchez-Barbudo Herrera wrote:
Hello all,
Thinking a little bit more on this.... For our public p2
repository we could solve an indirection (composite repo) and the
strange "SR0" doing the following:
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases
(composed by /updates)
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/X.Y.0
(composed by /updates/releases)
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/X.Y.1
(composed by /updates/releases)
- http://download.eclipse.org/modeling/mdt/ocl/updates/releases/X.Y.2
(composed by /updates/releases)
On the other hand, If we wanted to use term "repository" rather
than "updates", I think that the sooner the better (we will need
to announce into cross project mail list, fix the URL in the
features.xml files, etc).
Our public p2 repositories would stay as follows:
-
http://download.eclipse.org/modeling/mdt/ocl/repository ()
- http://download.eclipse.org/modeling/mdt/ocl/repository/releases
(composed by /repository)
- http://download.eclipse.org/modeling/mdt/ocl/repository/releases/3.0.0
(composed by /repository/releases)
- http://download.eclipse.org/modeling/mdt/ocl/repository/releases/3.0.1
(composed by /repository/releases)
- http://download.eclipse.org/modeling/mdt/ocl/repository/releases/3.0.2
(composed by /repository/releases, to appear in feb)
- http://download.eclipse.org/modeling/mdt/ocl/repository/releases/3.1.0
(composed by /repository/releases, to appear in Jun)
Our currently used Inidigo's repositoryes should be redirected to
the new URL:
-
http://download.eclipse.org/modeling/mdt/ocl/updates/milestones/3.0.1
(deprecated, redirected to -
http://download.eclipse.org/modeling/mdt/ocl/repository/milestones )
-
http://download.eclipse.org/modeling/mdt/ocl/updates/nightly/3.0.1
(deprecated, redirected to -
http://download.eclipse.org/modeling/mdt/ocl/repository/nightly
)
Besides, We should also maintain our current Helios public P2
repositories, which should be redirected to the new repositories:
-
http://download.eclipse.org/modeling/mdt/ocl/3_0/updates/
(deprecrated)
- http://download.eclipse.org/modeling/mdt/ocl/3_0/updates/releases
(deprecated)
We must note that both repositories currently have the same
content the P2 repo correspondent to our last Helios SR1. In 25
February, this two URL should be redirected to our Helios SR2: http://download.eclipse.org/modeling/mdt/ocl/repository/releases/3.0.2
Any feedback is welcome.
Best Regards,
Adolfo.
El 10/01/2011 20:20, Adolfo Sánchez-Barbudo Herrera escribió:
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).
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.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus found in
this message.
Checked by AVG - www.avg.com
Version: 10.0.1191 / Virus Database: 1435/3373 - Release Date:
01/11/11
|