Stephen, thanks for these hints, I sometimes used -DperformRelease=true validate as prepGoal and as git does not force you to push tags and is able to clone from the local repository as well, your way is much safer. However with svn removing/readding/recommitting etc. is painful and always leads to problems.
Regards Mirko -- Sent from my mobile On Nov 30, 2014 12:40 AM, "Stephen Connolly" < stephen.alan.conno...@gmail.com> wrote: > On Saturday, November 29, 2014, Mirko Friedenhagen < > mfriedenha...@gmail.com> > wrote: > > > Alejandro, > > > > I have a completely different approach as we use a staging maven > repository > > anyway: > > - make sure your workspace has no extra files by using your SCM clean > > function. > > - only run mvn release:prepare with the following preparationGoals > property > > -DperformRelease=true -DinstallAtEnd=true -DdeployAtEnd=true clean deploy > > - this ensures that only the tested and successfully deployed version of > > your software gets the tag. > > - I expect tagging to be the least dangerous part of the process compared > > to tests, integration tests or the whole maven run with all it's plugins. > > - additionally this speeds up the whole process. > > > But you are not building the checked out tag. If there are ignores that > ignore files that get incorporated in the build you could have a > non-reproducible build. > > (For example, I have a build (zendesk-java-client) where there is a > .gitignore in src/test/resources to allow testing with a .properties file > containing the credentials of a test zendesk. That gets released to > Central. If I had a source assembly as part of it (I cannot recall, I think > I do though) then releasing your way would publish the credentials to > Central in that source bundle... Better would be to have preparationGoals > trivial (ie `initialize`) and then don't push the tag until the very end... > (Though in my case I keep both as I want the additional tests to run with > the credentials and the standard tests to run without so that anyone else > can still build from the tag). The point being that most people just don't > see all the good stuff the release plugin does for you by default and > instead they try to hack around it... Your trick may work for you, but we > can't let people think it should work for everyone and every case) > > > > Regards > > Mirko > > -- > > Sent from my mobile > > On Nov 28, 2014 7:49 PM, <alejandro.e...@grassvalley.com <javascript:;>> > > wrote: > > > > > That's good to know Robert, thank you > > > > > > I will add that to our release dryrun and hopefully it will catch more > of > > > the uncaught problems early on > > > > > > Alejandro Endo | Software Designer/Concepteur de logiciels > > > > > > > > > > > > > > > > > > From: "Robert Scholte" <rfscho...@apache.org <javascript:;>> > > > To: "Maven Users List" <users@maven.apache.org <javascript:;>>, > > > Date: 2014-11-28 12:46 PM > > > Subject: Re: release plugin issue > > > > > > > > > > > > Op Fri, 28 Nov 2014 00:54:29 +0100 schreef > > > <alejandro.e...@grassvalley.com <javascript:;>>: > > > > > > > I'm using the release-plugin v2.5.1 and I'm often encountering two > > > > recurring stories with failed releases > > > > > > > > 1) Now the release can fail due to errors in the javadoc. This is > not a > > > > problem, the problem is that IF there are problems in the javadoc the > > > > release doesn't complete but the two commits and the tag has been > done > > > so > > > > after fixing the javadoc I need to reset the git repo to right before > > > the > > > > failed released AND I have to remove the tag to try again. I am > > > releasing > > > > from jenkins so the resume flag is set to false. if something fails > we > > > > start from the beginning, which makes sense in a build server IMO. My > > > > suggestion here would be to generate all those artifacts (javadoc and > > > > source) before committing and tagging the code, that way if they > fail, > > > > the > > > > repo is not in an invalid state. Another option would be improvement > #2 > > > > > > > > 2) Very often the dryRun succeeds but the real release fails, to the > > > > point > > > > where the dryRun is meaningless. This defeats the whole purpose of a > > > > dry-run. The problem is that the dry run is over simplified. For > > > example, > > > > again, if there are javadoc problems they won't be spotted because > the > > > > dry-run doesn't run javadoc generation. Anything that's part of the > > real > > > > build should be run on the dry-run except for things that make > > > persistent > > > > changes. Another problem I encounter often is that the real release > > > fails > > > > because the tag already exists in SCM (leftover from a previous > failed > > > > release). This should also be validated by the dryRun. If a real > > release > > > > can fail because a tag is already present then the dry run should > fail > > > if > > > > the tag is already present > > > > > > > > What do you guys think? If these points are considered valid I will > > open > > > > > > > a > > > > ticket at least for the second one, which is the worse of the two > > > > > > > > > > It's also possible to do a dryrun for the release:perform since version > > > 2.3 [1] > > > That's still not the default of the jenkins m2-release-plugin, but it > > > works. > > > > > > Robert > > > > > > [1] https://jira.codehaus.org/browse/MRELEASE-736 > > > > > > > > > > > Alejandro Endo | Software Designer/Concepteur de logiciels > > > > > > > > > > > > DISCLAIMER: > > > > Privileged and/or Confidential information may be contained in this > > > > message. If you are not the addressee of this message, you may not > > > > copy, use or deliver this message to anyone. In such event, you > > > > should destroy the message and kindly notify the sender by reply > > > > e-mail. It is understood that opinions or conclusions that do not > > > > relate to the official business of the company are neither given > > > > nor endorsed by the company. > > > > Thank You. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > <javascript:;> > > > For additional commands, e-mail: users-h...@maven.apache.org > > <javascript:;> > > > > > > > > > > > > DISCLAIMER: > > > Privileged and/or Confidential information may be contained in this > > > message. If you are not the addressee of this message, you may not > > > copy, use or deliver this message to anyone. In such event, you > > > should destroy the message and kindly notify the sender by reply > > > e-mail. It is understood that opinions or conclusions that do not > > > relate to the official business of the company are neither given > > > nor endorsed by the company. > > > Thank You. > > > > > > > > -- > Sent from my phone >
