Ed,
Thanks for the additions which make sense.
It probably will need some updates/additions (i.e adding the
maintenance P2 repo) as soon as I decide to the final organization
of our P2 repositories.
Cheers,
Adolfo.
El 12/01/2011 11:06, Willink, Ed escribió:
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|