Re: Toolchains part of Maven distribution / global toolchains
Op Sun, 02 Nov 2014 21:52:07 +0100 schreef Hervé BOUTEMY herve.bout...@free.fr: 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 typejdk/type provides version1.5/version vendorsun/vendor iddefault/id /provides configuration jdkHome/path/to/jdk/1.5/jdkHome /configuration /toolchain toolchain typejdk/type provides version1.6/version vendorsun/vendor idide/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 e...@zusammenkunft.net: 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 installationnow 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 wellFurthermore 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
Re: Toolchains part of Maven distribution / global toolchains
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 typejdk/type provides version1.5/version vendorsun/vendor iddefault/id /provides configuration jdkHome/path/to/jdk/1.5/jdkHome /configuration /toolchain toolchain typejdk/type provides version1.6/version vendorsun/vendor idide/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 e...@zusammenkunft.net: 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 installationnow 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 wellFurthermore 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
Re: Toolchains part of Maven distribution / global toolchains
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 installationnow 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 wellFurthermore 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
Re: Toolchains part of Maven distribution / global toolchains
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 installationnow 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 wellFurthermore 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
Re: Toolchains part of Maven distribution / global toolchains
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 installationnow 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 wellFurthermore
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
Re: Toolchains part of Maven distribution / global toolchains
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 installationnow 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
wellFurthermore
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. )
Re: Toolchains part of Maven distribution / global toolchains
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
typejdk/type
provides
version1.5/version
vendorsun/vendor
iddefault/id
/provides
configuration
jdkHome/path/to/jdk/1.5/jdkHome
/configuration
/toolchain
toolchain
typejdk/type
provides
version1.6/version
vendorsun/vendor
idide/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
e...@zusammenkunft.net:
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 installationnow 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
wellFurthermore
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
Re: Toolchains part of Maven distribution / global toolchains
Is this something we could back port to 3.0.6?
On 1 November 2014 19:52, Robert Scholte rfscho...@apache.org 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
typejdk/type
provides
version1.5/version
vendorsun/vendor
iddefault/id
/provides
configuration
jdkHome/path/to/jdk/1.5/jdkHome
/configuration
/toolchain
toolchain
typejdk/type
provides
version1.6/version
vendorsun/vendor
idide/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
e...@zusammenkunft.net:
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 installationnow 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
wellFurthermore
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...
Toolchains part of Maven distribution / global toolchains
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
Re: Toolchains part of Maven distribution / global toolchains
Hello, I think the user config has already a very big meaning because of multiple reasons: Typically developer workstations and CI servers all are single-user only. So the builds are always executed with the same user. So there is nobody complayning if the system is not configured on a system level. This is especially true as people stay away from modifying system config files if they are part of the software distribution and get updated. This is (in my thinking) the main reason why the focus on ~/.m2. However of course I would agree the configuration is symmetric, so it should also look for a system wide toolchain file. BTW: I see there another problem. Toolchains are seldomly used. There is still a lot of dicussions on enforcers/source/target versions. Having a toolchain declaration would fix all of them at the same time, so it is much preferred. Maybe all plugins should mention toolchain as the better alternative for those parameters? (And if would be good to actually fill the gaps on this wiki page: https://cwiki.apache.org/confluence/display/MAVENOLD/Toolchains). Related to this, can a system dependency refer to a toolchain home? (especially rt.jar or similiar needs). Gruss Bernd Am Sun, 19 Oct 2014 18:18:34 +0200 schrieb 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
Re: Toolchains part of Maven distribution / global toolchains
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. By putting it under the user.home, you'll never have to change it. So it works, but IMHO for the wrong reason. Makes we wonder if we need to think of a real global location as well... 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
Re: Toolchains part of Maven distribution / global toolchains
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 installationnow 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 wellFurthermore 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.)... 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
