User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
Kenn, Axel
So... It looks like clearly 1.b) and I'm not sure about 2. ;P
Supposing that we had a buckminter based build for our maintenance
stream (let's say Helios) if I used an EMF "interim" or "milestones"
repository which contains Maintenance (Helios) and Integrarion
(Indigo) artifacts... which EMF artifacts would be used in my
build?... I guess that Indigo's ones since they are more recient, am
I wrong ?
On the other hand, the b3aggr files should be different configured
for Helios and Indigos project... probably feeded by different P2
repositories: milestones/interim for Indigo and maintenance for
Helios.... It's also true that we usually specify the version used,
so we could probably use the same repository .... Well, anyway I
think that it makes some kind of sense using different repositories
.... so if you (or Ed W) are not against the decision MDT/OCL will
use different repositories to distinct artifacts which are used for
the current development (an interim repository) and maintenance (a
maintenance repository) streams.
Cheers,
Adolfo.
El 13/01/2011 18:50, Kenn Hussey escribió:
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.