You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "James Nord (jnord)" <jn...@cisco.com> on 2013/02/05 11:56:20 UTC
Testing [Vote] plugins?
Hi all,
I have a question which I am hoping someone can answer.
Rule #1 releases are golden.
However Apache plugin releases violate that rule[1][2]. If a vote fails the next vote seems to be for exactly the same version of the plugin
I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible).
Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used).
Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181.
So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment?
(or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)?
Regards,
/James
[1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote
[2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0
Re: Testing [Vote] plugins?
Posted by Olivier Lamy <ol...@apache.org>.
an other possibility is to download the source release zip and install
it locally.
I believe you want to test pmd.
So here: https://repository.apache.org/content/repositories/maven-198/org/apache/maven/plugins/maven-pmd-plugin/3.0/maven-pmd-plugin-3.0-source-release.zip
2013/2/5 Benson Margulies <bi...@gmail.com>:
> I keep a second Maven install dir that has a settings.xml that does
> not point to my corporate MRM, but rather directly to the outside
> world.
>
>
> On Tue, Feb 5, 2013 at 5:56 AM, James Nord (jnord) <jn...@cisco.com> wrote:
>> Hi all,
>>
>> I have a question which I am hoping someone can answer.
>>
>> Rule #1 releases are golden.
>> However Apache plugin releases violate that rule[1][2]. If a vote fails the next vote seems to be for exactly the same version of the plugin
>>
>> I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible).
>> Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used).
>>
>> Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181.
>>
>> So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment?
>> (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)?
>>
>> Regards,
>>
>> /James
>>
>> [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote
>> [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing [Vote] plugins?
Posted by Benson Margulies <bi...@gmail.com>.
I keep a second Maven install dir that has a settings.xml that does
not point to my corporate MRM, but rather directly to the outside
world.
On Tue, Feb 5, 2013 at 5:56 AM, James Nord (jnord) <jn...@cisco.com> wrote:
> Hi all,
>
> I have a question which I am hoping someone can answer.
>
> Rule #1 releases are golden.
> However Apache plugin releases violate that rule[1][2]. If a vote fails the next vote seems to be for exactly the same version of the plugin
>
> I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible).
> Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used).
>
> Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181.
>
> So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment?
> (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)?
>
> Regards,
>
> /James
>
> [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote
> [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Testing [Vote] plugins?
Posted by "James Nord (jnord)" <jn...@cisco.com>.
> -----Original Message-----
> From: Barrie Treloar [mailto:baerrach@gmail.com]
> Sent: 06 February 2013 02:37
> To: Maven Developers List
> Subject: Re: Testing [Vote] plugins?
>
> On 6 February 2013 10:39, Benson Margulies <bi...@gmail.com>
> wrote:
> > The issue here is that someone in our community might live in a world
> > where an MRM has interposed its body, in the words of Lytton
> > Strachey, between themselves and all external repos. Such people had
> > better follow olamy's advice about downloading source and building it
> > themselves.
>
> They can still do this, they just need to configure their MRM correctly.
>
> The staging releases should be quarantined on a separate URL.
> No developer should be using this particular URL, only the person delegated
> to test the staged release.
> They should then follow normal practice and delete the quarantined MRM
> repository when done.
This then requires more work than is ideal and as such it is likely that me as a community member will be able to do less testing (if any).
Testing would be done through the CI environment (which can include automates testing of the built product) and swapping maven settings for jobs, duplicating jobs and fiddling with MRMs is more work than I am able to do. Wouldn't it be nice if all I needed to do was create a branch in my repo and update the plugin version and not have to worry that someone is possibly going to recreate another release with the same version.
/James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing [Vote] plugins?
Posted by Barrie Treloar <ba...@gmail.com>.
On 6 February 2013 10:39, Benson Margulies <bi...@gmail.com> wrote:
> The issue here is that someone in our community might live in a world
> where an MRM has interposed its body, in the words of Lytton
> Strachey, between themselves and all external repos. Such people had
> better follow olamy's advice about downloading source and building it
> themselves.
They can still do this, they just need to configure their MRM correctly.
The staging releases should be quarantined on a separate URL.
No developer should be using this particular URL, only the person
delegated to test the staged release.
They should then follow normal practice and delete the quarantined MRM
repository when done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing [Vote] plugins?
Posted by Benson Margulies <bi...@gmail.com>.
The issue here is that someone in our community might live in a world
where an MRM has interposed its body, in the words of Lytton
Strachey, between themselves and all external repos. Such people had
better follow olamy's advice about downloading source and building it
themselves.
On Tue, Feb 5, 2013 at 7:04 PM, Barrie Treloar <ba...@gmail.com> wrote:
> On 5 February 2013 21:26, James Nord (jnord) <jn...@cisco.com> wrote:
>> Hi all,
>>
>> I have a question which I am hoping someone can answer.
>>
>> Rule #1 releases are golden.
>> However Apache plugin releases violate that rule[1][2]. If a vote fails the next vote seems to be for exactly the same version of the plugin
>>
>> I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible).
>> Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used).
>>
>> Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181.
>>
>> So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment?
>> (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)?
>>
>> Regards,
>>
>> /James
>>
>> [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote
>> [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0
>
> If these are being released into Central - then they *will* never change.
> They are Golden.
>
> Prior to getting their, e.g. during the voting process, these jars are
> released into a staging area.
> You are invited to try those jars from the staging area to ensure they
> dont have regression issues etc.
> If you do this then you generally delete your local m2 cache
> (~/.m2/repository) or you use a new settings.xml file that points to a
> different location.
> You would not normally use an MRM in this scenario as the staging jars
> are not yet Golden.
>
> If the release fail, then the staging areas are deleted and the
> process starts again. Nothing has happened to Central yet.
> If the release passes, then staging is promoted into Central, its all
> Golden and then never changes.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing [Vote] plugins?
Posted by Baptiste MATHUS <ml...@batmat.net>.
2013/2/6 James Nord (jnord) <jn...@cisco.com>
>
> > If these are being released into Central - then they *will* never change.
> > They are Golden.
>
> > Prior to getting their, e.g. during the voting process, these jars are
> released
> > into a staging area.
> > You are invited to try those jars from the staging area to ensure they
> dont
> > have regression issues etc.
>
> That's what I would like to do.
>
> > If you do this then you generally delete your local m2 cache
> > (~/.m2/repository) or you use a new settings.xml file that points to a
> > different location.
>
> Meanwhile these are in all the caches of the MRMs and it needs more work
> than would ideally be needed (if you want to widen testing to more of the
> community)
>
If you use a good and correctly configured MRM, this should actually be a
non issue.
By correctly configured, for example, I mean that staging areas should
NEVER be put behing your global corporate (or any, btw) proxy repo.
Adding staging to repositories for a build should always require a manually
operation (for example manually activating a profile, at least).
People using staged releases should know this is something quite special.
If the vote fails, you just have to wipe out your local repository and
you're done.
Cheers
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor ! nbsp;!
RE: Testing [Vote] plugins?
Posted by "James Nord (jnord)" <jn...@cisco.com>.
> If these are being released into Central - then they *will* never change.
> They are Golden.
> Prior to getting their, e.g. during the voting process, these jars are released
> into a staging area.
> You are invited to try those jars from the staging area to ensure they dont
> have regression issues etc.
That's what I would like to do.
> If you do this then you generally delete your local m2 cache
> (~/.m2/repository) or you use a new settings.xml file that points to a
> different location.
Meanwhile these are in all the caches of the MRMs and it needs more work than would ideally be needed (if you want to widen testing to more of the community)
> You would not normally use an MRM in this scenario as the staging jars are
> not yet Golden.
This definition of release contradicts mavens definition.
A release is something that has no -SNAPSHOT (or timestamp) at the end of its version.
Thus these are releases even if they do not make it onto central (and deleting nexus stages after allowing any maven to consume from it is a bad thing and imho one of the things that nexus pro really needs to improve on)
I am also well aware of how nexus staging works - and staging is not the issue, reusing the same release version is the issue.
All this extra hand fudging would disappear if the versions where used where unique e.g 1.0.0-1 vote fails next is 1.0.0-2.
But also how can I test it if I can't use it... (esp the maven-release-plugin!)
Most tests to be useful would be done in a CI environment with auto testing - configuring different jobs to have different settings would be a PITA.
> If the release fail, then the staging areas are deleted and the process starts
> again. Nothing has happened to Central yet.
But the artifacts have been used elsewhere (even just testing is using it...).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Testing [Vote] plugins?
Posted by Barrie Treloar <ba...@gmail.com>.
On 5 February 2013 21:26, James Nord (jnord) <jn...@cisco.com> wrote:
> Hi all,
>
> I have a question which I am hoping someone can answer.
>
> Rule #1 releases are golden.
> However Apache plugin releases violate that rule[1][2]. If a vote fails the next vote seems to be for exactly the same version of the plugin
>
> I sit behind a corporate MRM - and as such we keep every single release we download forever (as we need to make sure all builds are reproducible).
> Changing this policy to test plugins up for a vote could end up with an un-reproducible build (if a staged plugin is used).
>
> Grabbing the plugin and installing to my local maven repo is likely doomed to failure due to MNG-5181.
>
> So given that releases are not always golden my question is what do people do in order to test this with their software in a corporate environment?
> (or to put it another way why are versions re-used if a vote fails, violating the #1 maven rule)?
>
> Regards,
>
> /James
>
> [1] http://dev.markmail.org/message/mto7fl4ngxht63ue?q=list:org%2Eapache%2Emaven%2Edev+canceled+vote
> [2] http://dev.markmail.org/message/j4i325udpvoxm67d?q=list:org%2Eapache%2Emaven%2Edev+ANN+Maven+Filtering+version+1%2E0
If these are being released into Central - then they *will* never change.
They are Golden.
Prior to getting their, e.g. during the voting process, these jars are
released into a staging area.
You are invited to try those jars from the staging area to ensure they
dont have regression issues etc.
If you do this then you generally delete your local m2 cache
(~/.m2/repository) or you use a new settings.xml file that points to a
different location.
You would not normally use an MRM in this scenario as the staging jars
are not yet Golden.
If the release fail, then the staging areas are deleted and the
process starts again. Nothing has happened to Central yet.
If the release passes, then staging is promoted into Central, its all
Golden and then never changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org