Ed,
El 09/02/2011 18:20, Ed Willink escribió:
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.
I'd have bet that you didn't choose the easy way .... Just kidding
;P.... I'm not sure how the downloads can be mixed/combined from
different builds... I doubt I can do that using the current
publishing scripts we are using .... I'll contact MWE team to find
some clues about this.
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.
Maybe it could be a reasonable name for OCL extenders, like the
M2M/QVTo project. Anyway, I don't the name neither... I guess that
nobody will be hurt if we change the feature name ... ¿ "OCL SDK"
?.
Regards,
Adolfo.
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
