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. It will also break any script or program that creates classpaths by using jar names. And it will break the explicit CLASSPATH env variables and manifest attributes once again every time you upgrade - since the jar name will change. 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. 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. 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 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. .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. 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 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 jar in a system creates huge problems. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
