maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <>
Subject Re: Changing JDK version without specifying maven-compiler-plugin version
Date Sat, 30 Nov 2013 03:48:19 GMT
Hi Malte,

> Btw, tried to have a look at the namespace declaration at
> 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.


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


On Thu, Nov 28, 2013 at 5:12 AM, Malte Skoruppa <
> wrote:

> Hi,
>  I thought the version is defined in
>> 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:
> 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 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
> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message