Nick Burch <apache <at> gagravarr.org> writes: > You can grab 3.9 from http://www.apache.org/dyn/closer.cgi/poi/release/bin/
I tried downloading 3.9, and commons-codec is indeed in there. But it's in a separate jar in the lib subdirectory. So I still need to explicitly include it in my classpath to pick it up - whereas, when I combined the 3-8 jar and the commons-codec jar into a single poi.jar containing poi and all its dependecies, I only needed a single classpath entry for poi. I like having a consistent way to deploy my app with only 2 classpath entries - one for the app's jar and one for the poi library stuff it depends on. The main app is C code that calls poi via JNI to a 'poijni' wrapper around poi, and I don't want to have to change the classpath in the C code just because I've upgraded poi. But that seems to be at odds with the way Apache releases its stuff. In fact, looking back, even poi-3.2 had a lib subdirectory with other jars (I guess I'm just not referencing poi stuff that references those jars). So, is this a conflict between 'standard' Java practices for releasing libraries, and my preference for convenience? Or am I free to release this stuff in any form that makes me happy (i.e. is there no standard for this)? I can see where a big Java deployment wouldn't use jars at all - just installing all classes into a single tree. That'd solve the problem too. Recommendations? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
