Just to be clear, at this point in time, the Eclipse Foundation wishes
to provide nothing more than infrastructure and infrastructure support
for building.
To this end, I have completed my action item to get the CBI hardware
and environment ready. Build.eclipse.org has been configured as per
Nick's request, so he can start performing Modeling builds on it:
- I installed local instance of the MySQL database
- I configured a web server at http://build.eclipse.org for the
dashboard-esque tools
- I configured an account that the Modeling committers can share.
>From here, I'll work with Nick on isolating the EMFT build components
so that they can be instantiated for projects that request this.
Denis
Pascal Rapicault wrote:
The description of Orbit as a
packaging
step was an image to help get the point across.
In the end a build infrastructure
that
claims to be "common" should be able to deal with these kinds
of plugins (if you rely on pde build this is already handled) without
requiring
any manual script to be written.
Orbit is not jars, it is classfiles
laid down in a repo plus a manifest.mf, so a jar still needs to be
created
(and we want to make sure dependencies are satisfied). Once build,
those
jars should be published on a download page for other projects to
reconsume
(for example the SDK team would use those jars and no longer build ant,
lucene, etc.), which seems to be similar to what you are doing with
emft
3rd party jars.
The Orbit bits should also be
downloadable
individually.
PaScaL
Three comments here, and apologies in advance for
my usual verbosity. ;-)
1. Orbit
While I agree Orbit needs a build, and it's minimal code to
write/maintain... from your description it doesn't sound like a good
test
case since as you say, it's just a packaging step. In fact, assuming
it's
just an ant script to 'grab some jars and put them into a zip or two',
I
could whip that up in a few minutes and contrib it back.... but that
gets
us no closer to a common BUILD infrastructure, unless other builds work
the
same way... eg., assume that a "build" is nothing more than packaging
jars
already present in a workspace. Since most builds are .java ->
.class
->
.jar -> .zip, this doesn't really help. On the other hand... if
Orbit
is
just jars... does it need to even be a build? Why not just a central
repo
for jars? EMFT builds on emft.eclipse.org use a pile of 3rd party jars
just
located in a centrally located directory,
/home/www-data/build/3rdPartyjars, which builds reference by copying
required jars into workspaces/plugins dirs when building or running
tests,
then deleting before packaging. Would that be sufficient, or does Orbit
need to be downloaded or installed?
2. EMFT -> CBI
I've been greenlighted to help turn EMFT's build infra into a CBI that
can
be exploited by other projects, per Denis' note below. I'd be happy to
use
MDT as a testcase - this would be 5 builds under one Modeling
subproject
-
EODM (exists under EMFT), UML2-OCL (exists under EMFT, but requires a
new
namespace), UML2-UML (exists as current UML2), XSD (exists as part of
the
current EMF build and needs to be ripped out), and UML2-TOOLS (entirely
new
build). This might sound overly agressive, but the benefit to this
approach
is that it allows us to take existing builds (eg., EODM using EMFT) and
compare them to new builds (eg., EODM using CBI), to verify things like:
* jar/zip contents match
* build time is same or better
* other build artifacts are equivalent (eg., log files,
test results,
build config files, map files)
I should clarify that I'm not suggesting doing all 5 at once, but rather
one by one (in increasing order of pain) to prove the system is robust
enough to handle these 5 divergent projects' build needs. If it works
for
these, the next step might be to fold in other EMFT projects in order to
verify JDK5.0 support (eg., CDO, Net4j, JET). There's also the
multiple-namespace case presented by EMFT-Transaction
(org.eclipse.emf.{transaction|workspace}). These 4 are all currently
working as EMFT projects, so this step should hopefully be pretty
trivial.
>From there we could start encouraging other projects to get their
stuff
into CBI...
3. EMFT build limitations
Please note also that the EMFT build is not a silver bullet. It's
lacking
in at least two major ways: UI tests won't run [missing .so libraries]
and
Performance tests aren't available [never been set up]. These would be
the
first two things I'd like to see added to an existing build as part
of its
migration from EMFT to CBI. Solving the first is probably just an OS
thing;
solving the second is a little more elaborate (especially when win32
perf
tests are required but the build runs on linux), and could either entail
Derby/Cloudscape, or even MySQL to store and compare results over time.
There's also the issue of .qualifiers increasing for every jar added to
an
UM site, rather than only when contents change, which I know is verboten
but has yet to be fixed, about which Kim's presented some suggestions,
but
I haven't had time to look at yet.
--
Nick Boldt :: Software Developer, IBM Toronto Lab
Eclipse Modeling Framework :: http://eclipse.org/emf
905/413/4308 (t/l 969) :: codeslave@xxxxxxxxxx
Pascal
Rapicault/Ottawa/
IBM@IBMCA
To
Sent by:
Europa Build Workshop
europa-build-work
<europa-build-workshop@xxxxxxxxxxx>
shop-bounces@ecli
cc
pse.org
europa-build-workshop@xxxxxxxxxxx,
europa-build-workshop-bounces@eclip
se.org
10/05/2006 08:52
Subject
AM
Re: [europa-build-workshop]
Common
Build Infrastructure
Please respond to
Europa Build
Workshop
<europa-build-wor
kshop@xxxxxxxxxxx
>
Great, I even have a test case for you! The orbit bundles.
Here is why:
- the foundation is really trying to help on the build front
- the content of orbit spans multiple projects
- no team has stepped up to build those orbit bundles
- the build for those undles is dead simple since it is in fact just a
packaging step
- no coding is required (the foundation can't play the "we can't code"
card
<g>)
In short, it seems to be a perfect fit for the foundation.
Does that sound reasonnable?
PaScaL
Denis Roy <denis.roy@xxxxxxxxxxx>
Sent by:
europa-build-workshop-bounces@eclipse
To
.org
europa-build-workshop@ec
lipse.org
cc
10/04/2006 03:05 PM
Subject
[europa-build-workshop]
Please respond to
Common Build
Europa Build Workshop
Infrastructure
<europa-build-workshop@xxxxxxxxxxx>
Greetings,
With regards to the Common Build Infrastructure [1], I have two action
items:
1. prepare build.eclipse.org for use as a CBI. This includes preparing
a
MySQL database server and a web server
2. determine which route is best and/or available for a CBI: vservers
for projects or using build.eclipse.org
I'm in the process of doing 1. As for 2, I have spoken to The Powers
That Be, and it has been determined that provisioning vservers for each
project is not an option. Building should be done on build.eclipse.org,
as it's a monster machine well suited for the task.
As I understand it, Nick Boldt's/EMFT's current build system has most,
if not all, of the components that can be used by most projects. I
believe we had discussed a mechanism where the EMFT build system could
be instantiated independently for each project, allowing them to
customize their build system to suit their needs. If I did understand
this correctly, then I'd likely work with Nick in
a) creating a snapshot of the build components.
b) creating an installation process to instantiate this snapshot for
projects willing to use the CBI
c) preparing documentation of how it all works
d) running the CBI as a Phoenix component, so that it's transparent
Of course, I haven't spoken to Nick about any of this, but I did try
calling him - and it's the thought that counts. I wanted to put this
out there for you to see that we're making progress, and to gather your
feedback about a CBI. I'll be contacting Nick as soon as he's available
to discuss this option with him.
Denis
[1]
http://wiki.eclipse.org/index.php/Europa_Build_Workshop_Report#Common_Build_Infrastructure
--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx
_______________________________________________
europa-build-workshop mailing list
europa-build-workshop@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/europa-build-workshop
_______________________________________________
europa-build-workshop mailing list
europa-build-workshop@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/europa-build-workshop
_______________________________________________
europa-build-workshop mailing list
europa-build-workshop@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/europa-build-workshop
_______________________________________________
europa-build-workshop mailing list
europa-build-workshop@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/europa-build-workshop
--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx
|
