From: "Peter Donald" <[EMAIL PROTECTED]> > 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. >
Well, the excuse of the 3 hour hack should not be applying anymore. After all We are here after more than a year (2?) and at least 4 official releases. :-) If using this feature is so complicated, do we expect library writers to deal with the complication or are you proposing solving it for them? I am really not sure if I understand your argument here. > 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? > I would say that a big part of the problem is that the JVM people did a very bad job on educating the rest of the Java Standards on how Optional Packages where supposed to work or be managed, so everyone did its own hack with the classpath. > > 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. > Quoting from the JavaSoft documentation: Download optional packages A download optional package is a JAR files that is specified in the Class-Path header field in the manifest of another JAR files. Classes in download optional packages may be used by classes in the referencing JAR file. In a typical situation, an applet will be bundled in a JAR file whose manifest references a JAR file (or several JAR files) that will serve as an optional package for the purposes of that applet. Optional packages may reference each other in the same way. A Class-Path header might look like this, for example: Class-Path: servlet.jar infobus.jar acme/beans.jar This specifies that the classes in the files servlet.jar, infobus.jar, and acme/beans.jar will serve as optional pakcages for purposes of the classes in the JAR file whose manifest contains this header. The URLs in the Class-Path field are given relative to the URL of the JAR file of the applet or application. Unlike the case of installed optional packages, the location of the JAR files that serve as download optional packages is irrelevent. A download optional package is an optional package because it is specified as the value of the Class-Path header in another JAR file's manifest, not because it has any particular location. Another difference between installed and download optional packages is that only applets and applications bundled in a JAR file can make use of download optional packages. Applets and applications not bundled in a JAR file don't have a manifest from which to reference download optional packages. When searching for a class, the VM first searches among the classes in the system classes and in any installed optional packages. If the class is not found in either the system classes or in the installed optional packages, the VM will search for the class in any download optional packages referenced by the manifest of the application or applet. A download optional package will not be downloaded if a desired class is found among the installed optional packages, even if the download optional package is referenced by the manifest file of the applet or application. The extension mechanism will not install a download optional package in the Java 2 Runtime Environment or Java 2 SDK directory structure. Download optional packages do not become installed extentions after they have once been downloaded. Unlike installed optional packages, download optional packages cannot have any native code. End of quote. This seem to say that the JVM will do all the work. Granted, I am not sure how is this suppose to work with UserDefined ClassLoaders, but that does not aply to ant.jar since that ar is started by the JVM. > > 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. > I was not talking about JVM extensions but about $ANT_HOME/lib. > 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. > So we are just moving or incrementing the issue of managing the CLASSPATH to also managing some other ANT_LIB_PATH. Not too much of an improvement. My wish would be for ANT not requiring any special manipulation of CLASSPATH nor any aditional environment variables. > > 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. > This is just a possible interpretation. I do not see why there should be any difference between declaring tasks and declaring a group of tasks. I seems to me quite arbitrary to make such distinction. To me both should act at the same time. > 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. > Well usually these types of task use part of the project functionality to perform its job, that is why there are there and are not some generic tool somewhere else. Dividing the build process just because some tasks cannot be used in the project just creates arbitrary complexity. To me the semantics should be just the same as for <taskdef>. Cheers, Jose Alberto
