Hi Stephen, We are not using any preparationGoals. So it's not that my preparation goals are not mimicking a full release. It is that the default dry run is not mimicking a default full release. We are talking about completely vanilla release:prepare. The only non-default value is the resume=false. And about the tradeoff, I see your point, but IMO the defaults should not make those tradeoff decisions for you. The default should be the safest setting, not the fastest
Here are the two goals we run for full and for dry-run respectively -Dresume=false release:prepare release:perform -Dresume=false -DdryRun=true release:prepare I will try to play with the preparationGoals, but again, the default behaviour seems flawed to me Thanks for your help Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly <stephen.alan.conno...@gmail.com> To: Maven Users List <users@maven.apache.org>, Date: 2014-11-27 07:44 PM Subject: Re: release plugin issue On Thursday, 27 November 2014, <alejandro.e...@grassvalley.com> wrote: > 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 It sounds like your preparationGoals are not mimicing a full release... Very often people set them up that way because they are willing to trade off a failed perform against a faster prepare. Typically if you are doing the trade-off you go all the way and make preparationGoals be `initialize`... Sure version numbers are free don't you know > > 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. Again I wonder have you (or somebody else) tweaked the defaults > 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. Or by prepare before it starts the build... I think that should be a valid complaint > 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 > > > 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. > -- Sent from my phone 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.
