El 09/02/2011 17:08, Ed Willink escribió:
Hi
Adolfo
I started build 221 to pick up my commits that make Complete OCL
editor useable.
Hudson shows no sign of these CVS changes.
Build 221 got stuck on a final 'mv'. Maybe a diskspace issue.
Build 222 got stuck even earlier; maybe a hudson slave 1 issue.
Three funnies!
Yeap. I've been trying to find a proper machine on which make our
builds run. I guess it's a server problem since there are a lot of
jobs trying to build. Let's see what happens tomorrow...
Also we should set a timeout at twice normal running to avoid
hogging a slot.
I did that this morning.
BTW, Now that M6 has started I want to do some experiments
concerning Core + Tools jobs, so that in +1 time frame we only
create Core artifacts and in +3 time frame we create Tools
(currently examples) artifacts.
However, I have a couple of questions/doubts (ideas :D ) which may
need consideration, specially when publishing artifacts:
1. Separating Core from Tools. The idea is the following:
In principle, every repository (nightly, interim, milestones, etc)
would be a composite repository which composes a "CORE" repository
and "TOOLS" repository. The CORE repository would contain what we
know as OCL SDK [1] which will be generated by a first build. The
TOOLS repository would contain the Examples feature, which will be
generated by a second build. Therefore the Eclipse Release Train
would be feeded by the correspodent repository (i.e milestones
repository for M1, M2, M3, etc) so that it may find both the OCL
SDK and the OCL Examples features via the composite repository.
2. Creating incremental builds. The idea is the following:
In principle, every repository works as it has been wornking so far.
In a first build (+1) only OCL SDK is built. In a second build (+3)
OCL All-in-one (OCL SDK + Examples [1]) is built so that the content
of the generated repository will replace the content from the first
build.
In both cases I'll have to manage to create downloadable zips from
the downloads web page. The only difference is that "Core" builds
won't provide downloadable examples zips. We will probably proper
need a build alias when creating milestones and release candidates.
Some ideas:
a) 3.1.0M6 (in +1) and 3.1.0M6a (in +3).
b) 3.1.0M6-Core (in +1) and 3.1.0M6-Tools (in +3).
It looks like the idea 2 could be done quicker, and probably without
any undesirable surprise (For instance, when trying the idea 1, I'm
not sure If I'll be able to produce all the expected downloadable
zips: Update, SDK, Core SDK, etc If I only want to generate a p2
repository with the examples).
Finally another idea to consider is using "OCL Core SDK" instead of
the "OCL SDK" to use in the build scheduled at +1. It's lighter and
it's only what downstream projects need. In +3 everybody will have
the remaining stuff available...
[1] http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization
Best Regards,
Adolfo.
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|