Hi,
I've been working on the merger for Toolchains and my conclusion is that
we shouldn't add it to the settings.xml like it is specified right now.
Merging the settings.xml is quite easy: all complex types have a key,
which is used to merge.
The toolchain entries don't have such an element (see below).
There is an id, but it is hidden within <provides>
And <provides> is an Object, only the actual implementation based on the
<type> can understand the content of <provides>
In this case, only the DefaultJavaToolChain can decide if both entries are
the same or not. For jdk it should either be the <id> or <vendor>+<version>
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]
