>>>> Reasoning for "No Version Number":
>>>> - Allows build.xml files that use these JARs to define properties
>>>> (commons-beanutils.jar=${commons-beanutils.home}/commons-beanutils.jar)
>>>> without worrying about version numbers
>>>> - We're going to maintain API stability, right? :-)
>>>> - Versioning information should be included in the MANIFEST.MF
>>>> file inside the JAR anyway, so it's redundant in the filename
>>>
>
> I actually like having the version number on the jar.
>
> Can't the build scripts assume a pattern :
>
> commons-<component>-<version>.jar
>
> and then deal with them that way, wildcarding the <version> part when
> you don't care?
>
> To try to relate a little about why I think this, I have noticed that
> people do some strange things, like putting all jars into one directory
> for easy access/replacement/copying. So when you are dealing with a
> problem, and you get told the classpath is :
>
>
>CLASSPATH=/opt/jars/commons-beanutils.jar:/opt/jars/commons-fubar.jar:/opt/jars/woogie.jar...
>
> you have no clue whats really going on, requreing another round-trip to
> dig into the manifest. It also means when logging in production, and
> you dump your classpath to log, you can't tell either. (No, I personally
> never depend upon classpaths if I can avoid it...)
>
> Anyway, I don't feel too strongly (have been away from commons for a
> bit, so just getting back up to speed on stuff) and agree that the
> proposal would make things neater, but there is some upside to the
> version in the filename, and I think if we can arrange for it to be
> dealt with via patterns and wildcards, things might be better.
>
> geir
I would actually like to see the version number in the jar. When CJAN
becomes intelligent enough, you will be able to grab any particular
version, and it would be helpful for the version number to be in the
filename.
Scott
