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

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

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  
:



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

release:branch -> yes, release:prepare -> no


On 28 March 2014 13:49, James Nord (jnord)  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
> > wrote:
> >
> > > 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
:

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

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

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

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 wrote:

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

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:

Failures;

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

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


On 28 March 2014 12:23, ghostwolf59 wrote:

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

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


 

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

On 28 March 2014 11:12, ghostwolf59 wrote:

> 2.2.2


Then you are not using version 2.5

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

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:


org.apache.maven.plugins
maven-release-plugin
2.2.2

{my svn url and 
path}/${project.artifactId}/releases



This work:

org.apache.maven.plugins
maven-release-plugin
2.2.2

{my svn url and 
path}/${project.artifactId}/releases




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

2014-03-28 Thread Baptiste Mathus

Weird, many users reported the 2.5 had fixed their issues.

What (version) are you actually using for:
* maven
* maven-release-plugin (triple-check you hadn't redefined maven-scm-*
dependency somewhere)
* svn ? Git ? Something else ?

On a unrelated subject : issuing a "mvn clean install deploy" command shows
a tiny misunderstanding of how Maven works. You're asking maven to install
twice (said differently "deploy" already includes the steps from "install").

Cheers


2014-03-28 10:59 GMT+01:00 ghostwolf59 
:

> Hi,Occasionally we have a need to perform a formal release on unfinished
> work
> so it can be tracked.These snapshot releases would in effect be releases
> identical to a formal release with the exception that the snapshot for a
> set
> release is tagged with a time stamp when released into archiva's snapshot
> repository.We used to get around this by issuing the mvn clean
> release:prepare release:perform where we overwrite the proposed/suggested
> release at the prompt by qualifying the release number followed by
> appending
> "-SNAPSHOT"The build would be done identical to a formal release where the
> scm branch is created for the snapshot in  our svn source repo and the
> built
> snapshot would be released into our internal "snapshot" repo (oppose to
> formal non snapshot releases that ends up in the "releases" repo)This used
> to work really well but recently I don't seem to be able to overwrite the
> version at the prompt - when I do it simple prompts me again
> <
> http://maven.40175.n5.nabble.com/file/n5789837/release-version-prompt-v.2.5.jpg
> >
> It's a weird one - this have been proven to be working previously but
> suddenly it don't seem to work any more.The release plugin i currently use
> is v2.5 - in the past I used v 2.2.2 successfully.By reverting back to
> v2.2.2 of org.apache.maven.plugins.maven.release-plugin this work perfectly
> <
> http://maven.40175.n5.nabble.com/file/n5789837/release-version-prompt-v2.2.2.jpg
> >
> Is this a known issue and is it linked to v2.5 of the maven release plugin
> ?I can do snapshot releases using mvn clean install deploy but that would
> not branch tag the source and would not generate site infoBottom line -
> does
> anyone know how this can be done using the most recent
> maven-release-plugin?
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

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

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


On 3 February 2014 15:57, Stephen Connolly
wrote:

> are you using git 1.8.5.x?
>
>
> On 3 February 2014 15:56, Simone Tripodi  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

are you using git 1.8.5.x?


On 3 February 2014 15:56, Simone Tripodi  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 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 :


On 9 December 2013 20:48, Mark Derricutt  wrote:
I was speaking with Olivier on IRC earlier, so far I've managed to work  
around the issue by adding a  on the latest  
maven-scm-providers-gitexe inside my maven-release-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-09 Thread Olivier Lamy

On 9 December 2013 20:48, Mark Derricutt  wrote:
> I was speaking with Olivier on IRC earlier, so far I've managed to work 
> around the issue by adding a  on the latest 
> maven-scm-providers-gitexe inside my maven-release-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 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  wrote:

> I was speaking with Olivier on IRC earlier, so far I've managed to work
> around the issue by adding a  on the latest
> maven-scm-providers-gitexe inside my maven-release-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 Mark Derricutt

I was speaking with Olivier on IRC earlier, so far I've managed to work around 
the issue by adding a  on the latest maven-scm-providers-gitexe 
inside my maven-release-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

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

 Ok, removing the dependency to the parent in the aggregator seemed to fix the 
problem. now the push url makes sense:
git push https://github.com/theHilikus/JRoboCom.git master:master

However, now I encounter a problem i've always had in the past when releasing 
and never bothered to troubleshoot. After running git push I am asked for the 
username and pass of github. After I enter them, the release just hangs there

This is the output using -X

...
[INFO] Executing: /bin/sh -c cd "/home/hilikus/dev/Eclipse workspace/JRoboCom" 
&& git commit --verbose -F /tmp/maven-scm-1784899634.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 master:master
[INFO] Working directory: /home/hilikus/dev/Eclipse workspace/JRoboCom
Username for 'https://github.com': theHilikus
Password for 'https://thehili...@github.com':
//hangs here forever after i press enter

the only way i have been able to fix this is by cancelling the release 
(ctrl-c), running "git push https://github.com/theHilikus/JRoboCom.git 
master:master" by hand (no maven) which completes without a problem, then 
undoing the manual push and then rerunning the release-plugin, which now 
doesn't block after i enter my credentials; pretty annoying and long procedure.

Any ideas what could be wrong this time?

Thanks again,

Alejandro

-"Robert Scholte"  wrote: -----
To: "Maven Users List" 
From: "Robert Scholte" 
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 :

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

[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  wrote: -
To: Maven Users List 
From: Arnaud Héritier 
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 wrote:

> 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 :
>
>
>   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"  wrote: -
>> To: "Maven Users List" 
>> From: "Robert Scholte" 
>> 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<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 :
>>
>>
>>>
>>> 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
>>>  j

[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"  wrote: -
To: "Maven Users List" 
From: "Robert Scholte" 
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 :

>  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"  wrote: -
> To: "Maven Users List" 
> From: "Robert Scholte" 
> 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 :
>
>>
>>
>> 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  
>> ma

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  
:



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  
wrote:



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 :


  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"  wrote: -
To: "Maven Users List" 
From: "Robert Scholte" 
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<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  
:





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

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 wrote:

> 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 :
>
>
>   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"  wrote: -
>> To: "Maven Users List" 
>> From: "Robert Scholte" 
>> 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<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 :
>>
>>
>>>
>>> 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.gi

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 :


 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"  wrote: -
To: "Maven Users List" 
From: "Robert Scholte" 
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 :




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 ru

Re: maven-release-plugin with github project