subject:"Maven Release plugin"

On Thu, May 29, 2014 at 8:48 PM, Laird Nelson  wrote:

> Sure enough, I'm never seeing a git commit operation (with -X turned on).
>  How can I get commits to start working again?  Am I overlooking an option?
>

Upgrading the maven-release-plugin version to 2.5 caused commit operations
to start being issued again and I was (finally) able to perform a release
in the same way I've been performing them for years prior.

Other readers: do kindly check your own maven-release-plugin version
stanzas and make sure you're not using version 2.4.2.  When operating the
Apple git client, commits are never sent and you will release the wrong
thing with no errors.

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Maven release plugin having trouble with transformations?

On Thu, May 29, 2014 at 8:15 PM, Laird Nelson  wrote:

> It is as though the transformation is not being committed properly.
>

Sure enough, I'm never seeing a git commit operation (with -X turned on).
 How can I get commits to start working again?  Am I overlooking an option?

[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd /Users/ljnelson/Projects/github/nomen &&
git add -- pom.xml
[INFO] Working directory: /Users/ljnelson/Projects/github/nomen
[INFO] Executing: /bin/sh -c cd /Users/ljnelson/Projects/github/nomen &&
git status
[INFO] Working directory: /Users/ljnelson/Projects/github/nomen
[DEBUG] On branch master
[DEBUG] Your branch is up-to-date with 'origin/master'.
[DEBUG]
[DEBUG] Changes to be committed:
[DEBUG]   (use "git reset HEAD ..." to unstage)
[DEBUG]
[DEBUG] modified:   pom.xml
[DEBUG]
[DEBUG] Untracked files:
[DEBUG]   (use "git add ..." to include in what will be committed)
[DEBUG]
[DEBUG] pom.xml.releaseBackup
[DEBUG] release.properties
[DEBUG]
[INFO] Tagging release with the label nomen-1.0.6...
[DEBUG] ScmTagPhase :: scmTagParameters remotingTag true
[DEBUG] ScmTagPhase :: scmTagParameters scmRevision null
[DEBUG] ScmTagPhase :: fileSet  basedir =
/Users/ljnelson/Projects/github/nomen; files = []
[INFO] Executing: /bin/sh -c cd /Users/ljnelson/Projects/github/nomen &&
git tag -F
/var/folders/6q/r_047dp54lxdh5w7zhcg8044gn/T/maven-scm-174490540.commit
nomen-1.0.6

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Maven release plugin having trouble with transformations?

On Thu, May 29, 2014 at 7:52 PM, Laird Nelson  wrote:

> Now, on a particular project on GitHub, it is incorrectly transforming my
> pom.xml and attempting to release the project as a snapshot.
>

Whittling this down a bit, it looks like the transformation works properly,
because after transformation, the release plugin runs a build, and I can
see in that build that the version is correct (i.e. non-SNAPSHOT).

It appears to be in what is selected for tagging.  The thing that is tagged
(and then checked out later, and then released/deployed) is my original
development pom.xml.

It is as though the transformation is not being committed properly, or that
the tag is being misapplied.  All the other mysterious screwed-up behavior
descends from here.

What could account for this?  Why now?  Is there something GitHub-related
that might have changed (though that seems wrong)?

Best,
Laird

-- 
http://about.me/lairdnelson

Maven release plugin having trouble with transformations?

This is very puzzling.

For years I've used the maven-release-plugin to automate my releases with
no trouble.

Now, on a particular project on GitHub, it is incorrectly transforming my
pom.xml and attempting to release the project as a snapshot.

The project is drop-dead brainlessly simple.  It is a single-module project.

The version is of the form 1.X.X-SNAPSHOT to start with.  Let's say it's at
1.0.3-SNAPSHOT.

I run mvn release:prepare and answer all the prompts with the defaults, as
I have for years.  It correctly surmises that the release version should be
1.0.3 and the new dev version should be 1.0.4-SNAPSHOT.

It then transforms the pom.xml (apparently), and (apparently) tags the repo.

When I investigate the release.properties file, it looks OK.

However, when I look at the contents of the tag just created, it has the
wrong version in it (1.0.3-SNAPSHOT).  I've tried this back to back, and
sometimes the tag has really random old versions: it's almost like the git
checkout command that the release plugin issues is checking out the wrong
branch or otherwise screwing things up--and all of a sudden, for no
discernible reason.

When I then do a release:perform, what gets mvn deploy'ed is a snapshot
version instead of the expected release version.  Investigating
target/checkout shows that the wrong branch--or perhaps the "right"
branch/tag with the wrong contents--is what was "perform"ed on.

This behavior has never happened to me before and I have not added any
settings or changed anything.  I'm using Maven 3.0.5, the release plugin
version 2.4.2 and Apple git 1.8.5.2.  Completely stumped.

This is really just a plea for help with shotgunning in the dark; has
anyone observed behavior remotely like this before?

Thanks,
Best,
Laird

-- 
http://about.me/lairdnelson

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

2014-03-29 Thread Ron Wheeler


You don't mention Release Candidate of Milestone Releases.
It seems that some of the versions that are going through to integration 
and end-user testing might fit these categories.
These were mentioned earlier in this thread but seemed to have been 
skipped in the discussion as your process got better described.


Ron

On 29/03/2014 12:50 AM, ghostwolf59 wrote:

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





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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

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

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

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

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