commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Robertson <Jeff.Robert...@magnetbanking.com>
Subject RE: [beanutils] dependencies in manifest?
Date Tue, 03 Dec 2002 16:21:18 GMT
>   Extension-List: collections logging
>   collections-Extension-Name: org.apache.commons.collections
>   collections-Specification-Version: 1.0
>   collections-Implementation-Version: 1.0
>   collections-Implementation-Vendor-Id: org.apache
>   collections-Implementation-URL: ...URL to download...
>   logging-Extension-Name: org.apache.commons.logging
>   logging-Specification-Version: 1.0
>   logging-Implementation-Version: 1.0.2
>   logging-Implementation-Vendor-Id: org.apache
>   logging-Implementation-URL: ...URL to download...
> 
> This approach doesn't lock you into a directory structure for 
> your class
> loader repository, and also lets you declare a dependency on a minimum
> implementation version.  It would require some setup (to make download
> URLs available for the packages that don't have one yet), and 
> I'm not sure
> that the class loader used in a standalone app actually utilizes these
> manifest entries.

I haven't tried that.

This appears that it would require access to the download URLs in order for
the application to run. This is an assumption that will often fail (because
of firewalls, etc) for the clients that will be using the application I am
working on. They expect to get a single package that contains everything
they need (obviously minus the JVM and server software itself!), with no
additional downloads neccessary.

Maybe our needs are sufficiently different that no one mechanism could
satisfy both of us.

Mime
View raw message