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" <rfscho...@apache.org>:
> 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
> <herve.bout...@free.fr>:
>
> > 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
> >>
> >> <khmarba...@gmx.de>:
> >> > 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
> >> >>
> >> >> <rfscho...@apache.org>:
> >> >>> 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: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
