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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
