Replacing build.xml with Build.java - Doing Ant builds directly from Java

[Dean Schulze]

The Ant documentation has a section titled "Using Ant Tasks Outside
of Ant" which gives a teaser for how to use the Ant libraries from Java
code.  In theory it seems simple enough to replace build.xml with
Build.java. The Ant documentation hints at some undocumented
dependencies that I'll have to discover (undocumented from the point of
view of using Ant from within Java).
Using Java instead of xml to do an Ant build seems so obvious I wonder why there hasn't been a parallel track over the years for Build.java as well as build.xml.
I asked this same question over at stackoverflow.com:
http://stackoverflow.com/questions/972574/replacing-build-xml-with-build-java-using-java-and-the-ant-libraries-as-a-build
The answers indicate that it isn't difficult to do, but that it is necessary to "spoof" the project and target objects.
While it all looks encouraging I haven't seen any actual examples of how to deal with the undocumented issues mentioned.  Has anyone documented how to do Ant builds from Java?
Thanks.
Dean

[Cole, Derek E]

You are correct that there is very little documentation on the subject, other than a few small, simple examples on the net.  It seemed like one of the responders in that link you posted was implying that he spoofed the tasks he needed to use? That seems like quite a bit more work than would be necessary. When I have used ant from java, it was primarily to control dependencies, but I still had underlying build.xml files that individual targets were called from, using the java program to control when, handle errors, etc.

Derek

-----Original Message-----
From: Dean Schulze [mailto:dean_w_schulze@...]
Sent: Thursday, June 11, 2009 11:28 AM
To: user@...
Subject: Replacing build.xml with Build.java - Doing Ant builds directly from Java


The Ant documentation has a section titled "Using Ant Tasks Outside
of Ant" which gives a teaser for how to use the Ant libraries from Java
code.  In theory it seems simple enough to replace build.xml with
Build.java. The Ant documentation hints at some undocumented
dependencies that I'll have to discover (undocumented from the point of
view of using Ant from within Java).
Using Java instead of xml to do an Ant build seems so obvious I wonder why there hasn't been a parallel track over the years for Build.java as well as build.xml.
I asked this same question over at stackoverflow.com:
http://stackoverflow.com/questions/972574/replacing-build-xml-with-build-java-using-java-and-the-ant-libraries-as-a-build
The answers indicate that it isn't difficult to do, but that it is necessary to "spoof" the project and target objects.
While it all looks encouraging I haven't seen any actual examples of how to deal with the undocumented issues mentioned.  Has anyone documented how to do Ant builds from Java?
Thanks.
Dean




     

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Dean Schulze]

I anticipate using a simple build.xml with different targets to kick off the Build.java file passing in whatever parameters correspond to different targets.  The heavy lifting would be done by the Build.java.  build.xml would be used for parameter passing and for integration with Eclipse.

Ant build scripts make simple things like an if .... else difficult and things like changing the value of a property impossible.  Simple things can be done in xml I only anticipate using build.xml to invoke the Build.java.



--- On Thu, 6/11/09, Cole, Derek E <derek.e.cole@...> wrote:

From: Cole, Derek E <derek.e.cole@...>
Subject: RE: Replacing build.xml with Build.java - Doing Ant builds directly from Java
To: "Ant Users List" <user@...>
Date: Thursday, June 11, 2009, 9:41 AM

You are correct that there is very little documentation on the subject, other than a few small, simple examples on the net.  It seemed like one of the responders in that link you posted was implying that he spoofed the tasks he needed to use? That seems like quite a bit more work than would be necessary. When I have used ant from java, it was primarily to control dependencies, but I still had underlying build.xml files that individual targets were called from, using the java program to control when, handle errors, etc.

Derek

-----Original Message-----
From: Dean Schulze [mailto:dean_w_schulze@...]
Sent: Thursday, June 11, 2009 11:28 AM
To: user@...
Subject: Replacing build.xml with Build.java - Doing Ant builds directly from Java


The Ant documentation has a section titled "Using Ant Tasks Outside
of Ant" which gives a teaser for how to use the Ant libraries from Java
code.  In theory it seems simple enough to replace build.xml with
Build.java. The Ant documentation hints at some undocumented
dependencies that I'll have to discover (undocumented from the point of
view of using Ant from within Java).
Using Java instead of xml to do an Ant build seems so obvious I wonder why there hasn't been a parallel track over the years for Build.java as well as build.xml.
I asked this same question over at stackoverflow.com:
http://stackoverflow.com/questions/972574/replacing-build-xml-with-build-java-using-java-and-the-ant-libraries-as-a-build
The answers indicate that it isn't difficult to do, but that it is necessary to "spoof" the project and target objects.
While it all looks encouraging I haven't seen any actual examples of how to deal with the undocumented issues mentioned.  Has anyone documented how to do Ant builds from Java?
Thanks.
Dean




     

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Ashley Williams-8]

Hi Dean,

I use this technique frequently as in this example lifted straight  
from my code, see below.
All you have to remember is that a top level project owns many targets  
which in turn own many tasks,
so just make sure you set up the parent/child references in both  
directions.

                // create the ant parent project
                Project project = new Project();
                project.setName("project");
                project.init();

                // create the child target
                Target target = new Target();
                target.setName("target");
                project.addTarget(target);
                project.addBuildListener(new Log4jListener());

                // create the child untar task with gzip compression
                Untar untar = new Untar();
                untar.setTaskName("untar");
                untar.setSrc(artifactFile);
                untar.setDest(new File("."));
                Untar.UntarCompressionMethod method = new  
Untar.UntarCompressionMethod();
                method.setValue("gzip");
                untar.setCompression(method);
                untar.setProject(project);
                untar.setOwningTarget(target);
                target.addTask(untar);

                project.execute();

I am also the architect of ProtoJ over at google code http://code.google.com/p/protoj/ 
  which builds on ant and other
dependencies to control a project from java rather than script.

- Ashley



On 11 Jun 2009, at 16:28, Dean Schulze wrote:

>
> The Ant documentation has a section titled "Using Ant Tasks Outside
> of Ant" which gives a teaser for how to use the Ant libraries from  
> Java
> code.  In theory it seems simple enough to replace build.xml with
> Build.java. The Ant documentation hints at some undocumented
> dependencies that I'll have to discover (undocumented from the point  
> of
> view of using Ant from within Java).
> Using Java instead of xml to do an Ant build seems so obvious I  
> wonder why there hasn't been a parallel track over the years for  
> Build.java as well as build.xml.
> I asked this same question over at stackoverflow.com:
> http://stackoverflow.com/questions/972574/replacing-build-xml-with-build-java-using-java-and-the-ant-libraries-as-a-build
> The answers indicate that it isn't difficult to do, but that it is  
> necessary to "spoof" the project and target objects.
> While it all looks encouraging I haven't seen any actual examples of  
> how to deal with the undocumented issues mentioned.  Has anyone  
> documented how to do Ant builds from Java?
> Thanks.
> Dean
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Dale Anson]

For if/else, try/catch, and changing the value of a property, all you
need is either antcontrib (ant-contrib.sourceforge.net) or antelope
(antelope.tigris.org) tasks.

Dale


On Thu, Jun 11, 2009 at 10:48 AM, Dean Schulze<dean_w_schulze@...> wrote:

>
> I anticipate using a simple build.xml with different targets to kick off the Build.java file passing in whatever parameters correspond to different targets.  The heavy lifting would be done by the Build.java.  build.xml would be used for parameter passing and for integration with Eclipse.
>
> Ant build scripts make simple things like an if .... else difficult and things like changing the value of a property impossible.  Simple things can be done in xml I only anticipate using build.xml to invoke the Build.java.
>
>
>
> --- On Thu, 6/11/09, Cole, Derek E <derek.e.cole@...> wrote:
>
> From: Cole, Derek E <derek.e.cole@...>
> Subject: RE: Replacing build.xml with Build.java - Doing Ant builds directly from Java
> To: "Ant Users List" <user@...>
> Date: Thursday, June 11, 2009, 9:41 AM
>
> You are correct that there is very little documentation on the subject, other than a few small, simple examples on the net.  It seemed like one of the responders in that link you posted was implying that he spoofed the tasks he needed to use? That seems like quite a bit more work than would be necessary. When I have used ant from java, it was primarily to control dependencies, but I still had underlying build.xml files that individual targets were called from, using the java program to control when, handle errors, etc.
>
> Derek
>
> -----Original Message-----
> From: Dean Schulze [mailto:dean_w_schulze@...]
> Sent: Thursday, June 11, 2009 11:28 AM
> To: user@...
> Subject: Replacing build.xml with Build.java - Doing Ant builds directly from Java
>
>
> The Ant documentation has a section titled "Using Ant Tasks Outside
> of Ant" which gives a teaser for how to use the Ant libraries from Java
> code.  In theory it seems simple enough to replace build.xml with
> Build.java. The Ant documentation hints at some undocumented
> dependencies that I'll have to discover (undocumented from the point of
> view of using Ant from within Java).
> Using Java instead of xml to do an Ant build seems so obvious I wonder why there hasn't been a parallel track over the years for Build.java as well as build.xml.
> I asked this same question over at stackoverflow.com:
> http://stackoverflow.com/questions/972574/replacing-build-xml-with-build-java-using-java-and-the-ant-libraries-as-a-build
> The answers indicate that it isn't difficult to do, but that it is necessary to "spoof" the project and target objects.
> While it all looks encouraging I haven't seen any actual examples of how to deal with the undocumented issues mentioned.  Has anyone documented how to do Ant builds from Java?
> Thanks.
> Dean
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Ina, Antoine]

I am posing a general question about Ant vs Make vs Batch:
1- What is advantage of Ant script over regular Batch script that calls up the solution files for all the projects in
   your system tree of projects(for Windows platform)
2- How does Ant handle up and down project dependencies

Regards,
Antoine

-----Original Message-----
From: Ashley Williams [mailto:ashpublic@...]
Sent: 2009 Jun 11 12:52 PM
To: Ant Users List
Subject: Re: Replacing build.xml with Build.java - Doing Ant builds directlyfrom Java

Hi Dean,

I use this technique frequently as in this example lifted straight
from my code, see below.
All you have to remember is that a top level project owns many targets
which in turn own many tasks,
so just make sure you set up the parent/child references in both
directions.

                // create the ant parent project
                Project project = new Project();
                project.setName("project");
                project.init();

                // create the child target
                Target target = new Target();
                target.setName("target");
                project.addTarget(target);
                project.addBuildListener(new Log4jListener());

                // create the child untar task with gzip compression
                Untar untar = new Untar();
                untar.setTaskName("untar");
                untar.setSrc(artifactFile);
                untar.setDest(new File("."));
                Untar.UntarCompressionMethod method = new
Untar.UntarCompressionMethod();
                method.setValue("gzip");
                untar.setCompression(method);
                untar.setProject(project);
                untar.setOwningTarget(target);
                target.addTask(untar);

                project.execute();

I am also the architect of ProtoJ over at google code http://code.google.com/p/protoj/
  which builds on ant and other
dependencies to control a project from java rather than script.

- Ashley



On 11 Jun 2009, at 16:28, Dean Schulze wrote:

>
> The Ant documentation has a section titled "Using Ant Tasks Outside
> of Ant" which gives a teaser for how to use the Ant libraries from
> Java
> code.  In theory it seems simple enough to replace build.xml with
> Build.java. The Ant documentation hints at some undocumented
> dependencies that I'll have to discover (undocumented from the point
> of
> view of using Ant from within Java).
> Using Java instead of xml to do an Ant build seems so obvious I
> wonder why there hasn't been a parallel track over the years for
> Build.java as well as build.xml.
> I asked this same question over at stackoverflow.com:
> http://stackoverflow.com/questions/972574/replacing-build-xml-with-build-java-using-java-and-the-ant-libraries-as-a-build
> The answers indicate that it isn't difficult to do, but that it is
> necessary to "spoof" the project and target objects.
> While it all looks encouraging I haven't seen any actual examples of
> how to deal with the undocumented issues mentioned.  Has anyone
> documented how to do Ant builds from Java?
> Thanks.
> Dean
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

Dean Schulze schrieb am 11.06.2009 um 09:48:12 (-0700):
>
> Ant build scripts make simple things like an if .... else difficult

Use the extensions, as mentioned by others.

> and things like changing the value of a property impossible.

This might be seen as a feature (but I rather don't think it is).

Wrapping your mind around the Ant way of doing things is probably the
best thing you can do. Where it feels too awkward, use the extension
interface to write an Antlet.

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

Ashley Williams schrieb am 11.06.2009 um 17:51:45 (+0100):

>
> // create the ant parent project
> Project project = new Project();
> project.setName("project");
> project.init();
>
> // create the child target
> Target target = new Target();
> target.setName("target");
> project.addTarget(target);
> project.addBuildListener(new Log4jListener());

The Ant XML isn't exactly compact and doesn't flow like, say, Python
or Perl; but painstakingly recreating the XML structure from the API
is even harder for the eyeball.

But of course, this usage may have its places and applications.

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

Ina, Antoine schrieb am 11.06.2009 um 19:58:37 (+0200):
> I am posing a general question about Ant vs Make vs Batch:
> 1- What is advantage of Ant script over regular Batch script that
> calls up the solution files for all the projects in your system tree
> of projects(for Windows platform)

Now what's a "regular Windows batch script"? I like cmd.exe, but come
on, you don't want to program in that language, using GOTO and all that
stuff.

So you'd use WSH with VB, Perl, or whatever.

But then, WSH is no more cross-platform than CMD/BAT files.

For Java, you really want and need a cross-platform solution. The other
day on this list, I wondered why back then, they didn't simply choose
Perl or Python, which were and still are very good cross-platform tools.

Well, why not? :-)

First, Java was Java and couldn't possibly reuse, of all things, Perl.
(Although it would have worked very, very well for general purpose OS
and network and mail and whatnot stuff.)

Then, bootstrapping Java by Java certainly has advantages.

But why the clunky XML syntax? When Ant was conceived, XML was a hot
new thing, the final solution to almost everything, so doing XML was en
vogue.

Language design and syntax coherence probably weren't top priorities.

Somehow, Ant was adopted. How did it happen, and why? Does anyone know?

Today, you could also consider shifting off programming work (if you
have to do any) from Ant to Python or JRuby scripts, as there are Java
implementations of these languages. (Still no Perl.)

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Ashley Williams-8]

Michael,

You are right what you see is nasty ;) however I deliberately inlined  
the code for clarity.
In practice I actually abstract most of it into helper classes which  
is really
easy to do and you can mostly get away with code like this:

new UntarTask(src, dest).execute(); // execute single statement
new AntTarget(task1, task2, task3).execute(); // execute multiple  
targets

Anyone is free to take a look at some of my code here http://code.google.com/p/protoj/source/browse/#svn/ 
2.0.0/src/java/protoj/lang/ant
to get a head start on this, although if you copy it too closely be  
aware of the apache
open source license

***

 From my personal experience I've always found it to be the case that  
it's only a matter
of time before the build code not only requires logic, but also needs  
to be accessible
from the application - strange as that may sound. Unifying the  
codebase in that way
lets you do the simple, such as display the dependencies in the  
application about
box to the complex such as easily toggle aspectj load time weaving.

Yes extensions such as contrib can sort of help with this but IMHO  
when you go too far
down this road you are admitting that the (xml) ant DSL is no longer a  
good match
for your project. And until recently there hasn't been anywhere to  
turn to for such
projects.

- Ashley


On 12 Jun 2009, at 00:42, Michael Ludwig wrote:

> Ashley Williams schrieb am 11.06.2009 um 17:51:45 (+0100):
>>
>> // create the ant parent project
>> Project project = new Project();
>> project.setName("project");
>> project.init();
>>
>> // create the child target
>> Target target = new Target();
>> target.setName("target");
>> project.addTarget(target);
>> project.addBuildListener(new Log4jListener());
>
> The Ant XML isn't exactly compact and doesn't flow like, say, Python
> or Perl; but painstakingly recreating the XML structure from the API
> is even harder for the eyeball.
>
> But of course, this usage may have its places and applications.
>
> Michael Ludwig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@...
> For additional commands, e-mail: user-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Steve Loughran]

Michael Ludwig wrote:

> Ashley Williams schrieb am 11.06.2009 um 17:51:45 (+0100):
>> // create the ant parent project
>> Project project = new Project();
>> project.setName("project");
>> project.init();
>>
>> // create the child target
>> Target target = new Target();
>> target.setName("target");
>> project.addTarget(target);
>> project.addBuildListener(new Log4jListener());
>
> The Ant XML isn't exactly compact and doesn't flow like, say, Python
> or Perl; but painstakingly recreating the XML structure from the API
> is even harder for the eyeball.
>
> But of course, this usage may have its places and applications.

Ant's API-mode is a bit more brittle than the XML level, and there are a
few steps to setting it up. when I run it embedded, we have a special
logger that checks for an interrupted flag -if it is set it throws a
special subclass of BuildException

http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/ant/src/org/smartfrog/services/ant/InterruptibleLogger.java

All the rest of our embedding code is there to see, even though it has
an LGPL license, we're going to move to the ASF license, so ask nicely
and we'll edit the header on whichever file you want to cut and paste from.

http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/ant/

My most recent work in this area was using the unzip code, where it
turned out to be easier to take bits of the unzip task and call its
underlying code directly, bypassing the task (though using it as the
foundation for my own code)
http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/ant/src/org/smartfrog/services/archives/UnzipImpl.java?view=markup

Remember, this is the other right that open source software gives you.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Steve Loughran]

Michael Ludwig wrote:

> Ina, Antoine schrieb am 11.06.2009 um 19:58:37 (+0200):
>> I am posing a general question about Ant vs Make vs Batch:
>> 1- What is advantage of Ant script over regular Batch script that
>> calls up the solution files for all the projects in your system tree
>> of projects(for Windows platform)
>
> Now what's a "regular Windows batch script"? I like cmd.exe, but come
> on, you don't want to program in that language, using GOTO and all that
> stuff.
>
> So you'd use WSH with VB, Perl, or whatever.
>
> But then, WSH is no more cross-platform than CMD/BAT files.

> For Java, you really want and need a cross-platform solution. The other
> day on this list, I wondered why back then, they didn't simply choose
> Perl or Python, which were and still are very good cross-platform tools.
>
> Well, why not? :-)
>
> First, Java was Java and couldn't possibly reuse, of all things, Perl.

I will point out that my first contrib to this project was a perl script.

> (Although it would have worked very, very well for general purpose OS
> and network and mail and whatnot stuff.)

Actually its pretty tricky to write to x-platform perl, ruby or python,
just as it is to do it well in java too.

>
> Then, bootstrapping Java by Java certainly has advantages.

Ant is a language primarily for Java projects. Basing it on Java is not
just an ideological purity game, but the only way to get at those
internal bits of the JDK in the same process. all the original JDK
library tasks: javac, javadoc, rmic, etc do this: we go in and use the
underlying code.

>
> But why the clunky XML syntax? When Ant was conceived, XML was a hot
> new thing, the final solution to almost everything, so doing XML was en
> vogue.

I know its easy to dismiss it now, but it does have strengths
-any XML editor can work with it
-easy to use with XSLT operations

The XML editing meant that before IDEs had explicit support for the
semantics of Ant (properties, target dependencies), they could let you
edit it in a structured manner.


>
> Language design and syntax coherence probably weren't top priorities.

agreed.  However, we do strive to be more declarative than fully
procedural languages, we don't have loops and so lack full
turing-equivalence. There are also limits to what you can do in java

Notice how Ant deliberately leaves out all fault handing too. Not a full
workflow language based on something formal like Milner's Pi-calculus,
obviously.

>
> Somehow, Ant was adopted. How did it happen, and why? Does anyone know?

ant was written by James Duncan Davidson while sun was opening up
Tomcat, moving it from a sun project which used make to something for
anyone to use. Ant was a solution to a tooling problem.

1. There was no open source IDE at that time, open source projects
couldnt mandate a single IDE the way in-house java teams could.

2. there was no way open source projects could mandate a single platform
for the same reason. Today, I'd say "linux 1st, other unixes second,
ignore windows" -this is effectively what Hadoop does.

3. It turned out to offer a profound advantage over IDEs. The lack of an
IDE meant no debugger. All we had left was testing, and as JUnit came
out at the same time, the <junit> task got written, and the world became
a better place. Before then testing wasn't that mainstream, you sat in
front of the IDE and debugged. Now you add tests and wait for email from
the CI tool.

>
> Today, you could also consider shifting off programming work (if you
> have to do any) from Ant to Python or JRuby scripts, as there are Java
> implementations of these languages. (Still no Perl.)
>

There is a bit of perl in Ant, still works.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[David Weintraub]

On Thu, Jun 11, 2009 at 1:58 PM, Ina, Antoine <antoine.ina@...>wrote:

> I am posing a general question about Ant vs Make vs Batch:
> 1- What is advantage of Ant script over regular Batch script that calls up
> the solution files for all the projects in  your system tree of projects(for
> Windows platform)


Ant and Make do two things that Batch scripts cannot do:

1). Dependency Matrix calculations
2). Build Avoidance

Let's take the first one: Imagine you are building a dozen separate
components, but some of those components depend upon other components to be
built first. You could calculate out your own dependency tree, and then
implement that in your script. But, what happens if things change? Now,
you'll have to recalculate the dependency matrix and probably overhaul your
build script.

Ant and Make both handle the dependency matrix for you. You say that B
depends upon A, and C depends upon A and that A depends upon D, and both Ant
and Make will calculate out the build order of your components. If you make
a change (Say B now depends upon both A and C, Ant and Make will adjust the
build without major rewriting of your build script.

The other major thing is build avoidance. Let's say you have 1000 source
files that are used to build object files and then combined into a single
build entity. If I modify one of those source files, do I have to rebuild
all 1000 build object files? Of course, not. All I have to do is build that
changed object file and rebuild my single build entity.

Doing this build avoidance in a batch script is almost impossible. Doing it
in a Perl or Python script is possible, but a lot of work. Why not simply
use a tool that does it for you?

Now to answer other questions: Why XML for Ant?

XML is a very flexible tool since you can easily have entities embedded in
other entities in a way that's easy to parse. Yes, it isn't the most
readable human language, but then you can use a XML editor to help you. I
use VIM which does syntax highlighting and automatic indentations which
greatly helps me create my build.xml file.

Make and Ant differ in their approach to a build tool. In Make, you depend
upon third party tools such as your compiler and linker. Make only provides
a dependency matrix. The actual tools used to run the build are yours to
provide.

Ant took a different approach in that almost all the major tasks that are
needed for building are provided as part of the basic set. Thus, such tasks
as the <copy> task can also avoid doing extra work just like the <javac>
task does. It also removed the OS dependency upon the build system. The same
Ant file can build on Windows, Mac OS X, Unix, and even VMS and mainframe
operating systems. If you have a Java Development Kit on your system, you
can use the same Ant script.


> 2- How does Ant handle up and down project dependencies
>

I take it this means your dependency matrix. Ant handles this by building a
dependency matrix. You should never specify the order of an Ant build. You
only specify the local dependencies. I merely have to say "A" depends upon
"B" and that "B" depends upon "C". Ant figures out that it has to build "C"
first.

--
David Weintraub
qazwart@...

[Eric Fetzer]

"solution files" - if you're building .NET, go look at NAnt instead of Ant.  The difference is similar to that of a Volkswagon Beetle vs. Rolls Royce...




________________________________
From: "Ina, Antoine" <antoine.ina@...>
To: Ant Users List <user@...>
Sent: Thursday, June 11, 2009 11:58:37 AM
Subject: RE: Doing Ant builds

I am posing a general question about Ant vs Make vs Batch:
1- What is advantage of Ant script over regular Batch script that calls up the solution files for all the projects in
  your system tree of projects(for Windows platform)
2- How does Ant handle up and down project dependencies

Regards,
Antoine

-----Original Message-----
From: Ashley Williams [mailto:ashpublic@...]
Sent: 2009 Jun 11 12:52 PM
To: Ant Users List
Subject: Re: Replacing build.xml with Build.java - Doing Ant builds directlyfrom Java

Hi Dean,

I use this technique frequently as in this example lifted straight
from my code, see below.
All you have to remember is that a top level project owns many targets
which in turn own many tasks,
so just make sure you set up the parent/child references in both
directions.

                // create the ant parent project
                Project project = new Project();
                project.setName("project");
                project.init();

                // create the child target
                Target target = new Target();
                target.setName("target");
                project.addTarget(target);
                project.addBuildListener(new Log4jListener());

                // create the child untar task with gzip compression
                Untar untar = new Untar();
                untar.setTaskName("untar");
                untar.setSrc(artifactFile);
                untar.setDest(new File("."));
                Untar.UntarCompressionMethod method = new
Untar.UntarCompressionMethod();
                method.setValue("gzip");
                untar.setCompression(method);
                untar.setProject(project);
                untar.setOwningTarget(target);
                target.addTask(untar);

                project.execute();

I am also the architect of ProtoJ over at google code http://code.google.com/p/protoj/
  which builds on ant and other
dependencies to control a project from java rather than script.

- Ashley



On 11 Jun 2009, at 16:28, Dean Schulze wrote:

>
> The Ant documentation has a section titled "Using Ant Tasks Outside
> of Ant" which gives a teaser for how to use the Ant libraries from
> Java
> code.  In theory it seems simple enough to replace build.xml with
> Build.java. The Ant documentation hints at some undocumented
> dependencies that I'll have to discover (undocumented from the point
> of
> view of using Ant from within Java).
> Using Java instead of xml to do an Ant build seems so obvious I
> wonder why there hasn't been a parallel track over the years for
> Build.java as well as build.xml.
> I asked this same question over at stackoverflow.com:
> http://stackoverflow.com/questions/972574/replacing-build-xml-with-build-java-using-java-and-the-ant-libraries-as-a-build
> The answers indicate that it isn't difficult to do, but that it is
> necessary to "spoof" the project and target objects.
> While it all looks encouraging I haven't seen any actual examples of
> how to deal with the undocumented issues mentioned.  Has anyone
> documented how to do Ant builds from Java?
> Thanks.
> Dean
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...


The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[ddevienne]

On Fri, Jun 12, 2009 at 11:32 AM, Eric Fetzer<elstonkers@...> wrote:
> "solution files" - if you're building .NET, go look at NAnt instead of Ant.
> The difference is similar to that of a Volkswagon Beetle vs. Rolls Royce...

Me think in the end more Beetles were sold, for far more total money,
than Rolls Royce's ;-)

Just picking on your analogy, that's all. I'm sure NAnt is a good too.
Always easier to improve on an existing tool you copy, when you have
the luxury of hindsight and no backward compatibility constraints
though. Regarding the XML syntax, yes, it clunky but it's also that
it's good enough that people don't want to spent the time making (or
learning as a user) other front ends to Ant, something the body of Ant
committers have already said on this list (or the dev list) they'd
support and make it easier by adapting the Ant core if needed, if the
patches started coming.

Like many successful projects, Ant in part fell victims to its own
success, where any evolution has to take the large body of scripts
(and code in Ant's case) using it into account. There are many good
alternatives to Ant out there, some better even most likely, but Ant
has a community, tool / IDE support, and books to still make it
relevant despite its many flaws. It's momentum has definitely slowed
mind you, but just like Make it's not going away any time soon.
Gradual obsolescence is normal in this field after all :) --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

Steve Loughran schrieb am 12.06.2009 um 11:49:48 (+0100):

> Ant is a language primarily for Java projects. Basing it on Java is
> not just an ideological purity game, but the only way to get at those
> internal bits of the JDK in the same process. all the original JDK
> library tasks: javac, javadoc, rmic, etc do this: we go in and use the
> underlying code.

I see.

> >But why the clunky XML syntax? When Ant was conceived, XML was a hot
> >new thing, the final solution to almost everything, so doing XML was
> >en vogue.
>
> I know its easy to dismiss it now, but it does have strengths
> -any XML editor can work with it
> -easy to use with XSLT operations

I use XSLT a lot, and I really like XML. It lets you operate at a high
level, and with great flexibility. Sorry for conveying the expression
that it was the XML nature of Ant that I found clunky. It's rather that
by comparison of the Ant and XSLT syntaxes, I found Ant much more
difficult to memorize: path, location, name, file, dir - these are all
too similar to me, and I pick the wrong one. Just lack of habit, I gues.
Well, XSLT certainly has been given much more time for language design.

> The XML editing meant that before IDEs had explicit support for the
> semantics of Ant (properties, target dependencies), they could let you
> edit it in a structured manner.

I see; makes sense.

> we do strive to be more declarative than fully procedural languages,
> we don't have loops and so lack full turing-equivalence. There are
> also limits to what you can do in java

> Notice how Ant deliberately leaves out all fault handing too.

It's good guidance to know what not to attempt in Ant.

> >Somehow, Ant was adopted. How did it happen, and why? Does anyone
> >know?
>
> ant was written by James Duncan Davidson while sun was opening up
> Tomcat, moving it from a sun project which used make to something for
> anyone to use. Ant was a solution to a tooling problem.
>
> 1. There was no open source IDE at that time, open source projects
> couldnt mandate a single IDE the way in-house java teams could.
>
> 2. there was no way open source projects could mandate a single
> platform for the same reason. Today, I'd say "linux 1st, other unixes
> second, ignore windows" -this is effectively what Hadoop does.
>
> 3. It turned out to offer a profound advantage over IDEs. The lack of
> an IDE meant no debugger. All we had left was testing, and as JUnit
> came out at the same time, the <junit> task got written, and the world
> became a better place. Before then testing wasn't that mainstream, you
> sat in front of the IDE and debugged. Now you add tests and wait for
> email from the CI tool.

Thanks for these historical insights!

> >(Still no Perl.)
>
> There is a bit of perl in Ant, still works.

C:\jlib\ant-1.7.1 :: dir /s /b *.pl
C:\jlib\ant-1.7.1\bin\antRun.pl
C:\jlib\ant-1.7.1\bin\complete-ant-cmd.pl
C:\jlib\ant-1.7.1\bin\runant.pl

:-)

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

David Weintraub schrieb am 12.06.2009 um 12:22:52 (-0400):

> Ant and Make do two things that Batch scripts cannot do:
>
> 1). Dependency Matrix calculations
> 2). Build Avoidance

Good summary!

> Now to answer other questions: Why XML for Ant?
>
> XML is a very flexible tool since you can easily have entities
> embedded in other entities in a way that's easy to parse.

Most people nowadays ignore the physical structure of an XML document,
i.e. they ignore external entities, and also parameter entities. But
they're damn useful.

> I use VIM which does syntax highlighting and automatic indentations
> which greatly helps me create my build.xml file.

Me too. Just discovered "dit" and "dat". See ":help it", ":h at", ":h
tag-blocks". But you probably knew this.

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

Dominique Devienne schrieb am 12.06.2009 um 13:43:38 (-0500):

> There are many good alternatives to Ant out there, some better even
> most likely, but Ant has a community, tool / IDE support, and books to
> still make it relevant despite its many flaws. It's momentum has
> definitely slowed mind you, but just like Make it's not going away any
> time soon. Gradual obsolescence is normal in this field after all :)

Convinces me to make a greater in investment in learning Ant!

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

Ashley Williams schrieb am 12.06.2009 um 10:56:37 (+0100):

> From my personal experience I've always found it to be the case that
> it's only a matter of time before the build code not only requires
> logic, but also needs  to be accessible from the application - strange
> as that may sound. Unifying the  codebase in that way lets you do the
> simple, such as display the dependencies in the  application about box
> to the complex such as easily toggle aspectj load time weaving.

Okay :-) I'll try to keep this in mind - the need will certainly arise,
it's only a question of time ...

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

[Michael Ludwig-6]

Steve Loughran schrieb am 12.06.2009 um 11:49:48 (+0100):

> we do strive to be more declarative than fully procedural languages,
> we don't have loops and so lack full turing-equivalence. There are
> also limits to what you can do in java

I think I can take this to mean "in Ant extensions (written in Java)".
So what are these limits?

Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...