Re: Changing JDK version without specifying maven-compiler-plugin version
Hi Malte, Btw, tried to have a look at the namespace declaration at http://maven.apache.org/POM/4.0.0- this URL is specified in basically any project xmlns=... of any POM I have seen thus far. Turns out that page does not exist. What's up with that? Funny thing about XML namespaces... they don't actually have to point to a valid URL. They are merely global identifiers, which by convention often happen to point to a valid URL. See: http://www.w3schools.com/xml/xml_namespaces.asp From that page: Note: The namespace URI is not used by the parser to look up information. The purpose is to give the namespace a unique name. However, often companies use the namespace as a pointer to a web page containing namespace information. Notice that that same unique identifier is used as the first of a pair of space-separated values within the xsi:schemaLocation. Of course, one could nonetheless argue it is a bit odd to use an invalid URL as the global identifier. But I think the rationale is probably that using a namespace matching a domain one controls makes it highly unlikely to ever clash with anything else. It's a similar rationale to why Java package prefixes are inverse domain names by convention. Regards, Curtis On Thu, Nov 28, 2013 at 5:12 AM, Malte Skoruppa skoru...@cs.uni-saarland.de wrote: Hi, I thought the version is defined in https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob; f=maven-core/src/main/resources/META-INF/plexus/default-bindings.xml;h= 09ecba441e61d4a997b01af0171815c558548537;hb=maven-3.0.4 (replace hb with the version of your choice :-)). Hmm, I guess you're thinking of Maven 3.1 or something. In Maven 3.0.4 there does not seem to exist a maven-core/src/main/resources/ META-INF/plexus/default-bindings.xml (the fact that your URL does work although the file does not exist in that particular revision is presumably some git peculiarity) See here: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree; f=maven-core/src/main/resources/META-INF/plexus;hb=maven-3.0.4 (or just click the plexus link to go up one level in the git path at the URL you posted) Yet the same things are apparently defined in artifact-handlers.xml for Maven 3.0.4 (so my guess in my previous mail was presumably correct). Anyway, the precise xml file where the default plugin version is defined does not matter that much. What's interesting to note though, is that more things are going on behind the scenes than just what one sees from the uber-pom. So it's not as simple as I had expected. The default plugin version is defined in one place (somewhere in maven-core, and that place is not the uber-pom). The default Java source and target versions are defined somewhere else entirely, in the implementation of the maven-compiler-plugin. Makes sense, I guess. actually what is the case is that these parameters have an annotation like @Parameter(property=maven.compiler.source,defaultValue=1.5) private String source; So what happens is that if you don't specify a value in the configuration section then Maven checks to see if the property is defined, if not then it uses the default value Once you specify a value in the configuration section that is taken as gold. So if I get this correctly what happens is: 1. Maven looks if you have a configuration section for maven-compiler-plugin in your POM 2. If not then it looks if the property maven.compiler.source is defined somewhere (via POM or -Dmaven.compiler.source or whatever) 3. If that fails, it will take the default property defined in the annotation on the source string in AbstractCompilerMojo.java of the maven-compiler-plugin that you mentioned. I'm getting there. This level of detail I can live with :-D the only pity with using properties is that they are not namespaced most of the time (the maven.compiler.* ones being an exception here), output is claimed at least by three mojos IIRC. I would think that it's a nice feature to be able to declare arbitrary property name/value pairs in the POM, as they can be used to avoid redundancy in the POMs, for filters etc. But then, they are inherently not namespaced. What's the problem with that? (May again be a total noob question :-) Btw, tried to have a look at the namespace declaration at http://maven.apache.org/POM/4.0.0- this URL is specified in basically any project xmlns=... of any POM I have seen thus far. Turns out that page does not exist. What's up with that? I would have liked conventions like always prefix with plugin name. Agreed, that would be really nice in order to avoid clashes as with for example the output property that you mentioned and which is claimed by at least three mojos or so. Cheers, Malte - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Changing JDK version without specifying maven-compiler-plugin version
Hi, I thought the version is defined in https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-core/src/main/resources/META-INF/plexus/default-bindings.xml;h=09ecba441e61d4a997b01af0171815c558548537;hb=maven-3.0.4 (replace hb with the version of your choice :-)). Hmm, I guess you're thinking of Maven 3.1 or something. In Maven 3.0.4 there does not seem to exist a maven-core/src/main/resources/META-INF/plexus/default-bindings.xml (the fact that your URL does work although the file does not exist in that particular revision is presumably some git peculiarity) See here: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree;f=maven-core/src/main/resources/META-INF/plexus;hb=maven-3.0.4 (or just click the plexus link to go up one level in the git path at the URL you posted) Yet the same things are apparently defined in artifact-handlers.xml for Maven 3.0.4 (so my guess in my previous mail was presumably correct). Anyway, the precise xml file where the default plugin version is defined does not matter that much. What's interesting to note though, is that more things are going on behind the scenes than just what one sees from the uber-pom. So it's not as simple as I had expected. The default plugin version is defined in one place (somewhere in maven-core, and that place is not the uber-pom). The default Java source and target versions are defined somewhere else entirely, in the implementation of the maven-compiler-plugin. Makes sense, I guess. actually what is the case is that these parameters have an annotation like @Parameter(property=maven.compiler.source,defaultValue=1.5) private String source; So what happens is that if you don't specify a value in the configuration section then Maven checks to see if the property is defined, if not then it uses the default value Once you specify a value in the configuration section that is taken as gold. So if I get this correctly what happens is: 1. Maven looks if you have a configuration section for maven-compiler-plugin in your POM 2. If not then it looks if the property maven.compiler.source is defined somewhere (via POM or -Dmaven.compiler.source or whatever) 3. If that fails, it will take the default property defined in the annotation on the source string in AbstractCompilerMojo.java of the maven-compiler-plugin that you mentioned. I'm getting there. This level of detail I can live with :-D the only pity with using properties is that they are not namespaced most of the time (the maven.compiler.* ones being an exception here), output is claimed at least by three mojos IIRC. I would think that it's a nice feature to be able to declare arbitrary property name/value pairs in the POM, as they can be used to avoid redundancy in the POMs, for filters etc. But then, they are inherently not namespaced. What's the problem with that? (May again be a total noob question :-) Btw, tried to have a look at the namespace declaration at http://maven.apache.org/POM/4.0.0- this URL is specified in basically any project xmlns=... of any POM I have seen thus far. Turns out that page does not exist. What's up with that? I would have liked conventions like always prefix with plugin name. Agreed, that would be really nice in order to avoid clashes as with for example the output property that you mentioned and which is claimed by at least three mojos or so. Cheers, Malte - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Changing JDK version without specifying maven-compiler-plugin version
Hi all,
thank you for your helpful answers. I grasped a lot about how Maven
internally works and learned some tricks (e.g., dependency:analyze).
This is a great mailing list indeed.
@Laird: that is quite interesting. From all the other posts I really
gained the impression that my original question was actually unsolvable
(e.g., Stephen explicitly stated the goals are incompatible).
But this also led me to a new question.
Always eager to learn, I tried - just to see what would happen -
specifying in my POM at the same time maven.compiler.{source,target}
in the properties section, *as well as* specifying {source,target}
in the configuration section of the maven-compiler-plugin. It turns
out that the latter takes precedence over the former (i.e., when
different Java versions are specified in these two places, the
configuration of the maven-compiler-plugin is used).
Therefore, from my understanding up to this point, I suspected that
there must be something in the uber-pom akin to this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
versionSOME_DEFAULT_VERSION/version
configuration
source${maven.compiler.source}/source
target${maven.compiler.target}/target
/configuration
/plugin
where the maven.compiler.{source,target} would be specified in the
properties section of the uber-pom. That would have explained both
why Maven complains when I reconfigure the maven-compiler-plugin without
specifying the plugin version, as well as why redefining
maven.compiler.{source,target} in the properties section of my own pom
is a working solution for my original question.
So I finally decided to take a look at this uber-pom :)
I was suprised to find there is *no mention* of the
maven-compiler-plugin *at all* in this super-pom, that is,
$ export M2_HOME=/usr/share/maven
$ unzip -p $M2_HOME/lib/maven-model-builder-3.0.4.jar
org/apache/maven/model/pom-4.0.0.xml | grep compiler
$
...the latter command produces no output (I'm using Maven 3.0.4, as can
be seen from the path).
(Alternatively, one might search for compiler at
http://maven.apache.org/ref/3.0.4/maven-model-builder/super-pom.html,
but I wanted to make sure that indeed the same uber-pom is used on my
machine).
This is quite confusing. I firmly expected to see some kind of
configuration of the maven-compiler-plugin in the uber-pom. That is what
many of you led me to believe:
Stephen:
the core plugins all have a version specified in the über-pom that is
embedded within Maven.
Randal:
As was pointed out, core components such as the compiler plugin have a stable
default version via the 'uber-pom' as of a particular version of Maven
Mark:
generated POMs *do* specify the version of
m-compiler-p, by *not* specifying it. There's a built-in set of
defaults(1) buried inside Maven, which specify much of the
not-otherwise-specified.
So... where is this stable maven-compiler-plugin version specified,
precisely?
I did find some mentions of a stable maven-compiler-plugin version in
$M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/components.xml as well
as
$M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/artifact-handlers.xml,
but I'm not sure whether that's the actual place where the default
version of the maven-compiler-plugin is configured, and certainly none
of them is the uber-pom.
I'd just like to see it; I like to understand how stuff works ;-)
Thanks,
Malte
On 11/26/2013 04:26 PM, Stephen Connolly wrote:
On 26 November 2013 14:59, Malte Skoruppa skoru...@cs.uni-saarland.dewrote:
Hi,
I'm new to Maven and I'm currently going through the Getting Started
guide.
While reading, the following question came to me.
As far as I understand, Maven defaults to compiling all Java source files
with compatibility for JDK 1.3 (i.e., -source 1.3).
Well actually with newer versions of the compiler plugin the default has
been upped to 1.5
The guide explains how to change that behaviour, by configuring the
maven-compiler-plugin in the pom.xml:
http://maven.apache.org/guides/getting-started/index.
html#How_do_I_use_plug-ins
So far so good. However, if I do this, it appears that I also have to
specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in the
code snippet shown under the above link).
Generally, I don't want to do that. On the one hand, I would like for
Maven to simply use the latest version of the maven-compiler-plugin that is
available (the default behaviour).
Not the default behaviour any more at least since 2.0.9 IIRC... the
core plugins all have a version specified in the über-pom that is
embedded within Maven. Thus if you do not specify a version, you get the
version specified in the über-pom... for non-core plugins you will get the
latest, but your build is now irreproducible. Best practice is to specify
the version for all plugins.
On the other hand, I would like to use Java features above 1.3 (for
Re: Changing JDK version without specifying maven-compiler-plugin version
On 27 November 2013 10:18, Malte Skoruppa skoru...@cs.uni-saarland.dewrote:
Hi all,
thank you for your helpful answers. I grasped a lot about how Maven
internally works and learned some tricks (e.g., dependency:analyze). This
is a great mailing list indeed.
@Laird: that is quite interesting. From all the other posts I really
gained the impression that my original question was actually unsolvable
(e.g., Stephen explicitly stated the goals are incompatible).
But this also led me to a new question.
Always eager to learn, I tried - just to see what would happen -
specifying in my POM at the same time maven.compiler.{source,target} in
the properties section, *as well as* specifying {source,target} in the
configuration section of the maven-compiler-plugin. It turns out that the
latter takes precedence over the former (i.e., when different Java versions
are specified in these two places, the configuration of the
maven-compiler-plugin is used).
Therefore, from my understanding up to this point, I suspected that there
must be something in the uber-pom akin to this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
versionSOME_DEFAULT_VERSION/version
configuration
source${maven.compiler.source}/source
target${maven.compiler.target}/target
/configuration
/plugin
actually what is the case is that these parameters have an annotation like
@Parameter(property=maven.compiler.source,defaultValue=1.5)
private String source;
So what happens is that if you don't specify a value in the configuration
section then Maven checks to see if the property is defined, if not then it
uses the default value
Once you specify a value in the configuration section that is taken as
gold.
Hence why I said it was incompatible, as the property trick is just that, a
trick, and it will fall over under stress... none the less it is a handy
trick to have... as long as you are aware that it is a trick.
where the maven.compiler.{source,target} would be specified in the
properties section of the uber-pom. That would have explained both why
Maven complains when I reconfigure the maven-compiler-plugin without
specifying the plugin version, as well as why redefining
maven.compiler.{source,target} in the properties section of my own pom is
a working solution for my original question.
So I finally decided to take a look at this uber-pom :)
I was suprised to find there is *no mention* of the maven-compiler-plugin
*at all* in this super-pom, that is,
$ export M2_HOME=/usr/share/maven
$ unzip -p $M2_HOME/lib/maven-model-builder-3.0.4.jar
org/apache/maven/model/pom-4.0.0.xml | grep compiler
$
...the latter command produces no output (I'm using Maven 3.0.4, as can be
seen from the path).
(Alternatively, one might search for compiler at
http://maven.apache.org/ref/3.0.4/maven-model-builder/super-pom.html, but
I wanted to make sure that indeed the same uber-pom is used on my machine).
This is quite confusing. I firmly expected to see some kind of
configuration of the maven-compiler-plugin in the uber-pom. That is what
many of you led me to believe:
Stephen:
the core plugins all have a version specified in the über-pom that is
embedded within Maven.
Hmmm.. it seems I missed http://jira.codehaus.org/browse/MNG-4453 with the
transition to Maven 3.x... and as I lock plugin versions down anyways...
Randal:
As was pointed out, core components such as the compiler plugin have a
stable default version via the 'uber-pom' as of a particular version of
Maven
Mark:
generated POMs *do* specify the version of
m-compiler-p, by *not* specifying it. There's a built-in set of
defaults(1) buried inside Maven, which specify much of the
not-otherwise-specified.
So... where is this stable maven-compiler-plugin version specified,
precisely?
I did find some mentions of a stable maven-compiler-plugin version in
$M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/components.xml as well
as $M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/artifact-handlers.xml,
but I'm not sure whether that's the actual place where the default
version of the maven-compiler-plugin is configured, and certainly none of
them is the uber-pom.
I'd just like to see it; I like to understand how stuff works ;-)
Thanks,
Malte
On 11/26/2013 04:26 PM, Stephen Connolly wrote:
On 26 November 2013 14:59, Malte Skoruppa skoru...@cs.uni-saarland.de
wrote:
Hi,
I'm new to Maven and I'm currently going through the Getting Started
guide.
While reading, the following question came to me.
As far as I understand, Maven defaults to compiling all Java source files
with compatibility for JDK 1.3 (i.e., -source 1.3).
Well actually with newer versions of the compiler plugin the default has
been upped to 1.5
The guide explains how to change that behaviour, by configuring the
maven-compiler-plugin in the pom.xml:
Re: Changing JDK version without specifying maven-compiler-plugin version
Hello,
I thought the version is defined in
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-core/src/main/resources/META-INF/plexus/default-bindings.xml;h=09ecba441e61d4a997b01af0171815c558548537;hb=maven-3.0.4
(replace hb with the version of your choice :-)).
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Wed, Nov 27, 2013 at 11:32 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 November 2013 10:18, Malte Skoruppa skoru...@cs.uni-saarland.dewrote:
Hi all,
thank you for your helpful answers. I grasped a lot about how Maven
internally works and learned some tricks (e.g., dependency:analyze). This
is a great mailing list indeed.
@Laird: that is quite interesting. From all the other posts I really
gained the impression that my original question was actually unsolvable
(e.g., Stephen explicitly stated the goals are incompatible).
But this also led me to a new question.
Always eager to learn, I tried - just to see what would happen -
specifying in my POM at the same time maven.compiler.{source,target} in
the properties section, *as well as* specifying {source,target} in the
configuration section of the maven-compiler-plugin. It turns out that the
latter takes precedence over the former (i.e., when different Java versions
are specified in these two places, the configuration of the
maven-compiler-plugin is used).
Therefore, from my understanding up to this point, I suspected that there
must be something in the uber-pom akin to this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
versionSOME_DEFAULT_VERSION/version
configuration
source${maven.compiler.source}/source
target${maven.compiler.target}/target
/configuration
/plugin
actually what is the case is that these parameters have an annotation like
@Parameter(property=maven.compiler.source,defaultValue=1.5)
private String source;
So what happens is that if you don't specify a value in the configuration
section then Maven checks to see if the property is defined, if not then it
uses the default value
Once you specify a value in the configuration section that is taken as
gold.
Hence why I said it was incompatible, as the property trick is just that, a
trick, and it will fall over under stress... none the less it is a handy
trick to have... as long as you are aware that it is a trick.
where the maven.compiler.{source,target} would be specified in the
properties section of the uber-pom. That would have explained both why
Maven complains when I reconfigure the maven-compiler-plugin without
specifying the plugin version, as well as why redefining
maven.compiler.{source,target} in the properties section of my own pom is
a working solution for my original question.
So I finally decided to take a look at this uber-pom :)
I was suprised to find there is *no mention* of the maven-compiler-plugin
*at all* in this super-pom, that is,
$ export M2_HOME=/usr/share/maven
$ unzip -p $M2_HOME/lib/maven-model-builder-3.0.4.jar
org/apache/maven/model/pom-4.0.0.xml | grep compiler
$
...the latter command produces no output (I'm using Maven 3.0.4, as can be
seen from the path).
(Alternatively, one might search for compiler at
http://maven.apache.org/ref/3.0.4/maven-model-builder/super-pom.html, but
I wanted to make sure that indeed the same uber-pom is used on my machine).
This is quite confusing. I firmly expected to see some kind of
configuration of the maven-compiler-plugin in the uber-pom. That is what
many of you led me to believe:
Stephen:
the core plugins all have a version specified in the über-pom that is
embedded within Maven.
Hmmm.. it seems I missed http://jira.codehaus.org/browse/MNG-4453 with the
transition to Maven 3.x... and as I lock plugin versions down anyways...
Randal:
As was pointed out, core components such as the compiler plugin have a
stable default version via the 'uber-pom' as of a particular version of
Maven
Mark:
generated POMs *do* specify the version of
m-compiler-p, by *not* specifying it. There's a built-in set of
defaults(1) buried inside Maven, which specify much of the
not-otherwise-specified.
So... where is this stable maven-compiler-plugin version specified,
precisely?
I did find some mentions of a stable maven-compiler-plugin version in
$M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/components.xml as well
as $M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/artifact-handlers.xml,
but I'm not sure whether that's the actual place where the default
version of the maven-compiler-plugin is configured, and certainly none of
them is the uber-pom.
I'd just like to see it; I like to understand how stuff works ;-)
Thanks,
Malte
On 11/26/2013 04:26 PM, Stephen Connolly wrote:
On 26 November
Re: Changing JDK version without specifying maven-compiler-plugin version
ahh yes they got moved there...
On 27 November 2013 20:52, Mirko Friedenhagen mfriedenha...@gmail.comwrote:
Hello,
I thought the version is defined in
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-core/src/main/resources/META-INF/plexus/default-bindings.xml;h=09ecba441e61d4a997b01af0171815c558548537;hb=maven-3.0.4
(replace hb with the version of your choice :-)).
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Wed, Nov 27, 2013 at 11:32 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 November 2013 10:18, Malte Skoruppa skoru...@cs.uni-saarland.de
wrote:
Hi all,
thank you for your helpful answers. I grasped a lot about how Maven
internally works and learned some tricks (e.g., dependency:analyze).
This
is a great mailing list indeed.
@Laird: that is quite interesting. From all the other posts I really
gained the impression that my original question was actually unsolvable
(e.g., Stephen explicitly stated the goals are incompatible).
But this also led me to a new question.
Always eager to learn, I tried - just to see what would happen -
specifying in my POM at the same time maven.compiler.{source,target}
in
the properties section, *as well as* specifying {source,target} in
the
configuration section of the maven-compiler-plugin. It turns out that
the
latter takes precedence over the former (i.e., when different Java
versions
are specified in these two places, the configuration of the
maven-compiler-plugin is used).
Therefore, from my understanding up to this point, I suspected that
there
must be something in the uber-pom akin to this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
versionSOME_DEFAULT_VERSION/version
configuration
source${maven.compiler.source}/source
target${maven.compiler.target}/target
/configuration
/plugin
actually what is the case is that these parameters have an annotation
like
@Parameter(property=maven.compiler.source,defaultValue=1.5)
private String source;
So what happens is that if you don't specify a value in the
configuration
section then Maven checks to see if the property is defined, if not then
it
uses the default value
Once you specify a value in the configuration section that is taken as
gold.
Hence why I said it was incompatible, as the property trick is just
that, a
trick, and it will fall over under stress... none the less it is a handy
trick to have... as long as you are aware that it is a trick.
where the maven.compiler.{source,target} would be specified in the
properties section of the uber-pom. That would have explained both
why
Maven complains when I reconfigure the maven-compiler-plugin without
specifying the plugin version, as well as why redefining
maven.compiler.{source,target} in the properties section of my own
pom is
a working solution for my original question.
So I finally decided to take a look at this uber-pom :)
I was suprised to find there is *no mention* of the
maven-compiler-plugin
*at all* in this super-pom, that is,
$ export M2_HOME=/usr/share/maven
$ unzip -p $M2_HOME/lib/maven-model-builder-3.0.4.jar
org/apache/maven/model/pom-4.0.0.xml | grep compiler
$
...the latter command produces no output (I'm using Maven 3.0.4, as can
be
seen from the path).
(Alternatively, one might search for compiler at
http://maven.apache.org/ref/3.0.4/maven-model-builder/super-pom.html,
but
I wanted to make sure that indeed the same uber-pom is used on my
machine).
This is quite confusing. I firmly expected to see some kind of
configuration of the maven-compiler-plugin in the uber-pom. That is what
many of you led me to believe:
Stephen:
the core plugins all have a version specified in the über-pom that is
embedded within Maven.
Hmmm.. it seems I missed http://jira.codehaus.org/browse/MNG-4453 with
the
transition to Maven 3.x... and as I lock plugin versions down anyways...
Randal:
As was pointed out, core components such as the compiler plugin have a
stable default version via the 'uber-pom' as of a particular version of
Maven
Mark:
generated POMs *do* specify the version of
m-compiler-p, by *not* specifying it. There's a built-in set of
defaults(1) buried inside Maven, which specify much of the
not-otherwise-specified.
So... where is this stable maven-compiler-plugin version specified,
precisely?
I did find some mentions of a stable maven-compiler-plugin version in
$M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/components.xml as well
as
$M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/artifact-handlers.xml,
but I'm not sure whether that's the actual place where the
RE: Re: Changing JDK version without specifying maven-compiler-plugin version
The best part of convention over configuration: when convention doesn't work
you get to go on these fun easter egg hunts for where the configuration belongs.
- Original Message - Subject: Re: Changing JDK version without
specifying maven-compiler-plugin version
From: Stephen Connolly stephen.alan.conno...@gmail.com
Date: 11/27/13 2:25 pm
To: Maven Users List users@maven.apache.org
ahh yes they got moved there...
On 27 November 2013 20:52, Mirko Friedenhagen mfriedenha...@gmail.comwrote:
Hello,
I thought the version is defined in
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-core/src/main/resources/META-INF/plexus/default-bindings.xml;h=09ecba441e61d4a997b01af0171815c558548537;hb=maven-3.0.4
(replace hb with the version of your choice :-)).
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Wed, Nov 27, 2013 at 11:32 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 27 November 2013 10:18, Malte Skoruppa skoru...@cs.uni-saarland.de
wrote:
Hi all,
thank you for your helpful answers. I grasped a lot about how Maven
internally works and learned some tricks (e.g., dependency:analyze).
This
is a great mailing list indeed.
@Laird: that is quite interesting. From all the other posts I really
gained the impression that my original question was actually unsolvable
(e.g., Stephen explicitly stated the goals are incompatible).
But this also led me to a new question.
Always eager to learn, I tried - just to see what would happen -
specifying in my POM at the same time maven.compiler.{source,target}
in
the properties section, *as well as* specifying {source,target} in
the
configuration section of the maven-compiler-plugin. It turns out that
the
latter takes precedence over the former (i.e., when different Java
versions
are specified in these two places, the configuration of the
maven-compiler-plugin is used).
Therefore, from my understanding up to this point, I suspected that
there
must be something in the uber-pom akin to this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
versionSOME_DEFAULT_VERSION/version
configuration
source${maven.compiler.source}/source
target${maven.compiler.target}/target
/configuration
/plugin
actually what is the case is that these parameters have an annotation
like
@Parameter(property=maven.compiler.source,defaultValue=1.5)
private String source;
So what happens is that if you don't specify a value in the
configuration
section then Maven checks to see if the property is defined, if not then
it
uses the default value
Once you specify a value in the configuration section that is taken as
gold.
Hence why I said it was incompatible, as the property trick is just
that, a
trick, and it will fall over under stress... none the less it is a handy
trick to have... as long as you are aware that it is a trick.
where the maven.compiler.{source,target} would be specified in the
properties section of the uber-pom. That would have explained both
why
Maven complains when I reconfigure the maven-compiler-plugin without
specifying the plugin version, as well as why redefining
maven.compiler.{source,target} in the properties section of my own
pom is
a working solution for my original question.
So I finally decided to take a look at this uber-pom :)
I was suprised to find there is *no mention* of the
maven-compiler-plugin
*at all* in this super-pom, that is,
$ export M2_HOME=/usr/share/maven
$ unzip -p $M2_HOME/lib/maven-model-builder-3.0.4.jar
org/apache/maven/model/pom-4.0.0.xml | grep compiler
$
...the latter command produces no output (I'm using Maven 3.0.4, as can
be
seen from the path).
(Alternatively, one might search for compiler at
http://maven.apache.org/ref/3.0.4/maven-model-builder/super-pom.html,
but
I wanted to make sure that indeed the same uber-pom is used on my
machine).
This is quite confusing. I firmly expected to see some kind of
configuration of the maven-compiler-plugin in the uber-pom. That is what
many of you led me to believe:
Stephen:
the core plugins all have a version specified in the uuml;ber-pom that
is
embedded within Maven.
Hmmm.. it seems I missed http://jira.codehaus.org/browse/MNG-4453 with
the
transition to Maven 3.x... and as I lock plugin versions down anyways...
Randal:
As was pointed out, core components such as the compiler plugin have a
stable default version via the 'uber-pom' as of a particular version of
Maven
Mark:
generated POMs *do* specify the version of
m-compiler-p
Re: Property namespaces Was: Changing JDK version without specifying maven-compiler-plugin version
On Wed, Nov 27, 2013 at 6:49 AM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: the only pity with using properties is that they are not namespaced most of the time (the maven.compiler.* ones being an exception here), output is claimed at least by three mojos IIRC. And skipTests is almost a general one but you may not easily specify that you do not want to run surefire but e.g. invoker tests nonetheless :-) Oh, agreed. This is just a convenient way to have the OP's problem solved in one shot with two lines of XML. Best, Laird -- http://about.me/lairdnelson
Changing JDK version without specifying maven-compiler-plugin version
Hi,
I'm new to Maven and I'm currently going through the Getting Started
guide.
While reading, the following question came to me.
As far as I understand, Maven defaults to compiling all Java source
files with compatibility for JDK 1.3 (i.e., -source 1.3).
The guide explains how to change that behaviour, by configuring the
maven-compiler-plugin in the pom.xml:
http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plug-ins
So far so good. However, if I do this, it appears that I also have to
specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in
the code snippet shown under the above link).
Generally, I don't want to do that. On the one hand, I would like for
Maven to simply use the latest version of the maven-compiler-plugin that
is available (the default behaviour). On the other hand, I would like to
use Java features above 1.3 (for instance, generics).
So my first attempt was to simply remove the version2.5.1/version
part from the pom.xml under the maven-compiler-plugin configuration.
While this did in principle work, Maven was not happy at all and
complained with this message:
[WARNING] Some problems were encountered while building the effective
model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 19,
column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
So my question boils down to this: is there some way for me to achieve
the following three things at the same time:
(1) have Maven compile my source files with -source 1.4 (or anything
higher than 1.3)
(2) *not* specify the maven-compiler-plugin version to use; instead,
have Maven dynamically use the latest one available;
(3) *not* have Maven bitch about my project being malformed ;-)
I would imagine that this is not such a rare scenario:
(1) I do want to use Java features higher than those available in Java 1.3;
(2) I do *not* want having to monitor the maven-compiler-plugin by
myself all the time in order to check for updates and keep my pom.xml
referring to the currently latest version;
(3) yet I do *not* want Maven complaining about my project.xml being
malformed either.
So what's the clean way to do this? :-)
For clarity, I have written down the steps to reproduce my problem in
the Appendix, below.
Thanks,
Malte
APPENDIX: Steps to reproduce:
1. Generate a simple Maven project using the very command stated on
http://maven.apache.org/guides/getting-started/index.html#How_do_I_make_my_first_Maven_project
:
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
-DgroupId=com.mycompany.app \
-DartifactId=my-app
2. Replace the generated src/main/java/com/mycompany/app/App.java with
something that uses generics (not available in Java 1.3), e.g.:
package com.mycompany.app;
import java.util.*;
/**
* Hello world!
*
*/
public class App {
public static void main( String[] args) {
ListString myList = new ArrayListString();
myList.add( Hello);
myList.add( world);
for( IteratorString i = myList.iterator(); i.hasNext();)
System.out.println( i.next());
}
}
3. Try to compile using the command 'mvn compile'. Maven fails:
$ mvn compile
[INFO] Scanning for projects...
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.995s
[INFO] Finished at: Tue Nov 26 15:26:00 CET 2013
[INFO] Final Memory: 6M/117M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile
(default-compile) on project my-app: Compilation failure
[ERROR]
/home/malte/dev/java/testMaven/my-app/src/main/java/com/mycompany/app/App.java:[13,5]
error: generics are not supported in -source 1.3
...
4. Ok, so let's add the following to our pom.xml. This is copiedpasted
from
http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plug-ins
:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.5.1/version
configuration
source1.5/source
target1.5/target
/configuration
/plugin
/plugins
/build
Running 'mvn compile' again, everything works fine now.
5. Yet, I would like to avoid having to specify the version of
maven-compiler-plugin to be used. I simply want Maven to use the latest
one available. So, let's remove the line
version2.5.1/version
from the pom.xml again.
Running 'mvn compile' again, this works too, but Maven
Re: Changing JDK version without specifying maven-compiler-plugin version
On 26 November 2013 14:59, Malte Skoruppa skoru...@cs.uni-saarland.dewrote:
Hi,
I'm new to Maven and I'm currently going through the Getting Started
guide.
While reading, the following question came to me.
As far as I understand, Maven defaults to compiling all Java source files
with compatibility for JDK 1.3 (i.e., -source 1.3).
Well actually with newer versions of the compiler plugin the default has
been upped to 1.5
The guide explains how to change that behaviour, by configuring the
maven-compiler-plugin in the pom.xml:
http://maven.apache.org/guides/getting-started/index.
html#How_do_I_use_plug-ins
So far so good. However, if I do this, it appears that I also have to
specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in the
code snippet shown under the above link).
Generally, I don't want to do that. On the one hand, I would like for
Maven to simply use the latest version of the maven-compiler-plugin that is
available (the default behaviour).
Not the default behaviour any more at least since 2.0.9 IIRC... the
core plugins all have a version specified in the über-pom that is
embedded within Maven. Thus if you do not specify a version, you get the
version specified in the über-pom... for non-core plugins you will get the
latest, but your build is now irreproducible. Best practice is to specify
the version for all plugins.
On the other hand, I would like to use Java features above 1.3 (for
instance, generics).
So my first attempt was to simply remove the version2.5.1/version
part from the pom.xml under the maven-compiler-plugin configuration. While
this did in principle work, Maven was not happy at all and complained with
this message:
[WARNING] Some problems were encountered while building the effective
model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-compiler-plugin
is missing. @ line 19, column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
So my question boils down to this: is there some way for me to achieve the
following three things at the same time:
(1) have Maven compile my source files with -source 1.4 (or anything
higher than 1.3)
(2) *not* specify the maven-compiler-plugin version to use; instead, have
Maven dynamically use the latest one available;
(3) *not* have Maven bitch about my project being malformed ;-)
I would imagine that this is not such a rare scenario:
(1) I do want to use Java features higher than those available in Java 1.3;
Then set source and target to 1.3... and hope you never upgrade to Java 8
(2) I do *not* want having to monitor the maven-compiler-plugin by myself
all the time in order to check for updates and keep my pom.xml referring to
the currently latest version;
Incompatible goal. If you have a version of the compiler plugin that is
working. Leave it as is. If it isn't broken, don't fix it. If you decide
that it is broken (e.g. you think the version you have is not compiling
fast enough) then try upgrading... this way you have control over your build
(3) yet I do *not* want Maven complaining about my project.xml being
malformed either.
Specify the version, or live with Maven complaining.
The Maven way is to make doing the right thing easy... doing the not so
right thing should encounter some friction... but unless we have good
reason we should not prevent you from shooting your foot off... we can make
it difficult to aim the gun at your foot though!
So what's the clean way to do this? :-)
For clarity, I have written down the steps to reproduce my problem in the
Appendix, below.
Thanks,
Malte
APPENDIX: Steps to reproduce:
1. Generate a simple Maven project using the very command stated on
http://maven.apache.org/guides/getting-started/index.
html#How_do_I_make_my_first_Maven_project :
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
-DgroupId=com.mycompany.app \
-DartifactId=my-app
2. Replace the generated src/main/java/com/mycompany/app/App.java with
something that uses generics (not available in Java 1.3), e.g.:
package com.mycompany.app;
import java.util.*;
/**
* Hello world!
*
*/
public class App {
public static void main( String[] args) {
ListString myList = new ArrayListString();
myList.add( Hello);
myList.add( world);
for( IteratorString i = myList.iterator(); i.hasNext();)
System.out.println( i.next());
}
}
3. Try to compile using the command 'mvn compile'. Maven fails:
$ mvn compile
[INFO] Scanning for projects...
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
RE: Changing JDK version without specifying maven-compiler-plugin version
Specifying a plugin version number is generally a good idea as the
'latest-and-greatest' may break your build at an unexpected time (usually the
day before you need to deliver a product) or worse build differently such that
the product breaks. While due diligence is done to ensure that only compatible
changes are done to plugins, there are no guarantees that your particular setup
is not impacted. Add to that that a particular plugin version may be linked to
a particular version of Maven, so latest-and-greatest becomes a set of versions
depending on what version of Maven you are using. Perhaps the compiler plugin
is a bad example as it's relatively straight forward and probably somewhat
immune from breaking changes, but this is a behavior that works for all plugins.
I would question your need to use the 'latest-and-greatest' of a plugin. If a
plugin works and produces a working artifact, changing it to a newer version
should be a conscious decision and not a surprise, anymore than changing
versions of Maven should be done automatically. You can mitigate the amount of
work needed to change a plugin version by using a parent pom that sets the
version, and then all child poms will work with that version.
Remember, Infants are the only people that appreciate a change ;)
FWIW,
Randal Kamradt
- Original Message - Subject: Changing JDK version without
specifying maven-compiler-plugin version
From: Malte Skoruppa skoru...@cs.uni-saarland.de
Date: 11/26/13 7:59 am
To: users@maven.apache.org
Hi,
I'm new to Maven and I'm currently going through the Getting Started
guide.
While reading, the following question came to me.
As far as I understand, Maven defaults to compiling all Java source
files with compatibility for JDK 1.3 (i.e., -source 1.3).
The guide explains how to change that behaviour, by configuring the
maven-compiler-plugin in the pom.xml:
http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plug-ins
So far so good. However, if I do this, it appears that I also have to
specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in
the code snippet shown under the above link).
Generally, I don't want to do that. On the one hand, I would like for
Maven to simply use the latest version of the maven-compiler-plugin that
is available (the default behaviour). On the other hand, I would like to
use Java features above 1.3 (for instance, generics).
So my first attempt was to simply remove the version2.5.1/version
part from the pom.xml under the maven-compiler-plugin configuration.
While this did in principle work, Maven was not happy at all and
complained with this message:
[WARNING] Some problems were encountered while building the effective
model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 19,
column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
So my question boils down to this: is there some way for me to achieve
the following three things at the same time:
(1) have Maven compile my source files with -source 1.4 (or anything
higher than 1.3)
(2) *not* specify the maven-compiler-plugin version to use; instead,
have Maven dynamically use the latest one available;
(3) *not* have Maven bitch about my project being malformed ;-)
I would imagine that this is not such a rare scenario:
(1) I do want to use Java features higher than those available in Java 1.3;
(2) I do *not* want having to monitor the maven-compiler-plugin by
myself all the time in order to check for updates and keep my pom.xml
referring to the currently latest version;
(3) yet I do *not* want Maven complaining about my project.xml being
malformed either.
So what's the clean way to do this? :-)
For clarity, I have written down the steps to reproduce my problem in
the Appendix, below.
Thanks,
Malte
APPENDIX: Steps to reproduce:
1. Generate a simple Maven project using the very command stated on
http://maven.apache.org/guides/getting-started/index.html#How_do_I_make_my_first_Maven_project
:
mvn archetype:generate \
-DarchetypeGroupId=org.apache.maven.archetypes \
-DgroupId=com.mycompany.app \
-DartifactId=my-app
2. Replace the generated src/main/java/com/mycompany/app/App.java with
something that uses generics (not available in Java 1.3), e.g.:
package com.mycompany.app;
import java.util.*;
/**
* Hello world!
*
*/
public class App {
public static void main( String[] args) {
ListString myList = new ArrayListString();
myList.add( Hello);
myList.add( world);
for( IteratorString i = myList.iterator(); i.hasNext();)
System.out.println( i.next
Re: Changing JDK version without specifying maven-compiler-plugin version
Hi, thanks for your quick answer. Generally, I don't want to do that. On the one hand, I would like for Maven to simply use the latest version of the maven-compiler-plugin that is available (the default behaviour). Not the default behaviour any more at least since 2.0.9 IIRC... the core plugins all have a version specified in the über-pom that is embedded within Maven. Thus if you do not specify a version, you get the version specified in the über-pom... for non-core plugins you will get the latest, but your build is now irreproducible. Best practice is to specify the version for all plugins. Yes, I can see how specifying a version of the maven-compiler-plugin to use would be a good thing to do in order to make the build reproducible. It's a never change a winning team sort of paradigm, and one I'm not opposed to at all. Yet, please do note that the generated pom.xml from the archetype maven-archetype-quickstart does *not* specify a maven-compiler-plugin version to use. So does this imply that the maven-archetype-quickstart archetype actually does not conform to the best practice to do things? So, maybe I wasn't entirely clear. What really kind of surprises me is not that I have to specify a maven-compiler-plugin version per se. What suprises me is more this if you configure this, you also have to configure that thing. If I only want to change the default configuration w.r.t. the Java version I would like to use, why do I also have to change the default configuration w.r.t. the maven-compiler-plugin version I want to use? I would imagine that this is not such a rare scenario: (1) I do want to use Java features higher than those available in Java 1.3; Then set source and target to 1.3... and hope you never upgrade to Java 8 Uh, sorry, but... did you read my question? I want to use Java features HIGHER than 1.3. So why would I set source to 1.3? That is the opposite of what I want. And what does this have to do with Java 8? (2) I do *not* want having to monitor the maven-compiler-plugin by myself all the time in order to check for updates and keep my pom.xml referring to the currently latest version; Incompatible goal. If you have a version of the compiler plugin that is working. Leave it as is. If it isn't broken, don't fix it. If you decide that it is broken (e.g. you think the version you have is not compiling fast enough) then try upgrading... this way you have control over your build My question is precisely *why* this goal is incompatible. You see, I am allowed to not specify the maven-compiler-plugin version when I'm happy with the default Java version. But as soon as I decide that I want to use another Java version, I have to commit on a maven-compiler-plugin version. That is suprising, is it not? :) (3) yet I do *not* want Maven complaining about my project.xml being malformed either. Specify the version, or live with Maven complaining. The Maven way is to make doing the right thing easy... doing the not so right thing should encounter some friction... but unless we have good reason we should not prevent you from shooting your foot off... we can make it difficult to aim the gun at your foot though! So what you're saying is that the maven-archetype-quickstart archetype does a not so right thing since it does not specify a maven-compiler-plugin version in its POM? Thanks, Malte - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Changing JDK version without specifying maven-compiler-plugin version
Hey Randy, Ok... you convinced me about that: specifying a plugin version number is generally a good idea. :) I am not so intent on having the 'latest-and-greatest' plugin as you might think. It's more that I would like to stick to the default configuration unless I have good reason not to do so. It's really just that I find it kind of weird that if I want to deviate from one default (the Java version), I also *have* to deviate from another (the plugin version). But I guess I can live with it. One might also argue that those two defaults (Java version and plugin version) are somehow linked, so if I want to change one I should specify the other. E.g., not all plugin versions might support Java 1.7. Thank you for your competent answer! Malte On 11/26/2013 04:36 PM, rand...@kamradtfamily.net wrote: Specifying a plugin version number is generally a good idea as the 'latest-and-greatest' may break your build at an unexpected time (usually the day before you need to deliver a product) or worse build differently such that the product breaks. While due diligence is done to ensure that only compatible changes are done to plugins, there are no guarantees that your particular setup is not impacted. Add to that that a particular plugin version may be linked to a particular version of Maven, so latest-and-greatest becomes a set of versions depending on what version of Maven you are using. Perhaps the compiler plugin is a bad example as it's relatively straight forward and probably somewhat immune from breaking changes, but this is a behavior that works for all plugins. I would question your need to use the 'latest-and-greatest' of a plugin. If a plugin works and produces a working artifact, changing it to a newer version should be a conscious decision and not a surprise, anymore than changing versions of Maven should be done automatically. You can mitigate the amount of work needed to change a plugin version by using a parent pom that sets the version, and then all child poms will work with that version. Remember, Infants are the only people that appreciate a change ;) FWIW, Randal Kamradt - Original Message - Subject: Changing JDK version without specifying maven-compiler-plugin version From: Malte Skoruppa skoru...@cs.uni-saarland.de Date: 11/26/13 7:59 am To: users@maven.apache.org Hi, I'm new to Maven and I'm currently going through the Getting Started guide. While reading, the following question came to me. As far as I understand, Maven defaults to compiling all Java source files with compatibility for JDK 1.3 (i.e., -source 1.3). The guide explains how to change that behaviour, by configuring the maven-compiler-plugin in the pom.xml: http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plug-ins So far so good. However, if I do this, it appears that I also have to specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in the code snippet shown under the above link). Generally, I don't want to do that. On the one hand, I would like for Maven to simply use the latest version of the maven-compiler-plugin that is available (the default behaviour). On the other hand, I would like to use Java features above 1.3 (for instance, generics). So my first attempt was to simply remove the version2.5.1/version part from the pom.xml under the maven-compiler-plugin configuration. While this did in principle work, Maven was not happy at all and complained with this message: [WARNING] Some problems were encountered while building the effective model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 19, column 15 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. So my question boils down to this: is there some way for me to achieve the following three things at the same time: (1) have Maven compile my source files with -source 1.4 (or anything higher than 1.3) (2) *not* specify the maven-compiler-plugin version to use; instead, have Maven dynamically use the latest one available; (3) *not* have Maven bitch about my project being malformed ;-) I would imagine that this is not such a rare scenario: (1) I do want to use Java features higher than those available in Java 1.3; (2) I do *not* want having to monitor the maven-compiler-plugin by myself all the time in order to check for updates and keep my pom.xml referring to the currently latest version; (3) yet I do *not* want Maven complaining about my project.xml being malformed either. So what's the clean way to do this? :-) For clarity, I have written down the steps
Re: Changing JDK version without specifying maven-compiler-plugin version
On 26 November 2013 15:59, Malte Skoruppa skoru...@cs.uni-saarland.dewrote: Hi, thanks for your quick answer. Generally, I don't want to do that. On the one hand, I would like for Maven to simply use the latest version of the maven-compiler-plugin that is available (the default behaviour). Not the default behaviour any more at least since 2.0.9 IIRC... the core plugins all have a version specified in the über-pom that is embedded within Maven. Thus if you do not specify a version, you get the version specified in the über-pom... for non-core plugins you will get the latest, but your build is now irreproducible. Best practice is to specify the version for all plugins. Yes, I can see how specifying a version of the maven-compiler-plugin to use would be a good thing to do in order to make the build reproducible. It's a never change a winning team sort of paradigm, and one I'm not opposed to at all. Yet, please do note that the generated pom.xml from the archetype maven-archetype-quickstart does *not* specify a maven-compiler-plugin version to use. So does this imply that the maven-archetype-quickstart archetype actually does not conform to the best practice to do things? So, maybe I wasn't entirely clear. What really kind of surprises me is not that I have to specify a maven-compiler-plugin version per se. What suprises me is more this if you configure this, you also have to configure that thing. If I only want to change the default configuration w.r.t. the Java version I would like to use, why do I also have to change the default configuration w.r.t. the maven-compiler-plugin version I want to use? I would imagine that this is not such a rare scenario: (1) I do want to use Java features higher than those available in Java 1.3; Then set source and target to 1.3... and hope you never upgrade to Java 8 Uh, sorry, but... did you read my question? I want to use Java features HIGHER than 1.3. So why would I set source to 1.3? That is the opposite of what I want. And what does this have to do with Java 8? I read that as you wanting to only use features of Java 1.3 (madness I say) which will break once you have Java 8 as its javac will only support down to -source 1.6 IIRC (but it may be 1.5) I think it is current and two back that is the new policy that is being introduced from Java 8 onwards... (2) I do *not* want having to monitor the maven-compiler-plugin by myself all the time in order to check for updates and keep my pom.xml referring to the currently latest version; Incompatible goal. If you have a version of the compiler plugin that is working. Leave it as is. If it isn't broken, don't fix it. If you decide that it is broken (e.g. you think the version you have is not compiling fast enough) then try upgrading... this way you have control over your build My question is precisely *why* this goal is incompatible. You see, I am allowed to not specify the maven-compiler-plugin version when I'm happy with the default Java version. But as soon as I decide that I want to use another Java version, I have to commit on a maven-compiler-plugin version. That is suprising, is it not? :) (3) yet I do *not* want Maven complaining about my project.xml being malformed either. Specify the version, or live with Maven complaining. The Maven way is to make doing the right thing easy... doing the not so right thing should encounter some friction... but unless we have good reason we should not prevent you from shooting your foot off... we can make it difficult to aim the gun at your foot though! So what you're saying is that the maven-archetype-quickstart archetype does a not so right thing since it does not specify a maven-compiler-plugin version in its POM? Thanks, Malte - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Changing JDK version without specifying maven-compiler-plugin version
Hi, I read that as you wanting to only use features of Java 1.3 (madness I say) which will break once you have Java 8 as its javac will only support down to -source 1.6 IIRC (but it may be 1.5) I think it is current and two back that is the new policy that is being introduced from Java 8 onwards... Ah, interesting. I didn't know that about the downwards compatibility of Java. Thanks for the clarification. And I would agree that it would be madness to only use features of Java 1.3. :-D Which is the very reason I took a closer look at how to configure a higher Java compiler version in the first place ;-) Best, Malte (2) I do *not* want having to monitor the maven-compiler-plugin by myself all the time in order to check for updates and keep my pom.xml referring to the currently latest version; Incompatible goal. If you have a version of the compiler plugin that is working. Leave it as is. If it isn't broken, don't fix it. If you decide that it is broken (e.g. you think the version you have is not compiling fast enough) then try upgrading... this way you have control over your build My question is precisely *why* this goal is incompatible. You see, I am allowed to not specify the maven-compiler-plugin version when I'm happy with the default Java version. But as soon as I decide that I want to use another Java version, I have to commit on a maven-compiler-plugin version. That is suprising, is it not? :) (3) yet I do *not* want Maven complaining about my project.xml being malformed either. Specify the version, or live with Maven complaining. The Maven way is to make doing the right thing easy... doing the not so right thing should encounter some friction... but unless we have good reason we should not prevent you from shooting your foot off... we can make it difficult to aim the gun at your foot though! So what you're saying is that the maven-archetype-quickstart archetype does a not so right thing since it does not specify a maven-compiler-plugin version in its POM? Thanks, Malte - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Re: Changing JDK version without specifying maven-compiler-plugin version
Think of it not as 'if I configure one thing, I must configure another thing', but more as 'if I configure one thing, I must provide complete information about the thing I configure'. Complete information being information that does not has a stable default. As was pointed out, core components such as the compiler plugin have a stable default version via the 'uber-pom' as of a particular version of Maven, since core components are used whether you specify them in your pom or not because they are tied to a particular life-cycle phase by default. In today's highly componentized world, keeping track of versions, be they for plugins or code libraries, becomes one of the most complex problems developers face. IDEs like NetBeans can help via a pom editor by 'suggesting' versions. But ultimately, it is up to us as developers to favor precision over simplicity when the two come into conflict (unless your boss dictates that you keep it simple because 'we need to deliver tomorrow') - Original Message - Subject: Re: Changing JDK version without specifying maven-compiler-plugin version From: Malte Skoruppa skoru...@cs.uni-saarland.de Date: 11/26/13 9:05 am To: Maven Users List users@maven.apache.org Hey Randy, Ok... you convinced me about that: specifying a plugin version number is generally a good idea. :) I am not so intent on having the 'latest-and-greatest' plugin as you might think. It's more that I would like to stick to the default configuration unless I have good reason not to do so. It's really just that I find it kind of weird that if I want to deviate from one default (the Java version), I also *have* to deviate from another (the plugin version). But I guess I can live with it. One might also argue that those two defaults (Java version and plugin version) are somehow linked, so if I want to change one I should specify the other. E.g., not all plugin versions might support Java 1.7. Thank you for your competent answer! Malte On 11/26/2013 04:36 PM, rand...@kamradtfamily.net wrote: Specifying a plugin version number is generally a good idea as the 'latest-and-greatest' may break your build at an unexpected time (usually the day before you need to deliver a product) or worse build differently such that the product breaks. While due diligence is done to ensure that only compatible changes are done to plugins, there are no guarantees that your particular setup is not impacted. Add to that that a particular plugin version may be linked to a particular version of Maven, so latest-and-greatest becomes a set of versions depending on what version of Maven you are using. Perhaps the compiler plugin is a bad example as it's relatively straight forward and probably somewhat immune from breaking changes, but this is a behavior that works for all plugins. I would question your need to use the 'latest-and-greatest' of a plugin. If a plugin works and produces a working artifact, changing it to a newer version should be a conscious decision and not a surprise, anymore than changing versions of Maven should be done automatically. You can mitigate the amount of work needed to change a plugin version by using a parent pom that sets the version, and then all child poms will work with that version. Remember, Infants are the only people that appreciate a change ;) FWIW, Randal Kamradt - Original Message - Subject: Changing JDK version without specifying maven-compiler-plugin version From: Malte Skoruppa skoru...@cs.uni-saarland.de Date: 11/26/13 7:59 am To: users@maven.apache.org Hi, I'm new to Maven and I'm currently going through the Getting Started guide. While reading, the following question came to me. As far as I understand, Maven defaults to compiling all Java source files with compatibility for JDK 1.3 (i.e., -source 1.3). The guide explains how to change that behaviour, by configuring the maven-compiler-plugin in the pom.xml: http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plug-ins So far so good. However, if I do this, it appears that I also have to specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in the code snippet shown under the above link). Generally, I don't want to do that. On the one hand, I would like for Maven to simply use the latest version of the maven-compiler-plugin that is available (the default behaviour). On the other hand, I would like to use Java features above 1.3 (for instance, generics). So my first attempt was to simply remove the version2.5.1/version part from the pom.xml under the maven-compiler-plugin configuration. While this did in principle work, Maven was not happy at all and complained with this message: [WARNING] Some problems were encountered while building the effective model for com.mycompany.app:my
Re: Changing JDK version without specifying maven-compiler-plugin version
On Tue, Nov 26, 2013 at 05:05:40PM +0100, Malte Skoruppa wrote: [snip] I am not so intent on having the 'latest-and-greatest' plugin as you might think. It's more that I would like to stick to the default configuration unless I have good reason not to do so. It's really just that I find it kind of weird that if I want to deviate from one default (the Java version), I also *have* to deviate from another (the plugin version). Think of it this way: org.apache.maven.plugins:maven-compiler-plugin does not refer to a single plugin, but to the whole family of versions of that plugin. It's an incomplete set of coordinates, specifying a line rather than a point. The weirdness is inevitable, because in order to configure the plugin you have to specify which plugin you are configuring. It's a minor pain in the neck, flowing from the way Maven needs to work. I dislike it too, but one gets used to it. Maven deals in artifacts, not lines of development. I'm coming around to the position that grooming POMs to update the versions of all specified dependencies (packages *and* plugins) is just one of the things one does right after release, when beginning the next development cycle. dependency:analyze is a good source of suggestions. That way you regularly catch up with recent developments elsewhere, and can still pin down versions within a development cycle. Within each cycle I'd tend to hold versions stable unless someone releases an update that I really need. BTW, speaking of weirdness: generated POMs *do* specify the version of m-compiler-p, by *not* specifying it. There's a built-in set of defaults(1) buried inside Maven, which specify much of the not-otherwise-specified. Someone already mentioned this, but it may have sped by unnoticed. --- 1. All together, now: convention over configuration! -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
Re: Changing JDK version without specifying maven-compiler-plugin version
Regardless of the plug-in version, you want to specify the Java version that you want. The defaults have traditionally been very far behind the current version of Java. There are bugs or deficiencies in the older versions of the plug-in which is why new versions were created. It is a good idea to specify the versions of the plug-ins and java in the parent pom so that everyone is building all of their modules for your application with the same Java version. The plug-in version is unlikely to silently screw up your build but if it will not build your project, each person will have to find out what the problem is and fix it. You are better off to deal with it once in the parent pom and let the rest of the team just worry about the code that they write. Ron On 26/11/2013 11:05 AM, Malte Skoruppa wrote: Hey Randy, Ok... you convinced me about that: specifying a plugin version number is generally a good idea. :) I am not so intent on having the 'latest-and-greatest' plugin as you might think. It's more that I would like to stick to the default configuration unless I have good reason not to do so. It's really just that I find it kind of weird that if I want to deviate from one default (the Java version), I also *have* to deviate from another (the plugin version). But I guess I can live with it. One might also argue that those two defaults (Java version and plugin version) are somehow linked, so if I want to change one I should specify the other. E.g., not all plugin versions might support Java 1.7. Thank you for your competent answer! Malte On 11/26/2013 04:36 PM, rand...@kamradtfamily.net wrote: Specifying a plugin version number is generally a good idea as the 'latest-and-greatest' may break your build at an unexpected time (usually the day before you need to deliver a product) or worse build differently such that the product breaks. While due diligence is done to ensure that only compatible changes are done to plugins, there are no guarantees that your particular setup is not impacted. Add to that that a particular plugin version may be linked to a particular version of Maven, so latest-and-greatest becomes a set of versions depending on what version of Maven you are using. Perhaps the compiler plugin is a bad example as it's relatively straight forward and probably somewhat immune from breaking changes, but this is a behavior that works for all plugins. I would question your need to use the 'latest-and-greatest' of a plugin. If a plugin works and produces a working artifact, changing it to a newer version should be a conscious decision and not a surprise, anymore than changing versions of Maven should be done automatically. You can mitigate the amount of work needed to change a plugin version by using a parent pom that sets the version, and then all child poms will work with that version. Remember, Infants are the only people that appreciate a change ;) FWIW, Randal Kamradt - Original Message - Subject: Changing JDK version without specifying maven-compiler-plugin version From: Malte Skoruppa skoru...@cs.uni-saarland.de Date: 11/26/13 7:59 am To: users@maven.apache.org Hi, I'm new to Maven and I'm currently going through the Getting Started guide. While reading, the following question came to me. As far as I understand, Maven defaults to compiling all Java source files with compatibility for JDK 1.3 (i.e., -source 1.3). The guide explains how to change that behaviour, by configuring the maven-compiler-plugin in the pom.xml: http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plug-ins So far so good. However, if I do this, it appears that I also have to specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in the code snippet shown under the above link). Generally, I don't want to do that. On the one hand, I would like for Maven to simply use the latest version of the maven-compiler-plugin that is available (the default behaviour). On the other hand, I would like to use Java features above 1.3 (for instance, generics). So my first attempt was to simply remove the version2.5.1/version part from the pom.xml under the maven-compiler-plugin configuration. While this did in principle work, Maven was not happy at all and complained with this message: [WARNING] Some problems were encountered while building the effective model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 19, column 15 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. So my question boils down to this: is there some way for me to achieve
Re: Changing JDK version without specifying maven-compiler-plugin version
On Tuesday, November 26, 2013, Malte Skoruppa wrote: is there some way for me to achieve the following three things at the same time: (1) have Maven compile my source files with -source 1.4 (or anything higher than 1.3) (2) *not* specify the maven-compiler-plugin version to use; instead, have Maven dynamically use the latest one available; (3) *not* have Maven bitch about my project being malformed ;-) Yes. In your pom.xml's properties section add this: maven.compiler.source1.6/maven.compiler.source maven.compiler.target1.6/maven.compiler.target No other configuration or verbiage needed. All of the other posters' words are good. But no one answered your question. Best, Laird -- http://about.me/lairdnelson
Property namespaces Was: Changing JDK version without specifying maven-compiler-plugin version
Hello Laird, the only pity with using properties is that they are not namespaced most of the time (the maven.compiler.* ones being an exception here), output is claimed at least by three mojos IIRC. And skipTests is almost a general one but you may not easily specify that you do not want to run surefire but e.g. invoker tests nonetheless :-) I would have liked conventions like always prefix with plugin name. Regards Mirko -- Sent from my mobile On Nov 27, 2013 1:48 AM, Laird Nelson ljnel...@gmail.com wrote: On Tuesday, November 26, 2013, Malte Skoruppa wrote: is there some way for me to achieve the following three things at the same time: (1) have Maven compile my source files with -source 1.4 (or anything higher than 1.3) (2) *not* specify the maven-compiler-plugin version to use; instead, have Maven dynamically use the latest one available; (3) *not* have Maven bitch about my project being malformed ;-) Yes. In your pom.xml's properties section add this: maven.compiler.source1.6/maven.compiler.source maven.compiler.target1.6/maven.compiler.target No other configuration or verbiage needed. All of the other posters' words are good. But no one answered your question. Best, Laird -- http://about.me/lairdnelson
