It would be of great help if ant's run classpath could be extended dynamically while it is already running in order to automatically add lacking libs whose location is (solely) given in the context of a given project. E.g. the jar cotaining a specific JDBC driver. At least the addition of a classpath parameter (as for taskdef) to the antcall task would be very usefull. At the moment it is only possible to extend the classpath (more or less) statically on the command line by means of the "-lib" option or by injecting the required libs into the lib directory located under ant's home dir. The latter approach would (usually) result in a modified default installation which may cause troubles or at least establishes customized ant installations. I tried to solve the problem with ant's existing means which results in a somehow cumbersome script that isn't completely generic since it cotains an os dependency. The sniffet from my trial looks as follows: <target name="needsdriverlib"> <sql driver="${driver}" url="${url}" userid="${userid}" password="${password}" > select * from cat </sql> </target> <target name="ensuresdriverlib"> <!-- extension .bat depends on os windows --> <exec executable="ant.bat" spawn="false"> <arg value="-lib"/> <arg value="${lib.dir}/jdbc/jars"/> <arg value="needsdriverlib"/> </exec> </target> Hopefully you found this request worth to be considered in a future version. Thanks.
Maybe the provided example that uses the sql task was not the best choice to demonstrate the problem since this task allows either the specification of a classpath attribute or element. However the point is, that this is not a common feature of any task. E.g. it lacks for - script - junit - ...
1. you actually have a directory ${user.home}/.ant/lib that can also be used to host stuff, for per-user customisation. 2. all attempts to do dynamic classpath patching in ant have stumbled up against the IDE problem; IDE-hosted ant is a very different beast and we dont want to break it by patching IDE-managed classpaths. I fear that static classpaths are an architectural feature of ant that are very hard to fix. You can try redefining tasks with a new classpath and see what happens, though you may need to pull the relevant optional jar from the shared dir first.
I know the ${user.home}/.ant/lib option. However this is per user not per project. Maybe another solution which could help a bit would be to scan a third location, e.g. a subdirectory below the the project homedir such as ${basedir}/.ant/lib. By the wy this request for extension has nothing to do with IDEs. Rather i would like to have a mean to extend a standard ant installation with project specific jars. E.g. if I write an ant script that requires the groovy libs to be installed, I could ship them together with the project and inject them in case they are not already found on the classpath (by testing for existance of a ceratin class). So the only requirement would be to have a working ant installation. That should be all. And typing ant on the command line should do the rest. Without such means, the only way I see to solve the problem is to write a bootstrap target that injects the required libs into ants home lib or user lib. Calls itself again does what it should do and than ... should it always delete the injected libs (hmmm we need to keep track of already existant libs) and finally what's about performance. Hope I made it more clear and there is still a chance for consideration of this request.
Maybe http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 can help you. This feature is proposed for Ant 1.7. Take a look at http://jtools.org/ant-classloadertask/ for the most recent ('external-task') version of this feature. Cheers Rainer
Have you thought about using -lib option of ANT? you could either provide a script that calls ANT with this aditional parameter, or setting ANT_OPTS environment variable so it passes this argument. You will get the same effect as you want.
(In reply to comment #4) > Maybe > http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 > can help you. > This feature is proposed for Ant 1.7. > Take a look at > http://jtools.org/ant-classloadertask/ > for the most recent ('external-task') version of this feature. > Cheers > Rainer Thank you for this hint. Looks like it is what I'm looking for. Do you know something about the availability of Ant 1.7?
(In reply to comment #5) > Have you thought about using -lib option of ANT? you could either provide a > script that calls ANT with this aditional parameter, or setting ANT_OPTS > environment variable so it passes this argument. > > You will get the same effect as you want. > Good proposal! However, I knew about them and was not satisfied since both solutions add an additional level of indirection. We are used to have one single environment setup for all projects and not one per project. This environment setup solely points/sets the JAVA_HOME and ANT_HOME and finally starts a clean command line shell or dosbox. Up from there developers/testers/managers(!) switch to the appropriate project directory and just type ant which should do the rest. However, until all projects share the same libraries the usage of the ANT_OPTS would be reasonable (i.e. as a third environment variable to be set).
More or less a duplicat of http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 Thanks to Rainer Noack for pointing me to this issue. However may be it would be worth to consider a third (fixed) location for looking up thirdparty libraries, e.g. ${basedir}/.ant/lib *** This bug has been marked as a duplicate of 28228 ***