So unless we require a specific id per toolchain, I wouldn't add it to
the
settings.xml
<toolchains>
<toolchain>
<type>jdk</type>
<provides>
<version>1.5</version>
<vendor>sun</vendor>
<id>default</id>
</provides>
<configuration>
<jdkHome>/path/to/jdk/1.5</jdkHome>
</configuration>
</toolchain>
<toolchain>
<type>jdk</type>
<provides>
<version>1.6</version>
<vendor>sun</vendor>
<id>ide</id>
</provides>
<configuration>
<jdkHome>/path/to/jdk/1.6</jdkHome>
</configuration>
</toolchain>
</toolchains>
Robert
btw, I'm pretty far with the ToolchainMerger based on provides, just
need
to write tests to confirm the implementation.
Op Sat, 01 Nov 2014 19:14:03 +0100 schreef Bernd Eckenfels
<[email protected]>:
> Hello,
>
> i can see advantage and disadvantage to having it in the settings
file.
> In my case I have multiple settings files for different repo and
> security settings but only one toolchain describes the host
> installed software.
>
> One option would be to allow includes in the settings.xml, then you
can
> point to a shared toolchain.xml file but still get the whole resolving
> hierachy of settings.xml.
>
> (And you can use it to share or seperate other things. It is only a
> question on how to merge the DOMs).
>
> Gruss
> Bernd
>
> Am Sat, 01 Nov 2014 16:10:19 +0100 schrieb "Robert
>
> Scholte" <[email protected]>:
>> Very interesting suggestion.
>> And it shouldn't be a problem since the settings.xml is a Maven
>> specific file (unlike the pom.xml).
>>
>> Robert
>>
>> Op Sat, 01 Nov 2014 16:02:02 +0100 schreef Hervé BOUTEMY
>>
>> <[email protected]>:
>> > this makes me have another idea:
>> > why are toolchains configured in a specific toolchains.xml file
>> > instead as
>> > settings.xml?
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le samedi 1 novembre 2014 15:53:16 Robert Scholte a écrit :
>> >> Op Sun, 19 Oct 2014 20:19:07 +0200 schreef Karl Heinz Marbaise
>> >>
>> >> <[email protected]>:
>> >> > Hi,
>> >> >
>> >> > On 10/19/14 7:25 PM, Robert Scholte wrote:
>> >> >> Maybe I found an explanation for the location.
>> >> >> Current 'global' isn't really global. It's bound to the Maven
>> >> >> installation. So for instance: whenever you upgrade your Maven,
>> >> >> you shouldn't forget to copy the settings.xml.
>> >> >
>> >> > That's exactly the point...
>> >> >
>> >> > I have at the moment 150 developers which are currently runing
>> >> > against this wall cause the package which is delivered contains
>> >> > the
>> >>
>> >> settings.xml
>> >>
>> >> > in the conf folder of the maven installation....now i have to
>> >> > change
>> >>
>> >> the
>> >>
>> >> > nexus server ...
>> >> >
>> >> >> By putting it under the user.home, you'll never have to change
>> >> >> it.
>> >> >
>> >> > This will work for developers as well for build server like in
>> >> > Jenkins via Config-File-Provider[1] which already handles the
>> >> > setting.xml perfectly...this includes the toolchains.xml as
>> >> > well....Furthermore
>> >>
>> >> this
>> >>
>> >> > supports the usage on slaves as well...
>> >> >
>> >> >> So it works, but IMHO for the wrong reason.
>> >> >
>> >> > Hm..what do you mean by that? Are you talking about security
>> >> > (passwords..) in settings.xml ? (Config-File-Provider supports
>> >> > also credentials etc.)...
>> >>
>> >> I consider user settings as settings specific for this user (e.g.
>> >> passwords) and global settings as settings specific for the
>> >> system. So in
>> >> case you're using a system with multiple users, you don't have to
>> >> redefine
>> >> these settings for every user.
>> >> However, global settings aren't that global, they're bound to the
>> >> Maven Distribution.
>> >> The good thing about this, is that is makes it a lot easier to
>> >> distribute
>> >> a company preconfigured Maven. Just unpack
>> >> apache-maven-3.2.1-acme.zip and
>> >> your repo manager is already set up for you.
>> >>
>> >> It would make sense if there would be something like
>> >> ${env.ALLUSERSPROFILE}\.m2 , but I think that would
>> >> overcomplicate things.
>> >>
>> >> Anyhow, I think we should treat toolchains.xml just like
>> >> settings.xml and
>> >> allow it to be located under conf/ of the Maven distribution.
>> >>
>> >> >> Makes we wonder if we need to think of a real global location
>> >> >> as
>> >>
>> >> well...
>> >>
>> >> > I don't think so ...there are already existing solutions which
>> >> > work
>> >>
>> >> well
>> >>
>> >> > and are supported by the tools (Jenkins etc.)...
>> >> >
>> >> > Ok they might not be accepted by useers as a good solutions this
>> >> > is a different story...
>> >> >
>> >> > But if you introduce a new thing...update of tools etc.
needed...
>> >> >
>> >> > But we have to promote the existing solution....
>> >> >
>> >> > [1]
>>
>>
https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin
>>
>> >> > Kind regards
>> >> > Karl Heinz Marbaise
>> >> >
>> >> >> Robert
>> >> >>
>> >> >> Op Sun, 19 Oct 2014 18:18:34 +0200 schreef Robert Scholte
>> >> >>
>> >> >> <[email protected]>:
>> >> >>> Hi,
>> >> >>>
>> >> >>> since we're slowly upgrading the minimum JDK to run Maven it
>> >> >>> becomes more and more important to let our users know how they
>> >> >>> can compile with an ancient/older version of the JDK. I think
>> >> >>> we all agree that toolchains is the way to go.
>> >> >>> I proposed to add the toolchains to the Maven distribution
>> >> >>> and
>> >>
>> >> already
>> >>
>> >> >>> got a couple of +1's for that idea.
>> >> >>> However, it seems like the toolchain.xml is a user specific
>> >> >>> file and not a global file. [1]
>> >> >>> Putting this file under /conf of the distribution (next to
>> >> >>> the
>> >>
>> >> global
>> >>
>> >> >>> settings.xml) would probably confuse a lot of people it that
>> >> >>> file is not picked up from that location.
>> >> >>> Actually, I would say that tools are system specific and not
>> >> >>> just
>> >>
>> >> user
>> >>
>> >> >>> specific.
>> >> >>>
>> >> >>> Is there any historic reason to configure it per user?
>> >> >>> Should we support global toolchains as well?
>> >> >>>
>> >> >>> thanks,
>> >> >>> Robert
>> >> >>>
>> >> >>> [1]
>> >> >>>
http://maven.apache.org/guides/mini/guide-using-toolchains.html
>> >>
>> >> (
>> >>
>> >> >>> The toolchains.xml file (see below) is the configuration file
>> >> >>> where you set the installation paths of your toolchains. This
>> >> >>> file should
>> >>
>> >> be
>> >>
>> >> >>> put in your $user.home/.m2 directory. )
>>
>> ---------------------------------------------------------------------
>>
>> >> > 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]