groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Adamson <>
Subject Re: Remove Version from File Names in Distributions; Add Manifest
Date Tue, 28 Jul 2015 15:55:47 GMT
My non-contributor $0.02 would be exactly the opposite Henrik, for very
similar reasons.

I would agree that the embeddable jar should include version number by
default because that is supposed to be dropped around, but the rest of the
lib is already version locked to a groovy version. If someone is mucking
around with the directory contents of the groovy lib, they already have
made a bad decision causing drift from a traceable setup.

The very argument of the maven-gradle shows how having version numbers adds
a burden to other processes. Now the build-system and non-maven consumers
of the jars need specific specialized (but common) logic to do something
that has negligible benefit. Do you trust your dependency system to have
pulled the correct versions or not? If you don't, then you should look into
other dependency management tools.
The authoritative place for version meta-data is in the jar file, not it's
name; there even is a standard place for this MANIFEST.MF.
I remember the 90's being the era when the fashion was to jam every bit of
meta-data was jammed in file names (see cvs or tarball versioning), not the
other way around. Maven is from 2001, therefore it seems more correct to
attribute version numbering file names to be a hold-over from the 90s.


On Tue, Jul 28, 2015 at 10:38 AM, Henrik Martin <> wrote:

>  I'm not part of the contributor team, so I can't speak for the Groovy
> team, but I would strongly disagree with you. If you use Maven or Gradle,
> it's easy to maintain dependencies on particular versions of jar files, and
> have your IDE immediately pick up the new version. In fact, the default
> behavior for both Maven and Gradle is to explicitly maintain version
> numbers in artifacts. Removing this would be a step back to the 90s.
> Sometimes jar files have to copied into other directories outside of their
> normal home. An example is when deploying Tomcat. Stuff like jdbc drivers
> etc typically get copied into $CATALINA_BASE/lib. It's worth gold to
> immediately be able to tell which particular version of those jar files are
> in there, vs just seeing "foobar.jar".
> I would argue that you should probably change the practice of creating
> symlinks to explicitly versioned jar files as this is obviously a pain when
> new versions are introduced.
> Just my $0.02.
> -H
> On 7/28/15 5:26 AM, Steve Amerige wrote:
> Hi all,
> Every time we take a download of the latest Groovy software, we have to do
> the same task: remove version numbers from file names.  As of the 2.4.4
> release, there are 39 files, shown below, that have the version number as
> part of the distribution.  So, why is this a problem?
>    - IDEs cannot silently be updated to use a mandated Groovy version.
>    With 2.4.4 dealing with a zero-day vulnerability issue, we want to push
>    this out.  However, the version numbers in files mean that users must
>    participate in the updating.  This is not desirable.
>    - Links that users might have at the OS level are broken with each new
>    release.
>    - Version numbers in files makes it more difficult to diff between
>    releases.
>    - Version numbers as a part of a filename is a specific case of
>    metadata as part of file names and, as such, we consider it to be a bad
>    practice.  This information is better kept in a file, preferably machine
>    readable in a format such as JSON or XML, or in manifest files that can be
>    consumed by software that might do version number validation as part of
>    security efforts in maintaining code.
>  It is reasonable that the root directory include a version number.  But,
> under that directory, we'd expect that the contents are version-less. A
> good example of a version-less Apache project is the HTTP Server
> <>. The download is presently a file
> named *httpd-2.4.16.tar.gz*, and when extracted produces a top-level
> directory named *httpd-2.4.16*.  No file name contains the version number
> string.  The two files *CHANGES *and *httpd.spec *contain the version
> number string.  I believe that Groovy should follow this example, and
> possibly go one step better by having an explicit manifest file with all
> pertinent metadata for the Groovy release that includes metadata such as
> the version number, license name, checksums of files (for security
> checking), etc.
> If you agree, how can we start the process of making this change?
> Thanks,
> Steve Amerige
>  Principal Software Developer, Fraud and Compliance Solutions Development
> SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617
> ./lib/groovy-sql-2.4.4.jar
> ./lib/groovy-testng-2.4.4.jar
> ./lib/groovy-jsr223-2.4.4.jar
> ./lib/groovy-servlet-2.4.4.jar
> ./lib/groovy-json-2.4.4.jar
> ./lib/groovy-jmx-2.4.4.jar
> ./lib/groovy-test-2.4.4.jar
> ./lib/groovy-bsf-2.4.4.jar
> ./lib/groovy-groovydoc-2.4.4.jar
> ./lib/groovy-nio-2.4.4.jar
> ./lib/groovy-console-2.4.4.jar
> ./lib/groovy-xml-2.4.4.jar
> ./lib/groovy-ant-2.4.4.jar
> ./lib/groovy-docgenerator-2.4.4.jar
> ./lib/groovy-groovysh-2.4.4.jar
> ./lib/groovy-templates-2.4.4.jar
> ./lib/groovy-swing-2.4.4.jar
> ./lib/groovy-2.4.4.jar
> ./
> ./embeddable/groovy-all-2.4.4-indy.jar
> ./embeddable/groovy-all-2.4.4.jar
> ./indy/groovy-json-2.4.4-indy.jar
> ./indy/groovy-console-2.4.4-indy.jar
> ./indy/groovy-2.4.4-indy.jar
> ./indy/groovy-sql-2.4.4-indy.jar
> ./indy/groovy-jmx-2.4.4-indy.jar
> ./indy/groovy-servlet-2.4.4-indy.jar
> ./indy/groovy-xml-2.4.4-indy.jar
> ./indy/groovy-swing-2.4.4-indy.jar
> ./indy/groovy-templates-2.4.4-indy.jar
> ./indy/groovy-ant-2.4.4-indy.jar
> ./indy/groovy-groovydoc-2.4.4-indy.jar
> ./indy/groovy-nio-2.4.4-indy.jar
> ./indy/groovy-test-2.4.4-indy.jar
> ./indy/groovy-testng-2.4.4-indy.jar
> ./indy/groovy-groovysh-2.4.4-indy.jar
> ./indy/groovy-docgenerator-2.4.4-indy.jar
> ./indy/groovy-bsf-2.4.4-indy.jar
> ./indy/groovy-jsr223-2.4.4-indy.jar

View raw message