[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[mdt-ocl.dev] Build feature progress
|
Hi Adolfo
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.
That seems very sensible and what we want.
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).
I favour b). You could look at MWE2 where for Helios there were three
builds mwe, mwe2, mwe2-lang. Two of these now combine and they all
appear on the same build sub page.
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...
If you install from update ZIPs you find we currently offer
"OCL Extender SDK"
Ugh! what are we extending and what might you use for less extension?
A really bad name. I trust that it will vanish.
Regards
Ed
