On 26/07/2011, at 12:49 PM, Andrew Oberstar wrote:
> Interesting... It does only seem to be failing in the tests. It
> successfully executes PMD with the Gradle build.
>
> I guess the other difference is that I switched from using the tooling API to
> the test fixtures when I added them to the Gradle project. I'll have to look
> into that tomorrow.
I'd expect it to fail with the test fixture. This is because, by default, the
test fixture shoves every runtime dependency of Gradle and all the plugins into
a single classloader, and then expect things to work. The solution, I think, is
to fix the test fixture to do a better job at recreating the actual classloader
hierarchy, so that things that should be isolated at runtime actually are.
Possibly by sitting it on top of the tooling API.
In the meantime, the test fixture has a 'forking' mode which actually runs the
'gradle' command. You could use this to run the failing test:
./gradlew integTest:forkingIntegTest
-DforkingIntegTest.single=PMDIntegrationTest
Another option is to force the test fixture into forking mode in the test
itself. For example:
executor.executable('gradle')
>
> Andy
>
>
> On Mon, Jul 25, 2011 at 2:36 PM, Adam Murdoch <[email protected]>
> wrote:
>
> On 23/07/2011, at 11:47 AM, Andrew Oberstar wrote:
>
>> I'm working on adding these plugins to Gradle proper. However, I'm running
>> into classpath issues with the PMD plugin. I'm not an expert on this stuff,
>> so I was hoping someone here might be able to help.
>>
>> The situation arises when executing the PMD task while referencing the
>> standard rulesets included in the PMD distribution. The task fails with a
>> ClassCastException because it is trying to include CodeNarc's rulesets
>> rather than PMDs.
>
> Is it only failing in the test, or is it also failing when you run Gradle?
>
>> They both have rulesets in XML files underneath a rulesets folder directly
>> in the root of their JAR (and both have a basic.xml). This was not an issue
>> when these classes were in a separate plugin JAR loaded through the normal
>> buildscript {} block. I assume there's an extra layer of classloaders in
>> that case, but haven't been able to confirm it.
>>
>> Basically, I'm wondering what the correct approach for this is. Is there a
>> way to execute the PMD Ant task isolated from some of the other classes
>> available on Gradle's classpath?
>>
>> You can reproduce this with the PMDIntegrationTest class added to the
>> integTest subproject in my fork below.
>>
>> I'm working on this branch in my fork:
>> https://github.com/ajoberstar/gradle/tree/code-quality
>> Here's the most relevant commit:
>> https://github.com/ajoberstar/gradle/commit/cf7bd46837e22f8cb0a6ec58ed93f78beae82aa9
>>
>> Andy Oberstar
>>
>>
>> On Sun, May 15, 2011 at 3:51 PM, Adam Murdoch <[email protected]>
>> wrote:
>>
>> On 15/05/2011, at 2:53 AM, Andrew Oberstar wrote:
>>
>>> Hi all,
>>>
>>> I just released a few Gradle plugins for JDepend, PMD, and Findbugs. As
>>> far as I could tell (I may be wrong), there aren't any pure plugins for
>>> these tools. The code was mostly inspired by the samples in the Cookbook
>>> and the code-quality plugin. The implementations aren't that great, but
>>> they work for the most part. This is my first crack at this, so I welcome
>>> any comments, suggestions, or criticism.
>>
>> These look really good. You should list the plugins on the wiki:
>> http://wiki.gradle.org/display/GRADLE/Plugins
>>
>> Here are a few things you could do to simplify the code:
>>
>> - In JDepend, you can remove the onlyIf check added in the constructor, and
>> replace it with @SkipWhenEmpty on getClassesDir().
>>
>> - You could make Findbugs.classpath and classes with @InputFiles instead of
>> @Input. Same for PMD.rulesets. You get some better validation and the
>> up-to-date checking is potentially faster when Gradle knows these are input
>> files. On the other hand, this is also something Gradle could figure out
>> from the types of the properties, so perhaps we should change Gradle in this
>> instance.
>>
>>
>> --
>> Adam Murdoch
>> Gradle Co-founder
>> http://www.gradle.org
>> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
>> http://www.gradleware.com
>>
>>
>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
