You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Dimitris Mouchritsas <dm...@gmail.com> on 2007/11/27 16:23:53 UTC
Handling multiple subproject in J2EE app
Hi all, I'm trying to figure out what's the best way to handle a J2EE
project with different modules.
I'm thinking to create a sub project structure a bit like Maven but have ant
build files. I can handle
each project separately easily. My problem is interconnecting the
sub-projects. For example I would
like, when compiling the war servlet classes to depend on the EJB jar being
up to date. So I would like
to use a master build file but have each sub-project understand its
dependencies. Are there any best
practices that you know of?
--
Dimitris Mouchritsas
Computer Services
Re: Handling multiple subproject in J2EE app
Posted by Steve Loughran <st...@apache.org>.
Dimitris Mouchritsas wrote:
> I guess I need to start reading on Ivy then...
> While playing around with Joe's solution I managed to put ant in an infinite
> loop.
> My worst fear is that I won't be able to persuade my manager to start using
> Ivy.
Well, I could point you to Ant in Action as a book that not only covers
moving to ivy, looks at building and testing an EJB3 app in the process.
the source is in CVS, for you to check out and play with
http://sourceforge.net/projects/antbook
> Currently
> we do our build in a horrendous and huge, over 1500 line, build file.
>
<import> will let you break that up into three 500+ line files.
-steve
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Dimitris Mouchritsas <dm...@gmail.com>.
I guess I need to start reading on Ivy then...
While playing around with Joe's solution I managed to put ant in an infinite
loop.
My worst fear is that I won't be able to persuade my manager to start using
Ivy. Currently
we do our build in a horrendous and huge, over 1500 line, build file.
On Nov 27, 2007 6:43 PM, Steve Loughran <st...@apache.org> wrote:
> Dimitris Mouchritsas wrote:
> > Hi all, I'm trying to figure out what's the best way to handle a J2EE
> > project with different modules.
> > I'm thinking to create a sub project structure a bit like Maven but have
> ant
> > build files. I can handle
> > each project separately easily. My problem is interconnecting the
> > sub-projects. For example I would
> > like, when compiling the war servlet classes to depend on the EJB jar
> being
> > up to date. So I would like
> > to use a master build file but have each sub-project understand its
> > dependencies. Are there any best
> > practices that you know of?
> >
>
> Ivy. Every sub project publishes their artifacts; the next things down
> the chain pulls them in. Ivy can also generate an order for build files
> that takes the dependencies into account.
>
>
> --
> Steve Loughran http://www.1060.org/blogxter/publish/5
> Author: Ant in Action http://antbook.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
--
Dimitris Mouchritsas
Computer Services
Re: Handling multiple subproject in J2EE app
Posted by Steve Loughran <st...@apache.org>.
Dimitris Mouchritsas wrote:
> Hi all, I'm trying to figure out what's the best way to handle a J2EE
> project with different modules.
> I'm thinking to create a sub project structure a bit like Maven but have ant
> build files. I can handle
> each project separately easily. My problem is interconnecting the
> sub-projects. For example I would
> like, when compiling the war servlet classes to depend on the EJB jar being
> up to date. So I would like
> to use a master build file but have each sub-project understand its
> dependencies. Are there any best
> practices that you know of?
>
Ivy. Every sub project publishes their artifacts; the next things down
the chain pulls them in. Ivy can also generate an order for build files
that takes the dependencies into account.
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Prashant Reddy <pr...@pramati.com>.
On Tue, 2007-11-27 at 15:50 +0000, Joe Schmetzer wrote:
> Here's the technique I use in these situations:
>
> http://www.exubero.com/ant/dependencies.html
Another modification to the same technique would be to import predefined
"macrodef"s from a common-build script. This way the build file
importing the macros can pass its preferences as attributes. And the
build file looks much more readable.
-Prashant
>
> Cheers,
> Joe
>
> On Tue, November 27, 2007 3:23 pm, Dimitris Mouchritsas wrote:
> > Hi all, I'm trying to figure out what's the best way to handle a J2EE
> > project with different modules.
> > I'm thinking to create a sub project structure a bit like Maven but have
> > ant
> > build files. I can handle
> > each project separately easily. My problem is interconnecting the
> > sub-projects. For example I would
> > like, when compiling the war servlet classes to depend on the EJB jar
> > being
> > up to date. So I would like
> > to use a master build file but have each sub-project understand its
> > dependencies. Are there any best
> > practices that you know of?
> >
> > --
> > Dimitris Mouchritsas
> > Computer Services
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Stopping a process identified by name
Posted by "Agarkar, M (Milind)" <Mi...@rabobank.com>.
Hi,
Is there a way to stop/kill a process running on unix using the ant
script ? Would I need to write a custom task ?
Thanks,
Milind
_____________________________________________________________
This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat.
_____________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Rob Seegel <Ro...@comcast.net>.
Steve Loughran wrote:
>
> The ant tasks for maven are very similar, but I have found them to be
> -at the time I was looking at them for my book - to be of a fairly low
> quality. The authors werent heavy Ant users -it was the maven team after
> all- and were written with no tests, no reentrancy, and fairly weak
> failure modes. Also, Ivy is way better at handling complex dependency
> setups, with different paths for different custom tasks, etc. That said,
> Maven profiles may achieve something similar.
Just to echo my agreement here. I didn't find the Maven tasks usable
out-of-the-box (perhaps I was using an early version). The effort that
went into creating the tasks appeared to be grudging, at best, and I ran
into several issues early on.
I had to go into the source and add better error reporting, and other
minor modifications.s Also, in order to make them more usable in our
system, I found that I had to wrap the tasks inside friendlier macros.
It was a bit more work than I expected and a hassle, and I was close to
yanking the tasks out at some point and replacing it with Ivy.
Unfortunately, by that time I felt like I'd already had a time
investment and wasn't ready to start from scratch with another tool.
In retrospect, I'd have probably gone with Ivy, since its dependency
management appears to be more robust. The only benefit of going with the
Maven2 tasks that I can think of is that you already have the start of a
pom.xml if your project migrates to using Maven2. The entire process
helped me to gain a better understanding of Maven2 and its configuration
and repositories, which was nice, but I would have rather spent that
time working on real code, instead of finessing the Maven plugin.
Rob
>
> The Ivy stuff doesnt need Ant, but the team all use ant, it is an apache
> project under ant.apache.org these days, and we may move to tighter
> coupling in future.
>
> If you are sticking with Ant, use Ivy.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Steve Loughran <st...@apache.org>.
Dimitris Mouchritsas wrote:
> Thank you everyone. You've given me a lot of food for thought. From
> everyone's writings, if I understand correctly, the ant tasks for maven is
> nearly the same as ant+ivy, right? I suppose I will start looking into
> integrating ivy into a small example project and see what I'll get from
> this. From my point of view, I suppose we have a fairly standard J2EE
> project but should allow for flexibility (it's got a 2 year lifespan) as we
> don't know yet what might pop up. Once again thank you everyone.
>
> On Nov 28, 2007 7:27 AM, Joe Schmetzer <jo...@exubero.com> wrote:
>
The ant tasks for maven are very similar, but I have found them to be
-at the time I was looking at them for my book - to be of a fairly low
quality. The authors werent heavy Ant users -it was the maven team after
all- and were written with no tests, no reentrancy, and fairly weak
failure modes. Also, Ivy is way better at handling complex dependency
setups, with different paths for different custom tasks, etc. That said,
Maven profiles may achieve something similar.
The Ivy stuff doesnt need Ant, but the team all use ant, it is an apache
project under ant.apache.org these days, and we may move to tighter
coupling in future.
If you are sticking with Ant, use Ivy.
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Dimitris Mouchritsas <dm...@gmail.com>.
Thank you everyone. You've given me a lot of food for thought. From
everyone's writings, if I understand correctly, the ant tasks for maven is
nearly the same as ant+ivy, right? I suppose I will start looking into
integrating ivy into a small example project and see what I'll get from
this. From my point of view, I suppose we have a fairly standard J2EE
project but should allow for flexibility (it's got a 2 year lifespan) as we
don't know yet what might pop up. Once again thank you everyone.
On Nov 28, 2007 7:27 AM, Joe Schmetzer <jo...@exubero.com> wrote:
> Hi Dimitris,
>
> If you're still having troubles with the technique at
> http://www.exubero.com/ant/dependencies.html , I would recommend that
> you download the example scripts mentioned at the bottom of the email
> (http://www.exubero.com/ant/example.tar.gz ). Hopefully, using that as a
> base, you can extend it to your situation.
>
> I tend to use that technique for splitting a monolithic project into
> smaller, more manageable components. It's relatively simple, and doesn't
> rely on any other software, just purely Ant.
>
> You mentioned in another post that you managed to put Ant into an
> infinite loop using this technique, which sounds strange. Perhaps you
> have some sort of cyclical dependency? It's hard to say without looking
> at your scripts what actually happened.
>
> For larger build systems, I would definitely recommend looking at one of
> the repository solutions: Ivy or Maven2. This sort of configuration
> elegantly breaks the back of complex dependency management. To a degree,
> it can even handle cyclical dependencies (though of course, you should
> avoid that at all costs, anyway).
>
> I've heard a lot of good reports about Ivy, but I haven't used it
> myself. Other people on this list are better suited to sing praises in
> that direction.
>
> In my current company, we have settled on using Ant scripts and a Maven2
> repository with the Ant Tasks for Maven
> (http://maven.apache.org/ant-tasks.html ). This enabled us to move to a
> repository solution that could be shared by both Ant and Maven. We have
> a number of other projects that use Maven, and this seemed the best of
> both worlds. Just to be clear: I really like the Maven repository, but I
> don't really care much for Maven itself, as I discuss at
> http://www.exubero.com/blog/20070313_Why_I_Prefer_Ant_Over_Maven.html
>
> Cheers,
> Joe
>
> On Tue, 2007-11-27 at 18:38 +0200, Dimitris Mouchritsas wrote:
> > I've had a look in Joe's solution but I could not understand much yet.
> > Although it seems to be exactly what I want I've difficulty grasping the
> > solution. I want to take a look in Ivy as well but probably at a later
> time.
> > Thank you both. Joe if you could elaborate a bit on your solution...
> I'll
> > try to play with it a little bit to see if I can get a better grasp in
> the
> > meantime.
> >
> > On Nov 27, 2007 6:02 PM, Gilles Scokart <gs...@gmail.com> wrote:
> >
> > > You can have a look to ivy as well.
> > >
> > > Every module can be published to a repository. Every module can pick
> up
> > > its dependencies from this repository and if
> > > required you can write a master build that build the submodules in the
> > > right order.
> > >
> > > Gilles
> > >
> > > > -----Original Message-----
> > > > From: Joe Schmetzer [mailto:joe@exubero.com]
> > > > Sent: mardi 27 novembre 2007 16:50
> > > > To: Ant Users List
> > > > Subject: Re: Handling multiple subproject in J2EE app
> > > >
> > > > Here's the technique I use in these situations:
> > > >
> > > > http://www.exubero.com/ant/dependencies.html
> > > >
> > > > Cheers,
> > > > Joe
> > > >
> > > > On Tue, November 27, 2007 3:23 pm, Dimitris Mouchritsas wrote:
> > > > > Hi all, I'm trying to figure out what's the best way to handle a
> J2EE
> > > > > project with different modules.
> > > > > I'm thinking to create a sub project structure a bit like Maven
> but
> > > have
> > > > > ant
> > > > > build files. I can handle
> > > > > each project separately easily. My problem is interconnecting the
> > > > > sub-projects. For example I would
> > > > > like, when compiling the war servlet classes to depend on the EJB
> jar
> > > > > being
> > > > > up to date. So I would like
> > > > > to use a master build file but have each sub-project understand
> its
> > > > > dependencies. Are there any best
> > > > > practices that you know of?
> > > > >
> > > > > --
> > > > > Dimitris Mouchritsas
> > > > > Computer Services
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
--
Dimitris Mouchritsas
Computer Services
Re: Handling multiple subproject in J2EE app
Posted by Joe Schmetzer <jo...@exubero.com>.
Hi Dimitris,
If you're still having troubles with the technique at
http://www.exubero.com/ant/dependencies.html , I would recommend that
you download the example scripts mentioned at the bottom of the email
(http://www.exubero.com/ant/example.tar.gz ). Hopefully, using that as a
base, you can extend it to your situation.
I tend to use that technique for splitting a monolithic project into
smaller, more manageable components. It's relatively simple, and doesn't
rely on any other software, just purely Ant.
You mentioned in another post that you managed to put Ant into an
infinite loop using this technique, which sounds strange. Perhaps you
have some sort of cyclical dependency? It's hard to say without looking
at your scripts what actually happened.
For larger build systems, I would definitely recommend looking at one of
the repository solutions: Ivy or Maven2. This sort of configuration
elegantly breaks the back of complex dependency management. To a degree,
it can even handle cyclical dependencies (though of course, you should
avoid that at all costs, anyway).
I've heard a lot of good reports about Ivy, but I haven't used it
myself. Other people on this list are better suited to sing praises in
that direction.
In my current company, we have settled on using Ant scripts and a Maven2
repository with the Ant Tasks for Maven
(http://maven.apache.org/ant-tasks.html ). This enabled us to move to a
repository solution that could be shared by both Ant and Maven. We have
a number of other projects that use Maven, and this seemed the best of
both worlds. Just to be clear: I really like the Maven repository, but I
don't really care much for Maven itself, as I discuss at
http://www.exubero.com/blog/20070313_Why_I_Prefer_Ant_Over_Maven.html
Cheers,
Joe
On Tue, 2007-11-27 at 18:38 +0200, Dimitris Mouchritsas wrote:
> I've had a look in Joe's solution but I could not understand much yet.
> Although it seems to be exactly what I want I've difficulty grasping the
> solution. I want to take a look in Ivy as well but probably at a later time.
> Thank you both. Joe if you could elaborate a bit on your solution... I'll
> try to play with it a little bit to see if I can get a better grasp in the
> meantime.
>
> On Nov 27, 2007 6:02 PM, Gilles Scokart <gs...@gmail.com> wrote:
>
> > You can have a look to ivy as well.
> >
> > Every module can be published to a repository. Every module can pick up
> > its dependencies from this repository and if
> > required you can write a master build that build the submodules in the
> > right order.
> >
> > Gilles
> >
> > > -----Original Message-----
> > > From: Joe Schmetzer [mailto:joe@exubero.com]
> > > Sent: mardi 27 novembre 2007 16:50
> > > To: Ant Users List
> > > Subject: Re: Handling multiple subproject in J2EE app
> > >
> > > Here's the technique I use in these situations:
> > >
> > > http://www.exubero.com/ant/dependencies.html
> > >
> > > Cheers,
> > > Joe
> > >
> > > On Tue, November 27, 2007 3:23 pm, Dimitris Mouchritsas wrote:
> > > > Hi all, I'm trying to figure out what's the best way to handle a J2EE
> > > > project with different modules.
> > > > I'm thinking to create a sub project structure a bit like Maven but
> > have
> > > > ant
> > > > build files. I can handle
> > > > each project separately easily. My problem is interconnecting the
> > > > sub-projects. For example I would
> > > > like, when compiling the war servlet classes to depend on the EJB jar
> > > > being
> > > > up to date. So I would like
> > > > to use a master build file but have each sub-project understand its
> > > > dependencies. Are there any best
> > > > practices that you know of?
> > > >
> > > > --
> > > > Dimitris Mouchritsas
> > > > Computer Services
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Dimitris Mouchritsas <dm...@gmail.com>.
I've had a look in Joe's solution but I could not understand much yet.
Although it seems to be exactly what I want I've difficulty grasping the
solution. I want to take a look in Ivy as well but probably at a later time.
Thank you both. Joe if you could elaborate a bit on your solution... I'll
try to play with it a little bit to see if I can get a better grasp in the
meantime.
On Nov 27, 2007 6:02 PM, Gilles Scokart <gs...@gmail.com> wrote:
> You can have a look to ivy as well.
>
> Every module can be published to a repository. Every module can pick up
> its dependencies from this repository and if
> required you can write a master build that build the submodules in the
> right order.
>
> Gilles
>
> > -----Original Message-----
> > From: Joe Schmetzer [mailto:joe@exubero.com]
> > Sent: mardi 27 novembre 2007 16:50
> > To: Ant Users List
> > Subject: Re: Handling multiple subproject in J2EE app
> >
> > Here's the technique I use in these situations:
> >
> > http://www.exubero.com/ant/dependencies.html
> >
> > Cheers,
> > Joe
> >
> > On Tue, November 27, 2007 3:23 pm, Dimitris Mouchritsas wrote:
> > > Hi all, I'm trying to figure out what's the best way to handle a J2EE
> > > project with different modules.
> > > I'm thinking to create a sub project structure a bit like Maven but
> have
> > > ant
> > > build files. I can handle
> > > each project separately easily. My problem is interconnecting the
> > > sub-projects. For example I would
> > > like, when compiling the war servlet classes to depend on the EJB jar
> > > being
> > > up to date. So I would like
> > > to use a master build file but have each sub-project understand its
> > > dependencies. Are there any best
> > > practices that you know of?
> > >
> > > --
> > > Dimitris Mouchritsas
> > > Computer Services
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > For additional commands, e-mail: user-help@ant.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
--
Dimitris Mouchritsas
Computer Services
RE: Handling multiple subproject in J2EE app
Posted by Gilles Scokart <gs...@gmail.com>.
You can have a look to ivy as well.
Every module can be published to a repository. Every module can pick up its dependencies from this repository and if
required you can write a master build that build the submodules in the right order.
Gilles
> -----Original Message-----
> From: Joe Schmetzer [mailto:joe@exubero.com]
> Sent: mardi 27 novembre 2007 16:50
> To: Ant Users List
> Subject: Re: Handling multiple subproject in J2EE app
>
> Here's the technique I use in these situations:
>
> http://www.exubero.com/ant/dependencies.html
>
> Cheers,
> Joe
>
> On Tue, November 27, 2007 3:23 pm, Dimitris Mouchritsas wrote:
> > Hi all, I'm trying to figure out what's the best way to handle a J2EE
> > project with different modules.
> > I'm thinking to create a sub project structure a bit like Maven but have
> > ant
> > build files. I can handle
> > each project separately easily. My problem is interconnecting the
> > sub-projects. For example I would
> > like, when compiling the war servlet classes to depend on the EJB jar
> > being
> > up to date. So I would like
> > to use a master build file but have each sub-project understand its
> > dependencies. Are there any best
> > practices that you know of?
> >
> > --
> > Dimitris Mouchritsas
> > Computer Services
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Joe Schmetzer <jo...@exubero.com>.
Here's the technique I use in these situations:
http://www.exubero.com/ant/dependencies.html
Cheers,
Joe
On Tue, November 27, 2007 3:23 pm, Dimitris Mouchritsas wrote:
> Hi all, I'm trying to figure out what's the best way to handle a J2EE
> project with different modules.
> I'm thinking to create a sub project structure a bit like Maven but have
> ant
> build files. I can handle
> each project separately easily. My problem is interconnecting the
> sub-projects. For example I would
> like, when compiling the war servlet classes to depend on the EJB jar
> being
> up to date. So I would like
> to use a master build file but have each sub-project understand its
> dependencies. Are there any best
> practices that you know of?
>
> --
> Dimitris Mouchritsas
> Computer Services
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: Handling multiple subproject in J2EE app
Posted by Rob Seegel <Ro...@comcast.net>.
Dimitris Mouchritsas wrote:
> Are there any best practices that you know of?
I'm unsure if there is one set of practices that work well in all
circumstances, but I'd be happy to share a few ideas that I put into
place for our in-house build system which is used by 3-4 different
projects, one of which consists of over 50 sub-project modules.
Our project was on the cusp of growing to be unmanageable. Maven2 had
just been released and it looked interesting and had lots of features I
liked, but there were a few strikes against it in our circumstances that
made it unsuitable at the time. We ended up with a build system built
mostly with Ant, Ant-Contrib, Maven Ant Tasks, and a few in-house
developed tasks. The system relies heavily on features introduced in 1.6
such as <import> and <macrodef>, and shuns the use of the <antcall>
task. The setup also adopted a lot of basic Maven2 conventions, which is
one of the primary places we looked to for "best practices".
Each module in our project has a build.xml file AND a pom.xml. Basic
characteristics of projects are defined in the pom.xml. Name, type,
dependencies, parent. etc. Each project imports a skeleton project, that
provides for a basic build life cycle. Each project can also have
additional imports to "decorate" the skeleton project with process
enhancements (such as creating xmlbeans, using xdoclet, using hibernate,
etc). Functionality that was truly unique to a specific project was put
directly into its build.xml in standalone targets, or into special
targets that were hooked into the build life cycle.
There were two tasks we had to created that helped tie all of this
together. One was a task that extended the Ant-Contrib run-target, which
could call all targets defined by the same name (honoring their
dependencies). This may not seem like a big deal, but it was huge:
We could for example have the following task in the skeleton project:
<custom:call-target target="generate-code"
scope="all"
existance="optional" />
And other imported files could define a generate-code target (xmlbeans,
hibernate, etc) These would all be executed in the order in which they
were imported, without the skeleton target having to know the details of
which file they were defined. We could have added inclusions/exclusions,
but didn't need the additional complexity. The existance value told the
task not to complain if it couldn't find any matching targets, though it
was log the fact when verbose logging was configured.
Another important task was one which was tied into our Maven
integration. Early in the build cycle for each project, we checked a
project's dependencies to see if there were any dependencies within the
same project group (and internal dependency), if so, before the current
projects build would go any further, it would first use the <ant> task
to call the dependent projects default target, which in nearly all cases
was the "build" target, which ran through the same build life cycle on
the dependency and so on in a recursive fashion. The trickiest part here
was ensuring that a dependent project was not built more than once while
recursing.
Overall, it works pretty well. We have several large projects that use
the system and it appears to scale fairly well, though it does offer a
basic trade off. It is *definitely* slower that a setup where all the
source code is located in one directory and one large (and very
complicated) script would be used to do the same builds. On the other
hand maintenance is far easier, and it is a fairly easy thing to add new
modules without disrupting other existing functionality. The build for
each project is extremely small and in many cases consists of one or two
imports, along with a property override or two.
One thing we ran into which did present a challenge was that a a project
that created a WAR file might have a different set of depenedencies when
it was bundled by itself instead of deployed within an EAR. That was one
wrinkle that we never adequately addressed nor saw an easy solution for
using Maven's dependency management tasks.
We went with Maven, but after looking at Ivy, we could just as easily
have used it instead. At the time we were looking at striking a balance
between ant and maven, and creating a solution that wouldn't take us too
far from a Maven2 setup if we decided to reconsider it later. Since we
had already done quite a bit of legwork looking at Maven2, it made more
sense at the time to use the Maven2 plugin over Ivy for dependency
management.
We are able to get a lot of mileage out of a setup like this since we
have several folks who are very comfortable using and extended Ant.
There are things to watch out for when attempting something like this:
- be extremely carefully with naming conventions and properties.
- Watch out for ClassLoader issues and custom tasks.
- Be extremely careful about using <antcall> when importing files and
in large builds because of its consequences. We essentially outlawed it
within our system. If we needed to extract a commom process that never
needed to be called by itself and didn't really serve as a decent
override point, we used a macro. If that macro become overly complex
(obviously subjective) we replaced it with a pure Java task. There were
times when having one target call another are useful. It gives you the
opportunity to override the second target. In these cases we either took
advantage of target dependencies, or our <call-target> task, which was
based off of Ant-Contrib's <runtarget> task.
Anyway... just a few of my thoughts on it.
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org