On 28 Dec 07, at 2:52 AM 28 Dec 07, Dennis Lundberg wrote:
Jason van Zyl wrote:
On 27 Dec 07, at 4:02 PM 27 Dec 07, Dennis Lundberg wrote:
Hi
I've been applying patches to the pmd-plugin from Xavier Le
Vourch. The
patches have been of good quality.
Now I'm looking at a patch for http://jira.codehaus.org/browse/MPMD-63
which reads the jdk source level from the compiler-plugin, so that
it
can feed this info to PMD. This topic has been brought up from
time to
time and the only answer I have seen is: "No there is no standard
way of
doing this".
The code seems pretty straight-forward to me, but I wanted to
check with
you before I apply it. Here's a run down of what it does:
- Get the build/plugins from the pmd-plugins project model
- Pick out "org.apache.maven.plugins:maven-compiler-plugin"
- Create a DOM document of the plugin's configuration
- Use XPath to retrieve the "source" configuration
Is this a good/ok/bad thing to do?
Bad. You're going to end up with a bunch of plugins that are
implicitly
bound to one another and you'll have the same mess as Maven 1.x.
If someone wants to share that value across plugins then today
using a
property that is shared between the plugins is better then one plugin
lifting values from another. Then you're dealing with something
explicit
which you can see in the POM.
Thanks Jason, so the most general and forward-compatible way would
be a
best-practice.
Set up a property:
<properties>
<compileSource>1.5</compileSource>
</properties>
and use that in the configuration section of each plugin
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${compileSource}</source>
</configuration>
</plugin>
<plugin>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<targetJdk>${compileSource}</targetJdk>
</configuration>
</plugin>
I'll go ahead and close the issue as "won't fix" and add some
documentation, like the above.
Yes, because we certainly have a few cases (a concrete example that
Tom pointed out) where trying to make sure that plugins are
initialized so that their configurations are available and possibly
nothing else is just wrong. Plugin configuration sources are not
general configuration sources. The POM should be the general source of
configuration, the properties is a low-tech way of sharing it. The
tool chain will can replace that with a bit of brains later.
For anyone to generally try and check the consistency between two
plugin
configurations is just going to end up in a quagmire.
The toolchain is not going to happen tomorrow, but today we could
pick
some standard property keys for thing like the source level and use
that
in the POM so that many plugins can share the configuration. Plugins
poking into other plugin's configuration is the path to a mess.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]