groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Laforge <glafo...@gmail.com>
Subject Re: Remove Version from File Names in Distributions; Add Manifest
Date Wed, 29 Jul 2015 07:58:22 GMT
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 <blackdrag@gmx.org> 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>

Mime
View raw message