The embeddable jars are covertly named ;-) ./embeddable/groovy-all-2.4.4-indy.jar ./embeddable/groovy-all-2.4.4.jar
They aren't used (as far as I know) by groovy_home and the intention of those is to rip them out of the install and copy them around. That sets a different bar for me for expected usage patterns. The groovy_home/lib directory should not have its jars pillaged like that. I don't buy your second paragraph because it basically comes down to: if you use a maven dependency system then using maven dependencies is easy. That feels like the next best thing to a tooling-tautology. If the names hadn't been munged with versions, then Steve's example wouldn't be needing to strip them out or symlink or any of those hoops. It would be just as simple and robust as the idealized result that you need to use maven to achieve. If the only argument against referencing the manifest is the tooling, it seems more that it is so easy that elaborate tools haven't caught on. Unzipping is about the crudest way you could accomplish that, but also incredibly obvious. More refined exist very easily via google/stack overflow/etc: JDGUI, Jar Inspector, Jarzilla, and even if you had to do it from scratch one could just wrap `unzip -q -c "$1" META-INF/MANIFEST.MF`. But that is getting a bit off topic. In Steve's case of httpd, the archive had the version number, not every file within the archive. Appealing to generalities like "Most archives" is an argument from popularity and additionally it is obvious we just travel in different circles. I do have exposure to more than just java+maven platforms. Perhaps, my real take question/point is that if the groovy jars in a groovy-2.4.4/lib directory are not all groovy-2.4.4, there is something extremely bad already happening and abandon yea all hope. Having the "feature" of multiple jars of same name with different versions yields undefined behavior and and would rather just have one jar to verify than things working inconsistently. The version number for those files is either redundant or should be. --Jeff On Tue, Jul 28, 2015 at 5:04 PM, Henrik Martin <[email protected]> wrote: > > 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]> > [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 >> >> >> > >
