Xindice & Ant

[Terry Rosenbaum <Te...@amicas.com>]

I'm just curious. Why do we bundle Ant
with the Xindice release? I view Ant as
a developer's tool akin to javac. We
don't bundle jdk with Xindice (granted
the jdk is not an Apache production).

Shouldn't we just remove Ant from the
Xindice distribution and say that anyone
interested in building Xindice needs to
procure and install the necessary tools
as a prerequisite?

I can't count how many copies of Ant are
floating around on my machine due to
being carried along with
various application distributions.

Is ant actually used anywhere as part
of the Xindice runtime?

-Terry

Re: Xindice & Ant

[Vadim Gritsenko <va...@verizon.net>]

Vladimir R. Bossicard wrote:

>> (non-binding) -1 for removing ant:  If you to move in this direction, 
>> you can end up in the same place where Avalon is at the moment: even 
>> some of the commiters had difficulties building avalon, not to 
>> mention users.
>
>
> Ant.jar was always present in the Avalon repository but it was 
> Avalon's  own version of Ant (see the comment 'Update Ant so that it 
> can use Xalan 2.  I sent the diff to Peter to make it in the official 
> CVS--but this gets us going in the mean time.').  If you're using 
> alternate version I can fully understand that it can lead to some 
> conflicts.


No, I never had my version of Ant installed. I never had real need, and 
this prevents versioning issue. I'm using Ant which comes with the 
project. See Cocoon as an example: the only thing it needs is JDK, 
that's it. Ant is supplied, as well as other libraries.

In avalon, IIRC, you have to download/install numerous tools/utilities 
and checkout several CVS trees which makes the whole build process 
cumbersome.

Regarding bandwidth (you mentioned in other email): Unless you change 
ant.jar on a daily basis, it really does not matter for dial-up user: on 
regular "cvs update" jar will not be downloaded.


PS Please keep name when replying, helps organizing emails...

Regards,
Vadim



> But since we only use the official release it's unlikely we will have 
> the same problems.
>
> -Vladimir

Re: Xindice & Ant

["Vladimir R. Bossicard" <vl...@bossicard.com>]

> (non-binding) -1 for removing ant:  If you to move in this direction, 
> you can end up in the same place where Avalon is at the moment: even 
> some of the commiters had difficulties building avalon, not to mention 
> users.

Ant.jar was always present in the Avalon repository but it was Avalon's 
  own version of Ant (see the comment 'Update Ant so that it can use 
Xalan 2.  I sent the diff to Peter to make it in the official CVS--but 
this gets us going in the mean time.').  If you're using alternate 
version I can fully understand that it can lead to some conflicts.

But since we only use the official release it's unlikely we will have 
the same problems.

-Vladimir

-- 
Vladimir R. Bossicard
www.bossicard.com

Re: Xindice & Ant

[Vadim Gritsenko <va...@verizon.net>]

Michael Westbay wrote:

>Vladimir R. Bossicard-san wrote:
>  
>
>>IMO ant.jar should be removed from Xindice's lib directory.
>>    
>>
>
>I agree with this.  Two years ago, while Ant was starting to be adopted for 
>Java projects, it came with the project along with a build.bat and build.sh 
>script that set the CLASSPATH before executing Ant.  It wasn't that common 
>for too many developers to have Ant in their $PATH.
>
>More modern projects take care of the compiler CLASSPATH within build.xml and 
>allow personal settings in build.properties.  Those that do this assume that 
>the developer has Ant properly installed for command-line use.  Furthermore, 
>these projects that don't rely on an external script to set the CLASSPATH are 
>generally easier to use as-is with Together/CC, Borland, and other IDE's with 
>Ant support.
>

Totally agree with this point, no environment settings should be 
required to launch build.xml (may be except ANT_HOME)

>I think that most of the Java developer community is at the point that having 
>Ant as a prerequisite is a reasonable assumption.  Unless Ant is required for 
>execution of the actual application, I don't see a need to include it.
>

(non-binding) -1 for removing ant:  If you to move in this direction, 
you can end up in the same place where Avalon is at the moment: even 
some of the commiters had difficulties building avalon, not to mention 
users.


Regards,
Vadim

Re: Xindice & Ant

[Michael Westbay <we...@users.sourceforge.net>]

Vladimir R. Bossicard-san wrote:
>
> IMO ant.jar should be removed from Xindice's lib directory.

I agree with this.  Two years ago, while Ant was starting to be adopted for 
Java projects, it came with the project along with a build.bat and build.sh 
script that set the CLASSPATH before executing Ant.  It wasn't that common 
for too many developers to have Ant in their $PATH.

More modern projects take care of the compiler CLASSPATH within build.xml and 
allow personal settings in build.properties.  Those that do this assume that 
the developer has Ant properly installed for command-line use.  Furthermore, 
these projects that don't rely on an external script to set the CLASSPATH are 
generally easier to use as-is with Together/CC, Borland, and other IDE's with 
Ant support.

I think that most of the Java developer community is at the point that having 
Ant as a prerequisite is a reasonable assumption.  Unless Ant is required for 
execution of the actual application, I don't see a need to include it.

-- 
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home:           http://www.seaple.icc.ne.jp/~westbay
Commentary:     http://www.japanesebaseball.com/forum/

Re: Xindice & Ant

["Vladimir R. Bossicard" <vl...@bossicard.com>]

> Not being a part of the team I can't speak for them, but I bundle ant
> with my source distributions because I want to avoid ant version
> dependencies.

well I can surely understand your point.  But you may have some tricky 
CLASSPATH problems if you have your own ant jar in your classpath. If a 
project wants to keep an ant.jar in its lib directory, fine but this 
version should at least be the latest official release (which is not the 
case with Xindice right now).

IMO ant.jar should be removed from Xindice's lib directory.

-Vladimir


-- 
Vladimir R. Bossicard
www.bossicard.com

Re: Xindice & Ant

[Gary Shea <sh...@gtsdesign.com>]

On Thu, 17 Oct 2002, at 14:49 [-0400], Terry Rosenbaum (Terry@amicas.com) wrote:
> I'm just curious. Why do we bundle Ant
> with the Xindice release? I view Ant as
> a developer's tool akin to javac. We
> don't bundle jdk with Xindice (granted
> the jdk is not an Apache production).
>
> Shouldn't we just remove Ant from the
> Xindice distribution and say that anyone
> interested in building Xindice needs to
> procure and install the necessary tools
> as a prerequisite?
>
> I can't count how many copies of Ant are
> floating around on my machine due to
> being carried along with
> various application distributions.
>
> Is ant actually used anywhere as part
> of the Xindice runtime?
>
> -Terry

Not being a part of the team I can't speak for them, but I bundle ant
with my source distributions because I want to avoid ant version
dependencies.  With OS software, which is dependent on a community for
maintenance, you want to make the barriers to participation as low as
possible.  If someone tries to build Xindice and it doesn't work, they
may never try again.  If the cost of hooking 'em is a 716K jar file, no
problem.  At CompUSA this week I see a 30 Gig 7600 RPM drive for $50.
That drive will hold a LOT of copies of ant.jar ;)

	Gary