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