Is this something we could back port to 3.0.6? On 1 November 2014 19:52, Robert Scholte <[email protected]> wrote:
> 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] > >
