You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2016/01/05 18:14:57 UTC
Re: [all] Commons Parent - detach src/bin artifacts?
An alternative approach might be to leave the POM as is, and create a
separate script to download the source/binary bundles from Nexus to
the dist/dev area, and then delete them from Nexus.
On 22 December 2015 at 08:39, Pascal Schumacher
<pa...@gmx.net> wrote:
> Thanks for the explanation and sorry for the noise.
>
> Cheers,
> Pascal
>
>
> Am 22.12.2015 um 09:28 schrieb Luc Maisonobe:
>>
>> Le 22/12/2015 09:14, Pascal Schumacher a écrit :
>>>
>>> I agree.
>>>
>>> Maybe I misunderstand the issue, but please continue to attach sources
>>> to maven central releases. It's very helpful when the IDE can
>>> automatically download the source of jar and display it.
>>
>> This is already done.
>> There is a difference between the source distribution in the zip file
>> and the source jar. The former contains everything necessary to rebuild,
>> the second contains only the source for the sake of IDE auto-completion
>> and similar features.
>>
>> What we are talking about here is removing the source and binary zip,
>> not the source and binary jar.
>>
>> best regards,
>> Luc
>>
>>> Thanks,
>>> Pascal
>>>
>>> Am 21.12.2015 um 23:24 schrieb Christopher:
>>>>
>>>> Why detach them at all? Why not permit them to be uploaded to Maven
>>>> Central?
>>>> It may not be as useful for Java builds, but Maven repository isn't
>>>> designed to hold only jars. It can hold any type of artifact.
>>>>
>>>> On Mon, Dec 21, 2015 at 3:30 AM Emmanuel Bourg <eb...@apache.org>
>>>> wrote:
>>>>
>>>>> Le 20/12/2015 23:06, Emmanuel Bourg a écrit :
>>>>>
>>>>>> I've tested with JEXL and it seems to work
>>>>>> fine, I haven't noticed undesirable side effects.
>>>>>
>>>>> Actually there is one side effect: the .sha1 and .md5 files for the
>>>>> src/bin archives no longer come for free (they are currently generated
>>>>> when the archives are deployed in the local repository). So if we
>>>>> detach
>>>>> the files we should compensate with an explicit generation of the
>>>>> checksums using the antrun plugin immediately after the assembly
>>>>> plugin.
>>>>>
>>>>> Emmanuel Bourg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 5/01/2016 18:56, Phil Steitz a écrit :
> That could probably be scripted in maven somehow, like it is rigged
> for the site build.
I'm experimenting with this idea currently. I use the antrun plugin
to create a target/dist.apache.org directory with the bin/src archives
and the release notes ready to be committed (in a next step I'll also
try to commit them). But I'm blocked by another side effect of
detaching the assemblies, they are no longer GPG signed :(
Here is the Maven snippet I use:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<!-- Prepare the distribution directory -->
<mkdir dir="target/dist.apache.org/source"/>
<mkdir dir="target/dist.apache.org/binaries"/>
<copy todir="target/dist.apache.org">
<fileset dir="." includes="RELEASE*NOTES*"/>
</copy>
<copy todir="target/dist.apache.org/binaries">
<fileset dir="target" includes="*-bin.*"/>
</copy>
<copy todir="target/dist.apache.org/source">
<fileset dir="target" includes="*-src.*"/>
</copy>
<checksum algorithm="md5" format="MD5SUM">
<fileset dir="target/dist.apache.org/source" includes="*.zip,*.tar.gz"/>
<fileset dir="target/dist.apache.org/binaries" includes="*.zip,*.tar.gz"/>
</checksum>
<checksum algorithm="sha1" format="MD5SUM">
<fileset dir="target/dist.apache.org/source" includes="*.zip,*.tar.gz"/>
<fileset dir="target/dist.apache.org/binaries" includes="*.zip,*.tar.gz"/>
</checksum>
</target>
</configuration>
</execution>
</executions>
</plugin>
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by Matt Benson <gu...@gmail.com>.
Did this thread start out about distribution artifacts and end up
about asc.md5 and asc.sha1? AFAIK the latter problem is now taken care
of by Nexus, which is why the recent [weaver] RC was not affected by
it. Most likely [weaver] will differ from other candidates regarding
the distribution artifacts as well; as a multimodule project it
required a lot of non-default setup to begin with.
Matt
On Tue, Jan 5, 2016 at 5:36 PM, sebb <se...@gmail.com> wrote:
> On 5 January 2016 at 21:30, Luc Maisonobe <lu...@spaceroots.org> wrote:
>> Le 05/01/2016 22:26, Emmanuel Bourg a écrit :
>>> Le 5/01/2016 21:42, Phil Steitz a écrit :
>>>
>>>> Can you add file specs at the end to specify the .asc.md5 and
>>>> other cruft
>>>
>>> I didn't see any .asc.md5 file when releasing JEXL, I guess this issue
>>> has been solved now?
>>
>> I noticed the same thing when staging [math] artifacts on Nexus.
>> I only had to remove the bin and src zip and tar.gz files.
>
> However IO has the cruft:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1136/commons-io/commons-io/2.5/
>
> But Weaver does not:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1132/org/apache/commons/
>
> Maybe it depends which version of Maven was used to do the build?
>
>> best regards,
>> Luc
>>
>>>
>>> Emmanuel Bourg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by sebb <se...@gmail.com>.
On 5 January 2016 at 21:30, Luc Maisonobe <lu...@spaceroots.org> wrote:
> Le 05/01/2016 22:26, Emmanuel Bourg a écrit :
>> Le 5/01/2016 21:42, Phil Steitz a écrit :
>>
>>> Can you add file specs at the end to specify the .asc.md5 and
>>> other cruft
>>
>> I didn't see any .asc.md5 file when releasing JEXL, I guess this issue
>> has been solved now?
>
> I noticed the same thing when staging [math] artifacts on Nexus.
> I only had to remove the bin and src zip and tar.gz files.
However IO has the cruft:
https://repository.apache.org/content/repositories/orgapachecommons-1136/commons-io/commons-io/2.5/
But Weaver does not:
https://repository.apache.org/content/repositories/orgapachecommons-1132/org/apache/commons/
Maybe it depends which version of Maven was used to do the build?
> best regards,
> Luc
>
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 05/01/2016 22:26, Emmanuel Bourg a écrit :
> Le 5/01/2016 21:42, Phil Steitz a écrit :
>
>> Can you add file specs at the end to specify the .asc.md5 and
>> other cruft
>
> I didn't see any .asc.md5 file when releasing JEXL, I guess this issue
> has been solved now?
I noticed the same thing when staging [math] artifacts on Nexus.
I only had to remove the bin and src zip and tar.gz files.
best regards,
Luc
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 5/01/2016 21:42, Phil Steitz a écrit :
> Can you add file specs at the end to specify the .asc.md5 and
> other cruft
I didn't see any .asc.md5 file when releasing JEXL, I guess this issue
has been solved now?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by sebb <se...@gmail.com>.
On 5 January 2016 at 20:42, Phil Steitz <ph...@gmail.com> wrote:
> On 1/5/16 1:24 PM, sebb wrote:
>> On 5 January 2016 at 17:56, Phil Steitz <ph...@gmail.com> wrote:
>>> On 1/5/16 10:14 AM, sebb wrote:
>>>> An alternative approach might be to leave the POM as is, and create a
>>>> separate script to download the source/binary bundles from Nexus to
>>>> the dist/dev area, and then delete them from Nexus.
>>> Seems roundabout to me.
>> Is hacking the POM better?
>>
>>> As RM, I prefer to just commit artifacts
>>> that I have tested locally to svn, run a VOTE on exactly these
>>> artifacts and then just svn move them to release.
>> I'm not proposing changing where the VOTE files are staged.
>
> But how exactly do they get there? Who does the commit? What kind
> of script? If it is a shell script, I already have those working
> fine locally (checked in for the components I have recently RM-ed).
> The only annoyance is getting rid of the junk in the Nexus staging
> thingy and playing with the GUI there to release to central.
>>
>>> Automating
>>> delete of Nexus cruft would be wonderful if there is a way to do
>>> it.
>> Nexus allows DELETE (with suitable auth creds)
>>
>> $ curl --user user:pass --request DELETE URL
>>
>> The URL is of the form:
>>
>> https://repository.apache.org/service/local/repositories/orgapachecommons-1120/content/commons-net/commons-net/3.4/
>
> Cool! Can you add file specs at the end to specify the .asc.md5 and
> other cruft to selectively kill so you can just release what you
> want?
Sorry, I only copied the URL prefix from my script.
You need to add the filename to the end.
> Or do you have to kill the whole repo?
No. That would not be useful here ...
> Phil
>>
>>> I know some people don't like having to locally script the move
>>> of build artifacts into a local svn checkout of /dist/dev. That
>>> could probably be scripted in maven somehow, like it is rigged for
>>> the site build.
>>> Phil
>>>> On 22 December 2015 at 08:39, Pascal Schumacher
>>>> <pa...@gmx.net> wrote:
>>>>> Thanks for the explanation and sorry for the noise.
>>>>>
>>>>> Cheers,
>>>>> Pascal
>>>>>
>>>>>
>>>>> Am 22.12.2015 um 09:28 schrieb Luc Maisonobe:
>>>>>> Le 22/12/2015 09:14, Pascal Schumacher a écrit :
>>>>>>> I agree.
>>>>>>>
>>>>>>> Maybe I misunderstand the issue, but please continue to attach sources
>>>>>>> to maven central releases. It's very helpful when the IDE can
>>>>>>> automatically download the source of jar and display it.
>>>>>> This is already done.
>>>>>> There is a difference between the source distribution in the zip file
>>>>>> and the source jar. The former contains everything necessary to rebuild,
>>>>>> the second contains only the source for the sake of IDE auto-completion
>>>>>> and similar features.
>>>>>>
>>>>>> What we are talking about here is removing the source and binary zip,
>>>>>> not the source and binary jar.
>>>>>>
>>>>>> best regards,
>>>>>> Luc
>>>>>>
>>>>>>> Thanks,
>>>>>>> Pascal
>>>>>>>
>>>>>>> Am 21.12.2015 um 23:24 schrieb Christopher:
>>>>>>>> Why detach them at all? Why not permit them to be uploaded to Maven
>>>>>>>> Central?
>>>>>>>> It may not be as useful for Java builds, but Maven repository isn't
>>>>>>>> designed to hold only jars. It can hold any type of artifact.
>>>>>>>>
>>>>>>>> On Mon, Dec 21, 2015 at 3:30 AM Emmanuel Bourg <eb...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Le 20/12/2015 23:06, Emmanuel Bourg a écrit :
>>>>>>>>>
>>>>>>>>>> I've tested with JEXL and it seems to work
>>>>>>>>>> fine, I haven't noticed undesirable side effects.
>>>>>>>>> Actually there is one side effect: the .sha1 and .md5 files for the
>>>>>>>>> src/bin archives no longer come for free (they are currently generated
>>>>>>>>> when the archives are deployed in the local repository). So if we
>>>>>>>>> detach
>>>>>>>>> the files we should compensate with an explicit generation of the
>>>>>>>>> checksums using the antrun plugin immediately after the assembly
>>>>>>>>> plugin.
>>>>>>>>>
>>>>>>>>> Emmanuel Bourg
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>> ---------------------------------------------------------------------
>> 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
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by Phil Steitz <ph...@gmail.com>.
On 1/5/16 1:24 PM, sebb wrote:
> On 5 January 2016 at 17:56, Phil Steitz <ph...@gmail.com> wrote:
>> On 1/5/16 10:14 AM, sebb wrote:
>>> An alternative approach might be to leave the POM as is, and create a
>>> separate script to download the source/binary bundles from Nexus to
>>> the dist/dev area, and then delete them from Nexus.
>> Seems roundabout to me.
> Is hacking the POM better?
>
>> As RM, I prefer to just commit artifacts
>> that I have tested locally to svn, run a VOTE on exactly these
>> artifacts and then just svn move them to release.
> I'm not proposing changing where the VOTE files are staged.
But how exactly do they get there? Who does the commit? What kind
of script? If it is a shell script, I already have those working
fine locally (checked in for the components I have recently RM-ed).
The only annoyance is getting rid of the junk in the Nexus staging
thingy and playing with the GUI there to release to central.
>
>> Automating
>> delete of Nexus cruft would be wonderful if there is a way to do
>> it.
> Nexus allows DELETE (with suitable auth creds)
>
> $ curl --user user:pass --request DELETE URL
>
> The URL is of the form:
>
> https://repository.apache.org/service/local/repositories/orgapachecommons-1120/content/commons-net/commons-net/3.4/
Cool! Can you add file specs at the end to specify the .asc.md5 and
other cruft to selectively kill so you can just release what you
want? Or do you have to kill the whole repo?
Phil
>
>> I know some people don't like having to locally script the move
>> of build artifacts into a local svn checkout of /dist/dev. That
>> could probably be scripted in maven somehow, like it is rigged for
>> the site build.
>> Phil
>>> On 22 December 2015 at 08:39, Pascal Schumacher
>>> <pa...@gmx.net> wrote:
>>>> Thanks for the explanation and sorry for the noise.
>>>>
>>>> Cheers,
>>>> Pascal
>>>>
>>>>
>>>> Am 22.12.2015 um 09:28 schrieb Luc Maisonobe:
>>>>> Le 22/12/2015 09:14, Pascal Schumacher a écrit :
>>>>>> I agree.
>>>>>>
>>>>>> Maybe I misunderstand the issue, but please continue to attach sources
>>>>>> to maven central releases. It's very helpful when the IDE can
>>>>>> automatically download the source of jar and display it.
>>>>> This is already done.
>>>>> There is a difference between the source distribution in the zip file
>>>>> and the source jar. The former contains everything necessary to rebuild,
>>>>> the second contains only the source for the sake of IDE auto-completion
>>>>> and similar features.
>>>>>
>>>>> What we are talking about here is removing the source and binary zip,
>>>>> not the source and binary jar.
>>>>>
>>>>> best regards,
>>>>> Luc
>>>>>
>>>>>> Thanks,
>>>>>> Pascal
>>>>>>
>>>>>> Am 21.12.2015 um 23:24 schrieb Christopher:
>>>>>>> Why detach them at all? Why not permit them to be uploaded to Maven
>>>>>>> Central?
>>>>>>> It may not be as useful for Java builds, but Maven repository isn't
>>>>>>> designed to hold only jars. It can hold any type of artifact.
>>>>>>>
>>>>>>> On Mon, Dec 21, 2015 at 3:30 AM Emmanuel Bourg <eb...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Le 20/12/2015 23:06, Emmanuel Bourg a écrit :
>>>>>>>>
>>>>>>>>> I've tested with JEXL and it seems to work
>>>>>>>>> fine, I haven't noticed undesirable side effects.
>>>>>>>> Actually there is one side effect: the .sha1 and .md5 files for the
>>>>>>>> src/bin archives no longer come for free (they are currently generated
>>>>>>>> when the archives are deployed in the local repository). So if we
>>>>>>>> detach
>>>>>>>> the files we should compensate with an explicit generation of the
>>>>>>>> checksums using the antrun plugin immediately after the assembly
>>>>>>>> plugin.
>>>>>>>>
>>>>>>>> Emmanuel Bourg
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by sebb <se...@gmail.com>.
On 5 January 2016 at 17:56, Phil Steitz <ph...@gmail.com> wrote:
> On 1/5/16 10:14 AM, sebb wrote:
>> An alternative approach might be to leave the POM as is, and create a
>> separate script to download the source/binary bundles from Nexus to
>> the dist/dev area, and then delete them from Nexus.
>
> Seems roundabout to me.
Is hacking the POM better?
> As RM, I prefer to just commit artifacts
> that I have tested locally to svn, run a VOTE on exactly these
> artifacts and then just svn move them to release.
I'm not proposing changing where the VOTE files are staged.
> Automating
> delete of Nexus cruft would be wonderful if there is a way to do
> it.
Nexus allows DELETE (with suitable auth creds)
$ curl --user user:pass --request DELETE URL
The URL is of the form:
https://repository.apache.org/service/local/repositories/orgapachecommons-1120/content/commons-net/commons-net/3.4/
> I know some people don't like having to locally script the move
> of build artifacts into a local svn checkout of /dist/dev. That
> could probably be scripted in maven somehow, like it is rigged for
> the site build.
> Phil
>>
>> On 22 December 2015 at 08:39, Pascal Schumacher
>> <pa...@gmx.net> wrote:
>>> Thanks for the explanation and sorry for the noise.
>>>
>>> Cheers,
>>> Pascal
>>>
>>>
>>> Am 22.12.2015 um 09:28 schrieb Luc Maisonobe:
>>>> Le 22/12/2015 09:14, Pascal Schumacher a écrit :
>>>>> I agree.
>>>>>
>>>>> Maybe I misunderstand the issue, but please continue to attach sources
>>>>> to maven central releases. It's very helpful when the IDE can
>>>>> automatically download the source of jar and display it.
>>>> This is already done.
>>>> There is a difference between the source distribution in the zip file
>>>> and the source jar. The former contains everything necessary to rebuild,
>>>> the second contains only the source for the sake of IDE auto-completion
>>>> and similar features.
>>>>
>>>> What we are talking about here is removing the source and binary zip,
>>>> not the source and binary jar.
>>>>
>>>> best regards,
>>>> Luc
>>>>
>>>>> Thanks,
>>>>> Pascal
>>>>>
>>>>> Am 21.12.2015 um 23:24 schrieb Christopher:
>>>>>> Why detach them at all? Why not permit them to be uploaded to Maven
>>>>>> Central?
>>>>>> It may not be as useful for Java builds, but Maven repository isn't
>>>>>> designed to hold only jars. It can hold any type of artifact.
>>>>>>
>>>>>> On Mon, Dec 21, 2015 at 3:30 AM Emmanuel Bourg <eb...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Le 20/12/2015 23:06, Emmanuel Bourg a écrit :
>>>>>>>
>>>>>>>> I've tested with JEXL and it seems to work
>>>>>>>> fine, I haven't noticed undesirable side effects.
>>>>>>> Actually there is one side effect: the .sha1 and .md5 files for the
>>>>>>> src/bin archives no longer come for free (they are currently generated
>>>>>>> when the archives are deployed in the local repository). So if we
>>>>>>> detach
>>>>>>> the files we should compensate with an explicit generation of the
>>>>>>> checksums using the antrun plugin immediately after the assembly
>>>>>>> plugin.
>>>>>>>
>>>>>>> Emmanuel Bourg
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons Parent - detach src/bin artifacts?
Posted by Phil Steitz <ph...@gmail.com>.
On 1/5/16 10:14 AM, sebb wrote:
> An alternative approach might be to leave the POM as is, and create a
> separate script to download the source/binary bundles from Nexus to
> the dist/dev area, and then delete them from Nexus.
Seems roundabout to me. As RM, I prefer to just commit artifacts
that I have tested locally to svn, run a VOTE on exactly these
artifacts and then just svn move them to release. Automating
delete of Nexus cruft would be wonderful if there is a way to do
it. I know some people don't like having to locally script the move
of build artifacts into a local svn checkout of /dist/dev. That
could probably be scripted in maven somehow, like it is rigged for
the site build.
Phil
>
> On 22 December 2015 at 08:39, Pascal Schumacher
> <pa...@gmx.net> wrote:
>> Thanks for the explanation and sorry for the noise.
>>
>> Cheers,
>> Pascal
>>
>>
>> Am 22.12.2015 um 09:28 schrieb Luc Maisonobe:
>>> Le 22/12/2015 09:14, Pascal Schumacher a écrit :
>>>> I agree.
>>>>
>>>> Maybe I misunderstand the issue, but please continue to attach sources
>>>> to maven central releases. It's very helpful when the IDE can
>>>> automatically download the source of jar and display it.
>>> This is already done.
>>> There is a difference between the source distribution in the zip file
>>> and the source jar. The former contains everything necessary to rebuild,
>>> the second contains only the source for the sake of IDE auto-completion
>>> and similar features.
>>>
>>> What we are talking about here is removing the source and binary zip,
>>> not the source and binary jar.
>>>
>>> best regards,
>>> Luc
>>>
>>>> Thanks,
>>>> Pascal
>>>>
>>>> Am 21.12.2015 um 23:24 schrieb Christopher:
>>>>> Why detach them at all? Why not permit them to be uploaded to Maven
>>>>> Central?
>>>>> It may not be as useful for Java builds, but Maven repository isn't
>>>>> designed to hold only jars. It can hold any type of artifact.
>>>>>
>>>>> On Mon, Dec 21, 2015 at 3:30 AM Emmanuel Bourg <eb...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Le 20/12/2015 23:06, Emmanuel Bourg a écrit :
>>>>>>
>>>>>>> I've tested with JEXL and it seems to work
>>>>>>> fine, I haven't noticed undesirable side effects.
>>>>>> Actually there is one side effect: the .sha1 and .md5 files for the
>>>>>> src/bin archives no longer come for free (they are currently generated
>>>>>> when the archives are deployed in the local repository). So if we
>>>>>> detach
>>>>>> the files we should compensate with an explicit generation of the
>>>>>> checksums using the antrun plugin immediately after the assembly
>>>>>> plugin.
>>>>>>
>>>>>> Emmanuel Bourg
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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