Op Sun, 02 Nov 2014 21:52:07 +0100 schreef Hervé BOUTEMY <[email protected]>:

Le samedi 1 novembre 2014 20:52:56 Robert Scholte a écrit :
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>
I think this provide element should be changed to Properties instead of
Object/DOM: toolchain selector in m-toolchains-p defines requirement with
simple properties
so IMHO, this completely open Object/DOM structure is too open

I'm quite sure it's the same for configuration: simple properties should be
sufficient

I agree. Right now it is still an advice, but it's probably easier to change this to pure properties.
I'm already working on the 1.1.0 of toolchains, I'll change this as well.


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>
IMHO, the toolchains merging should not be based on an id but on full provides
info: what is merged or can be overridden is the configuration

I know every example provide an id, but I think it's confusing since this does
not have the same meaning as usual ids

+1, id is indeed weird and should be removed from the examples


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]


---------------------------------------------------------------------
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]

Reply via email to