> 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
