You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by "Shackelford, John-Mason" <Sh...@ncs.com> on 2002/08/09 17:10:52 UTC
versioning projects with the ant runner
Many moons ago now, I discussed refactoring a large build process (nearly
5,000 line of ant build instructions) with Dominique Devienne who suggested
that I consider writing my own replacement for org.apache.tools.ant.Main.
The recommendation was a good one and using this approach I am to load only
targets applicable to a specific build version (as well as those common to
all build versions) rather than everything at once. This approach
substantially improves performance for me as well as making the whole
project more maintainable.
If the committers are interested I would be happy to work on a patch for
org.apache.tools.ant.Main that would make this functionality more generally
available.
My proposal is to add a command line option to ant: -versionbuild which
would cause ant to look for a properties file on the classpath that has a
"build.version" key which indicates which version of the project to build.
The org.apache.tools.ant.Main class uses this value to do the equivalent of
ant -buildfile build-${build.version}.xml -Dbuild.version=${build.version}.
Each build file can then do entity includes to bring in targets common
across build versions and version specific targets.
Why would anyone want to do this?
Nested build files with <ant> calls work fine for builds that have one (or a
very few) basic path. For more complicated builds that need to expose many
targets for the developer to call from the command line, using <ant> to call
down is impractical since these targets are either not available when
invoking the command line on the top level build file, or else every target
in a child file that needs to be exposed must have a target in the parent. A
third option is to require developers to know which build file to use for a
given target and to call it directly via the -buildfile option--also
impractical when developers are executing some numerous targets scores of
times through out the day.
Combining all targets into one very large build file exposes them all, but
also creates a maintenance headache. The approach many use is to do entity
includes and have separate entity files for each bit of functionality. As a
build matures and needs to support multiple versions of the same
application, these entities naturally segregate targets common to all
versions of the application from those which change from version to version.
One may then easily produce a build file for a new version of an application
by including all the common entities:
<!DOCTYPE project [
<!ENTITY includeBase SYSTEM "buildfiles/common/base.ent">
<!ENTITY includeJUnit SYSTEM "buildfiles/common/junit.ent">
<!ENTITY includeShipPrep SYSTEM "buildfiles/common/ship-prep.ent">
.......
<!ENTITY includeEMS-v32 SYSTEM "buildfiles/v32/ems-v32.ent">
<!ENTITY includeEMS-shrserv-v32 SYSTEM
"buildfiles/v32/ems-shrserv-v32.ent">
.......
]>
&includeBase;
&includeJUnit;
&includeShipPrep;
......
&includeEMS-v32;
&includeEMS-shrserv-v32;
......
I would argue that:
1. Large build systems are not all that uncommon, and will be increasingly
common as time wears on.
2. Having many paths of execution (i.e. exposing many targets to the user)
can be important when ant is used interactively as part of a development
environment.
3. Versioned applications are a universal phenomenon. Reuse of build targets
across versions is not only possible, but probable as a build matures.
4. Typing:
$ ant -buildfile build-${build.version}.xml -Dbuild.version=${build.version}
mytarget1 mytarget2
every time one wants to say:
$ ant mytarget1 mytarget2
is royal pain. Solving the problem with a shell script is not really in the
spirit of ant.
Forgive my long-windedness. If any of the committers are interested I will
generalize the code I've written, integrate it back into
org.apache.tools.ant.Main and provide a patch.
John-Mason Shackelford
Software Developer
NCS Pearson - Measurement Services
2510 North Dodge St.
Iowa City, IA 52245
319-354-9200x6214
shacjo@ncs.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Gmane effect :-) Re: versioning projects with the ant runner
Posted by co...@covalent.net.
I've started using gmane, and it works very well - but sometimes
it has unexpected behaviors, like sending a message after 2 weeks.
My mistake - I forgot to confirm my address for this post.
Beeing able to use a newsreader and not have to receive and
subscribe to dozens of lists is very nice.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: versioning projects with the ant runner
Posted by Costin Manolache <cm...@yahoo.com>.
Nicola Ken Barozzi wrote:
> Well, first of all Centipede is changing in these days to use the new
> Ant embed proposal... anyway, here is a brief description for a
> knowledgeble person, who you are.
I plan to propose the embed to the main branch as soon
as I solve few remaining issues ( description, projecthelp ).
There is one more addition I want to make, an updated version of
antlib ( the one in sandbox won't compile since it needs support in
ProjectHelper ).
The antlib ( and possibly jjar, etc ) use is connected with the semantic
for namespaces ( at least each 'antlib' should have a unique ID - either
URI or URL that can be used as a namespace ). Most likely I'll just
add a hook to delegate task location and creation.
This is also usefull for tomcat ( to delegate to StandardClassLoader -
which has some interesting features ).
I'm still working on the details - probably next few weeks I'll post
something. ( I'll also wait for Stefan to return from vacation )
Don't know how this will affect centipede.
Costin
>
> Centipede is concretely an Ant distro, with already present in the lib
> dir the new embed proposal, jxpath (used in the proposal), ant-contrib
> and jjar.
>
> I took the ant scripts, changes *ant* to *cent*, ANT_HOME to
> CENTIPEDE_HOME, and that's it.
>
> So the core motor of Centipede is Ant+embed proposal, and any normal Ant
> project can be run by Centipede.
>
> The real core of Centipede is a buildfile that projects can <import>,
> and that gives common services: it downloads the project required
> libraries from a repository using JJAR, downloads, expands and executes
> Ant plugins called Cents, and makes available information for the
> project from Gump's project descriptor.
>
> The Cents are simply buildfiles that can be imported, along with the
> libraries and resources they need.
>
> For example, the JUnit cent has the JUnit jars, the Junit style
> stylesheets and a buildfile for doing common unit tests.
>
> Each cent already knows where to operate because I enhanced the Gump
> descriptor with the info needed.
>
> <>>>>>>>>>>><<<<<<<<<<<>
>
> Currently we are refactoring to use the embed prposal, since before we
> used entity includes and antcalls.
>
> Apart from that we will be soon ready to roll another beta and make Gump
> runs avaliable.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: versioning projects with the ant runner
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephane Bailliez wrote:
> ----- Original Message -----
> From: "Nicola Ken Barozzi" <ni...@apache.org>
>
>>Oh, and let me add that I've committed it to Centipede CVS, and it's
>>working nicely.
>
>
> btw Nikola. I need you to enlighten me.
>
> I'm just getting out of my cave, Centipede has been mentioned for a very
> long time but I just recently took the time to go the the web site, and I
> have a hard time really understanding it compared to maven. what it does,
> what it does not and vice versa.
> (No I did not install anything yet).
Well, first of all Centipede is changing in these days to use the new
Ant embed proposal... anyway, here is a brief description for a
knowledgeble person, who you are.
Centipede is concretely an Ant distro, with already present in the lib
dir the new embed proposal, jxpath (used in the proposal), ant-contrib
and jjar.
I took the ant scripts, changes *ant* to *cent*, ANT_HOME to
CENTIPEDE_HOME, and that's it.
So the core motor of Centipede is Ant+embed proposal, and any normal Ant
project can be run by Centipede.
The real core of Centipede is a buildfile that projects can <import>,
and that gives common services: it downloads the project required
libraries from a repository using JJAR, downloads, expands and executes
Ant plugins called Cents, and makes available information for the
project from Gump's project descriptor.
The Cents are simply buildfiles that can be imported, along with the
libraries and resources they need.
For example, the JUnit cent has the JUnit jars, the Junit style
stylesheets and a buildfile for doing common unit tests.
Each cent already knows where to operate because I enhanced the Gump
descriptor with the info needed.
<>>>>>>>>>>><<<<<<<<<<<>
Currently we are refactoring to use the embed prposal, since before we
used entity includes and antcalls.
Apart from that we will be soon ready to roll another beta and make Gump
runs avaliable.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: versioning projects with the ant runner
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Nicola Ken Barozzi" <ni...@apache.org>
>
> Oh, and let me add that I've committed it to Centipede CVS, and it's
> working nicely.
btw Nikola. I need you to enlighten me.
I'm just getting out of my cave, Centipede has been mentioned for a very
long time but I just recently took the time to go the the web site, and I
have a hard time really understanding it compared to maven. what it does,
what it does not and vice versa.
(No I did not install anything yet).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: versioning projects with the ant runner
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Diane Holt wrote:
> I think <include> task that Costin is working on will take care of this
> sort of thing, since it allows you to reference properties. (Of course, if
> you're only needing to build one version of your app per workspace, you
> can avoid the whole issue and just let your SCM do the work for you :)
Oh, and let me add that I've committed it to Centipede CVS, and it's
working nicely.
And also, the top-level task stuff is indeef helpful, since I found out
that I can xslt toplevel and then import the buildfile I've just
generated! :-O
I'm happy that my import patch helper respark this stuff, and Costin's
embed proposal with the import stuff is really neat =:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: versioning projects with the ant runner
Posted by Diane Holt <ho...@yahoo.com>.
I think <include> task that Costin is working on will take care of this
sort of thing, since it allows you to reference properties. (Of course, if
you're only needing to build one version of your app per workspace, you
can avoid the whole issue and just let your SCM do the work for you :)
Diane
=====
(holtdl@yahoo.com)
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>