You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mirko Friedenhagen <mf...@gmail.com> on 2013/11/27 07:49:43 UTC
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" <lj...@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.source>1.6</maven.compiler.source>
> <maven.compiler.target>1.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
>
Re: Changing JDK version without specifying maven-compiler-plugin version
Posted by Curtis Rueden <ct...@wisc.edu>.
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 <skoruppa@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Changing JDK version without specifying maven-compiler-plugin
version
Posted by Malte Skoruppa <sk...@cs.uni-saarland.de>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Property namespaces Was: Changing JDK version without specifying
maven-compiler-plugin version
Posted by Anders Hammar <an...@hammar.net>.
Feel free to file a ticket suggesting a text update! It's the best way to
ensure a change.
/Anders (mobile)
Den 28 nov 2013 20:41 skrev "Mirko Friedenhagen" <mf...@gmail.com>:
> Laird,
>
> your solution was very precise, I did not want to argue with your
> solution. However IMO maybe the plugin tutorial[0] should add a strong
> recommendation that parameter properties must always add a prefix :-).
>
> [0]
> http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Thu, Nov 28, 2013 at 4:04 AM, Laird Nelson <lj...@gmail.com> wrote:
> > On Wed, Nov 27, 2013 at 6:49 AM, Mirko Friedenhagen <
> mfriedenhagen@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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Property namespaces Was: Changing JDK version without specifying
maven-compiler-plugin version
Posted by Mirko Friedenhagen <mf...@gmail.com>.
Laird,
your solution was very precise, I did not want to argue with your
solution. However IMO maybe the plugin tutorial[0] should add a strong
recommendation that parameter properties must always add a prefix :-).
[0] http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/
On Thu, Nov 28, 2013 at 4:04 AM, Laird Nelson <lj...@gmail.com> wrote:
> On Wed, Nov 27, 2013 at 6:49 AM, Mirko Friedenhagen <mfriedenhagen@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Property namespaces Was: Changing JDK version without specifying
maven-compiler-plugin version
Posted by Laird Nelson <lj...@gmail.com>.
On Wed, Nov 27, 2013 at 6:49 AM, Mirko Friedenhagen <mfriedenhagen@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
Re: Property namespaces Was: Changing JDK version without specifying
maven-compiler-plugin version
Posted by Chris Graham <ch...@gmail.com>.
On Wed, Nov 27, 2013 at 5:49 PM, Mirko Friedenhagen <mfriedenhagen@gmail.com
> wrote:
> 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".
>
>
+10000000 to that!