[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [europa-build-workshop] Common Build Infrastructure
|
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
