On Thu, Jan 27, 2011 at 5:01 PM, Brian Fox <[email protected]> wrote: > I don't understand, running the full build on prepare is the default > Maven behavior. This is to make sure that after flipping all the > versions around, that the build works before tagging it.
I think I'm mushing a number of ideas together. Let me try to reassemble them in order. 1. In my opinion, the default Apache POM across the entire ASF should not turn on signing in prepare. Not everyone wants to do that. 2. Since the POM is versioned, changing it to stop that between '8' and '9' is not a problematic incompatibility, since projects have to make a active decision to move to the new one. 3. If my opinion does not carry the day on point 1 (or even if it does), then documentation in an easily-located ASF web site would avoid others getting as confused as I got when I used this POM as the parent of a new project and could not figure out what was going on in :prepare. 4. I had come to the conclusion that the intent of prepare was to be minimal, because it seemed a logical inference from the difficulty of controlling the lifecycle of prepare specifically (e.g. that only that <arguments/> element could change the profiles). As a result, on project that I work on, I've worked hard to get to the point where prepare was minimal. Workflow was 'run a complete build to make sure all is well, run prepare, run perform'. However, if you or anyone else actually knows that the intent of the design was that prepare should be a full build, I just stand corrected. --benson > > On Thu, Jan 27, 2011 at 4:22 PM, Benson Margulies <[email protected]> > wrote: >> I want to just put a bit of emphasis on the global impact of this POM. >> This POM gets advertised as the appropriate parent for \any/ Apache >> project building with Maven. As such, I submit to you, it should >> supply all of the necessary settings (e.g. repository locations, >> deployment) and no surprising extra behavior. If the Land Of Maven >> wants a policy of running a full build on prepare, I'd respectfully >> ask you to embody that policy in a POM that isn't the one advertised >> to the complete Apache community. >> >> On Thu, Jan 27, 2011 at 3:58 PM, Lukas Theussl <[email protected]> wrote: >>> >>> >>> Brian Fox wrote: >>>>> >>>>> FWIW, if the code-signing step fails due to some POM misconfiguration, >>>>> and >>>>> only runs in the perform step, then you've got to rollback the release >>>>> and >>>>> try it again...either that, or muck around with manually shifting the tag >>>>> in >>>>> the SCM, which is probably as ugly. >>>>> >>>>> I'm not as concerned about spending a little extra time to reduce the >>>>> chances of things going wrong in the release process, since this seems to >>>>> happen often enough already...and causes a HUGE waste of time in some >>>>> cases. >>>>> If we were releasing a 100+ module project structure, then I'd be willing >>>>> enough to give on this point and say that accepting a little extra risk >>>>> in >>>>> the 'perform' phase isn't that big of a deal. But, at least in Maven, the >>>>> releases aren't that big. >>>>> >>>> >>>> For Lukas: I agree with John here. >>>> >>>> For everyone else: +1 >>> >>> >>> For everyone: I agree too. Especially with the part about things going wrong >>> often enough. >>> >>> -Lukas >>> >>> >>>> >>>> ;p >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
