You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Tompkins <ch...@gmail.com> on 2017/05/28 01:01:25 UTC
[all] Deploying components
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
Re: [all] Deploying components
Posted by Rob Tompkins <ch...@gmail.com>.
> On Jun 5, 2017, at 7:06 AM, Benedikt Ritter <br...@apache.org> wrote:
>
> Hello Rob,
>
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins <ch...@gmail.com>:
>>
>> 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: 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] Deploying components
Posted by sebb <se...@gmail.com>.
On 5 June 2017 at 12:06, Benedikt Ritter <br...@apache.org> wrote:
> Hello Rob,
>
>> Am 28.05.2017 um 03:01 schrieb Rob Tompkins <ch...@gmail.com>:
>>
>> 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: 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] Deploying components
Posted by Benedikt Ritter <br...@apache.org>.
Hello Rob,
> Am 28.05.2017 um 03:01 schrieb Rob Tompkins <ch...@gmail.com>:
>
> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Deploying components
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 27, 2017, at 9:48 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On May 27, 2017 6:01 PM, "Rob Tompkins" <ch...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Deploying components
Posted by Gary Gregory <ga...@gmail.com>.
On May 27, 2017 6:01 PM, "Rob Tompkins" <ch...@gmail.com> 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
Re: [all] Deploying components
Posted by Benedikt Ritter <br...@apache.org>.
Hello Stian,
> Am 05.06.2017 um 18:58 schrieb Stian Soiland-Reyes <st...@apache.org>:
>
> 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" <ch...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Deploying components
Posted by Gary Gregory <ga...@gmail.com>.
I have used bin zips before to get to DLL files for example.
Gary
On Jun 5, 2017 9:58 AM, "Stian Soiland-Reyes" <st...@apache.org> 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" <ch...@gmail.com> 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
>
Re: [all] Deploying components
Posted by Stian Soiland-Reyes <st...@apache.org>.
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" <ch...@gmail.com> 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