github plugin?

[Romain Manni-Bucau]

Hi guys,

is there any maven github plugin (or any plan)? the goal would be to get
what we have with gem for instance in ruby world to be able to clone a repo
from the build to consider it as a dependency.

For java (and script jsr in particular) it would be great to get an
additional step: resource copy selection. Basically here what it would be
an interesting workflow:
1) git clone a branch on a repo in ${repo}
2) copy folder F or ${repo} in target/classes (copying the whole repo will
make the scripting JSR - aka JSR223 - not found the scripts in general)

wdyt?

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*

Re: github plugin?

[Aldrin Leal]

Wouldn't scm:bootstrap work?

--
-- Aldrin Leal, 
Master your EC2-fu! Get the latest ekaterminal public beta
http://www.ingenieux.com.br/products/ekaterminal/


On Mon, Jun 3, 2013 at 6:32 AM, Romain Manni-Bucau wrote:

> Hi guys,
>
> is there any maven github plugin (or any plan)? the goal would be to get
> what we have with gem for instance in ruby world to be able to clone a repo
> from the build to consider it as a dependency.
>
> For java (and script jsr in particular) it would be great to get an
> additional step: resource copy selection. Basically here what it would be
> an interesting workflow:
> 1) git clone a branch on a repo in ${repo}
> 2) copy folder F or ${repo} in target/classes (copying the whole repo will
> make the scripting JSR - aka JSR223 - not found the scripts in general)
>
> wdyt?
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>

Re: github plugin?

[Romain Manni-Bucau]

looks close yes, didn't know it, then playing with some file operation can
work

thanks

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/6/3 Aldrin Leal 

> Wouldn't scm:bootstrap work?
>
> --
> -- Aldrin Leal, 
> Master your EC2-fu! Get the latest ekaterminal public beta
> http://www.ingenieux.com.br/products/ekaterminal/
>
>
> On Mon, Jun 3, 2013 at 6:32 AM, Romain Manni-Bucau  >wrote:
>
> > Hi guys,
> >
> > is there any maven github plugin (or any plan)? the goal would be to get
> > what we have with gem for instance in ruby world to be able to clone a
> repo
> > from the build to consider it as a dependency.
> >
> > For java (and script jsr in particular) it would be great to get an
> > additional step: resource copy selection. Basically here what it would be
> > an interesting workflow:
> > 1) git clone a branch on a repo in ${repo}
> > 2) copy folder F or ${repo} in target/classes (copying the whole repo
> will
> > make the scripting JSR - aka JSR223 - not found the scripts in general)
> >
> > wdyt?
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau *
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
>

Re: github plugin?

[Romain Manni-Bucau]

Awesome! Thanks again, still need to go a bit deeper but it works:
https://github.com/rmannibucau/landslide-maven-plugin/blob/master/pom.xml

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/6/3 Romain Manni-Bucau 

> looks close yes, didn't know it, then playing with some file operation can
> work
>
> thanks
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/6/3 Aldrin Leal 
>
>> Wouldn't scm:bootstrap work?
>>
>> --
>> -- Aldrin Leal, 
>> Master your EC2-fu! Get the latest ekaterminal public beta
>> http://www.ingenieux.com.br/products/ekaterminal/
>>
>>
>> On Mon, Jun 3, 2013 at 6:32 AM, Romain Manni-Bucau > >wrote:
>>
>> > Hi guys,
>> >
>> > is there any maven github plugin (or any plan)? the goal would be to get
>> > what we have with gem for instance in ruby world to be able to clone a
>> repo
>> > from the build to consider it as a dependency.
>> >
>> > For java (and script jsr in particular) it would be great to get an
>> > additional step: resource copy selection. Basically here what it would
>> be
>> > an interesting workflow:
>> > 1) git clone a branch on a repo in ${repo}
>> > 2) copy folder F or ${repo} in target/classes (copying the whole repo
>> will
>> > make the scripting JSR - aka JSR223 - not found the scripts in general)
>> >
>> > wdyt?
>> >
>> > *Romain Manni-Bucau*
>> > *Twitter: @rmannibucau *
>> > *Blog: **http://rmannibucau.wordpress.com/*<
>> > http://rmannibucau.wordpress.com/>
>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
>> > *Github: https://github.com/rmannibucau*
>> >
>>
>
>

Re: github plugin?

[Chris Graham]

Use the exec plugin?

-Chris

Sent from my iPhone

On 03/06/2013, at 7:32 PM, Romain Manni-Bucau  wrote:

> Hi guys,
> 
> is there any maven github plugin (or any plan)? the goal would be to get
> what we have with gem for instance in ruby world to be able to clone a repo
> from the build to consider it as a dependency.
> 
> For java (and script jsr in particular) it would be great to get an
> additional step: resource copy selection. Basically here what it would be
> an interesting workflow:
> 1) git clone a branch on a repo in ${repo}
> 2) copy folder F or ${repo} in target/classes (copying the whole repo will
> make the scripting JSR - aka JSR223 - not found the scripts in general)
> 
> wdyt?
> 
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*

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

Re: github plugin?

[Romain Manni-Bucau]

scm plugin is what i was looking for, exec plugin was not portable enough

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/6/3 Chris Graham 

> Use the exec plugin?
>
> -Chris
>
> Sent from my iPhone
>
> On 03/06/2013, at 7:32 PM, Romain Manni-Bucau 
> wrote:
>
> > Hi guys,
> >
> > is there any maven github plugin (or any plan)? the goal would be to get
> > what we have with gem for instance in ruby world to be able to clone a
> repo
> > from the build to consider it as a dependency.
> >
> > For java (and script jsr in particular) it would be great to get an
> > additional step: resource copy selection. Basically here what it would be
> > an interesting workflow:
> > 1) git clone a branch on a repo in ${repo}
> > 2) copy folder F or ${repo} in target/classes (copying the whole repo
> will
> > make the scripting JSR - aka JSR223 - not found the scripts in general)
> >
> > wdyt?
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau *
> > *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: github plugin?

[Aldrin Leal]

I wonder if commons-vfs does offer some scm functionality. If it doesn't,
it would be just as amazing...


--
-- Aldrin Leal, 
Master your EC2-fu! Get the latest ekaterminal public beta
http://www.ingenieux.com.br/products/ekaterminal/


On Mon, Jun 3, 2013 at 10:00 AM, Romain Manni-Bucau
wrote:

> scm plugin is what i was looking for, exec plugin was not portable enough
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau *
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/6/3 Chris Graham 
>
> > Use the exec plugin?
> >
> > -Chris
> >
> > Sent from my iPhone
> >
> > On 03/06/2013, at 7:32 PM, Romain Manni-Bucau 
> > wrote:
> >
> > > Hi guys,
> > >
> > > is there any maven github plugin (or any plan)? the goal would be to
> get
> > > what we have with gem for instance in ruby world to be able to clone a
> > repo
> > > from the build to consider it as a dependency.
> > >
> > > For java (and script jsr in particular) it would be great to get an
> > > additional step: resource copy selection. Basically here what it would
> be
> > > an interesting workflow:
> > > 1) git clone a branch on a repo in ${repo}
> > > 2) copy folder F or ${repo} in target/classes (copying the whole repo
> > will
> > > make the scripting JSR - aka JSR223 - not found the scripts in general)
> > >
> > > wdyt?
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau *
> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > *Github: https://github.com/rmannibucau*
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Robert Scholte]

All nice ideas, but let's go back to a real usecase:

Let's assume we're having an issue with componentX-1.4
If you weren't one of the testers, then this dependency was pulled from  
Maven Central. You can check out the code as specified in the tag, etc.  
etc. No issues here.
But if you were one of the testers you must be sure that you're not using  
the staged version anymore, but the one from Maven Central. When reusing  
version numbers due to unsuccessful staged versions, you can only confirm  
it by comparing the *revisions* of both componentX-1.4
I think somehow (the rootcause of) MNG-5181 is related: if you're using an  
artifact originally from a staging repo and that repo has disappeared, the  
build must fail. You are forced to clean up these staged artifacts, so  
they are pulled from Maven Central. Only this way your local build is the  
same as any other developers build.

As said before: - the actual release is the one in the dist-folder
- tags are just an easy way to refer to a certain revision.
- so if you want to be 100% sure you're checking out the correct source,  
use revisions and not tags (which means revision must be set during  
packaging, e.g in the manifest file).


Robert

Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies  
:



I would consider it delux if the release plugin were enhanced to
support a more sophisticated mapping between artifact versions and
tags -- as per Kristian, wouldn't it be cool if it could iterate over
tags while repeating itself on customer-visible release numbers? I'd
help to code this is we had a collective understanding of how we
wanted it to work.

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


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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly]

Now the issue with componentX-1.4 that you wan to test is one that only
shows up behind your corporate proxy, and you have a system set up with the
failing case and you dare not change anything...

So you add the staging repo to your mirror, run the test case, and drop the
test artifact from the mirror as fast as you can... (Because creating a
separate mirror would require changing the test setup and resulting in
re-resolution again)

The thing is that the test is a long test... And now you don't know who
else has got that invalid componentX-1.4 (because your test is still
failing) and when the fixed componentX-1.4 is released you may find a
nightmare tracking it down again.

Somewhat contrived some might say, but that is the use case where this s
more critical

On Monday, 3 June 2013, Robert Scholte wrote:

> All nice ideas, but let's go back to a real usecase:
>
> Let's assume we're having an issue with componentX-1.4
> If you weren't one of the testers, then this dependency was pulled from
> Maven Central. You can check out the code as specified in the tag, etc.
> etc. No issues here.
> But if you were one of the testers you must be sure that you're not using
> the staged version anymore, but the one from Maven Central. When reusing
> version numbers due to unsuccessful staged versions, you can only confirm
> it by comparing the *revisions* of both componentX-1.4
> I think somehow (the rootcause of) MNG-5181 is related: if you're using an
> artifact originally from a staging repo and that repo has disappeared, the
> build must fail. You are forced to clean up these staged artifacts, so they
> are pulled from Maven Central. Only this way your local build is the same
> as any other developers build.
> As said before: - the actual release is the one in the dist-folder
> - tags are just an easy way to refer to a certain revision.
> - so if you want to be 100% sure you're checking out the correct source,
> use revisions and not tags (which means revision must be set during
> packaging, e.g in the manifest file).
>
> Robert
>
> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
> bimargul...@gmail.com>:
>
>  I would consider it delux if the release plugin were enhanced to
>> support a more sophisticated mapping between artifact versions and
>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
>> tags while repeating itself on customer-visible release numbers? I'd
>> help to code this is we had a collective understanding of how we
>> wanted it to work.
>>
>> --**--**-
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> --**--**-
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sent from my phone

maven-surefire pull request: SUREFIRE-999: Skip phase `validate` during sit...

[mfriedenhagen]

Github user mfriedenhagen closed the pull request at:

https://github.com/apache/maven-surefire/pull/23


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

maven-surefire pull request: Surefire 999 annotation based

[mfriedenhagen]

Github user mfriedenhagen closed the pull request at:

https://github.com/apache/maven-surefire/pull/24


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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Robert Scholte]

Although it is slightly off-topic (I assumed our Apache environment), but  
also in this case: as long as componentX-1.4 was staged and not released,  
developers must adjust their settings.xml to test componentX-1.4.
So they should be aware that this component was not released and should  
remove it afterwards (when the release is dropped(?)).
So how important is tracking down if Maven could verify that your version  
of the componentX-1.4 is not the same as the released componentX-1.4? In  
such case keeping your version is useless, because your build will always  
be different then the one created by other developers.
IIUC even though we say "final version are only downloaded once", Maven3  
keeps verifying it with the original repository.


A worst case scenario would be if the build-server pulls in staged  
artifacts (because someone specified the staging URL and committed a  
pom.xml with this artifact as dependency) and the repository is used by  
all jobs. This might lead to false-positive test results or false-negative  
test-results.


When you're using a repository-manager without staging support, then the  
story is a bit different. In that case artifacts immediately end up in the  
company-repository and you'll loose track of who is using is. In such  
cases you should never redeploy with the same version.


Robert

Op Mon, 03 Jun 2013 19:49:19 +0200 schreef Stephen Connolly  
:



Now the issue with componentX-1.4 that you wan to test is one that only
shows up behind your corporate proxy, and you have a system set up with  
the

failing case and you dare not change anything...

So you add the staging repo to your mirror, run the test case, and drop  
the

test artifact from the mirror as fast as you can... (Because creating a
separate mirror would require changing the test setup and resulting in
re-resolution again)

The thing is that the test is a long test... And now you don't know who
else has got that invalid componentX-1.4 (because your test is still
failing) and when the fixed componentX-1.4 is released you may find a
nightmare tracking it down again.

Somewhat contrived some might say, but that is the use case where this s
more critical

On Monday, 3 June 2013, Robert Scholte wrote:


All nice ideas, but let's go back to a real usecase:

Let's assume we're having an issue with componentX-1.4
If you weren't one of the testers, then this dependency was pulled from
Maven Central. You can check out the code as specified in the tag, etc.
etc. No issues here.
But if you were one of the testers you must be sure that you're not  
using

the staged version anymore, but the one from Maven Central. When reusing
version numbers due to unsuccessful staged versions, you can only  
confirm

it by comparing the *revisions* of both componentX-1.4
I think somehow (the rootcause of) MNG-5181 is related: if you're using  
an
artifact originally from a staging repo and that repo has disappeared,  
the
build must fail. You are forced to clean up these staged artifacts, so  
they
are pulled from Maven Central. Only this way your local build is the  
same

as any other developers build.
As said before: - the actual release is the one in the dist-folder
- tags are just an easy way to refer to a certain revision.
- so if you want to be 100% sure you're checking out the correct source,
use revisions and not tags (which means revision must be set during
packaging, e.g in the manifest file).

Robert

Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
bimargul...@gmail.com>:

 I would consider it delux if the release plugin were enhanced to

support a more sophisticated mapping between artifact versions and
tags -- as per Kristian, wouldn't it be cool if it could iterate over
tags while repeating itself on customer-visible release numbers? I'd
help to code this is we had a collective understanding of how we
wanted it to work.

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



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




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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Kristian Rosenvold]

If you add apache staging to your corp proxy
and expose that to everyone you are mixing test and production.
/me dislikes the concept.

The way I usually solve this is to have an additional
corp repo-url that exposes the regular internal repo
*and*  staging. This url is used to test staging.
(I have yet to come across a scenaro where multiple
users share this ;)

Kristian


2013/6/3 Stephen Connolly :
> Now the issue with componentX-1.4 that you wan to test is one that only
> shows up behind your corporate proxy, and you have a system set up with the
> failing case and you dare not change anything...
>
> So you add the staging repo to your mirror, run the test case, and drop the
> test artifact from the mirror as fast as you can... (Because creating a
> separate mirror would require changing the test setup and resulting in
> re-resolution again)
>
> The thing is that the test is a long test... And now you don't know who
> else has got that invalid componentX-1.4 (because your test is still
> failing) and when the fixed componentX-1.4 is released you may find a
> nightmare tracking it down again.
>
> Somewhat contrived some might say, but that is the use case where this s
> more critical
>
> On Monday, 3 June 2013, Robert Scholte wrote:
>
>> All nice ideas, but let's go back to a real usecase:
>>
>> Let's assume we're having an issue with componentX-1.4
>> If you weren't one of the testers, then this dependency was pulled from
>> Maven Central. You can check out the code as specified in the tag, etc.
>> etc. No issues here.
>> But if you were one of the testers you must be sure that you're not using
>> the staged version anymore, but the one from Maven Central. When reusing
>> version numbers due to unsuccessful staged versions, you can only confirm
>> it by comparing the *revisions* of both componentX-1.4
>> I think somehow (the rootcause of) MNG-5181 is related: if you're using an
>> artifact originally from a staging repo and that repo has disappeared, the
>> build must fail. You are forced to clean up these staged artifacts, so they
>> are pulled from Maven Central. Only this way your local build is the same
>> as any other developers build.
>> As said before: - the actual release is the one in the dist-folder
>> - tags are just an easy way to refer to a certain revision.
>> - so if you want to be 100% sure you're checking out the correct source,
>> use revisions and not tags (which means revision must be set during
>> packaging, e.g in the manifest file).
>>
>> Robert
>>
>> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
>> bimargul...@gmail.com>:
>>
>>  I would consider it delux if the release plugin were enhanced to
>>> support a more sophisticated mapping between artifact versions and
>>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
>>> tags while repeating itself on customer-visible release numbers? I'd
>>> help to code this is we had a collective understanding of how we
>>> wanted it to work.
>>>
>>> --**--**-
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
> --
> Sent from my phone

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Stephen Connolly]

On Monday, 3 June 2013, Kristian Rosenvold wrote:

> If you add apache staging to your corp proxy
> and expose that to everyone you are mixing test and production.
> /me dislikes the concept.
>
> The way I usually solve this is to have an additional
> corp repo-url that exposes the regular internal repo
> *and*  staging. This url is used to test staging.


The *point* is what happens when your test case machine is pointing to the
proxy. If you switch that to a different URL _maven.repositories will kick
in and re-resolve potentially breaking your test case.

The only way I can see out of such is to edit the test machine's hosts file
so that the DNs name gets resolved to a different server and that assumes
the proxy is referenced by DNS and not eg https:/
10.0.0.5/nexus/groups/public/

I did say this is likely a rare case, but it is the case that would force
burning version numbers, and the exception tests (or proves in old English)
the rule

(Anyway vote is over, so issue is moot. I don't care enough to call a
second vote)

> (I have yet to come across a scenaro where multiple
> users share this ;)
>
> Kristian
>
>
> 2013/6/3 Stephen Connolly 
> >:
> > Now the issue with componentX-1.4 that you wan to test is one that only
> > shows up behind your corporate proxy, and you have a system set up with
> the
> > failing case and you dare not change anything...
> >
> > So you add the staging repo to your mirror, run the test case, and drop
> the
> > test artifact from the mirror as fast as you can... (Because creating a
> > separate mirror would require changing the test setup and resulting in
> > re-resolution again)
> >
> > The thing is that the test is a long test... And now you don't know who
> > else has got that invalid componentX-1.4 (because your test is still
> > failing) and when the fixed componentX-1.4 is released you may find a
> > nightmare tracking it down again.
> >
> > Somewhat contrived some might say, but that is the use case where this s
> > more critical
> >
> > On Monday, 3 June 2013, Robert Scholte wrote:
> >
> >> All nice ideas, but let's go back to a real usecase:
> >>
> >> Let's assume we're having an issue with componentX-1.4
> >> If you weren't one of the testers, then this dependency was pulled from
> >> Maven Central. You can check out the code as specified in the tag, etc.
> >> etc. No issues here.
> >> But if you were one of the testers you must be sure that you're not
> using
> >> the staged version anymore, but the one from Maven Central. When reusing
> >> version numbers due to unsuccessful staged versions, you can only
> confirm
> >> it by comparing the *revisions* of both componentX-1.4
> >> I think somehow (the rootcause of) MNG-5181 is related: if you're using
> an
> >> artifact originally from a staging repo and that repo has disappeared,
> the
> >> build must fail. You are forced to clean up these staged artifacts, so
> they
> >> are pulled from Maven Central. Only this way your local build is the
> same
> >> as any other developers build.
> >> As said before: - the actual release is the one in the dist-folder
> >> - tags are just an easy way to refer to a certain revision.
> >> - so if you want to be 100% sure you're checking out the correct source,
> >> use revisions and not tags (which means revision must be set during
> >> packaging, e.g in the manifest file).
> >>
> >> Robert
> >>
> >> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
> >> bimargul...@gmail.com >:
> >>
> >>  I would consider it delux if the release plugin were enhanced to
> >>> support a more sophisticated mapping between artifact versions and
> >>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
> >>> tags while repeating itself on customer-visible release numbers? I'd
> >>> help to code this is we had a collective understanding of how we
> >>> wanted it to work.
> >>>
> >>>
> --**--**-
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>
> >>
> --**--**-
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
> > --
> > Sent from my phone
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> For additional commands, e-mail: dev-h...@maven.apache.org 
>
>

-- 
Sent from my phone

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Barrie Treloar]

Write this scenario up in the "trouble shooting" notes on how to test
staging releases.

I fit into the "behind corporate proxy" category but I have not had
this problem (I use Kristian's solution).
Admittedly the effort required to configure the corporate proxy for a
staging url is often enough to disuade me from testing that plugin.
It is easier to pull out my personal laptop and tether it to test the
plugin.

Anyway with this discussion captured somewhere, if it truly becomes an
issues for enough people they can find what we discussed and re-raise
options.

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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Chris Graham]

Um, did I miss something, but what is a unreleased (ie for it to be pulled,
then it has to be right?) artifact doing in central to start with?

-Chris


On Tue, Jun 4, 2013 at 3:32 AM, Robert Scholte  wrote:

> All nice ideas, but let's go back to a real usecase:
>
> Let's assume we're having an issue with componentX-1.4
> If you weren't one of the testers, then this dependency was pulled from
> Maven Central. You can check out the code as specified in the tag, etc.
> etc. No issues here.
> But if you were one of the testers you must be sure that you're not using
> the staged version anymore, but the one from Maven Central. When reusing
> version numbers due to unsuccessful staged versions, you can only confirm
> it by comparing the *revisions* of both componentX-1.4
> I think somehow (the rootcause of) MNG-5181 is related: if you're using an
> artifact originally from a staging repo and that repo has disappeared, the
> build must fail. You are forced to clean up these staged artifacts, so they
> are pulled from Maven Central. Only this way your local build is the same
> as any other developers build.
> As said before: - the actual release is the one in the dist-folder
> - tags are just an easy way to refer to a certain revision.
> - so if you want to be 100% sure you're checking out the correct source,
> use revisions and not tags (which means revision must be set during
> packaging, e.g in the manifest file).
>
> Robert
>
> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies <
> bimargul...@gmail.com>:
>
>
>  I would consider it delux if the release plugin were enhanced to
>> support a more sophisticated mapping between artifact versions and
>> tags -- as per Kristian, wouldn't it be cool if it could iterate over
>> tags while repeating itself on customer-visible release numbers? I'd
>> help to code this is we had a collective understanding of how we
>> wanted it to work.
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@maven.apache.**org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@maven.apache.**org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>