subject:"Re\: maven\-release\-plugin"

I don't think this issue have been rectified.

The maven release plugin I use (downloaded from maven central via my plugin)
is as follows...

This fail:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.2.2/version
configuration
tagBase{my svn url and 
path}/${project.artifactId}/releases/tagBase
/configuration
/plugin

This work:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.2.2/version
configuration
tagBase{my svn url and 
path}/${project.artifactId}/releases/tagBase
/configuration
/plugin


The clean - as I understand it - would ensure you always have a clean
workspace derived from the remote source at release time - removing the
chance that someone committed something between now and when I perform my
release - that makes perfect sense to me and is a good safeguard







--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789843.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

On 28 March 2014 11:12, ghostwolf59 martin.cederv...@commerce.wa.gov.auwrote:

 version2.2.2/version


Then you are not using version 2.5

Re: maven release-plugin 2.5 bug - releasing snapshots...

Sorry for that - I was just in the process of updating this a simple
copy/paste mistake 

I am using 2.5 when the problem occur - as illustrated on the image below

http://maven.40175.n5.nabble.com/file/n5789868/release-version-prompt-v.2.5-w.version.jpg
 

As you can see the prompt What is the release version for  ... keep coming
back - v2.5 does not accept me overwriting this.

Using v.2.2.2 allow me to overwrite this with anything that then takes me to
the scm prompt and so on - which ultimately allow me to do what I really
want.



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789868.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

You do know you are not allowed to release a version containing a -SNAPSHOT
don't you?


On 28 March 2014 12:23, ghostwolf59 martin.cederv...@commerce.wa.gov.auwrote:

 Sorry for that - I was just in the process of updating this a simple
 copy/paste mistake

 I am using 2.5 when the problem occur - as illustrated on the image below

 
 http://maven.40175.n5.nabble.com/file/n5789868/release-version-prompt-v.2.5-w.version.jpg
 

 As you can see the prompt What is the release version for  ... keep
 coming
 back - v2.5 does not accept me overwriting this.

 Using v.2.2.2 allow me to overwrite this with anything that then takes me
 to
 the scm prompt and so on - which ultimately allow me to do what I really
 want.



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789868.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

That's a way to general statement to be made  - that also is incorrect   ! 

A snapshot is not allowed for final release - but could still be released
into a shapshot repo for test purposes !
The question really bogs down to how much control you'd like to have against
a release snapshot.
Anyone can in effect release a snapshot into the remote archiva snapshot
repo but no scm branch tag would take place and the source this snapshot was
based on would be unknown since uncommitted data could have been used.

If you go down the path of controlling this (in selected cases) you'd like
to have full control over the source it represent as well be able to assess
the site info linked to this release.

A simple mvn deploy would not do these things - it would only promote a
local build into archiva's snapshot repository - with a lot of ??? to follow
when it comes to QA, source control etc.


I am not trying to do a */release/* as such - it's a legit release of a
*/snapshot/* to be used for test purposed in a highly controlled manner
pending official signoffs - once a signoff is received a proper release for
that version would be performed.

The final release would never be allowed to be a snapshot - nor would any
snapshot dependencies be allowed but that's a side issue and have absolutely
nothing to do with what I am arguing about.

The snapshot release would end up in a dedicated snapshot repository so why
you go down this path I don't really understand - bogs down to how v2.2.2 vs
higher versions of the release-plugin behaves.

I have now done some tests going back in history and it shows that all
versions after *v.2.3.2* (my initial test was on v2.2.2) fails when it comes
to this...

So it appear that v 2.4 onwards all fail when it comes to this 

Succeeds:
http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.3.2.jpg
 

Failures;
http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.5-w.version.jpg
 

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.2.jpg
 

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.1.jpg
 

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.jpg
 





-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789892.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

Let me rephrase. The release plugin is designed to make release versions.
It is not designed to make -SNAPSHOT versions. It was a bug that it let you
specify a -SNAPSHOT version as the release version. The bug has been fixed.

On 28 March 2014 13:18, ghostwolf59 martin.cederv...@commerce.wa.gov.auwrote:

That's a way to general statement to be made - that also is incorrect !

A snapshot is not allowed for final release - but could still be released
into a shapshot repo for test purposes !
The question really bogs down to how much control you'd like to have
against
a release snapshot.
Anyone can in effect release a snapshot into the remote archiva snapshot
repo but no scm branch tag would take place and the source this snapshot
was
based on would be unknown since uncommitted data could have been used.

If you go down the path of controlling this (in selected cases) you'd like
to have full control over the source it represent as well be able to assess
the site info linked to this release.

A simple mvn deploy would not do these things - it would only promote a
local build into archiva's snapshot repository - with a lot of ??? to
follow
when it comes to QA, source control etc.

I am not trying to do a */release/* as such - it's a legit release of a
*/snapshot/* to be used for test purposed in a highly controlled manner
pending official signoffs - once a signoff is received a proper release for
that version would be performed.

The final release would never be allowed to be a snapshot - nor would any
snapshot dependencies be allowed but that's a side issue and have
absolutely
nothing to do with what I am arguing about.

The snapshot release would end up in a dedicated snapshot repository so why
you go down this path I don't really understand - bogs down to how v2.2.2
vs
higher versions of the release-plugin behaves.

I have now done some tests going back in history and it shows that all
versions after *v.2.3.2* (my initial test was on v2.2.2) fails when it
comes
to this...

So it appear that v 2.4 onwards all fail when it comes to this

Succeeds:

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.3.2.jpg

Failures;

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.5-w.version.jpg

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.2.jpg

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.1.jpg

http://maven.40175.n5.nabble.com/file/n5789892/release-version-prompt-v.2.4.jpg

-
good @ being sucked @
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789892.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

Doing it as I explained did NOT allow you to do a release or refer to it
within other resources during a legic release phase

What you triggered was a release (as if legit) to go into the snapshot repo
- cant see any issues with that kind of behavior and have turned out to be
very useful when implementing formal test signoffs where exact version
tested against become critical (mind you these test phases is done before
even taken the app to UAT - technically still in a development phase).

Allowing these formal snapshots releases to be released into the snapshot
repo can hardly affect the normal behavior of releasing local builds
(without any constraint of the build was done against committed data - as
it's currently works) 

From what I hear is that someone decided to plug this feature = personally
(and form an organizational point of view I think you removed useful
functionality)

Next question: if this now is a planned move - why not allow snapshots (that
maven does on local uncommitted data) to be processed as if it actually is
somewhat legit - without open up the possibility to use this as a prod state
resource in the dependency sections ?





-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789916.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

RE: maven release-plugin 2.5 bug - releasing snapshots...

2014-03-28 Thread James Nord (jnord)

shouldn't release:branch still support this still though?

If not that's bad as you will end up with a release version on the head of 
either the source branch or the new branch (and both should be used for ongoing 
development so should be snapshots...)

/James

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: 28 March 2014 13:32
 To: Maven Users List
 Subject: Re: maven release-plugin 2.5 bug - releasing snapshots...
 
 Let me rephrase. The release plugin is designed to make release versions.
 It is not designed to make -SNAPSHOT versions. It was a bug that it let you
 specify a -SNAPSHOT version as the release version. The bug has been fixed.
 
 
 On 28 March 2014 13:18, ghostwolf59
 martin.cederv...@commerce.wa.gov.auwrote:
 
  That's a way to general statement to be made  - that also is incorrect   !
 
  A snapshot is not allowed for final release - but could still be
  released into a shapshot repo for test purposes !
  The question really bogs down to how much control you'd like to have
  against a release snapshot.
  Anyone can in effect release a snapshot into the remote archiva
  snapshot repo but no scm branch tag would take place and the source
  this snapshot was based on would be unknown since uncommitted data
  could have been used.
 
  If you go down the path of controlling this (in selected cases) you'd
  like to have full control over the source it represent as well be able
  to assess the site info linked to this release.
 
  A simple mvn deploy would not do these things - it would only promote
  a local build into archiva's snapshot repository - with a lot of ???
  to follow when it comes to QA, source control etc.
 
 
  I am not trying to do a */release/* as such - it's a legit release
  of a
  */snapshot/* to be used for test purposed in a highly controlled
  manner pending official signoffs - once a signoff is received a proper
  release for that version would be performed.
 
  The final release would never be allowed to be a snapshot - nor would
  any snapshot dependencies be allowed but that's a side issue and have
  absolutely nothing to do with what I am arguing about.
 
  The snapshot release would end up in a dedicated snapshot repository
  so why you go down this path I don't really understand - bogs down to
  how v2.2.2 vs higher versions of the release-plugin behaves.
 
  I have now done some tests going back in history and it shows that all
  versions after *v.2.3.2* (my initial test was on v2.2.2) fails when it
  comes to this...
 
  So it appear that v 2.4 onwards all fail when it comes to this
 
  Succeeds:
  
  http://maven.40175.n5.nabble.com/file/n5789892/release-version-
 prompt-
  v.2.3.2.jpg
  
 
  Failures;
  
  http://maven.40175.n5.nabble.com/file/n5789892/release-version-
 prompt-
  v.2.5-w.version.jpg
  
 
  
  http://maven.40175.n5.nabble.com/file/n5789892/release-version-
 prompt-
  v.2.4.2.jpg
  
 
  
  http://maven.40175.n5.nabble.com/file/n5789892/release-version-
 prompt-
  v.2.4.1.jpg
  
 
  
  http://maven.40175.n5.nabble.com/file/n5789892/release-version-
 prompt-
  v.2.4.jpg
  
 
 
 
 
 
  -
  good @ being sucked @
  --
  View this message in context:
  http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-
 releasin
  g-snapshots-tp5789837p5789892.html
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

Fully agree but with a snapshot not should be treated an release.

The concept of official snapshots along with full site info and branch
tagging don't seem wrong where I come from.
If a project going through some stringent QA where formal test teams want to
keep track of what they testing against, then I think some kind of mile
stone snapshot have a place.

If on the other hand the only way these projects can keep track of these
mile stones releases, then it seem that the only option would be to
release something official - in effect clogging the official prod state
repo with non prod state content.

I think this bogs down to convenience - maven release process provide a few
steps that makes is fairly simple for developers to deal with and
distinguish between snapshot's and formal releases i.e non tagged release
without the -SNAPSHOT tag

I find it somewhat difficult to understand why earlier versions of the
maven-release-plugin allow for this when at the same time the same plugin
prevent final releases to refer to -snapshot's ?
Fair enough if a line has been drawn between snapshots and formal release,
but the convenience factor seem get lost in the discussion.

Exactly what is the rationale behind allowing a snapshot being released
without the site info and scm branches being created? - apart from this
being a quick release - it's not complete and auditing this release becomes
troublesome lacking scm branch and site info to audit.
These snapshots don;t even have to be committed back to your scm, so what
happens if test teams sign off on such milestone - at the time this is
committed back, the source may have changed.

Personally I think it would be better to release a mile stone snapshot
with full information (such as a scm branch and site info being generated
and deployed)

If snapshots (as a concept) is problematic then why not open up for a mile
stone snapshot concept ?
A mile stone released into the official releases repo is still not to be
treated as a release so no dependencies should be allowed to exists to
snapshot or mile stone ref's when you perform an official release.

Another point to make is that a snapshot repo can / and will be cleaned on
regular basis - after all a snapshot *or if mile stone snapshot is deemed
as short lived resources never meant for prod.

Have I got this concept completely wrong or do we need to introduce yet more
layers on what we have at our disposal ?

cheers





-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789928.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

release:branch - yes, release:prepare - no


On 28 March 2014 13:49, James Nord (jnord) jn...@cisco.com wrote:

 shouldn't release:branch still support this still though?

 If not that's bad as you will end up with a release version on the head of
 either the source branch or the new branch (and both should be used for
 ongoing development so should be snapshots...)

 /James

  -Original Message-
  From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
  Sent: 28 March 2014 13:32
  To: Maven Users List
  Subject: Re: maven release-plugin 2.5 bug - releasing snapshots...
 
  Let me rephrase. The release plugin is designed to make release versions.
  It is not designed to make -SNAPSHOT versions. It was a bug that it let
 you
  specify a -SNAPSHOT version as the release version. The bug has been
 fixed.
 
 
  On 28 March 2014 13:18, ghostwolf59
  martin.cederv...@commerce.wa.gov.auwrote:
 
   That's a way to general statement to be made  - that also is incorrect
   !
  
   A snapshot is not allowed for final release - but could still be
   released into a shapshot repo for test purposes !
   The question really bogs down to how much control you'd like to have
   against a release snapshot.
   Anyone can in effect release a snapshot into the remote archiva
   snapshot repo but no scm branch tag would take place and the source
   this snapshot was based on would be unknown since uncommitted data
   could have been used.
  
   If you go down the path of controlling this (in selected cases) you'd
   like to have full control over the source it represent as well be able
   to assess the site info linked to this release.
  
   A simple mvn deploy would not do these things - it would only promote
   a local build into archiva's snapshot repository - with a lot of ???
   to follow when it comes to QA, source control etc.
  
  
   I am not trying to do a */release/* as such - it's a legit release
   of a
   */snapshot/* to be used for test purposed in a highly controlled
   manner pending official signoffs - once a signoff is received a proper
   release for that version would be performed.
  
   The final release would never be allowed to be a snapshot - nor would
   any snapshot dependencies be allowed but that's a side issue and have
   absolutely nothing to do with what I am arguing about.
  
   The snapshot release would end up in a dedicated snapshot repository
   so why you go down this path I don't really understand - bogs down to
   how v2.2.2 vs higher versions of the release-plugin behaves.
  
   I have now done some tests going back in history and it shows that all
   versions after *v.2.3.2* (my initial test was on v2.2.2) fails when it
   comes to this...
  
   So it appear that v 2.4 onwards all fail when it comes to this
  
   Succeeds:
   
   http://maven.40175.n5.nabble.com/file/n5789892/release-version-
  prompt-
   v.2.3.2.jpg
   
  
   Failures;
   
   http://maven.40175.n5.nabble.com/file/n5789892/release-version-
  prompt-
   v.2.5-w.version.jpg
   
  
   
   http://maven.40175.n5.nabble.com/file/n5789892/release-version-
  prompt-
   v.2.4.2.jpg
   
  
   
   http://maven.40175.n5.nabble.com/file/n5789892/release-version-
  prompt-
   v.2.4.1.jpg
   
  
   
   http://maven.40175.n5.nabble.com/file/n5789892/release-version-
  prompt-
   v.2.4.jpg
   
  
  
  
  
  
   -
   good @ being sucked @
   --
   View this message in context:
   http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-
  releasin
   g-snapshots-tp5789837p5789892.html
   Sent from the Maven - Users mailing list archive at Nabble.com.
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

2014-03-28 Thread Robert Scholte

So if I understand correctly you want to use SNAPSHOTs because:
- you don't want the artifact to end up in the releases-repository yes,
because QA needs to be done first
- SNAPSHOTs are cleaned up automatically, so if QA doesn't accept a
release, it's cleaned up for you.

The SNAPSHOT usage here is some kind of workaround if there would only be
exactly 1 releases-repository. (assuming you're using a repository manager
like Nexus, Artifactory or Archiva [1]).
However, nowadays repo manager have features to be able to cope with this
kind of problems.
What you are looking for is staging: a concept where you release your
artifacts to the QA-repository. If they accept it, they push it to the
next repository, ... until it is pushed to the company-repository, ready
to be used by everyone.
If one of the testing departments doesn't accept a version, the stage is
destroyed and the artifact won't be available anymore.
AFAIK all these repo managers support staging, however for some you have
to pay. (Or there are ways to fake staging, i.e. downloading from one repo
and uploading to the other...)

The QA should never accept that they test a SNAPSHOT. If they accept it,
they should also test the released version, just because it is a new
distribution.

Google a bit more for artifact repository + staging, which is a proven
concept which seems to match your requirements.

regards,
Robert

[1] http://maven.apache.org/repository-management.html

Op Fri, 28 Mar 2014 17:24:10 +0100 schreef ghostwolf59
martin.cederv...@commerce.wa.gov.au:

Fully agree but with a snapshot not should be treated an release.

The concept of official snapshots along with full site info and branch
tagging don't seem wrong where I come from.
If a project going through some stringent QA where formal test teams
want to

keep track of what they testing against, then I think some kind of mile
stone snapshot have a place.

If on the other hand the only way these projects can keep track of these
mile stones releases, then it seem that the only option would be to
release something official - in effect clogging the official prod
state

repo with non prod state content.

I think this bogs down to convenience - maven release process provide a
few

steps that makes is fairly simple for developers to deal with and
distinguish between snapshot's and formal releases i.e non tagged release
without the -SNAPSHOT tag

I find it somewhat difficult to understand why earlier versions of the
maven-release-plugin allow for this when at the same time the same plugin
prevent final releases to refer to -snapshot's ?
Fair enough if a line has been drawn between snapshots and formal
release,

but the convenience factor seem get lost in the discussion.

Exactly what is the rationale behind allowing a snapshot being released
without the site info and scm branches being created? - apart from this
being a quick release - it's not complete and auditing this release
becomes

troublesome lacking scm branch and site info to audit.
These snapshots don;t even have to be committed back to your scm, so what
happens if test teams sign off on such milestone - at the time this is
committed back, the source may have changed.

Personally I think it would be better to release a mile stone snapshot
with full information (such as a scm branch and site info being generated
and deployed)

If snapshots (as a concept) is problematic then why not open up for a
mile

stone snapshot concept ?
A mile stone released into the official releases repo is still not to
be

treated as a release so no dependencies should be allowed to exists to
snapshot or mile stone ref's when you perform an official release.

Another point to make is that a snapshot repo can / and will be cleaned
on
regular basis - after all a snapshot *or if mile stone snapshot is
deemed

as short lived resources never meant for prod.

Have I got this concept completely wrong or do we need to introduce yet
more

layers on what we have at our disposal ?

cheers

-
good @ being sucked @
--
View this message in context:
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789928.html

Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

2014-03-28 Thread Robert Scholte


Hi,
Let me join this thread, because that someone is me. As said by Stephen:  
the version handling prior to 2.4 contained several issues, so you were  
relying on a bug.

This has all been done as part of MRELEASE-511[1] and related issues.

There is no such thing as a formal SNAPSHOT: it's a formal release or a  
SNAPSHOT, not both.
If you want the release to be formal, use version patterns with alpha,  
beta, milestone or release candidate as supported by Maven (through  
Aether)[2]
If you want to  upload to the SNAPSHOT repository, just deploy the  
development version
If you want a tag/branch, either use release:branch, scm:branch or  
scm:tag[3]
Keep in mind: the difference in behavior between a release and a SNAPSHOT.  
And versions are considered cheap nowadays.


thanks,
Robert

[1] https://jira.codehaus.org/browse/MRELEASE-511
[2]  
http://sonatype.github.io/sonatype-aether/apidocs/org/sonatype/aether/util/version/GenericVersionScheme.html

[3] http://maven.apache.org/scm/maven-scm-plugin/

Op Fri, 28 Mar 2014 15:12:54 +0100 schreef ghostwolf59  
martin.cederv...@commerce.wa.gov.au:



Doing it as I explained did NOT allow you to do a release or refer to it
within other resources during a legic release phase

What you triggered was a release (as if legit) to go into the snapshot  
repo
- cant see any issues with that kind of behavior and have turned out to  
be

very useful when implementing formal test signoffs where exact version
tested against become critical (mind you these test phases is done before
even taken the app to UAT - technically still in a development phase).

Allowing these formal snapshots releases to be released into the  
snapshot

repo can hardly affect the normal behavior of releasing local builds
(without any constraint of the build was done against committed data - as
it's currently works)

From what I hear is that someone decided to plug this feature =  
personally

(and form an organizational point of view I think you removed useful
functionality)

Next question: if this now is a planned move - why not allow snapshots  
(that
maven does on local uncommitted data) to be processed as if it actually  
is
somewhat legit - without open up the possibility to use this as a prod  
state

resource in the dependency sections ?





-
good @ being sucked @
--
View this message in context:  
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789916.html

Sent from the Maven - Users mailing list archive at Nabble.com.

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


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

Re: maven release-plugin 2.5 bug - releasing snapshots...

2014-03-28 Thread Wayne Fay

 Let me join this thread, because that someone is me. As said by Stephen:
 the version handling prior to 2.4 contained several issues, so you were
 relying on a bug.

Reminds me of this classic XKCD... :)
https://xkcd.com/1172/

Wayne

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

Re: maven release-plugin 2.5 bug - releasing snapshots...

 So if I understand correctly you want to use SNAPSHOTs because:
 - you don't want the artifact to end up in the releases-repository yes,  

correct

 because QA needs to be done first

Not quite - occasionally projects (still in development state but nearing
its end) engage formal internal test teams to conduct tests against what
they delivered (these tests involve performance, integration as well as
functional tests)
All this takes place in an *non* locked down SIT env.
Our formal Archiva release repository is technically not used for other than
resources that is deemed well behaved that passed internal unit tests,
system integration and in some cases systems that have gone through formal
tests by test teams that received a signed off by the internal test team.
Once a delivery has been signed off the official release id done (into our
releases repo) - this release is then pushed out to the locked down UAT env
where the business perform functional tests and once happy and a sign off
have been received that same release is then pushed into PROD.
So in effect our releases repo is only used for UAT and PROD.

Releasing a snapshot is a convenient one but I think a snapshot could be
viewed in two different ways, normal  mile stone where mile stone snapshot
releases could include all the info a formal release would include.
- The ability to release snapshot still exists under the latest plugins -
what's now gone missing is the ability to release everything that would be
generated during a formal release i.e javadoc, site info, scm branch tagging
etc.
Even if a snapshot is cleaned out I think it would be very rare occasions
where this would become a problem - the scm branch could in such case be
used to rebuild the lost snapshot release.

I think our bottom line is that we only want to see properly tested and sane
releases in our prod state releases repo - any such release have been
formally requested and approved by our Change Management process - snapshots
is managed by individual developers and do not go through a sign off
process.

The way we integrated Archiva, project site info and Subversion works really
well - this latest issue of not being able to build full snapshot releases
would in effect force us to change our current process - either by banning
these sort of mile stones or force developers to 
1. manually branch tag the source, 
2. build a local site 
3. push the locally built site info out to our project web site 
4. push out the snapshot to archivas snapshot repo

There's a lot that can (and honestly will) go wrong here - the earlier
version of the plugin took care of most of this (only issue being that a
developer may overwrite the release and scm version at the prompt with wrong
info)
 
 What you are looking for is staging: a concept where you release your  
 artifacts to the QA-repository. If they accept it, they push it to the  
 next repository, ... until it is pushed to the company-repository, ready  
 to be used by everyone. 

I will look into this - seem like a sensible way to go about things

Thanks for the advice given by all

cheers



-
good @ being sucked @
--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789950.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

Re: Maven Release Plugin throws Authentication Required error

2014-03-06 Thread Baptiste Mathus

Hi,
First try do to that without using Jenkins at all. This is a pure maven
configuration thing. You just seem to be missing the  authentication part
(see username and password parameters maybe).

When you manage to release some dummy versions of your project, then and
only then try doing it from Jenkins or any other automated system.

Cheers
Le 6 mars 2014 15:14, D Vijay vijayd1...@gmail.com a écrit :

 Dear All,


 I need help in configuring the Maven Release plugin. I am trying to
 configure the plugin in Jenkins job. I am getting authentication exception.
 For invoking maven release plugin do we need to have svn client from where
 we are invoking the release? PFA the errors  the configuration that I used
 for this.

 My requirement is to configure maven release plugin as follows:

 1. My current version is at 1.0.0-SNAPSHOT and once testing is done and
 ready for movement to production the maven release plugin will be invoked
 from Jenkins job to move the code from branch to trunk.
 2. The configuration has to check out the source from branch, update all
 the POMs to version 1.0.0, tag the source code and check in the code at
 trunk location. The tags folder will contain the tagged version at 1.0.0
 (as best practice we need to change the version from 1.0.0-SNAPSHOT to
 1.0.0 once the product is ready for production, right? or while moving to
 UAT itself it should be done?).
 3. Also, the next snapshot version will be updated to 1.0.1-SNAPSHOT(which
 is configurable in release plugin) and checked in at branch level for the
 next development.

 I am able to configure this, but somehow it is not working. I am getting
 authentication exception.
 svn: Authentication required for 
 'https://server-mydomain.com:443https://server-mydomain.com/
 '.


 Thank you,

 Vijay.


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

Re: maven-release-plugin updates modules with wrong versioning

2014-02-03 Thread Stephen Connolly

are you using git 1.8.5.x?


On 3 February 2014 15:56, Simone Tripodi simonetrip...@apache.org wrote:

 Hi all mates,

 in Apache Oltu we have a commons modules set[1] which I am trying to cut a
 release, but I am experiencing for the first time a strange issue: when
 installing all modules from /trunk, versions respect what it is specified
 in project.version field in the POM, but when releasing them, all modules
 inherit the version from the parent.

 Can I kindly ask you an extra pair of eyes that would help me detecting why
 this is happening?

 Many thanks in advance, all the best!
 -Simo

 [1] https://svn.apache.org/repos/asf/oltu/trunk/commons/

 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi

Re: maven-release-plugin updates modules with wrong versioning

2014-02-03 Thread Stephen Connolly

nevermind... wrong question that this is the answer for


On 3 February 2014 15:57, Stephen Connolly
stephen.alan.conno...@gmail.comwrote:

 are you using git 1.8.5.x?


 On 3 February 2014 15:56, Simone Tripodi simonetrip...@apache.org wrote:

 Hi all mates,

 in Apache Oltu we have a commons modules set[1] which I am trying to cut a
 release, but I am experiencing for the first time a strange issue: when
 installing all modules from /trunk, versions respect what it is specified
 in project.version field in the POM, but when releasing them, all modules
 inherit the version from the parent.

 Can I kindly ask you an extra pair of eyes that would help me detecting
 why
 this is happening?

 Many thanks in advance, all the best!
 -Simo

 [1] https://svn.apache.org/repos/asf/oltu/trunk/commons/

 http://people.apache.org/~simonetripodi/
 http://twitter.com/simonetripodi

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

2013-12-09 Thread Stephen Connolly

There is a know issue with Git and release plugin 2.4.2 and something to do
with SCM version bundled in Maven 3.1.1? (or maybe 3.1.x) Olivier may know
more.


On 9 December 2013 02:40, Mark Derricutt m...@talios.com wrote:

 Hey all,

 Just encountered a strange issue with the maven-release-plugin, when doing
 a release:prepare from my machine using Maven 3.1.1, and
 maven-release-plugin 2.4.2 I get the following output:

 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Tagging release with the label com.smxemail.translation-13.2.9...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git tag
 -F
 /var/folders/bq/jtxn4t511xz7l_t3t4q4c634gn/T/maven-scm-596385603.commit
 com.smxemail.translation-13.2.9
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 ls-files
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Transforming 'com.smxemail.translation'...
 [INFO] Not removing release POMs
 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Release preparation complete.
 [INFO]
 
 [INFO] BUILD SUCCESS

 You can see here that there are no git commit commands being run, this
 in turn breaks the build.

 A coworker who is still using Maven 3.0.4 was able to prepare and release
 the artefact fine however, so I'm wondering if there's some issue at the
 SCM layer of maven that's breaking when running under 3.1.1 that isn't an
 issue when using 3.0.4.

 Has anyone else seen any behaviour like this?

 Mark

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

2013-12-09 Thread Mark Derricutt

I was speaking with Olivier on IRC earlier, so far I've managed to work around 
the issue by adding a dependency/ on the latest maven-scm-providers-gitexe 
inside my maven-release-plugin plugin/ block and that seems to have resolved 
the issue.

Simply dropping back to 2.3.2 of the release plugin didn't help as that still 
picked up the older maven-scm version which was looking for a git status output 
starting with #.

Mark

On 9 Dec 2013, at 22:00, Stephen Connolly wrote:

 There is a know issue with Git and release plugin 2.4.2 and something to do
 with SCM version bundled in Maven 3.1.1? (or maybe 3.1.x) Olivier may know
 more.


signature.asc
Description: OpenPGP digital signature

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

2013-12-09 Thread Stephen Connolly

yeah your subsequent reply where you identified the change in git behaviour
would lead to that solution...


On 9 December 2013 09:48, Mark Derricutt m...@talios.com wrote:

 I was speaking with Olivier on IRC earlier, so far I've managed to work
 around the issue by adding a dependency/ on the latest
 maven-scm-providers-gitexe inside my maven-release-plugin plugin/ block
 and that seems to have resolved the issue.

 Simply dropping back to 2.3.2 of the release plugin didn't help as that
 still picked up the older maven-scm version which was looking for a git
 status output starting with #.

 Mark

 On 9 Dec 2013, at 22:00, Stephen Connolly wrote:

  There is a know issue with Git and release plugin 2.4.2 and something to
 do
  with SCM version bundled in Maven 3.1.1? (or maybe 3.1.x) Olivier may
 know
  more.

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

2013-12-09 Thread Olivier Lamy

On 9 December 2013 20:48, Mark Derricutt m...@talios.com wrote:
 I was speaking with Olivier on IRC earlier, so far I've managed to work 
 around the issue by adding a dependency/ on the latest 
 maven-scm-providers-gitexe inside my maven-release-plugin plugin/ block and 
 that seems to have resolved the issue.

 Simply dropping back to 2.3.2 of the release plugin didn't help as that still 
 picked up the older maven-scm version which was looking for a git status 
 output starting with #.


Yup correct.
I hope we avoid such issue when using jgit provider (if it's released one day)

 Mark

 On 9 Dec 2013, at 22:00, Stephen Connolly wrote:

 There is a know issue with Git and release plugin 2.4.2 and something to do
 with SCM version bundled in Maven 3.1.1? (or maybe 3.1.x) Olivier may know
 more.

AFAIK scm is not bundled with core.



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

2013-12-09 Thread Robert Scholte


Hi,

Here's a list of the maven-release-plugin and the matching SCM versions.

m-release-plugin:2.3.2 depends on scm:1.7
m-release-plugin:2.4 depends on scm:1.8 (standard upgrade, incl. SCM-686)
m-release-plugin:2.4.1 depends on scm:1.7 (back due to MRELEASE-830,  
SCM-709 )

m-release-plugin:2.4.2 depends on scm:1.7

SCM-686 introduced the porcelain option. However, suddenly all releases  
where evaluated/tagged from the root of the repository instead of the root  
of the project. This broke a lot of projects, more compared to the  
addition of porcelain, so I decided to fall back to 1.7.
SCM-709 is probably fixed by now, but I'm still missing the feedback. I've  
closed it as part of SCM 1.9, so I'll include it with the next m-release-p.


Robert

Op Mon, 09 Dec 2013 11:56:21 +0100 schreef Olivier Lamy ol...@apache.org:


On 9 December 2013 20:48, Mark Derricutt m...@talios.com wrote:
I was speaking with Olivier on IRC earlier, so far I've managed to work  
around the issue by adding a dependency/ on the latest  
maven-scm-providers-gitexe inside my maven-release-plugin plugin/  
block and that seems to have resolved the issue.


Simply dropping back to 2.3.2 of the release plugin didn't help as that  
still picked up the older maven-scm version which was looking for a git  
status output starting with #.




Yup correct.
I hope we avoid such issue when using jgit provider (if it's released  
one day)



Mark

On 9 Dec 2013, at 22:00, Stephen Connolly wrote:

There is a know issue with Git and release plugin 2.4.2 and something  
to do
with SCM version bundled in Maven 3.1.1? (or maybe 3.1.x) Olivier may  
know

more.


AFAIK scm is not bundled with core.




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

Re: maven-release-plugin oddity - no git commit under mvn 3.1.1

2013-12-08 Thread Mark Derricutt

Ok - so this looks to be an issue introduced in Git 1.8.5, from
https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt

 * git status now omits the prefix to make its output a comment in a
   commit log editor, which is not necessary for human consumption.
   Scripts that parse the output of git status are advised to use
   git status --porcelain instead, as its format is stable and easier
   to parse.

From looking at the git log of
./maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/status/GitStatusConsumer.java
I see that the has been using the newer git status --porcelain command
for some time now, however from walking the dependencies of
maven-release-plugin, I appear to find 1.7 being resolved ( at least via
IntellliJ ).

It looks like Olivier Lamy updated the git status support in [1] in git
commit 5c58908896a1b82bc6ee0af005adf0d6ef326395

Up until this week this didn't appear to be a problem, until Git 1.8.5 was
released and removed the leading # from the status messages

How do we get Maven to start using the newer releases of SCM - is that just
a matter of declaring a dependency in my parent pom?

Mark



[1] [SCM-686] Maven SCM failed to parse git status output if git messages
are translated - Submitted by Ralf Thielow.

-- 
Great artists are extremely selfish and arrogant things — Steven Wilson,
Porcupine Tree


On Mon, Dec 9, 2013 at 3:40 PM, Mark Derricutt m...@talios.com wrote:

 Hey all,

 Just encountered a strange issue with the maven-release-plugin, when doing
 a release:prepare from my machine using Maven 3.1.1, and
 maven-release-plugin 2.4.2 I get the following output:

 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Tagging release with the label com.smxemail.translation-13.2.9...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git tag
 -F
 /var/folders/bq/jtxn4t511xz7l_t3t4q4c634gn/T/maven-scm-596385603.commit
 com.smxemail.translation-13.2.9
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 ls-files
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Transforming 'com.smxemail.translation'...
 [INFO] Not removing release POMs
 [INFO] Checking in modified POMs...
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git add
 -- pom.xml
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Executing: /bin/sh -c cd
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation  git
 status
 [INFO] Working directory:
 /Users/amrk/IdeaProjects/securemx/smx3/com.smxemail.translation
 [INFO] Release preparation complete.
 [INFO]
 
 [INFO] BUILD SUCCESS

 You can see here that there are no git commit commands being run, this
 in turn breaks the build.

 A coworker who is still using Maven 3.0.4 was able to prepare and release
 the artefact fine however, so I'm wondering if there's some issue at the
 SCM layer of maven that's breaking when running under 3.1.1 that isn't an
 issue when using 3.0.4.

 Has anyone else seen any behaviour like this?

 Mark

Re: maven-release-plugin with github project

2013-07-27 Thread Robert Scholte


http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
will help you.

Robert

Op Sat, 27 Jul 2013 18:13:28 +0200 schreef alejandro.e...@miranda.com:




I'm  trying to release a multimodule maven project cloned in github. My   
project has the parent pom as a submodule of the root aggregator. if i   
run the release in dryRun mode it works fine, however if I run it for   
real this is what i get near the end



...
[INFO] Checking in modified POMs...
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom   git add -- jrobocom-parent/pom.xml  
jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml   
jrobocom-samples/simple/black-jacks/pom.xml   
jrobocom-samples/simple/bank-jumper/pom.xml pom.xml

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom  git status

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom   git commit --verbose -F  
/tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml  
jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml   
jrobocom-samples/simple/black-jacks/pom.xml   
jrobocom-samples/simple/bank-jumper/pom.xml pom.xml

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom  git symbolic-ref HEAD

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom   git push   
https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator   
master:master

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  


[INFO] Reactor Summary:
[INFO]
[INFO] Parent POM  SKIPPED
...
[INFO] Bank-jumper ... SKIPPED
[INFO] The overall aggregator  FAILURE  
[3:30.447s]
[INFO]  


[INFO] BUILD FAILURE
[INFO]  


[INFO] Total time: 3:32.658s
[INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
[INFO] Final Memory: 9M/44M
[INFO]  

[ERROR]  Failed to execute goal   
org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare   
(default-cli) on project jrobocom-aggregator: Unable to commit files

[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR]  fatal:   
https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refs   
not found: did you run git update-server-info on the server?

[ERROR] - [Help 1]


If  I run that same git push command by hand it does give me that  
error,  however, if i run the push with the url just up to .git and  
remove the /jrobocom-aggregator it works fine


Where  does the MRP take the push url from? i'm running mvn from the  
root  aggregator since i want to release all submodules together but i  
don't  see why the push url should include the aggregator's artifact id


What am i doing wrong? this seems like the canonical release procedure

This  is the aggregator POM (before running the release) in case anyone  
is  interested  
https://github.com/theHilikus/JRoboCom/blob/master/pom.xml  and from  
there you can find all the other poms


Thank you,
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.


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

Re: maven-release-plugin with github project

2013-07-27 Thread Arnaud Héritier

Someone show me a similar issue with the release plugin in a project
using git where the parent/reactor is at the same level than modules
(moreover each modules where git submodules AFAIR )

The usage of relative path with in the reactor breaks the release.
There is an issue in Jira with a patch but AFAIR there was only the
code fix (no new test ..)

-
Arnaud

Le 27 juil. 2013 à 18:14, alejandro.e...@miranda.com
alejandro.e...@miranda.com a écrit :



 I'm  trying to release a multimodule maven project cloned in github. My  
 project has the parent pom as a submodule of the root aggregator. if i  run 
 the release in dryRun mode it works fine, however if I run it for  real this 
 is what i get near the end


 ...
 [INFO] Checking in modified POMs...
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom   git add -- jrobocom-parent/pom.xml 
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml  
 jrobocom-samples/legends/pom.xml jrobocom-samples/simple/pom.xml  
 jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom  git status
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom   git commit --verbose -F 
 /tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml 
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml  
 jrobocom-samples/legends/pom.xml jrobocom-samples/simple/pom.xml  
 jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom  git symbolic-ref HEAD
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse 
 workspace/JRoboCom   git push  
 https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  master:master
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Parent POM  SKIPPED
 ...
 [INFO] Bank-jumper ... SKIPPED
 [INFO] The overall aggregator  FAILURE [3:30.447s]
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 3:32.658s
 [INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
 [INFO] Final Memory: 9M/44M
 [INFO] 
 
 [ERROR]  Failed to execute goal  
 org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare  (default-cli) on 
 project jrobocom-aggregator: Unable to commit files
 [ERROR] Provider message:
 [ERROR] The git-push command failed.
 [ERROR] Command output:
 [ERROR]  fatal:  
 https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refs  not 
 found: did you run git update-server-info on the server?
 [ERROR] - [Help 1]


 If  I run that same git push command by hand it does give me that error,  
 however, if i run the push with the url just up to .git and remove the 
 /jrobocom-aggregator it works fine

 Where  does the MRP take the push url from? i'm running mvn from the root  
 aggregator since i want to release all submodules together but i don't  see 
 why the push url should include the aggregator's artifact id

 What am i doing wrong? this seems like the canonical release procedure

 This  is the aggregator POM (before running the release) in case anyone is  
 interested https://github.com/theHilikus/JRoboCom/blob/master/pom.xml  and 
 from there you can find all the other poms

 Thank you,
 DISCLAIMER:
 Privileged and/or Confidential information may be contained in this
 message. If you are not the addressee of this message, you may not
 copy, use or deliver this message to anyone. In such event, you
 should destroy the message and kindly notify the sender by reply
 e-mail. It is understood that opinions or conclusions that do not
 relate to the official business of the company are neither given
 nor endorsed by the company.
 Thank You.

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

Re: maven-release-plugin with github project

 Thank you Robert
I tried MRP 2.3.2 and i got the exact same result. I also have the same setup 
referenced in the OP's comment on the accepted answer (aggregator inherits from 
parent, parent is a submodule of aggregator and actual code modules depend on 
their sibling parent) but somehow it doesn't work for me. The only difference i 
see is git.

Arnaud, in the SO question referenced by Robert and in the blog post referenced 
in it at least 2 other people managed to make it work with an explicit relative 
path. Here is the referenced blog
http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
i'm sure adding git submodules makes everything much more complex. This is why 
i'm surprised mine doesn't work, my setup is very vanilla so i'm sure there's 
hundreds of people trying to do the same thing

Thanks for your help

Any other ideas?

i would still like to know why the push url contains the artifactId of the 
aggregator. I'm not sure if this is MRP or the scm plugin's doing



-Robert Scholte rfscho...@apache.org wrote: -
To: Maven Users List users@maven.apache.org
From: Robert Scholte rfscho...@apache.org
Date: 07/27/2013 12:29PM
Subject: Re: maven-release-plugin with github project

http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
will help you.

Robert

Op Sat, 27 Jul 2013 18:13:28 +0200 schreef alejandro.e...@miranda.com:



 I'm  trying to release a multimodule maven project cloned in github. My  
 project has the parent pom as a submodule of the root aggregator. if i  
 run the release in dryRun mode it works fine, however if I run it for  
 real this is what i get near the end


 ...
 [INFO] Checking in modified POMs...
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom   git add -- jrobocom-parent/pom.xml  
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
 jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
 jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom  git status
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom   git commit --verbose -F  
 /tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml  
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
 jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
 jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom  git symbolic-ref HEAD
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom   git push  
 https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  
 master:master
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Parent POM  SKIPPED
 ...
 [INFO] Bank-jumper ... SKIPPED
 [INFO] The overall aggregator  FAILURE  
 [3:30.447s]
 [INFO]  
 
 [INFO] BUILD FAILURE
 [INFO]  
 
 [INFO] Total time: 3:32.658s
 [INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
 [INFO] Final Memory: 9M/44M
 [INFO]  
 
 [ERROR]  Failed to execute goal  
 org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare  
 (default-cli) on project jrobocom-aggregator: Unable to commit files
 [ERROR] Provider message:
 [ERROR] The git-push command failed.
 [ERROR] Command output:
 [ERROR]  fatal:  
 https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refs  
 not found: did you run git update-server-info on the server?
 [ERROR] - [Help 1]


 If  I run that same git push command by hand it does give me that  
 error,  however, if i run the push with the url just up to .git and  
 remove the /jrobocom-aggregator it works fine

 Where  does the MRP take the push url from? i'm running mvn from the  
 root  aggregator since i want to release all submodules together but i  
 don't  see why the push url should include the aggregator's artifact id

 What am i doing wrong

Re: maven-release-plugin with github project

2013-07-27 Thread Robert Scholte


Hi,

From which location are you releasing, from master or from jrobocom-parent?

If it's the first, then the scm section should be placed here.
If it's the latter, I think your scm-connections are wrong(not sure) and  
you must use m-release-p 2.3.2 due to the SCM-709 issue.


Robert


Op Sat, 27 Jul 2013 21:35:48 +0200 schreef alejandro.e...@miranda.com:


 Thank you Robert
I tried MRP 2.3.2 and i got the exact same result. I also have the same  
setup referenced in the OP's comment on the accepted answer (aggregator  
inherits from parent, parent is a submodule of aggregator and actual  
code modules depend on their sibling parent) but somehow it doesn't work  
for me. The only difference i see is git.


Arnaud, in the SO question referenced by Robert and in the blog post  
referenced in it at least 2 other people managed to make it work with an  
explicit relative path. Here is the referenced blog

http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
i'm sure adding git submodules makes everything much more complex. This  
is why i'm surprised mine doesn't work, my setup is very vanilla so i'm  
sure there's hundreds of people trying to do the same thing


Thanks for your help

Any other ideas?

i would still like to know why the push url contains the artifactId of  
the aggregator. I'm not sure if this is MRP or the scm plugin's doing




-Robert Scholte rfscho...@apache.org wrote: -
To: Maven Users List users@maven.apache.org
From: Robert Scholte rfscho...@apache.org
Date: 07/27/2013 12:29PM
Subject: Re: maven-release-plugin with github project

http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
will help you.

Robert

Op Sat, 27 Jul 2013 18:13:28 +0200 schreef alejandro.e...@miranda.com:




I'm  trying to release a multimodule maven project cloned in github. My  
 project has the parent pom as a submodule of the root aggregator. if i  
run the release in dryRun mode it works fine, however if I run it for  
real this is what i get near the end



...
[INFO] Checking in modified POMs...
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom   git add -- jrobocom-parent/pom.xml  
jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
jrobocom-samples/simple/bank-jumper/pom.xml pom.xml

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom  git status

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom   git commit --verbose -F  
/tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml  
jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
 jrobocom-samples/simple/black-jacks/pom.xml  
jrobocom-samples/simple/bank-jumper/pom.xml pom.xml

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom  git symbolic-ref HEAD

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
workspace/JRoboCom   git push  
https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  
master:master

[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  


[INFO] Reactor Summary:
[INFO]
[INFO] Parent POM  SKIPPED
...
[INFO] Bank-jumper ... SKIPPED
[INFO] The overall aggregator  FAILURE  
[3:30.447s]
[INFO]  


[INFO] BUILD FAILURE
[INFO]  


[INFO] Total time: 3:32.658s
[INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
[INFO] Final Memory: 9M/44M
[INFO]  

[ERROR]  Failed to execute goal  
org.apache.maven.plugins:maven-release-plugin:2.4.1:prepare  
(default-cli) on project jrobocom-aggregator: Unable to commit files

[ERROR] Provider message:
[ERROR] The git-push command failed.
[ERROR] Command output:
[ERROR]  fatal:  
https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator/info/refs  
not found: did you run git update-server-info on the server?

[ERROR] - [Help 1]


If  I run that same git push command by hand it does give me that  
error,  however, if i run the push

Re: maven-release-plugin with github project

2013-07-27 Thread Arnaud Héritier

The issue I was referring to was this one :
https://jira.codehaus.org/browse/MRELEASE-581

Arnaud


On Sat, Jul 27, 2013 at 9:49 PM, Robert Scholte rfscho...@apache.orgwrote:

 Hi,

 From which location are you releasing, from master or from jrobocom-parent?

 If it's the first, then the scm section should be placed here.
 If it's the latter, I think your scm-connections are wrong(not sure) and
 you must use m-release-p 2.3.2 due to the SCM-709 issue.

 Robert


 Op Sat, 27 Jul 2013 21:35:48 +0200 schreef alejandro.e...@miranda.com:


   Thank you Robert
 I tried MRP 2.3.2 and i got the exact same result. I also have the same
 setup referenced in the OP's comment on the accepted answer (aggregator
 inherits from parent, parent is a submodule of aggregator and actual code
 modules depend on their sibling parent) but somehow it doesn't work for me.
 The only difference i see is git.

 Arnaud, in the SO question referenced by Robert and in the blog post
 referenced in it at least 2 other people managed to make it work with an
 explicit relative path. Here is the referenced blog
 http://warpedjavaguy.**wordpress.com/2011/08/08/how-**
 i-defeated-the-maven-release-**plugin-in-a-flat-structured-**
 multi-module-project/http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
 i'm sure adding git submodules makes everything much more complex. This
 is why i'm surprised mine doesn't work, my setup is very vanilla so i'm
 sure there's hundreds of people trying to do the same thing

 Thanks for your help

 Any other ideas?

 i would still like to know why the push url contains the artifactId of
 the aggregator. I'm not sure if this is MRP or the scm plugin's doing



 -Robert Scholte rfscho...@apache.org wrote: -
 To: Maven Users List users@maven.apache.org
 From: Robert Scholte rfscho...@apache.org
 Date: 07/27/2013 12:29PM
 Subject: Re: maven-release-plugin with github project

 http://stackoverflow.com/**questions/17766247/maven-**
 release-plugin-pushing-tags-**to-wrong-repo/17771493#**17771493http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
 will help you.

 Robert

 Op Sat, 27 Jul 2013 18:13:28 +0200 schreef alejandro.e...@miranda.com:



 I'm  trying to release a multimodule maven project cloned in github. My
  project has the parent pom as a submodule of the root aggregator. if i run
 the release in dryRun mode it works fine, however if I run it for real this
 is what i get near the end


 ...
 [INFO] Checking in modified POMs...
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom   git add -- jrobocom-parent/pom.xml
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml
  jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
  jrobocom-samples/simple/**4Lunch/pom.xml
  jrobocom-samples/simple/black-**jacks/pom.xml
 jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom  git status
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom   git commit --verbose -F /tmp/maven-scm-646807004.
 **commit  jrobocom-parent/pom.xml jrobocom-core/pom.xml
  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml
  jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
  jrobocom-samples/simple/**4Lunch/pom.xml
  jrobocom-samples/simple/black-**jacks/pom.xml
 jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom  git symbolic-ref HEAD
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom   git push https://github.com/theHilikus/**
 JRoboCom.git/jrobocom-**aggregatorhttps://github.com/theHilikus/JRoboCom.git/jrobocom-aggregatormaster:master
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] --**--**
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Parent POM ..**.. SKIPPED
 ...
 [INFO] Bank-jumper ..**. SKIPPED
 [INFO] The overall aggregator  FAILURE
 [3:30.447s]
 [INFO] --**--**
 
 [INFO] BUILD FAILURE
 [INFO] --**--**
 
 [INFO] Total time: 3:32.658s
 [INFO] Finished at: Tue Jul 23 22:31:43 EDT 2013
 [INFO] Final Memory: 9M/44M
 [INFO

Re: maven-release-plugin with github project

2013-07-27 Thread Robert Scholte

I'll try to fix this with Mark for the next release. I think more and more  
people will hit this issue.


Robert

Op Sat, 27 Jul 2013 22:15:33 +0200 schreef Arnaud Héritier  
aherit...@gmail.com:



The issue I was referring to was this one :
https://jira.codehaus.org/browse/MRELEASE-581

Arnaud


On Sat, Jul 27, 2013 at 9:49 PM, Robert Scholte  
rfscho...@apache.orgwrote:



Hi,

From which location are you releasing, from master or from  
jrobocom-parent?


If it's the first, then the scm section should be placed here.
If it's the latter, I think your scm-connections are wrong(not sure) and
you must use m-release-p 2.3.2 due to the SCM-709 issue.

Robert


Op Sat, 27 Jul 2013 21:35:48 +0200 schreef alejandro.e...@miranda.com:


  Thank you Robert

I tried MRP 2.3.2 and i got the exact same result. I also have the same
setup referenced in the OP's comment on the accepted answer (aggregator
inherits from parent, parent is a submodule of aggregator and actual  
code
modules depend on their sibling parent) but somehow it doesn't work  
for me.

The only difference i see is git.

Arnaud, in the SO question referenced by Robert and in the blog post
referenced in it at least 2 other people managed to make it work with  
an

explicit relative path. Here is the referenced blog
http://warpedjavaguy.**wordpress.com/2011/08/08/how-**
i-defeated-the-maven-release-**plugin-in-a-flat-structured-**
multi-module-project/http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
i'm sure adding git submodules makes everything much more complex. This
is why i'm surprised mine doesn't work, my setup is very vanilla so i'm
sure there's hundreds of people trying to do the same thing

Thanks for your help

Any other ideas?

i would still like to know why the push url contains the artifactId of
the aggregator. I'm not sure if this is MRP or the scm plugin's doing



-Robert Scholte rfscho...@apache.org wrote: -
To: Maven Users List users@maven.apache.org
From: Robert Scholte rfscho...@apache.org
Date: 07/27/2013 12:29PM
Subject: Re: maven-release-plugin with github project

http://stackoverflow.com/**questions/17766247/maven-**
release-plugin-pushing-tags-**to-wrong-repo/17771493#**17771493http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
will help you.

Robert

Op Sat, 27 Jul 2013 18:13:28 +0200 schreef  
alejandro.e...@miranda.com:





I'm  trying to release a multimodule maven project cloned in github.  
My
 project has the parent pom as a submodule of the root aggregator. if  
i run
the release in dryRun mode it works fine, however if I run it for  
real this

is what i get near the end


...
[INFO] Checking in modified POMs...
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
workspace/JRoboCom   git add -- jrobocom-parent/pom.xml
jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
jrobocom-samples/pom.xml

 jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
 jrobocom-samples/simple/**4Lunch/pom.xml
 jrobocom-samples/simple/black-**jacks/pom.xml
jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
workspace/JRoboCom  git status
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
workspace/JRoboCom   git commit --verbose -F  
/tmp/maven-scm-646807004.

**commit  jrobocom-parent/pom.xml jrobocom-core/pom.xml
 jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml
 jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
 jrobocom-samples/simple/**4Lunch/pom.xml
 jrobocom-samples/simple/black-**jacks/pom.xml
jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
workspace/JRoboCom  git symbolic-ref HEAD
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
workspace/JRoboCom   git push https://github.com/theHilikus/**
JRoboCom.git/jrobocom-**aggregatorhttps://github.com/theHilikus/JRoboCom.git/jrobocom-aggregatormaster:master
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
[INFO]  
--**--**


[INFO] Reactor Summary:
[INFO]
[INFO] Parent POM ..**.. SKIPPED
...
[INFO] Bank-jumper ..**. SKIPPED
[INFO] The overall aggregator  FAILURE
[3:30.447s]
[INFO]  
--**--**


[INFO] BUILD FAILURE
[INFO]  
--**--**


[INFO] Total time: 3

[CAUTION: Suspicious URL content] Re: maven-release-plugin with github project

from the root of the project, which is the same level as the aggregator pom. 
But instead of putting the scm section there like you suggest, I just made the 
aggregator inherit from its submodule (jrobocom-parent). Maybe this is what's 
confusing the release plugin. i will try duplicating the SCM section on the 
aggregator (not great, DRY principle, but i need to be able to have a defined 
SCM on the code modules so I cannot just move the scm section from 
jrobocom-parent to jrobocom-aggregator)





-Robert Scholte rfscho...@apache.org wrote: -
To: Maven Users List users@maven.apache.org
From: Robert Scholte rfscho...@apache.org
Date: 07/27/2013 03:49PM
Subject: [CAUTION: Suspicious URL content]  Re: maven-release-plugin with 
github project

Hi,

 From which location are you releasing, from master or from jrobocom-parent?

If it's the first, then the scm section should be placed here.
If it's the latter, I think your scm-connections are wrong(not sure) and  
you must use m-release-p 2.3.2 due to the SCM-709 issue.

Robert


Op Sat, 27 Jul 2013 21:35:48 +0200 schreef alejandro.e...@miranda.com:

  Thank you Robert
 I tried MRP 2.3.2 and i got the exact same result. I also have the same  
 setup referenced in the OP's comment on the accepted answer (aggregator  
 inherits from parent, parent is a submodule of aggregator and actual  
 code modules depend on their sibling parent) but somehow it doesn't work  
 for me. The only difference i see is git.

 Arnaud, in the SO question referenced by Robert and in the blog post  
 referenced in it at least 2 other people managed to make it work with an  
 explicit relative path. Here is the referenced blog
 http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
 i'm sure adding git submodules makes everything much more complex. This  
 is why i'm surprised mine doesn't work, my setup is very vanilla so i'm  
 sure there's hundreds of people trying to do the same thing

 Thanks for your help

 Any other ideas?

 i would still like to know why the push url contains the artifactId of  
 the aggregator. I'm not sure if this is MRP or the scm plugin's doing



 -Robert Scholte rfscho...@apache.org wrote: -
 To: Maven Users List users@maven.apache.org
 From: Robert Scholte rfscho...@apache.org
 Date: 07/27/2013 12:29PM
 Subject: Re: maven-release-plugin with github project

 http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
 will help you.

 Robert

 Op Sat, 27 Jul 2013 18:13:28 +0200 schreef alejandro.e...@miranda.com:



 I'm  trying to release a multimodule maven project cloned in github. My  
  project has the parent pom as a submodule of the root aggregator. if i  
 run the release in dryRun mode it works fine, however if I run it for  
 real this is what i get near the end


 ...
 [INFO] Checking in modified POMs...
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom   git add -- jrobocom-parent/pom.xml  
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
 jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
 jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
  jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom  git status
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom   git commit --verbose -F  
 /tmp/maven-scm-646807004.commit  jrobocom-parent/pom.xml  
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml  
 jrobocom-samples/pom.xml  jrobocom-samples/legends/pom.xml  
 jrobocom-samples/simple/pom.xml  jrobocom-samples/simple/4Lunch/pom.xml  
  jrobocom-samples/simple/black-jacks/pom.xml  
 jrobocom-samples/simple/bank-jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom  git symbolic-ref HEAD
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse  
 workspace/JRoboCom   git push  
 https://github.com/theHilikus/JRoboCom.git/jrobocom-aggregator  
 master:master
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Parent POM  SKIPPED
 ...
 [INFO] Bank-jumper ... SKIPPED
 [INFO] The overall aggregator  FAILURE  
 [3:30.447s]
 [INFO]  
 
 [INFO

[CAUTION: Suspicious URL content] Re: maven-release-plugin with github project

 There seem to be some differences to my case. The bug says It seems to think 
for some reason that I am at the root of my scm tree. In my case i AM in the 
root of my scm tree. Also, in his problem, the build fails on the git commit. 
in my case it fails on the git push after the commit succeeds. Some comments 
also mention it happens in windows/cygwin. I'm running mine in linux

-Arnaud Héritier aherit...@gmail.com wrote: -
To: Maven Users List users@maven.apache.org
From: Arnaud Héritier aherit...@gmail.com
Date: 07/27/2013 04:16PM
Subject: [CAUTION: Suspicious URL content]  Re: maven-release-plugin with 
github project

The issue I was referring to was this one :
https://jira.codehaus.org/browse/MRELEASE-581

Arnaud

On Sat, Jul 27, 2013 at 9:49 PM, Robert Scholte rfscho...@apache.orgwrote:

 Hi,

 From which location are you releasing, from master or from jrobocom-parent?

 If it's the first, then the scm section should be placed here.
 If it's the latter, I think your scm-connections are wrong(not sure) and
 you must use m-release-p 2.3.2 due to the SCM-709 issue.

 Robert

 Op Sat, 27 Jul 2013 21:35:48 +0200 schreef alejandro.e...@miranda.com:

   Thank you Robert
 I tried MRP 2.3.2 and i got the exact same result. I also have the same
 setup referenced in the OP's comment on the accepted answer (aggregator
 inherits from parent, parent is a submodule of aggregator and actual code
 modules depend on their sibling parent) but somehow it doesn't work for me.
 The only difference i see is git.

 Arnaud, in the SO question referenced by Robert and in the blog post
 referenced in it at least 2 other people managed to make it work with an
 explicit relative path. Here is the referenced blog
 http://warpedjavaguy.**wordpress.com/2011/08/08/how-**
 i-defeated-the-maven-release-**plugin-in-a-flat-structured-**
 multi-module-project/http://warpedjavaguy.wordpress.com/2011/08/08/how-i-defeated-the-maven-release-plugin-in-a-flat-structured-multi-module-project/
 i'm sure adding git submodules makes everything much more complex. This
 is why i'm surprised mine doesn't work, my setup is very vanilla so i'm
 sure there's hundreds of people trying to do the same thing

 Thanks for your help

 Any other ideas?

 i would still like to know why the push url contains the artifactId of
 the aggregator. I'm not sure if this is MRP or the scm plugin's doing

 -Robert Scholte rfscho...@apache.org wrote: -
 To: Maven Users List users@maven.apache.org
 From: Robert Scholte rfscho...@apache.org
 Date: 07/27/2013 12:29PM
 Subject: Re: maven-release-plugin with github project

 http://stackoverflow.com/**questions/17766247/maven-**
 release-plugin-pushing-tags-**to-wrong-repo/17771493#**17771493http://stackoverflow.com/questions/17766247/maven-release-plugin-pushing-tags-to-wrong-repo/17771493#17771493
 will help you.

 Robert

 Op Sat, 27 Jul 2013 18:13:28 +0200 schreef alejandro.e...@miranda.com:

 I'm  trying to release a multimodule maven project cloned in github. My
  project has the parent pom as a submodule of the root aggregator. if i run
 the release in dryRun mode it works fine, however if I run it for real this
 is what i get near the end

 ...
 [INFO] Checking in modified POMs...
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom   git add -- jrobocom-parent/pom.xml
 jrobocom-core/pom.xml  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml
  jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
  jrobocom-samples/simple/**4Lunch/pom.xml
  jrobocom-samples/simple/black-**jacks/pom.xml
 jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom  git status
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom   git commit --verbose -F /tmp/maven-scm-646807004.
 **commit  jrobocom-parent/pom.xml jrobocom-core/pom.xml
  jrobocom-simple-gui/pom.xml jrobocom-samples/pom.xml
  jrobocom-samples/legends/pom.**xml jrobocom-samples/simple/pom.**xml
  jrobocom-samples/simple/**4Lunch/pom.xml
  jrobocom-samples/simple/black-**jacks/pom.xml
 jrobocom-samples/simple/bank-**jumper/pom.xml pom.xml
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO] Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom  git symbolic-ref HEAD
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO]  Executing: /bin/sh -c cd /home/hilikus/dev/Eclipse
 workspace/JRoboCom   git push https://github.com/theHilikus/**
 JRoboCom.git/jrobocom-**aggregatorhttps://github.com/theHilikus/JRoboCom.git/jrobocom-aggregatormaster:master
 [INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
 [INFO

Re: maven-release-plugin with github project