|
Maven Diaries |
|
[]
Why Maven uses JAR names with versions
[
jvanzyl
]
There was a discussion on the mailing list about why the Maven developers chose to mandate the use of a version for artifacts placed in the repository so I thought I would write an entry about it. There are the technical reason for the versioning JARs which allows us to easily operate on a Maven repository but there a simple human usability issue we tried to consider as well. It's very easy to tell what you are dealing with when you are looking at, say, commons-collections-2.0.jar. You know what it is without having to pry the JAR open and look at the manifest. If you cannot easily tell what it is you're looking at by just looking at an artifact you can very easily make a mistake that can cost your project a lot of time. Take for example the case where you may accidentally or inadvertently place an incompatible version of a JAR somewhere in your build. You get a ClassNotFoundException or a NoClassDefFoundError and you begin your hunt. You will eventually figure out what's causing the problem and you will most likely find the culprit JAR. What's the first question you're going to ask? The first question you're going to ask is "What version of this are we suppose to be using?". If you build your projects with Maven you get useful things like the POM placed in your JARs and the manifest is richly populated so you can find out whatever you need to know about the artifact. But if you look at a lot of artifacts distributed by third parties they usually won't contain metadata about the project and sometimes the manifest doesn't even include anything but the default two line manifest produced by Ant. Yikes! Take a look at a lot of SUN JARs or JARs from companies like Documentum. They have no useful information in the manifest. I have made mistakes like this myself in the past and have ended up having to go back to distributions and compare JAR sizes to find out what version of an artifact had slipped in. Not fun, and this almost always happens at the most inopportune of times. So the stipulation of having a version in the artifact was a decision we made not only for technical reasons but to try and help project against simple mistakes which can cost many man hours to fix. Multiply this simple mistake over all the projects using Java and you've got a lot of potential for wasted time. Some have argued that it is also a waste of time having to change version names in scripts and other project artifacts and our argument to this is that's why we made the POM. So that you have the one place to deal with your version information and we have endeavoured to make Maven take care of this burden for you in your day-to-day work. We think that you you can have the best of both worlds here. Being able to know exactly what you're looking at when looking at artifacts, which really can save you time in a dire situation, and be able to work easily with changing versions of artifacts when your projects are in flux. To allow rapid, yet safe change, across your projects while still retaining the simple feature of being able to easily distinguish what you have by simply looking at it. We really believe that this small change in practice, whereby a version is added to the artifact name, provides a great benefit. We're not trying to foist an arbitrary decision on users. We believe that this practice will really save you time and aggravation when dealing with your day-to-day development practices. +1 I remember back in the days before Maven, when we used Ant, we always made sure JARs did *not* contain version numbers, because our developers always complained about the extra work they needed whenever we imposed a version upgrade. Soon enough, though, funny errors started to occur, and many times we found out someone messed with the JAR files. So we switched back, and when we started using Maven we were glad that others thought the same. --Arik Kfir, April 22, 2005 03:38 PM
The idea of versioning jars seems to be a bad decision when dealing with a code base that is reused across many organizations or even third parties. My thoughts; why have many versions of a jar and have the overhead of managing the "copy and pasted" code when you can utilize a formalized principle like the "Open and Closed Principle". It seems to me the complexity of maintaining multiple versions is just not needed. --Brett Burch, November 15, 2007 07:40 PM
http://www.74yy.cn/2007/shengmingdetiaozhan/3434/ 生命的挑战 --fdasfdsafds, November 24, 2007 02:39 PM
cheap valium --cheap valium, August 25, 2008 09:16 PM
Post a comment
|