commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [CRYPTO]1.0.0 Release Plan
Date Wed, 13 Jul 2016 09:24:12 GMT
On 13 July 2016 at 07:04, Sun, Dapeng <dapeng.sun@intel.com> wrote:
> Copy the native files from other platforms to target is worked. I also uploaded a SNAPSHOT
version contains native of Linux and Mac. If there is no concerns, I will try to add windows
and kick off the first release.
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.0.0-SNAPSHOT/commons-crypto-1.0.0-20160713.032556-2.jar
>

That works for me on MacOSX (tested using 'java -jar
commons-crypto-1.0.0-20160713.032556-2.jar')

I think there need to be a RELEASE NOTES file (generated from the changes).
I have created an initial sample; changes.xml needs to be updated with
the OS/version support details and the RN regenerated.

However I wonder whether the Changes section should be present, given
that there is no previous release (AFAIK).
If it is needed, then it needs updating with all the other relevant fixes.

> Regards
> Dapeng
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Wednesday, July 13, 2016 12:09 AM
> To: Commons Developers List
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On 12 July 2016 at 14:54, sebb <sebbaz@gmail.com> wrote:
>> On 12 July 2016 at 14:20, Sun, Dapeng <dapeng.sun@intel.com> wrote:
>>> Separating artifacts for each native library, I think it should be same as copying
the native binary files. We also need to collect the artifacts for unpacking and bundling.
>>
>> Yes.
>>
>>> About using the 'all' artifact, users may be confused about downloading the artifacts
for all the different platforms, especially for the platforms they don't need.
>>
>> I think we could have a separate project that creates a jar containing
>> the Java classes plus all released native builds.
>>
>> AIUI the code can automatically extract the native code from the jar,
>> so it should be easy to use.
>>
>> If we also release the Java classes and native builds as separate
>> jars, then users would have the choice:
>>
>> - download the jar containing the Java classes plus all released
>> native builds
>> - download the Java classes jar plus any native builds they need
>>
>> Or maybe when releasing a native build, we could package it with the
>> Java classes.
>
> It looks like that already happens - the MacOSX installed jar includes the jnilib file.
>
>> That would give users a different choice:
>> - download the specific build for their system; this would work as is
>> - download the combined build for all released native targets
>>
>>> -----Original Message-----
>>> From: Marcelo Vanzin [mailto:vanzin@cloudera.com]
>>> Sent: Tuesday, July 12, 2016 2:09 AM
>>> To: Commons Developers List <dev@commons.apache.org>
>>> Subject: Re: [CRYPTO]1.0.0 Release Plan
>>>
>>> On Mon, Jul 11, 2016 at 2:34 AM, sebb <sebbaz@gmail.com> wrote:
>>>> However bundling multiple native binaries is going to make it tricky to release.
>>>> How will it be done? The native parts will have to be built
>>>> separately and then combined somehow.
>>>
>>> The way I'd do it is to have separate artifacts for each native library, and
then a final job that merges all those into a final "commons-crypto-all" artifact containing
all the native libraries.
>>> That would mean a single artifact ultimately deployed as part of a commons-crypto
release, but I don't know how easy it is to pull that off as far as build infrastructure goes.
>>>
>>> Another option is to actually deploy each native artifact separately, and have
the "all" artifact be just a dummy artifact that depends on all the others; so no jar merging
or anything. That might be easier.
>>> Maybe.
>>>
>>> --
>>> Marcelo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message