1. We considered changing this for EMF too, since "repository" is a more appropriate terms than "updates"... but I've been waiting on the platform to change their URL and then follow their lead.
2. I think this is what the old "interim" repositories were/are used for, in addition to integration builds. In EMF we are putting interim maintenance builds in our milestones repository.
Thanks for your feedback. An interesting bug which I was not aware
of... Despite the fact I was included in it some months ago...
>.<
I'll try to fix all toguether tomorrow.... just wondering a couple
questions:
1.- Any opinion about the use of the word "repository" rather than
"updates" ?. I believe that is a proper name for the URL. However, I
guess that changing things unnecessarily is not usually welcome, so
four possible answer here:
a) "repository" doesn't look like a good idea, forget any chance to
change that
c) "repository" looks like a good idea, but we all should use the
convention without bothering anybody elese...let's go on using
"updates"
c) "repository" looks like a very good idea, so feel free to use it
for the "MDT/OCL" P2 repository.
d) "repository" looks like such a good idea, that all modeling
project could probably adopt it !!!... Let's talk about it in the
next PMC call.
2.- Does make sense any repository for placing software which comes
from the current-in-development maintenance branch? something like http://download.eclipse.org/modeling/mdt/ocl/repository/maintenance
a) "a maintenance repository" doesn't look like a good idea, forget
any chance to change that.
b) "a maintenance repository" looks like a very good idea, so feel
free to use it for the "MDT/OCL" P2 repository.
c) "a maintenance repository" looks like such a good idea, that all
modeling project could probably adopt it !!!... Let's talk about it
in the next PMC call.
Cheers,
Adolfo.
El 13/01/2011 16:09, Kenn Hussey escribió:
What you've proposed for your repository organization
looks fine. There is indeed trend to move away from project
"roll-up" repositories (e.g., the ones for MDT) in favour of using
the composite Modeling repositories (http://www.eclipse.org/modeling/updates/*)
instead. You'll need to request updates to the composite Modeling
repositories when the time comes (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=314388).
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:
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).
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...
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.
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:
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.
- 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.
- 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.