ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: We need to stop the lies
Date Mon, 25 Feb 2002 05:30:09 GMT
> From: Peter Donald []
> On Sun, 24 Feb 2002 19:58, Jose Alberto Fernandez wrote:
> > The JDK spec specifies that all dependant jars are named relative to the
> > jar requiring it, and the only variable allowed is the ${os_name} or
> > something like that to work arround native libraries. So, libraries of a
> > project have no way to express dependencies on libraries that come with
> > ANT, or your AppServer, etc.
> Nope. Go read the spec.


I've seen you say this many times but never understood why. I have read extensions/spec.html
and it has the following 

Under "Optional Package Deployment", there is "Bundled optional packages are provided at the
same code base as the application and will automatically be downloaded in the case of network
applications (applets)."

Under "Bundled Optional Packages", there is 

"An application (or, more generally, JAR file) specifies the relative URLs of the optional
packages (and libraries) that it needs via the manifest attribute Class-Path. This attribute
lists the URLs to search for implementations of optional packages (or other libraries) if
they cannot be found as optional packages installed on the host Java virtual machine*. These
relative URLs may include JAR files and directories for any libraries or resources needed
by the application or optional package. Relative URLs not ending with '/' are assumed to refer
to JAR files"


"Currently, the URLs must be relative to the code base of the JAR file for security reasons.
Thus, remote optional packages will originate from the same code base as the application.
A future enhancement will leverage the facilities of the Java 2 Platform's Security APIs to
allow references to JAR files at other URLs. 

Each relative URL is resolved against the code base that the containing application or optional
package was loaded from. If the resulting URL is invalid or refers to a resource that cannot
be found then it is ignored."

All of this is handled by the VM. Can you point out where the spec deals with application
resolution of optional packages?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message