Costin Manolache <[EMAIL PROTECTED]> wrote on 02/03/2003 03:12:55 AM:
> On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: > > > Having a file encode <project>-<artifact>-<version>.type has been > very useful for us. > > > > Yes, it's often different from what the project creates and > distributes, but I (and others) > > have been bitten by > > commons-logging.jar, struts.jar, junit.jar so many times, that > seeing log4j-1.2.5.jar is a > > godsend. > > Yes, but I already mentioned that it can easily break features that work: > if a project uses Classpath attributes in the manifest ( a legal option > that simplifies setup - you may like it or not ) - then some things will > stop working. Having a versioned copy of the jar file around doesn't break anything that already exists. No-one is saying that people should remove their old stuff. > It will also break any script or program that creates classpaths by using > jar names. As will changing the directory it's in, the file extension etc. > And it will break the explicit CLASSPATH env variables and manifest > attributes once again every time you upgrade - since the jar name will > change. You mean people still specify CLASSPATH env variables. Yick. But, again, if you 'upgrade' you don't have to remove the old files. > It'll also break Ant build files that use the jar name - just do a grep > on jakarta and you'll find how many they are. And many of those are the ones people can't be bothered setting up. Most of commons for example is a PITA to build. I tried recently to quickly get commons-modeler going for a Tomcat connector, and it was a joke. Try building struts from source, the setup is a bitch. > All those problems can only be solved with the active participation > of the projects - by implementing whatever code is needed to support > filenames that change. For Classpath attributes - that's not possible, > so project will have to agree to stop using this (nice IMO ) feature. Not necessarily. If the manifest is built by a tool, it can automatically place the correct names in the classpath entry for you. > It doesn't matter how nice the versioned filename may look or > how much it can simplify maven code - if it breaks the code of the Costin, I'm not speaking about maven code here. In fact, I'm not talking about any code at all. > project ( sometimes in subtle ways - if ant or a project won't find a jar, > it may disable a feature ) > > It is also redundant information - each jar has a well-defined Manifest > that should include version. Really. Go read all the manifests on www.ibiblio.org/maven/*.jar and tell me how many: a) Have a valid manifest b) Have a license in the jar c) Have code from other projects contained within Believe me, the actual jars that are distributed by most projects do not come packaged ready for binary distribution. Take for example commons-logging 1.0.2 and the manifest in it's jar, which has: Class-Path: log4j.jar log4j-core.jar in it. > .so files are versioned - that would be the perfect argument to convince > people to adopt this naming scheme. But think what happens if someone > takes a .so file that was shiped with an application, and renames it to > something he feels is nicer. The app will just stop working. You can't > mess with a project distribution files without the risk of breaking > something. Nor should you just 'mess with a project distribution files' and expect things to still work. > Many people like this naming convention - but they can't impose it > to everyone. I'm more then willing to accept and support this naming Call your jars what you like. Noone is 'imposing' it on you. > scheme - my only condition is to be the result of an informed decision > by the apache developer community. ( the breakages are just 2 simple > examples - there are many other arguments in both sides ) > > BTW - an important thing to keep in mind is that in many cases the > latest version of a .jar may fix security bugs - so it shouldn't > just pick the buggy jar. Having multiple versions of the same What are you talking about here? What 'shouldn't just pick the buggy jar'? If something goes about picking new versions of jars, that I've gone to the trouble to specify, I'm going to be very upset. If I've asked for 'the latest', fair enough. > jar in a system creates huge problems. Having multiple versions of the same jar in many 'systems' is not an issue. Classloader isolation exists for a reason. Imagine a servlet engine where you can only have one copy of struts.jar. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
