>>The only problem with this is that the user build script
>>needs to set the correct property before the antlib is activated.
>>
>>
>>
>Which I think it is not much to ask.
>
>I have a conceptual problem of usability on an antlib written like this,
>remember, in the broader sense, the antlib is written by a third party
>for the
>usage of unrelated users in unrelated projects.
>Having a classpath in there, constricts the user of the library to
>follow
>whichever layout criteria the third-party decides.
>Which does not seem to be right.
>
>
The context in which I say this is: I have a big application
(www.fuego.com) that provides ant tasks to perform most of its admin
operation,
it is a requirement to have the application installed and then define a
property "fuego.basedir" that tells where the app is installed.
The main problem is that I cannot bundle all the required files to use
the application in a single antlib, it would be extremely big and hard
to update/patch/etc. without lots of manual intervention.
My intention is to minimize the manual steps to have a fuego antlib
working, so the xmlns:fuego="antlib:fuego.tools.ant" was great. Using an
include.xml file is a good workaround but that implies that on every
build besides the xml namespace they need to do one more step, that is a
100% increase in the number or changes they need to run fuego. :)
I guess that most big application might follow this kind of path, having
a small antlib file, and refer to the dependencies that are in the
application install dir.
I completely agree that for most basic/optional (core) tasks would
include all the dependencies in the antlib, but for a big app it is not
possible. I guess my case is the one for tasks that are bundled in other
applications.
For example, if the Tomcat guys bundle their tasks with them, why should
you copy all the jasper stuff to an antlib instead of reference them
from the antlib.xml
MAriano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
|