Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4BEEE945.5050107@callenish.com>
Date: Sat, 15 May 2010 11:34:45 -0700
From: Bruce Atherton <bruce@callenish.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: dev@ant.apache.org
Subject: Re: Ant source structure and ant*.jar build products
References: <hsk3j3$7h7$1@dough.gmane.org> <4BEDD539.8070506@gmx.de>
In-Reply-To: <4BEDD539.8070506@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 14/05/2010 3:56 PM, Antoine Levy-Lambert wrote:
> Jesse Glick wrote:
>    
>> In relation to
>> <https://issues.apache.org/bugzilla/show_bug.cgi?id=49287>:
>>
>> Ironically enough, I find the Ant build script to be a poor example of
>> an Ant script. The system of compiling certain classes and not others
>> according to classpath availability, and then packing classes to
>> different JARs, is difficult to understand and debug, and it is too
>> easy to accidentally put a class in the wrong JAR.
>>
>> Would be much easier to manage (and possibly more friendly to IDEs) if
>> classes were split into several physical source roots.

Multiple source trees are easy with modern IDEs but make things trickier 
moving between directories with a text editor. This model of breaking up 
source code into modules is successful because the modules have 
something in common, and if you are working in one module there will be 
(ideally) minimal dependencies on other modules so you don't have to 
jump around much. That isn't true in this case. The JARs are divided 
based on a couple of non-module reasons. When we want modules, we use 
antlibs.

Antoine has already identified one reason we break the jars up: 
dependencies on other libraries that we don't ship. Then there is the 
core/optional divide.

Stefan can correct me if I'm wrong, but I think the original thinking 
was that way back when, people were commonly embedding bits and pieces 
of ant in their programs to get a limited form of dependency injection. 
This was before Spring popularized the concept. Avalon had it 
(PicoContainer?), but you had to program your whole system to Avalon 
whereas embedding Ant was more lightweight, particularly if all those 
optional tasks that contain half a dozen VCS tasks (among other thiings) 
were left out in an optional tasks jar file. So separating out ant core 
to get the XML interpretation for connecting the pieces of your 
application and getting a bunch of handy utility tasks at the same time 
seemed like a good way to go.

I think now, if people embed Ant they treat it as more of a 
script-engine black box, rather than picking and choosing among the 
pieces. We've pulled the little used optional tasks out into antlibs, so 
they are already modules. To me, the need for a split between core and 
optional has gone away.

I'm not sure how this related to bootstrap-ant, I haven't looked at that 
for a long time.

Anyway, my point is that if we go for one big jar and include fetch.xml 
behaviour in the standard build, then we don't need to break the source 
directories apart.

>
> there is a problem with some libraries such as NetRexx or jai which have
> non BSD licenses. I think nearly all other dependencies can be
> downloaded using ant -f fetch.xml.
>    

I think we should have a vote on moving any tasks into their own antlibs 
if we can't download the dependencies. A criteria for shipping ant 
should be that all the tasks we ship with ant itself should be usable 
just based on simple instructions for getting ant up and running. In 
other words, instructions like:

         1. download ant.1x.y.zip from here
         2. uncompress into ANT_HOME directory
         3. cd to ANT_HOME
         4. run bin/ant -f fetch.xml -Ddest=optional
         5. add ANT_HOME/bin to your PATH

should result in a fully functional version of ant running all the tasks 
we claim to ship with. Of course, some additional dependencies may be 
necessary (different scripting languages for example, jython is not 
included by default right now) but all the tasks should be usable for 
something.

So my feeling is that the netrexx and image tasks should move to their 
own antlibs unless IBM or Oracle are willing to redistribute freely. I 
think netrexx probably should be an antlib anyway, but image is probably 
more widely used so it is too bad users of it would need an extra 
download step. Then again they already need to do some extra work thanks 
to the JAI dependency.

BTW, it seems a terrible oversite that fetch.xml is only mentioned on 
the Install page as a file that is part of the ant distribution, and is 
not outlined as one of the steps you are likely to want to perform when 
installing ant. I'll fix this.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org