On 7/28/15 8:55 AM, Jeff Adamson wrote:
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.
Not sure what you mean by the "embeddable jar", but it sounds to me like
you're arguing for having two different conventions then. Some jar files
with version numbers, and some without. I'd rather have consistency.
Virtually every jar file in existence these days is built by either
Maven, Gradle, or some similar build/dependency management tools. Since
the default behavior of these tools is to version the archives, it seems
counter productive to move away from that. Like it or not, but it has
become the industry standard.
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.
I would argue that in Steve's use case, they've added the burden by not
utilizing the build system to do the dependency management. It seems a
lot easier and a lot less error prone, to simply have your build system
download the correct Groovy version and ensure that the build depends on
that version only, rather than pushing out zip archives, unzipping them,
and then having scripts deal with stripping out the version numbers from
the jars. That seems like a much more brittle and error prone system
than simply using something like Gradle. In the most recent environments
I've worked, we've used Gradle to ensure that all developers depend on
the same versions of all build files, whether or not we're building from
the command line or from within the IDE. No need for symlinks (which
aren't that portable anyway) or renaming of anything. Our developers use
various versions of Windows, MacOS, and Linux. It would be a much harder
task to follow Steve's practice of managing symlinks across several
different types of OS'es and numerous flavors of those.
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.
The problem with the manifest is that in order to read it, you have to
unzip the archive. How many tools out there actually utilize that
feature in reality? A jar file is an archive, not much different from
any other archive type like tar, etc. Most archives contain the version
information in the file name.
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.
--Jeff
I don't remember seeing much of jar file naming with version information
from the 90s, but hey, it's been a while. Maybe my memory is failing me :-)
-H
On Tue, Jul 28, 2015 at 10:38 AM, Henrik Martin <[email protected]
<mailto:[email protected]>> 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 <http://httpd.apache.org/download.cgi>. 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
./apache-groovy-src-2.4.4-incubating.zip
./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
