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]

Reply via email to