On 26 April 2012 23:13, Robert Scholte <apa...@sourcegrounds.com> wrote:
> Op Thu, 26 Apr 2012 14:57:14 +0200 schreef Stephen Connolly < > stephen.alan.connolly@gmail.**com <stephen.alan.conno...@gmail.com>>: > > > On 26 April 2012 13:40, Anders Hammar <and...@hammar.net> wrote: >> >> > I would argue that those are broken projects. You should pretty much >>> always >>> > use mrm if you are using invoker for testing a maven plugin. There are >>> > cases where you might use invoker for something else, in which case you >>> > should not be specifying a custom settings.xml. >>> >>> I might be wrong, but this would be the case for most of the plugins >>> at Apache Maven then. And all mojos at Codehaus Mojo. >>> >>> >> Correct. Everyone except versions-maven-plugin @ mojo is doing it wrong >> ;-) >> >> > Well, I managed to get the ci-aggregator fixed last weekend, but the > versions-m-p still has some problems ;) > See > http://bamboo.ci.codehaus.org/**browse/MOJO<http://bamboo.ci.codehaus.org/browse/MOJO> > > IIRC that is some actual broken tests ;-) > > >> >>> > So, in short, if you specify a custom settings.xml then no merge by >>> default. >>> >>> Ah, so could the rule be that if no settings.xml is specified use the >>> one of the calling process. If one is specified, do not merge by >>> default? >>> >>> >> That would be the correct thing to do IMHO >> >> >> >>> /Anders >>> >>> > >>> > >>> >> That's why I want the calling process' settings-xml to be merged. And >>> >> I argue that, at least in my use case :-), that would be the default >>> >> behavior. >>> >> >>> > >>> > I have no issue with being able to turn it on via the CLI if you know >>> what >>> > you are doing, but where a project has provided a custom settings.xml >>> it >>> > must be assumed that the reason for the custom settings.xml is because >>> they >>> > want to control the invoker environment completely... if they are not >>> using >>> > mrm then they are being foolish as there is no other way to lock down >>> the >>> > invoker environment *and* work transparently behind a proxy at the >>> present >>> > time. >>> > >>> > If this is not the default behavior but needs to be configured, it has >>> >> to be able to turn on from command line as one shouldn't have to >>> >> update the pom IMO. >>> >> >>> >> At least my couple of cents, >>> >> /Anders >>> >> On Thu, Apr 26, 2012 at 10:15, Stephen Connolly >>> >> <stephen.alan.connolly@gmail.**com <stephen.alan.conno...@gmail.com>> >>> wrote: >>> >> > I actually think the merge feature is a step backwards and I am >>> toying >>> >> with >>> >> > being -1 on the commit. >>> >> > >>> >> > for proxies I think mrm-maven-plugin @ mojo is the way to go. >>> >> > >>> >> > invoker is a different use case from release, so passing through the >>> >> > settings is, in general, a bad thing. If you make the merge an >>> opt-in >>> >> then >>> >> > that is OK, but personally I cannot see any good use case for it now >>> that >>> >> > we have mrm-maven-plugin to solve the proxy issue >>> >> > >>> >> > On 26 April 2012 09:07, Olivier Lamy <ol...@apache.org> wrote: >>> >> > >>> >> >> Good catch on the warning for activated profiles. >>> >> >> They are activated in the maven build so the invoker plugin merge >>> >> >> those setting with those eventually defined in the mojo >>> configuration >>> >> >> field (<settingsFile> ). >>> >> >> What I can do is made this merge feature optional (off by default >>> and >>> >> >> add a debug flag to display it for debugging purpose). >>> >> >> WDYT ? >>> >> >> >>> >> >> 2012/4/25 Karl Heinz Marbaise <khmarba...@gmx.de>: >>> >> >> > Hi, >>> >> >> > >>> >> >> > just an other question came to my mind >>> >> >> > >>> >> >> > What is the purpose of the >>> >> >> > >>> >> http://maven.apache.org/**plugins/maven-invoker-plugin-** >>> 1.6/build-job.html<http://maven.apache.org/plugins/maven-invoker-plugin-1.6/build-job.html> >>> >> >> This is the format of the file produced by invoker plugin and used >>> by >>> >> >> the report mojo. >>> >> >> > >>> >> >> > It's given as a link in the docs? But i can't find an explanation >>> >> which >>> >> >> > intention it has ? May be i oversight it simply ? >>> >> >> > >>> >> >> > Can someone enlighten me? >>> >> >> > >>> >> >> > Thanks in advance... >>> >> >> > >>> >> >> > >>> >> >> > Kind regards >>> >> >> > Karl Heinz Marbaise >>> >> >> > -- >>> >> >> > SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / >>> 415 >>> 893 >>> >> >> > Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029 >>> >> >> > Hauptstrasse 177 USt.IdNr: DE191347579 >>> >> >> > 52146 Würselen http://www.soebes.de >>> >> >> > >>> >> >> > >>> ------------------------------**------------------------------** >>> --------- >>> >> >> > To unsubscribe, e-mail: >>> >> >> > dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> >>> >> >> > For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> > >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> Olivier Lamy >>> >> >> Talend: http://coders.talend.com >>> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >> >> >>> >> >> ------------------------------**------------------------------** >>> --------- >>> >> >> To unsubscribe, e-mail: >>> >> >> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> >>> >> >> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >>> >> >> >>> >> >>> >> ------------------------------**------------------------------** >>> --------- >>> >> To unsubscribe, e-mail: >>> >> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> >>> >> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >>> >> >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> > For additional commands, e-mail: dev-h...@maven.apache.org > >
