Hi Team,
Firstly, sorry for the delayed response. I had the last Friday off
because I'm moving to a flat, and I haven't had any access to Internet
until Yesterday's night (I don't have Internet in the new flat yet). I
also have this week off as holidays, in which I mainly wanted to
complete the moving. However, giving the circumstances, I'll also be
working on our builds to have MDT/OCL ready in time.
Let's see what we have in hands:
David has recently updated the Agenda with the Service Releases (And
Indigo milestones) schedule :
http://wiki.eclipse.org/Helios_Simultaneous_Release#Milestones_and_Release_Candidates
An Helios SR RC1 this Tuesday (10th August).
An Indigo M1 next Monday (16th August ).
The point is that my buckminster's progress is currently stopped. I
filed a bugzilla last Thursday https://bugs.eclipse.org/bugs/show_bug.cgi?id=321857
which has not replied yet. I'll try to do some tricks during this
afternoon (for instance, placing the buckminster ocl-build.properties
file in accesible place) to workaround the issue, however, If I don't
have access to our job's workspace I suppose that new errors will arise.
So, my proposal to accomplish, at least, the Helios SR "warm up" is
using Athena's build system as we did for Galileo. I'll do some
investigation since I haven't done any maintenance build, but I think
Alex's scripts and hudson jobs are ready to create such a build. The
tasks involved will be:
- Create a branch for the maintenance release 3.0.1 ->
R3_0_maintenance.
- Increase every plugin/feature version number to 3.0.1.
- Build a Maintenance Release (I guess I'll need to do some
configuration setup, for instance to point the maintenance release to
the new created branch)
- Promote the build.
- Change the Helios b3aggr file with the new versions of
plugins/features.
Regarding Indigo, let's see if I get some support from hudson's team
during this week. In the worst case, we will be able ti do the same as
we have to do for this SR "warm up"
P.S: when working on this, I'll also be connected via skype which is
more helpful than email/newsgroups (giving the circumstances). I have
all you, Ed, Alex, Laurent, even Stephane (he is in vacation, though)
and Kenn (who is coming back from his vacations, as I read in an other
email). Any comment/help about this, would be appreciated if it's via
Skype.
Cheers,
Adolfo.
El 06/08/2010 8:21, Ed Willink escribió:
Hi Adolfo
It looks as if David's tooling may have done the conversion for us.
I hope you can get things in place to participate in this warm up.
Regards
Ed
-------- Original Message --------
Ready for Helios SR1 builds?
As we've planned, we have a "warm
up" Helios SR1 build coming next week. See
http://wiki.eclipse.org/Helios/Simultaneous_Release_Plan#Milestones_and_Release_Candidates
We call it "RC1", but it is
not truly a "release candidate", that is, lots of fixes remain,
and we don't
recommend adopters or users spend
much
time doing early testing, since lots will still change.
It is, though, a good test for
ourselves,
that we all remember how to do builds, update our .build files, create
packages,
etc.
.... and file format change?
Especially now, this cycle, since we
no longer have .build files!
Instead we have b3aggrcon files. No
one complained when I
proposed we switch for SR1,
so
I've done that switch
now, just this evening. While this
will
require some of you to react on short notice ...
those of you who automatically
create
or update .build files .... it is advantageous to do this conversion
now
since
1) the b3 aggregator basically does
it automatically under the covers for us each build,
2) having in native format allows us
to use the b3 aggregator editor, and
3) the b3aggr files can be copied
and
used as the initial input for our Indigo set of files.
Simply sync up, or check out
'org.eclipse.helios.build'
and you'll see the new files (and the old ones deleted).
For more history, see bug
312645 ... I quote the
concluding
comment below, for maximum communication of
"how to" information.
As always, questions welcome, and
don't
hesitate to say (or open bugs) if something has gone wrong with the
conversion.
Thanks all ... especially to Filip
and
Thomas for providing the b3 aggregator and helping me use it. It'll
make
all our
lives easier, now that we have the
native
format, and can use the b3 aggregator editor directly in IDE which can
often
spot problems with files or repos
"live",
in IDE, before the contribution is checked into CVS.
= = = = = =
<quote>
Just in time for Helios SR1 warm up,
I have converted all the .build files to the "native" b3 aggregator
format so I
will count this as fixed. The conversion went smoothly and the first
build
worked, see https://build.eclipse.org/hudson/job/helios.runAggregator/239/
Naturally, will need to be confirmed by those providing content, but at
least
the build itself went fine.
The 'helios.build' file was automatically converted to 'helios.b3aggr'
file by
b3 aggregator (in the IDE -- its always been doing that, during batch
builds).
>From there, there is a function where each contribution was
selected in
aggregator editor, and "detach resource" ran. I gave each contribution
a file
name similar to what it had, but with a .b3aggrcon extension, instead
of
.build
See http://wiki.eclipse.org/Eclipse_b3/aggregator/manual
for more information
about b3 aggregator.
In general, projects can contribute (edit) .b3aggrcon files that only
change
version
numbers of features or repository location URLs, but editing of things
like
categories, contributors names and email addresses, or even adding or
removing
features should be done by using the aggregator editor on the main
helios.b3aggr file, which will update all relevant files related to
those
changes.
If needed for comparison, or reverting!, I tagged
org.eclipse.helios.build and
org.eclipse.helios.tools with
v201008060015preconversion
<quote>
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
