Sam Ruby wrote:
>
> Jason van Zyl wrote:
> >
> > I have personally started using an installed version of
> > Ant and I place all the jars I need for building in the
> > $ANT_HOME/lib directory. I have actually found this to
> > be a lot easier when building multiple projects.
>
> Instead of actually copying jars, what many Jakarta projects are moving
> towards is
>
> <property file="build.properties"/> <!-- Component local -->
> <property file="../build.properties"/> <!-- Commons local -->
> <property file="${user.home}/build.properties"/> <!-- User local -->
>
> With a properties file that looks something like:
>
> # -------------------------------------------------------------------
> # EXTERNAL DEPENDENCIES
> # -------------------------------------------------------------------
>
> # junit.jar -- JUnit classes (http://junit.org)
> junit.jar=/java/junit/junit.jar
>
> # sax2.jar -- SAX 2 classes (http://megginson.com/SAX/)
> sax2.jar=/java/sax/sax2.jar
>
> # j2ee.jar -- J2EE classes (http://java.sun.com/products/j2ee/)
> j2ee.jar=/java/j2ee/j2ee.jar
I haven't tried this method but I will give it a whirl and see
what I think.
> For what it's worth, I go a step further and use Gump for my daily
> development. Instead of a properties file, there is a small XML file per
> project which describes either where to find the project or how to build
> it. You can find an example at:
>
> http://jakarta.apache.org/builds/gump/latest/project_jakarta-turbine.html
>
> If you look at it you will see that it depends on the velocity project
> definition (done externally), optionally will make use of freemarker if it
> is availalbe, and contains a self-contained definition of XML-RPC -
> including a reference ot the jar inside of the CVS. This particular
> project definition even contains the definition for a second buildable
> project, namely torque.
>
> The way this works is that Gump has a generation step that consumes all of
> these definitions and builds a single consolidated script for you - right
> now this can be done either as a shell script, a batch file, or an Ant
> build.xml. At the moment, these three have slightly different
> functionallities. In the case of the batch file or shell script, what I
> can do is:
>
> build jakarta-turbine
>
> Which will build jakarta-turbine with the default target. Optionally, I
> can add Ant options and targets, thus:
>
> build jakarta-turbine -verbose -Doptimize=on package
>
> Scripts are also generated to update projects which come from cvs. In a
> single command, you can update all of the sources to the projects you are
> interested in, either by name:
>
> update jakarta-velocity jakarta-turbine
>
> Or simply specify all
>
> update all
>
> The all "target" also works for the build script, and has a nice additional
> feature that it produces a web page that summarizes all of the results.
> Early on inthe development, I build a small script which would invoke "gen
> && update all && build all" which I named "guba", from which ulitmately
> Gump got its name.
>
> There are other aspects of Gump that I have not touched on - for example,
> the definition of a workspace which describes overall which projects you
> are interested in, global options, and repository defintions. And a
> profile which describes a common set of projects definitions that a
> workspace can draw from.
>
> > I have always liked having jars in CVS for ease of
> > use, but I think that if for every project I built
> > kept all required jars in CVS I would have 50 copies
> > of Ant and Xerces lying around. Until something like
> > CJAN is working I wouldn't want to remove all the jars.
> > But I think moving in the direction of removing jars
> > from CVS and using something like CJAN is the right
> > way to go.
>
> Putting jars in CVS optimizes for the use case of a developer who is
> interested in only one project or a small set of independent projects.
> This is an important use case.
>
> CJAN certainly has a role for people who simply like to install software
> and run with it. But as Java requires a compilation step - something that
> CPAN users don't have to deal with, I suspect that many Java developers
> will prefer to get source.
>
> Jason, if you are building dozens of projects, I would be interested in
> your feedback (in words or patches) on some of the ideas in Gump.
I am building many projects and I did try gump, but rapidly became
irritated with having to hand edit the workspace file everytime you
made updates. I sent a rudimentary patch so that I could try to build
the TDK with gump but they weren't integrated. You started making
the profile some what more portable when the same patches were
integrated into AntGump.
I also find the xsl almost impossible to look at, I simply
don't like all the logic in the xsl. Some like it, which is fine but
I can't look at it and therefore trying to modify Gump or trying to
fix it became difficult for me.
What I am most interested in now is a set of DTDs for the profile,
projects,
and repositories. I eventually figured out what tags were available
and am using a Java based tool that I call maven that uses Velocity
to generate ant files. Basically a profile is mapped into a Java object
and then I use a dependency engine that geir whipped up for me to
figure everything out.
What I really want is to be able to have someone download a profile
for the TDK and easily build it so that many turbiner's can start
testing standard apps. Maybe gump is better at this now, but earlier
using the xml workspace
was very cumbersome because it was tied to your setup for checking
backward compatibility which is what I saw Gump as. After submitting
my first set of patches and getting no comment and not having them
integrated I wasn't really all that interested in playing with
gump anymore. Then I tried ant gump, but the xsl just throws me for a
loop.
I much prefer dealing with a profile as an object. I have a sub-optimal
xml->java object mapper but eventually if we get some standard DTDs I
can
use something like castor or another mapping tool that can use a DTD.
The other thing I had slated for maven was the ability for each project
to take care of it's own project definition. I'm sure you have the same
plan. I also wanted to make a turbine app out of it to try and make it
simple to maintain the configuration.
I really would like to work together, so maybe the first thing we can do
is get the DTDs going. I really can't deal with XSL, it drives me mad,
and I don't believe it's very maintainable so I don't think I'll be
playing
with gump anymore but we can probably find some common ground.
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://jakarta.apache.org/commons
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
