Hi, I don't know if it was the original motivation, but at least this gives us kind of a feature. Releasing is a particular milestone in a project lifecycle. So having to think twice abt it is not totally bad imo.
For example, passing -DskipTests during a release would be plain nonsense to me. And you might end up doing this kind of thing without a conscious choice. -Darguments forces you to think: ok this is what I want to pass to my release. Cheers Le 4 sept. 2011 20:51, "Ansgar Konermann" <[email protected]> a écrit : > Am 04.09.2011 20:43 schrieb "Benson Margulies" <[email protected]>: >> >> On Sun, Sep 4, 2011 at 2:34 PM, Ansgar Konermann >> <[email protected]> wrote: >> > Am 04.09.2011 20:29 schrieb "Brian Fox" <[email protected]>: >> >> >> >> Release forks the build and therefore not all the parameters are >> >> passed through. There is a parameter for the plugin though to specify >> >> which agurments to pass, I forget what it is, but I'm sure you know >> >> how to find it ;-) >> > >> > -Darguments="..." >> >> I wonder: why? Does anyone know a use case in which it's important to >> make the setttings or global settings different in the forked >> execution? > > I'm not a Maven guru, but no, all the use cases I encountered involved > passing the same set of parameters to the forked lifecycle. > > I'd also love to understand the motivation behind making this *not* the > default behaviour. > > Best > > Ansgar >> >> > >> >> >> >> On Sun, Sep 4, 2011 at 1:48 PM, Benson Margulies < [email protected] >> >> > wrote: >> >> > I was a bit taken aback when a run of the maven release plugin failed >> >> > because I ran >> >> > >> >> > mvn -gs my_settings.xml release:prepare >> >> > >> >> > and then the build couldn't find the repositories from the global >> > settings? >> >> > >> >> > Is there really on purpose, or should I write up a JIRA? >> >> > >> >> > --------------------------------------------------------------------- >> >> > 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] >>
