On Wed, 10 Oct 2001 19:59, Jose Alberto Fernandez wrote: > > > How about external libraries being required? > > > > I think we should go with the standard java mechanisms for "Optional > > Packages" (see jdk1.3 docs) combined with the ancient Class-Path: foo.jar > > approach. This is what all new APIs are moving towards and is fairly > > flexible. About the only irritating thing is that there is no standard to > > say 2.0 is incompatible with 1.0 version of same library ;( > > I would like to explore this more. > To start with, if this mechanism is so good, why aren't we using it in ANT > already?
Ant started as a 3 hour hack on a plane (at a time when the Optional Package spec didn't exist?). It takes a considerable investment of effort to implement Optional Package management. Is it any surprise why it is not used? We don't even clearly separate bewteen container and task. Look at other specs that weren't hacks but were thought out. Servlet 1.0 had clear separation between container and servlet - yet it took till servlet 2.3 to get Optional Package handling. Why is that? > Why is our shell/batch script putting things in the CLASPATH? why do we use batch scripts? > Following this line, the correct thing to do would be to specify all the > jar dependencies for ANT core in ant.jar itself and let the JVM made up the > classpath. Hence we would be able to just do "java -jar $HOME/bin/ant.jar > $@" or equivalent. The JVM does not implement that. Go read the Optional Package spec - it is up to developer to do it. The new servlet and EJB APIs require container implement it IIRC so we should see more vendors using it. > In any case, in ANT, any additional jars should be declared in the > classpath of the tasks (which are not core) that need it. today - yes. Tomorrow I don't see any reason for that. The type library can declare it's own dependencies and leave the container to determine the best way to satisfy the dependencies. I don't see a good reason why the user should have to deal with semi-difficuly problems (like ClassPath management) when it can be automated. > > > <tasklib name="lib1" location="mydir/mytasks.jar" /> > > > > I am also -1 on specifying location. We should just give name of library > > and it can be searched for on type.lib.path or whatever. > > The problem with this approach is the assumption that every ANT user has > administration rights over its ANT installation. Although that may be the > case in most cases, there are shops that have automounted /bin directories > reflecting the standard of the shop. In such cases not be able to declare > things outside the predefined locations is a problem. Which I presume is a > problem people have with JVM extensions also. What do you do on > shared/globally-administered environments. Anyone who allows JVM extensions should be shot, burnt and stabbed ;) They are evil and the cause of pain in most cases. As a matter of fact almost all applications I write reset the "java.ext.dirs" variable to something harmless. The type.lib.path can be extended by user the same way that the header (or library) serach path for gcc can be extended. Perhaps it could be as simple as ant -L ~/my/ant/lib/path However in reality you would usually define a OS environment variable to extend it. Probably something like export ANT_LIB_PATH=~/ant-ext/lib:/opt/some-local-tool:/usr/local/another/local/tool or whatever. > I have had projects where local tasks are build as part of the project, > since these tasks need to be made available to end-users, they should be > build into a library and used within the same project. Just like I can do > with individual taskdefs today. I see importing a library and taskdefs as different beasts. Importing a library happens prioir to build file being "executed" and uses the search path etc. While taskdef does it at runtime and could theoretically load a tasklib file. That I don't mind using a location. However the import elements at top of build file definetly should not use a location/url/filename in my mind. However I would suggest that if you are building and then using tasks you should probably break them into two projects and make one depend on the other. > Notice by the way that in my above syntax the attribute "name" was a way to > declare namespaces, to use to avoid clashing. We could definetly use > something else, if we really think this type of namespace support is really > useful. am not completely sure at this point. I largely like it but I am comfortable with XML. As a few people (Conor?) pointed out it is less intuitive and much more complex if you are forced to use namespaces for tasks (aswell as for aspects, and perhaps for inter build file referencing and ...). -- Cheers, Pete -------------------------------------------------- The fact that nobody understands you doesn't mean you're an artist. --------------------------------------------------
