Hi Adolfo
Thanks for the extra prod.
Quite good.
Tidied up a few typos/English.
Changed 'forever' to 'for as long as the corresponding
Eclipse platform is available' for releases; who knows what will happen in 20
years?
Trimmed M/RC to the three most recent. Really don't need to
keep M1 during RC4.
Regards
Ed
Ed,
Ok. I guess that, as the project leader, you approve the
retention policy for the MDT/OCL project (http://wiki.eclipse.org/MDT/OCL#Retention_Policy
)
I'm not sure what you mean with "compatible with EMF"...
...Concerning the MDT repository:
On the one hand, our
repository can be a child repository (composed/aggregated by) the MDT one.
However, somebody should ensure that this happens. On the other hand, lately
it seems to be a tendency to remove the MDT "man in the middle". Actually, our
Helios MDT/OCL P2 repository is an independent repository from the the MDT
one, I think that MoDisco P2 repositories is not integrated with the MDT one,
etc
Kenn, as MDT project leader and PMC member could you give us some
feedback about our repositories organization, what we should do regarding the
MDT repository, etc Does all the stuff we are discussing make sense
?
Best Regards, Adolfo.
El 11/01/2011 21:11, Ed Willink
escribió:
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
Please consider the environment before printing a hard copy of this
e-mail.
The information contained in this e-mail is confidential. It is intended
only for the stated addressee(s) and access to it by any other person is
unauthorised. If you are not an addressee, you must not disclose, copy,
circulate or in any other way use or rely on the information contained in
this e-mail. Such unauthorised use may be unlawful. If you have received
this e-mail in error, please inform us immediately on +44 (0)118 986 8601
and delete it and all copies from your system.
Thales Research and Technology (UK) Limited. A company registered in
England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne
Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number:
774298
Thales UK Limited. A company registered in England and Wales. Registered
Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX. Registered Number: 868273
|