Jason van Zyl wrote:
>
> I was wondering what state Gump is in for using on a bunch
> of different machines?
>
> There are 4 of now building the TDK on a regular basis and I
> would like to try and use Gump again for this.
>
> Is it possible to have a setup on a machine that is independent
> of the project definitions?
>
> If this is possible could you give us a hand setting this up?
I think so - and if not, together we can work to make it so. Warning: I'm
travelling next week, so my responses may lag.
Overview ( if you want to follow along, take a look at
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/ ) :
At the top is a workspace. It contains the definition of things that
vary from machine to machine. For examples, take a look at rubix.xml (a
Linux machine) and rubypad.xml (a Windows box). One thing it can
contain is entire project definitions if these are not common (example:
I reference a php build structure on my Linux box, which is optionally
included by cocoon2. Unresolved optional includes are not an error).
It can also contain repository definitions, but I am in the process of
factoring that out - most of this data should be fixed, it is only
typically the user and possibly the path information that changes).
Workspaces can also reference profiles. Profiles are a collection of
projects and associated repository definitions that often are built
together. I have four machines on which I build the gump profile (see
profile/gump.xml), so this contains the information that is common to
all four. Again, more of the repository information should migrate into
here.
Profiles reference projects. By now, you are pretty familiar with what
a project contains: essentially a list of inputs (depends), processing
(ant targets and properties) and outputs (names of the jar files and the
home directory in which they can be found).
Projects may contain nested projects. Essentially the outer most
project corresponds to a cvs module, and the inner projects correspond
to a specific set of inputs/processing/outputs.
How this could work for the TDK:
You said you had four machines. This means that you would have four
workspaces defined. Whereas I bootstrap ant and build village from
source, you may choose not to. Assuming that you don't choose to
bootstrap Ant, you would simply put a project definition for Ant in each
workspace. Now the only thing which is likely to vary is the home
directory so you might want to only have this in workspace, and create a
definition for a release/jakarta-ant.1.3.xml which is referenced by
profile/tdk.xml which contains the rest of the information.
The key is the tdk profile. In it, you simply list references to the
projects and repositories that you wish to include. To get started, you
can simply take the subset of the gump profile that you see as relevant,
substituting definitions which do not contain ant tags for projects
which do not wish to build.
Over time, you can then add more project definitions. If I'm interested
in them (which is highly likely), then they can also be included in the
gump profile.
How to get started:
Checkout out proposal/gump from jakarta-alexandria. Clone rubix.xml or
rubypad.xml and make whatever adjustments you find necessary to gen.sh
or gen.bat. Strip out the parts you don't need, and change the
reference to gump to tdk. Then clone gump and strip out what you don't
need. Then run gen.sh, and you will have produced an update and a build
script, which is copied to the basedir directory specified in your
workspace. Execute "update all" and then "build all".
I'm sure that this will take several iterations to get right, and likely
some questions here, but once you are done you will find that the update
and build scripts can be used for daily development. The update script
will accept a list of projects. The build script accepts a project and
a list of ant options. I mentioned that I have four machines which can
run Gump, but only one of them runs daily. The others I run a full gump
when I want to get up to date, and then only update and build individual
projects. As an example of something I do when I've decided that some
speculative changes I was working on is a dead end:
rm -rf xml-axis
update xml-axis
build xml-axis dist
Future directions:
I mentioned things I intend to do over time above. I am also slowly
converting gen.sh and gen.bat into Java. Initially this will involve
programmatically calling XSLT Transforms, but I've already converted
some of the logic into Java code that manipulates the DOM directly.
Another future direction I would like to explore is to further exploit
the dependency information to produce smarter update and build commands.
Perhaps an "update -r jakarta-turbine" would update jakarta turbine and
all of the projects defined in your profile for which turbine depends,
and a "build -r jakarta-turbine" might build the various dependencies in
the correct order.
This could prove helpful if you want to show others how to build a TDK.
Tell them to checkout gump, clone and tailor your workspace, and then
gen; update all; build all.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
