Dev environment for multiple Ant-based projects

[Jeff Turner <je...@socialchange.net.au>]

Hi all,

I was wondering, how do most people manage their CLASSPATHs and shell
environment in general when working with multiple Ant-based projects?
I've assumed *nix here, but the question applies to all platforms.

In a standard Ant-based project, you've got:

 - build.(sh|bat) in the project root
 - the code you're working on in src/*
 - the jar files necessary to build in lib/* and perhaps
src/classes/WEB-INF/lib/*

Now to do the usual code-compile-debug cycle, it would seem that you
either have to:

 - keep jumping between your source directory and project root, eg
    $ vi Foo.java
    $ cd ../../../../../
    $ ./build.sh
    $ cd src/WEB-INF/classes/bar/baz

 - or preset your CLASSPATH to include the source root, and stuff in
/lib and WEB-INF/classes/lib, and compile in the source directory.

I suspect most people choose the second option. This breaks the clean
notion of everything going through Ant, and puts the burden of
CLASSPATH maintenance on developers instead of the build system.
Developers can no longer jump between projects without first fixing
their CLASSPATH.

One could of course have a universal CLASSPATH with all possibly
useful jars, but that's a headache to maintain, especially when
different projects need different versions of the same jar.


Anyway, a solution I came up with was to have a .projrc file in each
project root, and to invoke a new shell which uses .projrc. The new
shell provides an environment where project-specific CLASSPATHs,
aliases and whatnot can be set, and cleanly unset when the developer
stops working, or switches to another project.

Currently, the .projrc sets the CLASSPATH, sets $HOME to the project
root, and creates an alias 'cdc' to the working code directory. Most
of the work is done in a global /etc/projrc file. If anyone wants to
play with it, the files are attached.

--Jeff

Dev environment for multiple Ant-based projects

[tc...@lisa.com.au]

Jeff Turner writes:
[znip!]
We have come to a similar solution, but we don't make it as automated
as you do. Each project has a script called environment.sh (or
something similar). The developer is then required to set any
variables which may not have sensible defaults, and then

source environment.sh

They can then do as they will. If they want to set up their .bashrc
with the correct 'export's and 'source's then that's up to them.

Regards
Tom

Re: Dev environment for multiple Ant-based projects

[Jeff Turner <je...@socialchange.net.au>]

Conor MacNeill wrote:
> 
> > From: jeff@new-smtp1.ihug.com.au
> >
> > Hi all,
> >
> > I was wondering, how do most people manage their CLASSPATHs and shell
> > environment in general when working with multiple Ant-based projects?
[snip]

> 
> My classpath contains just Jaxp bits at the moment. In all our projects the
> classpaths necessary to compile the projects are setup in the build file
> itself. Have you considered using two windows?
> 
> In my own setup, my editor takes care of invoking ant. My cycle goes
> something like
> 1. make a change to the code.
> 2. click a button in the editor to run ant in the project root.
> 3. Get ant output in an editor window.
> 4. click on any errors.

Neat :) How does your editor script know where the project root is
relative to the current working directory?

As an offtopic-but-useful tip, you can get vim to handle jikes output
by adding:

set makeprg=jikes\ +E\ %
set efm=%f:%l:%*\\d:%*\\d:%c:%m

to your .vimrc, and then typing ":make" to compile.

> 
> One of the issues is whether ant will need absolute file references. You can
> eliminate these entirely by using the classpath - your classpath contains
> all the absolute locations (such as jars).
> 
> Personally I am not too worried about having absolute references in ant. I
> do try to keep them out of my build file though. I usually just isolate them
> to a locations.properties file. For example, we use JUnit. In my
> locations.properties file I specify a property junit.home and then in ant I
> just refer to ${junit.home}/junit.jar.
> 
> The properties are set with the following
>   <property file="${user.home}/locations.properties"/>
>   <property file="locations.properties"/>
> 
> With the current no-override behaviour of ant, this means that the project's
> locations are only used if not set by the user.

I'd never realised that property elements could refer to files. The
above sounds like a very useful technique; thanks for pointing it out.


--Jeff

> In the end it is probably similar to your solution but works within ant.
> 
> Conor

RE: Dev environment for multiple Ant-based projects

[Conor MacNeill <co...@cognet.com.au>]

> From: jeff@new-smtp1.ihug.com.au
>
> Hi all,
>
> I was wondering, how do most people manage their CLASSPATHs and shell
> environment in general when working with multiple Ant-based projects?
> I've assumed *nix here, but the question applies to all platforms.
>
> In a standard Ant-based project, you've got:
>
>  - build.(sh|bat) in the project root
>  - the code you're working on in src/*
>  - the jar files necessary to build in lib/* and perhaps
> src/classes/WEB-INF/lib/*
>
> Now to do the usual code-compile-debug cycle, it would seem that you
> either have to:
>
>  - keep jumping between your source directory and project root, eg
>     $ vi Foo.java
>     $ cd ../../../../../
>     $ ./build.sh
>     $ cd src/WEB-INF/classes/bar/baz
>
>  - or preset your CLASSPATH to include the source root, and stuff in
> /lib and WEB-INF/classes/lib, and compile in the source directory.
>

Jeff,

My classpath contains just Jaxp bits at the moment. In all our projects the
classpaths necessary to compile the projects are setup in the build file
itself. Have you considered using two windows?

In my own setup, my editor takes care of invoking ant. My cycle goes
something like
1. make a change to the code.
2. click a button in the editor to run ant in the project root.
3. Get ant output in an editor window.
4. click on any errors.

One of the issues is whether ant will need absolute file references. You can
eliminate these entirely by using the classpath - your classpath contains
all the absolute locations (such as jars).

Personally I am not too worried about having absolute references in ant. I
do try to keep them out of my build file though. I usually just isolate them
to a locations.properties file. For example, we use JUnit. In my
locations.properties file I specify a property junit.home and then in ant I
just refer to ${junit.home}/junit.jar.

The properties are set with the following
  <property file="${user.home}/locations.properties"/>
  <property file="locations.properties"/>

With the current no-override behaviour of ant, this means that the project's
locations are only used if not set by the user.

In the end it is probably similar to your solution but works within ant.

Conor