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: [email protected]
For additional commands, e-mail: [email protected]
