Re: [all] Deploying components

2017-06-06 Thread Benedikt Ritter 
Hello Stian,

> Am 05.06.2017 um 18:58 schrieb Stian Soiland-Reyes :
> 
> Personally I am happy about source distributions accompanying the jars in
> Maven Central, which are actually rebuildable as opposed to the
> -source.jars.
> 
> they continue to be retrievable using Maven version mechanisms, compares to
> more fragile scripts crawling archive.apache.org (dist only contains the
> latest version).
> 
> The -bin archives are less useful, however I have used their hashes during
> RC testing to confirm the jars in staging reasonably match the RC in dist
> (this can also be achieved by simply unpacking the binary dist and
> navigating to the jars)

It’s a PITA to manually commit the archive to the distilled area. This should 
be automated as part of the release process.

Regards,
Benedikt

> 
> 
> 
> On 28 May 2017 3:01 am, "Rob Tompkins"  wrote:
> 
>> Hello all,
>> 
>> Benedikt and I were chatting last week about how the .tar and .zip
>> distributions get uploaded to nexus during "mvn deploy” and how annoying
>> that side effect of the deployment happens to be. Coincidentally, I just
>> ran across a note that  Mladen Turk added at the end of the commons-daemon
>> release guide:
>> 
>> https://github.com/apache/commons-daemon/blob/trunk/
>> HOWTO-RELEASE.txt#L41-L43 > commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43>
>> 
>> I’m thinking: (1) interesting note, knowing that the problem still exists,
>> and (2) I wonder if there would be community appetite for an attempt at
>> adding better automation to the release process. I’m betting that with a
>> little effort we probably could improve the release experience at least a
>> little.
>> 
>> Cheers,
>> -Rob


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

Re: [all] Deploying components

2017-06-05 Thread Gary Gregory 
I have used bin zips before to get to DLL files for example.

Gary

On Jun 5, 2017 9:58 AM, "Stian Soiland-Reyes"  wrote:

> Personally I am happy about source distributions accompanying the jars in
> Maven Central, which are actually rebuildable as opposed to the
> -source.jars.
>
> they continue to be retrievable using Maven version mechanisms, compares to
> more fragile scripts crawling archive.apache.org (dist only contains the
> latest version).
>
> The -bin archives are less useful, however I have used their hashes during
> RC testing to confirm the jars in staging reasonably match the RC in dist
> (this can also be achieved by simply unpacking the binary dist and
> navigating to the jars)
>
>
>
> On 28 May 2017 3:01 am, "Rob Tompkins"  wrote:
>
> > Hello all,
> >
> > Benedikt and I were chatting last week about how the .tar and .zip
> > distributions get uploaded to nexus during "mvn deploy” and how annoying
> > that side effect of the deployment happens to be. Coincidentally, I just
> > ran across a note that  Mladen Turk added at the end of the
> commons-daemon
> > release guide:
> >
> > https://github.com/apache/commons-daemon/blob/trunk/
> > HOWTO-RELEASE.txt#L41-L43  > commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43>
> >
> > I’m thinking: (1) interesting note, knowing that the problem still
> exists,
> > and (2) I wonder if there would be community appetite for an attempt at
> > adding better automation to the release process. I’m betting that with a
> > little effort we probably could improve the release experience at least a
> > little.
> >
> > Cheers,
> > -Rob
>

Re: [all] Deploying components

2017-06-05 Thread Stian Soiland-Reyes 
Personally I am happy about source distributions accompanying the jars in
Maven Central, which are actually rebuildable as opposed to the
-source.jars.

they continue to be retrievable using Maven version mechanisms, compares to
more fragile scripts crawling archive.apache.org (dist only contains the
latest version).

The -bin archives are less useful, however I have used their hashes during
RC testing to confirm the jars in staging reasonably match the RC in dist
(this can also be achieved by simply unpacking the binary dist and
navigating to the jars)



On 28 May 2017 3:01 am, "Rob Tompkins"  wrote:

> Hello all,
>
> Benedikt and I were chatting last week about how the .tar and .zip
> distributions get uploaded to nexus during "mvn deploy” and how annoying
> that side effect of the deployment happens to be. Coincidentally, I just
> ran across a note that  Mladen Turk added at the end of the commons-daemon
> release guide:
>
> https://github.com/apache/commons-daemon/blob/trunk/
> HOWTO-RELEASE.txt#L41-L43  commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43>
>
> I’m thinking: (1) interesting note, knowing that the problem still exists,
> and (2) I wonder if there would be community appetite for an attempt at
> adding better automation to the release process. I’m betting that with a
> little effort we probably could improve the release experience at least a
> little.
>
> Cheers,
> -Rob

Re: [all] Deploying components

2017-06-05 Thread sebb 
On 5 June 2017 at 12:06, Benedikt Ritter  wrote:
> Hello Rob,
>
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins :
>>
>> Hello all,
>>
>> Benedikt and I were chatting last week about how the .tar and .zip 
>> distributions get uploaded to nexus during "mvn deploy” and how annoying 
>> that side effect of the deployment happens to be. Coincidentally, I just ran 
>> across a note that  Mladen Turk added at the end of the commons-daemon 
>> release guide:
>>
>> https://github.com/apache/commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43
>>  
>> 
>>
>> I’m thinking: (1) interesting note, knowing that the problem still exists, 
>> and (2) I wonder if there would be community appetite for an attempt at 
>> adding better automation to the release process. I’m betting that with a 
>> little effort we probably could improve the release experience at least a 
>> little.
>
> Nice catch, however I alway run clean when deploying, since I don’t want 
> stale build artifacts to be deployed (this happened to me once).

Unfortunately that may not be sufficient, as it won't remove spurious
source files.

It's best to checkout the tag in a clean directory and build from there.

IMO that is what the release plugin should do, however instead it
updates the trunk version and builds from the 'unclean' workspace.
If the RC fails, then trunk has to be backdated.
Meanwhile any CI builds will have picked up the new SNAPSHOT version.

The release plugin should assume that the RC may fail, and not update
trunk until the release process succeeds.

> I’m planning to ask the maven user list on how we can improve our deployment 
> process.

They are unlikely to accept that the release plugin has limitations ...

> Regards,
> Benedikt
>
>>
>> Cheers,
>> -Rob
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [all] Deploying components

2017-06-05 Thread Rob Tompkins 

> On Jun 5, 2017, at 7:06 AM, Benedikt Ritter  wrote:
> 
> Hello Rob,
> 
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins :
>> 
>> Hello all,
>> 
>> Benedikt and I were chatting last week about how the .tar and .zip 
>> distributions get uploaded to nexus during "mvn deploy” and how annoying 
>> that side effect of the deployment happens to be. Coincidentally, I just ran 
>> across a note that  Mladen Turk added at the end of the commons-daemon 
>> release guide:
>> 
>> https://github.com/apache/commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43
>>  
>> 
>> 
>> I’m thinking: (1) interesting note, knowing that the problem still exists, 
>> and (2) I wonder if there would be community appetite for an attempt at 
>> adding better automation to the release process. I’m betting that with a 
>> little effort we probably could improve the release experience at least a 
>> little.
> 
> Nice catch, however I alway run clean when deploying, since I don’t want 
> stale build artifacts to be deployed (this happened to me once).
> 
> I’m planning to ask the maven user list on how we can improve our deployment 
> process.

Sounds good to me. I was going to play around with the commons-build-plugin to 
see what I could do with that.

> 
> Regards,
> Benedikt
> 
>> 
>> Cheers,
>> -Rob
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


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

Re: [all] Deploying components

2017-06-05 Thread Benedikt Ritter 
Hello Rob,

> Am 28.05.2017 um 03:01 schrieb Rob Tompkins :
> 
> Hello all,
> 
> Benedikt and I were chatting last week about how the .tar and .zip 
> distributions get uploaded to nexus during "mvn deploy” and how annoying that 
> side effect of the deployment happens to be. Coincidentally, I just ran 
> across a note that  Mladen Turk added at the end of the commons-daemon 
> release guide:
> 
> https://github.com/apache/commons-daemon/blob/trunk/HOWTO-RELEASE.txt#L41-L43 
> 
> 
> I’m thinking: (1) interesting note, knowing that the problem still exists, 
> and (2) I wonder if there would be community appetite for an attempt at 
> adding better automation to the release process. I’m betting that with a 
> little effort we probably could improve the release experience at least a 
> little.

Nice catch, however I alway run clean when deploying, since I don’t want stale 
build artifacts to be deployed (this happened to me once).

I’m planning to ask the maven user list on how we can improve our deployment 
process.

Regards,
Benedikt

> 
> Cheers,
> -Rob


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