[sonar-dev] Detecting custom annotations in a plugin

[Chad Johnston]

Hello,

We have developed a couple of custom annotations that we use on our code to mark issues with code. I'm trying to write a plugin that will report on the number of these annotations found.

I am really confused about how to find this information within my Sensor. I know that the Checkstyle AST will report on annotations, and it seems like Squid might as well. Which one of these would be better to use, and how would I go about accessing that data in my plugin? Between these two, it seems like there should be some way to access the AST without reinventing the wheel.

It looks like I could perform a Squid query on a certain metric, but I need to find the annotations first to be able to create the metric.

I looked at the Javadoc for the CheckstyleSquidBridge, but it doesn't seem to be quite the right fit either.

Any help is appreciated.

Thanks,

Chad

[Simon Brandhof]

Hi Chad,

You're right, it's not recommended to implement your own new parser. Sonar API does not provide ability to connect to parsers, so as you said you should extend one of the existing parsers. I recommend to have a look at Checkstyle plugins (documentation). Squid, that is our rule engine based on Checkstyle, is not extensible yet.

Regards
Simon

On 2 June 2012 03:13, Chad Johnston <[hidden email]> wrote:

Hello,

We have developed a couple of custom annotations that we use on our code to mark issues with code. I'm trying to write a plugin that will report on the number of these annotations found.

I am really confused about how to find this information within my Sensor. I know that the Checkstyle AST will report on annotations, and it seems like Squid might as well. Which one of these would be better to use, and how would I go about accessing that data in my plugin? Between these two, it seems like there should be some way to access the AST without reinventing the wheel.

It looks like I could perform a Squid query on a certain metric, but I need to find the annotations first to be able to create the metric.

I looked at the Javadoc for the CheckstyleSquidBridge, but it doesn't seem to be quite the right fit either.

Any help is appreciated.

Thanks,

Chad

[Jesús Badenas Martínez]

Hi guys,

we are really interested in this question. We have had a look at Checkstyle plugin documentation. We have used the example provided in the documentation and we have been able to create a new rule and obtain the AST data to calculate number of conditional sentences (if) of a file.

But, to obtain this information we need to activate the rule in the quality profile of Sonar.

So, the question is: Is there any way to obtain the same data without the rule activation?

Regards.

Jesús

2012/6/4 Simon Brandhof <[hidden email]>

Hi Chad,

You're right, it's not recommended to implement your own new parser. Sonar API does not provide ability to connect to parsers, so as you said you should extend one of the existing parsers. I recommend to have a look at Checkstyle plugins (documentation). Squid, that is our rule engine based on Checkstyle, is not extensible yet.

Regards
Simon

On 2 June 2012 03:13, Chad Johnston <[hidden email]> wrote:

Hello,

We have developed a couple of custom annotations that we use on our code to mark issues with code. I'm trying to write a plugin that will report on the number of these annotations found.

I am really confused about how to find this information within my Sensor. I know that the Checkstyle AST will report on annotations, and it seems like Squid might as well. Which one of these would be better to use, and how would I go about accessing that data in my plugin? Between these two, it seems like there should be some way to access the AST without reinventing the wheel.

It looks like I could perform a Squid query on a certain metric, but I need to find the annotations first to be able to create the metric.

I looked at the Javadoc for the CheckstyleSquidBridge, but it doesn't seem to be quite the right fit either.

Any help is appreciated.

Thanks,

Chad

[Chad Johnston]

Simon,

I think I can make a Checkstyle extension work. It's not exactly what
I want, but I think I can massage it to fit.

My problem now is that the annotations I'm looking for are on unit
test files, and Checkstyle is applied only to non-test source files.
Is there a way that I can indicate that my plugin wants the test
sources instead of the regular sources?

Thanks,
Chad

On Mon, Jun 4, 2012 at 3:37 AM, Simon Brandhof
<[hidden email]> wrote:

> Hi Chad,
>
> You're right, it's not recommended to implement your own new parser. Sonar
> API does not provide ability to connect to parsers, so as you said you
> should extend one of the existing parsers. I recommend to have a look at
> Checkstyle plugins (documentation). Squid, that is our rule engine based on
> Checkstyle, is not extensible yet.
>
> Regards
> Simon
>
>
> On 2 June 2012 03:13, Chad Johnston <[hidden email]> wrote:
>>
>> Hello,
>>
>> We have developed a couple of custom annotations that we use on our code
>> to mark issues with code. I'm trying to write a plugin that will report on
>> the number of these annotations found.
>>
>> I am really confused about how to find this information within my Sensor.
>> I know that the Checkstyle AST will report on annotations, and it seems like
>> Squid might as well. Which one of these would be better to use, and how
>> would I go about accessing that data in my plugin? Between these two, it
>> seems like there should be some way to access the AST without reinventing
>> the wheel.
>>
>> It looks like I could perform a Squid query on a certain metric, but I
>> need to find the annotations first to be able to create the metric.
>>
>> I looked at the Javadoc for the CheckstyleSquidBridge, but it doesn't seem
>> to be quite the right fit either.
>>
>> Any help is appreciated.
>>
>> Thanks,
>> Chad
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Simon Brandhof]

Hi guys,

I'm afraid that both of you are right : checkstyle extensions require rules to be enabled and unit tests are not inspected.
The only workaround I have mind is to implement your rule with PMD instead of Checkstyle. Indeed the PMD plugin supports inspection of unit tests in sonar 3.1.

Regards
Simon  

On 5 June 2012 20:52, Chad Johnston <[hidden email]> wrote:

Simon,

I think I can make a Checkstyle extension work. It's not exactly what
I want, but I think I can massage it to fit.

My problem now is that the annotations I'm looking for are on unit
test files, and Checkstyle is applied only to non-test source files.
Is there a way that I can indicate that my plugin wants the test
sources instead of the regular sources?

Thanks,
Chad

On Mon, Jun 4, 2012 at 3:37 AM, Simon Brandhof
<[hidden email]> wrote:
> Hi Chad,
>
> You're right, it's not recommended to implement your own new parser. Sonar
> API does not provide ability to connect to parsers, so as you said you
> should extend one of the existing parsers. I recommend to have a look at
> Checkstyle plugins (documentation). Squid, that is our rule engine based on
> Checkstyle, is not extensible yet.
>
> Regards
> Simon
>
>
> On 2 June 2012 03:13, Chad Johnston <[hidden email]> wrote:
>>
>> Hello,
>>
>> We have developed a couple of custom annotations that we use on our code
>> to mark issues with code. I'm trying to write a plugin that will report on
>> the number of these annotations found.
>>
>> I am really confused about how to find this information within my Sensor.
>> I know that the Checkstyle AST will report on annotations, and it seems like
>> Squid might as well. Which one of these would be better to use, and how
>> would I go about accessing that data in my plugin? Between these two, it
>> seems like there should be some way to access the AST without reinventing
>> the wheel.
>>
>> It looks like I could perform a Squid query on a certain metric, but I
>> need to find the annotations first to be able to create the metric.
>>
>> I looked at the Javadoc for the CheckstyleSquidBridge, but it doesn't seem
>> to be quite the right fit either.
>>
>> Any help is appreciated.
>>
>> Thanks,
>> Chad
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email