This sounds like an anti-pattern to me to remove version names of the JARs. In a distant past when we were storing version-less JAR files in CVS, it was a real hell :-) That's build tools responsibilities to bring in the right artifacts in the build deliverables.
On Wed, Jul 29, 2015 at 7:41 AM, Jochen Theodorou <[email protected]> wrote: > Am 28.07.2015 14:26, schrieb Steve Amerige: > >> 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. >> > > first of all, I got the impression that the discussion so far was a tiny > bit misguided. We have the zip distribution and the jars that go to maven. > The maven artifacts of course would stay as they are, this is only about > the zip distribution. > > [...] > >> It is reasonable that the root directory include a version number. But, >> under that directory, we'd expect that the contents are version-less. >> > > The reason that we have the version numbers there basically is, that the > jars in the zip are the same jars as for maven, that's why they have > version numbers. It was not all that of a big deal before we started having > 17+ modules. > > [...] > >> 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. >> > > license information must go into the LICENSE and NOTICE (and DISCLAIMER) > files as per ASF requirements. Checksums are imho not making sense as part > of the zip, because if the zip is manipulated, then it is no use to use the > zip contents to verify the zip contents. As for the version number... I > think a file VERSION is often used for that. > > But Steve, I do have a question... > Normally the things you describe are part of the installation process as > well as making a package for the system installation. That means normally > you want a system package. Installing software packages manually in a > system with a packaging manager is usually a bad idea. > > GVM was mentioned, but GVM is not for a system-wide installation like > Steve wants it. And it is (currently) not a way to provide libraries for > usage by applications outside of a GVM package. > > As for how.... changing distSpec in assemble.groovy to include some > renames may do it. Anyone interested in doing a pull request? Of course I > would also like to hear Cedric as our current build master about this. > > bye blackdrag > > -- > Jochen "blackdrag" Theodorou > blog: http://blackdragsview.blogspot.com/ > > -- Guillaume Laforge Apache Groovy committer & PMC member Product Ninja & Advocate at Restlet <http://restlet.com> Blog: http://glaforge.appspot.com/ Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
