[all] Deploying components

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[all] Deploying components

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 <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.

Cheers,
-Rob
Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

garydgregory
On May 27, 2017 6:01 PM, "Rob Tompkins" <[hidden email]> 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 <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.


A big +1 to making releases less painful. As long as we want to deploy to
both Apache dist folders and Nexus, that might still be a pain.

Gary


Cheers,
-Rob
Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

Rob Tompkins

> On May 27, 2017, at 9:48 PM, Gary Gregory <[hidden email]> wrote:
>
> On May 27, 2017 6:01 PM, "Rob Tompkins" <[hidden email]> 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 <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.
>
>
> A big +1 to making releases less painful. As long as we want to deploy to
> both Apache dist folders and Nexus, that might still be a pain.

Not much more painful than our site-deploy mechanics, I would think. But, that all depends on how hack-tactular you want to get with the maven-antrun-plugin. Wheeeeeeee. :-)

>
> Gary
>
>
> Cheers,
> -Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

Benedikt Ritter-4
In reply to this post by Rob Tompkins
Hello Rob,

> Am 28.05.2017 um 03:01 schrieb Rob Tompkins <[hidden email]>:
>
> 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 <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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

Rob Tompkins

> On Jun 5, 2017, at 7:06 AM, Benedikt Ritter <[hidden email]> wrote:
>
> Hello Rob,
>
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins <[hidden email]>:
>>
>> 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 <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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

sebb-2-2
In reply to this post by Benedikt Ritter-4
On 5 June 2017 at 12:06, Benedikt Ritter <[hidden email]> wrote:

> Hello Rob,
>
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins <[hidden email]>:
>>
>> 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 <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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

Stian Soiland-Reyes
In reply to this post by Rob Tompkins
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" <[hidden email]> 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 <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.
>
> Cheers,
> -Rob
Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

garydgregory
I have used bin zips before to get to DLL files for example.

Gary

On Jun 5, 2017 9:58 AM, "Stian Soiland-Reyes" <[hidden email]> 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" <[hidden email]> 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 <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.
> >
> > Cheers,
> > -Rob
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Deploying components

Benedikt Ritter-4
In reply to this post by Stian Soiland-Reyes
Hello Stian,

> Am 05.06.2017 um 18:58 schrieb Stian Soiland-Reyes <[hidden email]>:
>
> 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" <[hidden email]> 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 <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.
>>
>> Cheers,
>> -Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]