You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ghostwolf59 <ma...@commerce.wa.gov.au> on 2014/03/28 10:59:59 UTC
maven release-plugin 2.5 bug - releasing snapshots...
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.
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Ron Wheeler <rw...@artifact-software.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by ghostwolf59 <ma...@commerce.wa.gov.au>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Robert Scholte <rf...@apache.org>.
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
<ma...@commerce.wa.gov.au>:
> Fully agree but with a snapshot not should be treated an release.
>
> The concept of "official snapshots" along with full site info and branch
> tagging don't seem wrong where I come from.
> If a project going through some stringent QA where formal test teams
> want to
> keep track of what they testing against, then I think some kind of "mile
> stone snapshot" have a place.
>
> If on the other hand the only way these projects can keep track of these
> "mile stones" releases, then it seem that the only option would be to
> release something "official" - in effect clogging the "official" prod
> state
> repo with non prod state content.
>
> I think this bogs down to convenience - maven release process provide a
> few
> steps that makes is fairly simple for developers to deal with and
> distinguish between snapshot's and formal releases i.e non tagged release
> without the -SNAPSHOT tag
>
> I find it somewhat difficult to understand why earlier versions of the
> maven-release-plugin allow for this when at the same time the same plugin
> prevent final releases to refer to -snapshot's ?
> Fair enough if a line has been drawn between snapshots and formal
> release,
> but the convenience factor seem get lost in the discussion.
>
> Exactly what is the rationale behind allowing a snapshot being released
> without the site info and scm branches being created? - apart from this
> being a quick release - it's not complete and auditing this release
> becomes
> troublesome lacking scm branch and site info to audit.
> These snapshots don;t even have to be committed back to your scm, so what
> happens if test teams sign off on such milestone - at the time this is
> committed back, the source may have changed.
>
> Personally I think it would be better to release a "mile stone" snapshot
> with full information (such as a scm branch and site info being generated
> and deployed)
>
> If snapshots (as a concept) is problematic then why not open up for a
> "mile
> stone" snapshot concept ?
> A "mile stone" released into the official releases repo is still not to
> be
> treated as a release so no dependencies should be allowed to exists to
> snapshot or "mile stone" ref's when you perform an official release.
>
> Another point to make is that a snapshot repo can / and will be cleaned
> on
> regular basis - after all a snapshot *or if "mile stone" snapshot is
> deemed
> as short lived resources never meant for prod.
>
> Have I got this concept completely wrong or do we need to introduce yet
> more
> layers on what we have at our disposal ?
>
> cheers
>
>
>
>
>
> -----
> good @ being sucked @
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789928.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by ghostwolf59 <ma...@commerce.wa.gov.au>.
Fully agree but with a snapshot not should be treated an release.
The concept of "official snapshots" along with full site info and branch
tagging don't seem wrong where I come from.
If a project going through some stringent QA where formal test teams want to
keep track of what they testing against, then I think some kind of "mile
stone snapshot" have a place.
If on the other hand the only way these projects can keep track of these
"mile stones" releases, then it seem that the only option would be to
release something "official" - in effect clogging the "official" prod state
repo with non prod state content.
I think this bogs down to convenience - maven release process provide a few
steps that makes is fairly simple for developers to deal with and
distinguish between snapshot's and formal releases i.e non tagged release
without the -SNAPSHOT tag
I find it somewhat difficult to understand why earlier versions of the
maven-release-plugin allow for this when at the same time the same plugin
prevent final releases to refer to -snapshot's ?
Fair enough if a line has been drawn between snapshots and formal release,
but the convenience factor seem get lost in the discussion.
Exactly what is the rationale behind allowing a snapshot being released
without the site info and scm branches being created? - apart from this
being a quick release - it's not complete and auditing this release becomes
troublesome lacking scm branch and site info to audit.
These snapshots don;t even have to be committed back to your scm, so what
happens if test teams sign off on such milestone - at the time this is
committed back, the source may have changed.
Personally I think it would be better to release a "mile stone" snapshot
with full information (such as a scm branch and site info being generated
and deployed)
If snapshots (as a concept) is problematic then why not open up for a "mile
stone" snapshot concept ?
A "mile stone" released into the official releases repo is still not to be
treated as a release so no dependencies should be allowed to exists to
snapshot or "mile stone" ref's when you perform an official release.
Another point to make is that a snapshot repo can / and will be cleaned on
regular basis - after all a snapshot *or if "mile stone" snapshot is deemed
as short lived resources never meant for prod.
Have I got this concept completely wrong or do we need to introduce yet more
layers on what we have at our disposal ?
cheers
-----
good @ being sucked @
--
View this message in context: http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789928.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Wayne Fay <wa...@gmail.com>.
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Robert Scholte <rf...@apache.org>.
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
<ma...@commerce.wa.gov.au>:
> Doing it as I explained did NOT allow you to do a release or refer to it
> within other resources during a legic release phase
>
> What you triggered was a release (as if legit) to go into the snapshot
> repo
> - cant see any issues with that kind of behavior and have turned out to
> be
> very useful when implementing formal test signoffs where exact version
> tested against become critical (mind you these test phases is done before
> even taken the app to UAT - technically still in a development phase).
>
> Allowing these "formal" snapshots releases to be released into the
> snapshot
> repo can hardly affect the normal behavior of releasing local builds
> (without any constraint of the build was done against committed data - as
> it's currently works)
>
> From what I hear is that someone decided to plug this "feature" =
> personally
> (and form an organizational point of view I think you removed useful
> functionality)
>
> Next question: if this now is a planned move - why not allow snapshots
> (that
> maven does on local uncommitted data) to be processed as if it actually
> is
> somewhat legit - without open up the possibility to use this as a prod
> state
> resource in the dependency sections ?
>
>
>
>
>
> -----
> good @ being sucked @
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789916.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by ghostwolf59 <ma...@commerce.wa.gov.au>.
Doing it as I explained did NOT allow you to do a release or refer to it
within other resources during a legic release phase
What you triggered was a release (as if legit) to go into the snapshot repo
- cant see any issues with that kind of behavior and have turned out to be
very useful when implementing formal test signoffs where exact version
tested against become critical (mind you these test phases is done before
even taken the app to UAT - technically still in a development phase).
Allowing these "formal" snapshots releases to be released into the snapshot
repo can hardly affect the normal behavior of releasing local builds
(without any constraint of the build was done against committed data - as
it's currently works)
>From what I hear is that someone decided to plug this "feature" = personally
(and form an organizational point of view I think you removed useful
functionality)
Next question: if this now is a planned move - why not allow snapshots (that
maven does on local uncommitted data) to be processed as if it actually is
somewhat legit - without open up the possibility to use this as a prod state
resource in the dependency sections ?
-----
good @ being sucked @
--
View this message in context: http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789916.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Stephen Connolly <st...@gmail.com>.
release:branch -> yes, release:prepare -> no
On 28 March 2014 13:49, James Nord (jnord) <jn...@cisco.com> wrote:
> shouldn't release:branch still support this still though?
>
> If not that's bad as you will end up with a release version on the head of
> either the source branch or the new branch (and both should be used for
> ongoing development so should be snapshots...)
>
> /James
>
> > -----Original Message-----
> > From: Stephen Connolly [mailto:stephen.alan.connolly@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
> > <ma...@commerce.wa.gov.au>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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: maven release-plugin 2.5 bug - releasing snapshots...
Posted by "James Nord (jnord)" <jn...@cisco.com>.
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.connolly@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
> <ma...@commerce.wa.gov.au>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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Stephen Connolly <st...@gmail.com>.
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 <ma...@commerce.wa.gov.au>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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by ghostwolf59 <ma...@commerce.wa.gov.au>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Stephen Connolly <st...@gmail.com>.
You do know you are not allowed to release a version containing a -SNAPSHOT
don't you?
On 28 March 2014 12:23, ghostwolf59 <ma...@commerce.wa.gov.au>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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by ghostwolf59 <ma...@commerce.wa.gov.au>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Stephen Connolly <st...@gmail.com>.
On 28 March 2014 11:12, ghostwolf59 <ma...@commerce.wa.gov.au>wrote:
> <version>2.2.2</version>
Then you are not using version 2.5
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by ghostwolf59 <ma...@commerce.wa.gov.au>.
I don't think this issue have been rectified.
The maven release plugin I use (downloaded from maven central via my plugin)
is as follows...
This fail:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.2</version>
<configuration>
<tagBase>{my svn url and path}/${project.artifactId}/releases</tagBase>
</configuration>
</plugin>
This work:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.2</version>
<configuration>
<tagBase>{my svn url and path}/${project.artifactId}/releases</tagBase>
</configuration>
</plugin>
The clean - as I understand it - would ensure you always have a clean
workspace derived from the remote source at release time - removing the
chance that someone committed something between now and when I perform my
release - that makes perfect sense to me and is a good safeguard
--
View this message in context: http://maven.40175.n5.nabble.com/maven-release-plugin-2-5-bug-releasing-snapshots-tp5789837p5789843.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven release-plugin 2.5 bug - releasing snapshots...
Posted by Baptiste Mathus <ml...@batmat.net>.
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 <ma...@commerce.wa.gov.au>
:
> 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 <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!