domi | 1 Oct 14:26 2011
Picon

Re: [sonar-dev] Re: [sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

Freddy,

I'm glad to see that you understand the use case :)
Although I'm not 100% align with your outcome…
I'm sure we could make the plugin aware of all the installed triggers automatically, without having to update the plugin when ever a new trigger is available.

e.g. the following code gives you dynamically access to all the currently installed triggers (TriggerDescriptors):

        final DescriptorExtensionList<Trigger<?>, TriggerDescriptor> allTriggers = hudson.triggers.Trigger.all();
        for (TriggerDescriptor triggerDescriptor : allTriggers) {
final String triggerName = triggerDescriptor.getDisplayName();
// create a checkbox for each trigger in the UI ...
}

this and a general switch (via BuildParameter) to skip the sonar execution for a given run would probably solve 99% of all the use cases.
If you think this would help, I'll be happy to implement it…

One note to the plugin: As i read somewhere, you also plan to provide a build step to trigger Sonar: this is really a good idea and I hope it comes in addition to the current SonarPublisher and not as a replacement. 

regards Domi  


On 30.09.2011, at 14:17, Freddy Mallet wrote:

Thanks for your feedback Domi, John and Michael.

In fact there is only one use case and indeed it's difficult to ignore the value of this use case : being able to deactivate the sonar analysis when the job has been triggered by some SCM changes.

I do think that the main drawback of the current Sonar Hudson plugin is the white list approach. With this approach we say : "Execute Sonar analysis when ..." which means that each time a user want to use a new trigger, the Sonar Hudson plugin needs to be updated to support this trigger.

But this is not really what Sonar users wants to define. A Sonar user just want to say : 
  • "Don't execute Sonar when the job has been triggered only by some SCM changes"
  • and/or "Don't execute Sonar when the job has been triggered only by the build of a SNAPSHOT dependency"
Moreover, with this black list approach, perhaps it's even useless to be able to override those properties at project level.

All that to say that we've reopened the ticket https://jira.codehaus.org/browse/SONARPLUGINS-1388.

Kind regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
twitter.com/FreddyMallet
----------------------------------------



On Wed, Sep 28, 2011 at 9:05 PM, Michael Schaaf <michael.schaaf.wo.de <at> googlemail.com> wrote:
Hello Michael,

the builds of our company are just the same as Johns and domis.
We have about 50 Projects in Sonar which are inspected on nightly and manual builds.
Builds on code changes only compile and run tests to give quick feedback to the developer.

The triggers are configured in the settings of hudson and used in the jobs. I'm currently thinking about integration of the web-plugin with functionallity from the hudson/jenkins sonar plugin. It is possible to configure default properties and use them in all jobs.

The deletion of the triggers would double of our hudson jobs, which would be much more work.

Is there an other solution to configure hudson/jenkins to run code inspection only on nightly builds? I had a short look at the pipes plugin but think it is not possible.

regards

Michael

Am 28.09.11 08:14, schrieb Michael Hüttermann:


Hello Domi, hello John,
may I ask, what exactly is your use case that you rely on *triggers*, or with other words: why does removement of triggers (as you said:) "will cause more work and increase the potential for error of the build teams.". Would you mind to elaborate a bit about your concrete setting and build chain?


Michael



Am Dienstag, den 27.09.2011, 20:34 +0200 schrieb domi <domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org>:
I'm sorry if my first mail sounded rude, that was definitely not the
intention!
Sonar does play a very important role in our setup and we don't want
to miss it, but without the trigger support we limited use of it and
its also getting harder to promote it.
If you think the Build Pipeline plugin should be used, then I'm at
the same point, because this plugin is really hard to handle if you
have hundreds of job to setup (e.g. number of views, permissions,…).
regards Domi

On 27.09.2011, at 20:18, Vogtle, John wrote:

Team,

I agree with Domi. For anyone with a large number of Hudson/Jenkins
jobs, this decision will cause more work and increase the potential
for error of the build teams. Duplicating jobs is not really a viable
option.

Could you describe a use case and/or roadmap for the Jenkins Sonar
plugin? Is your thought to leverage the pipeline plugin instead of
using triggers within the Sonar plugin?

From my point of view the Triggers _are_ the reason for the plugin.
Otherwise you could simply add sonar to the list of targets to be
executed by Ant or Maven. I could well be missing an crucial point
here and would welcome some discussion on this point.

You do terrific work but I really don’t understand the rationale
here. Thanks for any input you could provide.

 -John

JOHN M. VOGTLE|BANK OF AMERICA|STRATEGY & SHARED SERVICES: SD
COE|CONSUMER CHANNELS TECHNOLOGY|585.265.3694|

FROM: domi [mailto:domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org]
SENT: Tuesday, September 27, 2011 1:47 PM
TO: dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org [1]
CC: user
SUBJECT: Re: [sonar-dev] Re: [sonar-user] Re: [sonar-dev] Re:
[sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

Hi,

are you serious?

I think I don't quite understand your point, but on our site, this
basically means that we have to double the number of jobs configured
in Jenkins - which is a really pain!

…can you be more precise why you want to remove this, I do
understand some of your points, but I think its more up to the user to
decide whether he wants to take the risk or not.

otherwise, maybe someone just does a clone of the plugin then...

regards Domi

On 26.09.2011, at 17:41, Freddy Mallet wrote:

FYI, we've decided to finally remove the support of triggers in the
1.7 version of the upcoming Hudson/Jenkins plugin.

Indeed, we introduced this feature due to lack of native support by
Hudson/Jenkins of "pipeline"/"chain of jobs" concept (see for instance
http://wiki.hudson-ci.org/display/HUDSON/Build+Pipeline+Plugin [2])
but this was clearly a mistake :

   * This feature had lot of limitations that we don't want to fix
(like supporting all kind of triggers, being able to launch manually a
Sonar analysis even if the "manual" trigger is not activated, ... )
   * Using this feature is not a good practice as :

   * In case of failure, we don't know if the failure is due to the CI
step or to the Sonar analysis
   * If the job requires more time to be executed, we don't know if
this is due to the CI step of to the Sonar analysis

We know that this choice can impact some of you and we're sorry about
that but we really remove this feature to globally improve the
usability of the plugin.

Kind regards,

Freddy
----------------------------------------
Freddy Mallet
www.SonarSource.org [3]
www.SonarSource.com [4]
----------------------------------------

On Sun, Sep 18, 2011 at 9:18 AM, Freddy Mallet  wrote:
Indeed Ann, this would be a very useful feature and that's why the
ticket http://jira.codehaus.org/browse/SONARPLUGINS-1376 [6] has been
created : "Make it possible to use a pattern like "lib/*.jar" to
define the value of the 'sonar.libraries' property"

Kind regards,

Freddy
----------------------------------------
Freddy Mallet
www.SonarSource.org [7]
www.SonarSource.com [8]
----------------------------------------

On Fri, Sep 16, 2011 at 2:21 PM,  wrote:
Okay, then here's my comment/request:

I have projects that are years-old accretions of frameworks &
technologies. The number of jars approaches 100. It would be ideal,
from my perspective, to be able to list:

libraries=path/to/tomcat/libs,path/to/war/libs,/path/to/other.jar

Ann Campbell
Engineer-Systems-IS Prod Sys-Shop Floor Sys
Shaw Industries Inc.
201 South Hamilton Street
Dalton, GA 30720
EMAIL: ann.campbell-K67OQRCp/lRBDgjK7y7TUQ@public.gmane.org [10]  OFFICE: 706.275.3857 [11]

Please consider the environment before printing.

From: Simon Brandhof

To: dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org [13]
Date: 09/16/2011 04:54 AM
Subject: Re: [sonar-dev] Re: [sonar-user] Re: [sonar-dev] Re:
[sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

-------------------------

Just to be more clear : accepted values are paths to JAR and paths to
directory of classes.
Example :
libraries=path/to/junit.jar,path/to/other.jar,path/to/classes

"path/to/classes" is a directory that contains .class files, not
JARs.

On 16 September 2011 10:24, Simon Brandhof  wrote:
The comment says "path" but the example data shows a jar listing.
I'll actually be able to specify a comma-delimited set of paths tho,
right?

Exact

**********************************************************

Privileged and/or confidential information may be contained in this
message. If you are not the addressee indicated in this message (or
are not responsible for delivery of this message to that person) , you
may not copy or deliver this message to anyone. In such case, you
should destroy this message and notify the sender by reply e-mail.

If you or your employer do not consent to Internet e-mail for
messages of this kind, please advise the sender.

Shaw Industries does not provide or endorse any opinions, conclusions
or other information in this message that do not relate to the
official business of the company or its subsidiaries.

**********************************************************

-------------------------
This message w/attachments (message) is intended solely for the use
of the intended recipient(s) and may contain information that is
privileged, confidential or proprietary. If you are not an intended
recipient, please notify the sender, and then please delete and
destroy all copies and attachments, and be advised that any review or
dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell
or a solicitation of any investment products or other financial
product or service, an official confirmation of any transaction, or an
official statement of Sender. Subject to applicable law, Sender may
intercept, monitor, review and retain e-communications (EC) traveling
through its networks/systems and may produce any such EC to
regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the
handling of EC, and EC may be archived, supervised and produced in
countries other than the country in which you are located. This
message cannot be guaranteed to be secure or free of errors or
viruses.

References to "Sender" are references to any subsidiary of Bank of
America Corporation. Securities and Insurance Products: * Are Not FDIC
Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank
Deposit * Are Not a Condition to Any Banking Service or Activity * Are
Not Insured by Any Federal Government Agency. Attachments that are
part of this EC may have additional important disclosures and
disclaimers, which you should read. This message is subject to terms
available at the following link:
http://www.bankofamerica.com/emaildisclaimer [15]. By messaging with
Sender you consent to the foregoing.


Links:
------
[1] mailto:dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
[2] http://wiki.hudson-ci.org/display/HUDSON/Build+Pipeline+Plugin
[3] http://www.SonarSource.org/
[4] http://www.SonarSource.com/
[5] mailto:freddy.mallet <at> sonarsource.com
[6] http://jira.codehaus.org/browse/SONARPLUGINS-1376
[7] http://www.SonarSource.org/
[8] http://www.SonarSource.com/
[9] mailto:ann.campbell <at> shawinc.com
[10] mailto:ann.campbell <at> shawinc.com
[11] http://webmailer.hosteurope.de/tel:706.275.3857
[12] mailto:simon.brandhof <at> sonarsource.com
[13] mailto:dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
[14] mailto:simon.brandhof <at> sonarsource.com
[15] http://www.bankofamerica.com/emaildisclaimer



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

  http://xircles.codehaus.org/manage_email




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

  http://xircles.codehaus.org/manage_email




Evgeny Mandrikov | 1 Oct 15:19 2011
Picon

Re: Re: [sonar-dev] Re: [sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

Hi Domi,


This code snippet definitely will work to list all available triggers, but in fact we need to solve another task - by Cause determine Trigger and as far as I know there is no such association in Jenkins / Hudson. Trigger simply calls constructor of Cause.

On Sat, Oct 1, 2011 at 16:26, domi <domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org> wrote:
Freddy,

I'm glad to see that you understand the use case :)
Although I'm not 100% align with your outcome…
I'm sure we could make the plugin aware of all the installed triggers automatically, without having to update the plugin when ever a new trigger is available.

e.g. the following code gives you dynamically access to all the currently installed triggers (TriggerDescriptors):

        final DescriptorExtensionList<Trigger<?>, TriggerDescriptor> allTriggers = hudson.triggers.Trigger.all();
        for (TriggerDescriptor triggerDescriptor : allTriggers) {
final String triggerName = triggerDescriptor.getDisplayName();
// create a checkbox for each trigger in the UI ...
}

this and a general switch (via BuildParameter) to skip the sonar execution for a given run would probably solve 99% of all the use cases.
If you think this would help, I'll be happy to implement it…

One note to the plugin: As i read somewhere, you also plan to provide a build step to trigger Sonar: this is really a good idea and I hope it comes in addition to the current SonarPublisher and not as a replacement. 

regards Domi  


On 30.09.2011, at 14:17, Freddy Mallet wrote:

Thanks for your feedback Domi, John and Michael.

In fact there is only one use case and indeed it's difficult to ignore the value of this use case : being able to deactivate the sonar analysis when the job has been triggered by some SCM changes.

I do think that the main drawback of the current Sonar Hudson plugin is the white list approach. With this approach we say : "Execute Sonar analysis when ..." which means that each time a user want to use a new trigger, the Sonar Hudson plugin needs to be updated to support this trigger.

But this is not really what Sonar users wants to define. A Sonar user just want to say : 
  • "Don't execute Sonar when the job has been triggered only by some SCM changes"
  • and/or "Don't execute Sonar when the job has been triggered only by the build of a SNAPSHOT dependency"
Moreover, with this black list approach, perhaps it's even useless to be able to override those properties at project level.

All that to say that we've reopened the ticket https://jira.codehaus.org/browse/SONARPLUGINS-1388.

Kind regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
twitter.com/FreddyMallet
----------------------------------------



On Wed, Sep 28, 2011 at 9:05 PM, Michael Schaaf <michael.schaaf.wo.de-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
Hello Michael,

the builds of our company are just the same as Johns and domis.
We have about 50 Projects in Sonar which are inspected on nightly and manual builds.
Builds on code changes only compile and run tests to give quick feedback to the developer.

The triggers are configured in the settings of hudson and used in the jobs. I'm currently thinking about integration of the web-plugin with functionallity from the hudson/jenkins sonar plugin. It is possible to configure default properties and use them in all jobs.

The deletion of the triggers would double of our hudson jobs, which would be much more work.

Is there an other solution to configure hudson/jenkins to run code inspection only on nightly builds? I had a short look at the pipes plugin but think it is not possible.

regards

Michael

Am 28.09.11 08:14, schrieb Michael Hüttermann:


Hello Domi, hello John,
may I ask, what exactly is your use case that you rely on *triggers*, or with other words: why does removement of triggers (as you said:) "will cause more work and increase the potential for error of the build teams.". Would you mind to elaborate a bit about your concrete setting and build chain?


Michael



Am Dienstag, den 27.09.2011, 20:34 +0200 schrieb domi <domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org>:
I'm sorry if my first mail sounded rude, that was definitely not the
intention!
Sonar does play a very important role in our setup and we don't want
to miss it, but without the trigger support we limited use of it and
its also getting harder to promote it.
If you think the Build Pipeline plugin should be used, then I'm at
the same point, because this plugin is really hard to handle if you
have hundreds of job to setup (e.g. number of views, permissions,…).
regards Domi

On 27.09.2011, at 20:18, Vogtle, John wrote:

Team,

I agree with Domi. For anyone with a large number of Hudson/Jenkins
jobs, this decision will cause more work and increase the potential
for error of the build teams. Duplicating jobs is not really a viable
option.

Could you describe a use case and/or roadmap for the Jenkins Sonar
plugin? Is your thought to leverage the pipeline plugin instead of
using triggers within the Sonar plugin?

From my point of view the Triggers _are_ the reason for the plugin.
Otherwise you could simply add sonar to the list of targets to be
executed by Ant or Maven. I could well be missing an crucial point
here and would welcome some discussion on this point.

You do terrific work but I really don’t understand the rationale
here. Thanks for any input you could provide.

 -John

JOHN M. VOGTLE|BANK OF AMERICA|STRATEGY & SHARED SERVICES: SD
COE|CONSUMER CHANNELS TECHNOLOGY|585.265.3694|

FROM: domi [mailto:domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org]
SENT: Tuesday, September 27, 2011 1:47 PM
TO: dev <at> sonar.codehaus.org [1]
CC: user
SUBJECT: Re: [sonar-dev] Re: [sonar-user] Re: [sonar-dev] Re:
[sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

Hi,

are you serious?

I think I don't quite understand your point, but on our site, this
basically means that we have to double the number of jobs configured
in Jenkins - which is a really pain!

…can you be more precise why you want to remove this, I do
understand some of your points, but I think its more up to the user to
decide whether he wants to take the risk or not.

otherwise, maybe someone just does a clone of the plugin then...

regards Domi

On 26.09.2011, at 17:41, Freddy Mallet wrote:

FYI, we've decided to finally remove the support of triggers in the
1.7 version of the upcoming Hudson/Jenkins plugin.

Indeed, we introduced this feature due to lack of native support by
Hudson/Jenkins of "pipeline"/"chain of jobs" concept (see for instance
http://wiki.hudson-ci.org/display/HUDSON/Build+Pipeline+Plugin [2])
but this was clearly a mistake :

   * This feature had lot of limitations that we don't want to fix
(like supporting all kind of triggers, being able to launch manually a
Sonar analysis even if the "manual" trigger is not activated, ... )
   * Using this feature is not a good practice as :

   * In case of failure, we don't know if the failure is due to the CI
step or to the Sonar analysis
   * If the job requires more time to be executed, we don't know if
this is due to the CI step of to the Sonar analysis

We know that this choice can impact some of you and we're sorry about
that but we really remove this feature to globally improve the
usability of the plugin.

Kind regards,

Freddy
----------------------------------------
Freddy Mallet
www.SonarSource.org [3]
www.SonarSource.com [4]
----------------------------------------

On Sun, Sep 18, 2011 at 9:18 AM, Freddy Mallet  wrote:
Indeed Ann, this would be a very useful feature and that's why the
ticket http://jira.codehaus.org/browse/SONARPLUGINS-1376 [6] has been
created : "Make it possible to use a pattern like "lib/*.jar" to
define the value of the 'sonar.libraries' property"

Kind regards,

Freddy
----------------------------------------
Freddy Mallet
www.SonarSource.org [7]
www.SonarSource.com [8]
----------------------------------------

On Fri, Sep 16, 2011 at 2:21 PM,  wrote:
Okay, then here's my comment/request:

I have projects that are years-old accretions of frameworks &
technologies. The number of jars approaches 100. It would be ideal,
from my perspective, to be able to list:

libraries=path/to/tomcat/libs,path/to/war/libs,/path/to/other.jar

Ann Campbell
Engineer-Systems-IS Prod Sys-Shop Floor Sys
Shaw Industries Inc.
201 South Hamilton Street
Dalton, GA 30720
EMAIL: ann.campbell-K67OQRCp/lRBDgjK7y7TUQ@public.gmane.org [10]  OFFICE: 706.275.3857 [11]

Please consider the environment before printing.

From: Simon Brandhof

To: dev <at> sonar.codehaus.org [13]
Date: 09/16/2011 04:54 AM
Subject: Re: [sonar-dev] Re: [sonar-user] Re: [sonar-dev] Re:
[sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

-------------------------

Just to be more clear : accepted values are paths to JAR and paths to
directory of classes.
Example :
libraries=path/to/junit.jar,path/to/other.jar,path/to/classes

"path/to/classes" is a directory that contains .class files, not
JARs.

On 16 September 2011 10:24, Simon Brandhof  wrote:
The comment says "path" but the example data shows a jar listing.
I'll actually be able to specify a comma-delimited set of paths tho,
right?

Exact

**********************************************************

Privileged and/or confidential information may be contained in this
message. If you are not the addressee indicated in this message (or
are not responsible for delivery of this message to that person) , you
may not copy or deliver this message to anyone. In such case, you
should destroy this message and notify the sender by reply e-mail.

If you or your employer do not consent to Internet e-mail for
messages of this kind, please advise the sender.

Shaw Industries does not provide or endorse any opinions, conclusions
or other information in this message that do not relate to the
official business of the company or its subsidiaries.

**********************************************************

-------------------------
This message w/attachments (message) is intended solely for the use
of the intended recipient(s) and may contain information that is
privileged, confidential or proprietary. If you are not an intended
recipient, please notify the sender, and then please delete and
destroy all copies and attachments, and be advised that any review or
dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell
or a solicitation of any investment products or other financial
product or service, an official confirmation of any transaction, or an
official statement of Sender. Subject to applicable law, Sender may
intercept, monitor, review and retain e-communications (EC) traveling
through its networks/systems and may produce any such EC to
regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the
handling of EC, and EC may be archived, supervised and produced in
countries other than the country in which you are located. This
message cannot be guaranteed to be secure or free of errors or
viruses.

References to "Sender" are references to any subsidiary of Bank of
America Corporation. Securities and Insurance Products: * Are Not FDIC
Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank
Deposit * Are Not a Condition to Any Banking Service or Activity * Are
Not Insured by Any Federal Government Agency. Attachments that are
part of this EC may have additional important disclosures and
disclaimers, which you should read. This message is subject to terms
available at the following link:
http://www.bankofamerica.com/emaildisclaimer [15]. By messaging with
Sender you consent to the foregoing.


Links:
------
[1] mailto:dev <at> sonar.codehaus.org
[2] http://wiki.hudson-ci.org/display/HUDSON/Build+Pipeline+Plugin
[3] http://www.SonarSource.org/
[4] http://www.SonarSource.com/
[5] mailto:freddy.mallet <at> sonarsource.com
[6] http://jira.codehaus.org/browse/SONARPLUGINS-1376
[7] http://www.SonarSource.org/
[8] http://www.SonarSource.com/
[9] mailto:ann.campbell <at> shawinc.com
[10] mailto:ann.campbell <at> shawinc.com
[11] http://webmailer.hosteurope.de/tel:706.275.3857
[12] mailto:simon.brandhof <at> sonarsource.com
[13] mailto:dev <at> sonar.codehaus.org
[14] mailto:simon.brandhof <at> sonarsource.com
[15] http://www.bankofamerica.com/emaildisclaimer



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

  http://xircles.codehaus.org/manage_email




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

  http://xircles.codehaus.org/manage_email







--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_
domi | 1 Oct 16:30 2011
Picon

Re: [sonar-dev] Re: [sonar-user] Re: [sonar-dev] Re: [sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

Damn, you'r right!  :)
let me think about it again...
/Domi

On 01.10.2011, at 15:19, Evgeny Mandrikov wrote:

Hi Domi,

This code snippet definitely will work to list all available triggers, but in fact we need to solve another task - by Cause determine Trigger and as far as I know there is no such association in Jenkins / Hudson. Trigger simply calls constructor of Cause.

On Sat, Oct 1, 2011 at 16:26, domi <domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org> wrote:
Freddy,

I'm glad to see that you understand the use case :)
Although I'm not 100% align with your outcome…
I'm sure we could make the plugin aware of all the installed triggers automatically, without having to update the plugin when ever a new trigger is available.

e.g. the following code gives you dynamically access to all the currently installed triggers (TriggerDescriptors):

        final DescriptorExtensionList<Trigger<?>, TriggerDescriptor> allTriggers = hudson.triggers.Trigger.all();
        for (TriggerDescriptor triggerDescriptor : allTriggers) {
final String triggerName = triggerDescriptor.getDisplayName();
// create a checkbox for each trigger in the UI ...
}

this and a general switch (via BuildParameter) to skip the sonar execution for a given run would probably solve 99% of all the use cases.
If you think this would help, I'll be happy to implement it…

One note to the plugin: As i read somewhere, you also plan to provide a build step to trigger Sonar: this is really a good idea and I hope it comes in addition to the current SonarPublisher and not as a replacement. 

regards Domi  


On 30.09.2011, at 14:17, Freddy Mallet wrote:

Thanks for your feedback Domi, John and Michael.

In fact there is only one use case and indeed it's difficult to ignore the value of this use case : being able to deactivate the sonar analysis when the job has been triggered by some SCM changes.

I do think that the main drawback of the current Sonar Hudson plugin is the white list approach. With this approach we say : "Execute Sonar analysis when ..." which means that each time a user want to use a new trigger, the Sonar Hudson plugin needs to be updated to support this trigger.

But this is not really what Sonar users wants to define. A Sonar user just want to say : 
  • "Don't execute Sonar when the job has been triggered only by some SCM changes"
  • and/or "Don't execute Sonar when the job has been triggered only by the build of a SNAPSHOT dependency"
Moreover, with this black list approach, perhaps it's even useless to be able to override those properties at project level.

All that to say that we've reopened the ticket https://jira.codehaus.org/browse/SONARPLUGINS-1388.

Kind regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
twitter.com/FreddyMallet
----------------------------------------



On Wed, Sep 28, 2011 at 9:05 PM, Michael Schaaf <michael.schaaf.wo.de-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
Hello Michael,

the builds of our company are just the same as Johns and domis.
We have about 50 Projects in Sonar which are inspected on nightly and manual builds.
Builds on code changes only compile and run tests to give quick feedback to the developer.

The triggers are configured in the settings of hudson and used in the jobs. I'm currently thinking about integration of the web-plugin with functionallity from the hudson/jenkins sonar plugin. It is possible to configure default properties and use them in all jobs.

The deletion of the triggers would double of our hudson jobs, which would be much more work.

Is there an other solution to configure hudson/jenkins to run code inspection only on nightly builds? I had a short look at the pipes plugin but think it is not possible.

regards

Michael

Am 28.09.11 08:14, schrieb Michael Hüttermann:


Hello Domi, hello John,
may I ask, what exactly is your use case that you rely on *triggers*, or with other words: why does removement of triggers (as you said:) "will cause more work and increase the potential for error of the build teams.". Would you mind to elaborate a bit about your concrete setting and build chain?


Michael



Am Dienstag, den 27.09.2011, 20:34 +0200 schrieb domi <domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org>:
I'm sorry if my first mail sounded rude, that was definitely not the
intention!
Sonar does play a very important role in our setup and we don't want
to miss it, but without the trigger support we limited use of it and
its also getting harder to promote it.
If you think the Build Pipeline plugin should be used, then I'm at
the same point, because this plugin is really hard to handle if you
have hundreds of job to setup (e.g. number of views, permissions,…).
regards Domi

On 27.09.2011, at 20:18, Vogtle, John wrote:

Team,

I agree with Domi. For anyone with a large number of Hudson/Jenkins
jobs, this decision will cause more work and increase the potential
for error of the build teams. Duplicating jobs is not really a viable
option.

Could you describe a use case and/or roadmap for the Jenkins Sonar
plugin? Is your thought to leverage the pipeline plugin instead of
using triggers within the Sonar plugin?

From my point of view the Triggers _are_ the reason for the plugin.
Otherwise you could simply add sonar to the list of targets to be
executed by Ant or Maven. I could well be missing an crucial point
here and would welcome some discussion on this point.

You do terrific work but I really don’t understand the rationale
here. Thanks for any input you could provide.

 -John

JOHN M. VOGTLE|BANK OF AMERICA|STRATEGY & SHARED SERVICES: SD
COE|CONSUMER CHANNELS TECHNOLOGY|585.265.3694|

FROM: domi [mailto:domi-7W4aSUSHuKgfv37vnLkPlQ@public.gmane.org]
SENT: Tuesday, September 27, 2011 1:47 PM
TO: dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org [1]
CC: user
SUBJECT: Re: [sonar-dev] Re: [sonar-user] Re: [sonar-dev] Re:
[sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

Hi,

are you serious?

I think I don't quite understand your point, but on our site, this
basically means that we have to double the number of jobs configured
in Jenkins - which is a really pain!

…can you be more precise why you want to remove this, I do
understand some of your points, but I think its more up to the user to
decide whether he wants to take the risk or not.

otherwise, maybe someone just does a clone of the plugin then...

regards Domi

On 26.09.2011, at 17:41, Freddy Mallet wrote:

FYI, we've decided to finally remove the support of triggers in the
1.7 version of the upcoming Hudson/Jenkins plugin.

Indeed, we introduced this feature due to lack of native support by
Hudson/Jenkins of "pipeline"/"chain of jobs" concept (see for instance
http://wiki.hudson-ci.org/display/HUDSON/Build+Pipeline+Plugin [2])
but this was clearly a mistake :

   * This feature had lot of limitations that we don't want to fix
(like supporting all kind of triggers, being able to launch manually a
Sonar analysis even if the "manual" trigger is not activated, ... )
   * Using this feature is not a good practice as :

   * In case of failure, we don't know if the failure is due to the CI
step or to the Sonar analysis
   * If the job requires more time to be executed, we don't know if
this is due to the CI step of to the Sonar analysis

We know that this choice can impact some of you and we're sorry about
that but we really remove this feature to globally improve the
usability of the plugin.

Kind regards,

Freddy
----------------------------------------
Freddy Mallet
www.SonarSource.org [3]
www.SonarSource.com [4]
----------------------------------------

On Sun, Sep 18, 2011 at 9:18 AM, Freddy Mallet  wrote:
Indeed Ann, this would be a very useful feature and that's why the
ticket http://jira.codehaus.org/browse/SONARPLUGINS-1376 [6] has been
created : "Make it possible to use a pattern like "lib/*.jar" to
define the value of the 'sonar.libraries' property"

Kind regards,

Freddy
----------------------------------------
Freddy Mallet
www.SonarSource.org [7]
www.SonarSource.com [8]
----------------------------------------

On Fri, Sep 16, 2011 at 2:21 PM,  wrote:
Okay, then here's my comment/request:

I have projects that are years-old accretions of frameworks &
technologies. The number of jars approaches 100. It would be ideal,
from my perspective, to be able to list:

libraries=path/to/tomcat/libs,path/to/war/libs,/path/to/other.jar

Ann Campbell
Engineer-Systems-IS Prod Sys-Shop Floor Sys
Shaw Industries Inc.
201 South Hamilton Street
Dalton, GA 30720
EMAIL: ann.campbell-K67OQRCp/lRBDgjK7y7TUQ@public.gmane.org [10]  OFFICE: 706.275.3857 [11]

Please consider the environment before printing.

From: Simon Brandhof

To: dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org [13]
Date: 09/16/2011 04:54 AM
Subject: Re: [sonar-dev] Re: [sonar-user] Re: [sonar-dev] Re:
[sonar-user] Upcoming version of Jenkins/Hudson Sonar Plugin

-------------------------

Just to be more clear : accepted values are paths to JAR and paths to
directory of classes.
Example :
libraries=path/to/junit.jar,path/to/other.jar,path/to/classes

"path/to/classes" is a directory that contains .class files, not
JARs.

On 16 September 2011 10:24, Simon Brandhof  wrote:
The comment says "path" but the example data shows a jar listing.
I'll actually be able to specify a comma-delimited set of paths tho,
right?

Exact

**********************************************************

Privileged and/or confidential information may be contained in this
message. If you are not the addressee indicated in this message (or
are not responsible for delivery of this message to that person) , you
may not copy or deliver this message to anyone. In such case, you
should destroy this message and notify the sender by reply e-mail.

If you or your employer do not consent to Internet e-mail for
messages of this kind, please advise the sender.

Shaw Industries does not provide or endorse any opinions, conclusions
or other information in this message that do not relate to the
official business of the company or its subsidiaries.

**********************************************************

-------------------------
This message w/attachments (message) is intended solely for the use
of the intended recipient(s) and may contain information that is
privileged, confidential or proprietary. If you are not an intended
recipient, please notify the sender, and then please delete and
destroy all copies and attachments, and be advised that any review or
dissemination of, or the taking of any action in reliance on, the
information contained in or attached to this message is prohibited.
Unless specifically indicated, this message is not an offer to sell
or a solicitation of any investment products or other financial
product or service, an official confirmation of any transaction, or an
official statement of Sender. Subject to applicable law, Sender may
intercept, monitor, review and retain e-communications (EC) traveling
through its networks/systems and may produce any such EC to
regulators, law enforcement, in litigation and as required by law.
The laws of the country of each sender/recipient may impact the
handling of EC, and EC may be archived, supervised and produced in
countries other than the country in which you are located. This
message cannot be guaranteed to be secure or free of errors or
viruses.

References to "Sender" are references to any subsidiary of Bank of
America Corporation. Securities and Insurance Products: * Are Not FDIC
Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank
Deposit * Are Not a Condition to Any Banking Service or Activity * Are
Not Insured by Any Federal Government Agency. Attachments that are
part of this EC may have additional important disclosures and
disclaimers, which you should read. This message is subject to terms
available at the following link:
http://www.bankofamerica.com/emaildisclaimer [15]. By messaging with
Sender you consent to the foregoing.


Links:
------
[1] mailto:dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
[2] http://wiki.hudson-ci.org/display/HUDSON/Build+Pipeline+Plugin
[3] http://www.SonarSource.org/
[4] http://www.SonarSource.com/
[5] mailto:freddy.mallet <at> sonarsource.com
[6] http://jira.codehaus.org/browse/SONARPLUGINS-1376
[7] http://www.SonarSource.org/
[8] http://www.SonarSource.com/
[9] mailto:ann.campbell <at> shawinc.com
[10] mailto:ann.campbell <at> shawinc.com
[11] http://webmailer.hosteurope.de/tel:706.275.3857
[12] mailto:simon.brandhof <at> sonarsource.com
[13] mailto:dev-4ptiAEWXIyqxIXFVlbCvtR2eb7JE58TQ@public.gmane.org
[14] mailto:simon.brandhof <at> sonarsource.com
[15] http://www.bankofamerica.com/emaildisclaimer



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

  http://xircles.codehaus.org/manage_email




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

  http://xircles.codehaus.org/manage_email







--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_

Racodon, David | 2 Oct 19:47 2011
Picon

[Complexity Widget] Space missing

Hi,

 

On the Complexity widget, when using Time changes…, a space is missing before the parentheses displaying the changes.

It’s well displayed for Total but not for complexity/method, complexity/class and complexity/file.

 

Could you please add this space for readability reason?

 

Thank you very much

 

Regards,

 

David Racodon | Logica | Software Quality Center Team Leader

 


Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Evgeny Mandrikov | 2 Oct 20:57 2011
Picon

Re: [Complexity Widget] Space missing

Hi,


I've created ticket - http://jira.codehaus.org/browse/SONAR-2850

On Sun, Oct 2, 2011 at 21:47, Racodon, David <david.racodon-AhJhbHGVnpvQT0dZR+AlfA@public.gmane.org> wrote:

Hi,

 

On the Complexity widget, when using Time changes…, a space is missing before the parentheses displaying the changes.

It’s well displayed for Total but not for complexity/method, complexity/class and complexity/file.

 

Could you please add this space for readability reason?

 

Thank you very much

 

Regards,

 

David Racodon | Logica | Software Quality Center Team Leader

 


Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.



--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_
Freddy Mallet | 2 Oct 22:03 2011
Picon

Re: Migrating Derby Database in Oracle 11

Hello,


First of all, please do not send your emails to both the Sonar user and dev mailing lists as this is the best way to not get any answer.

Currently, I'm migrating out of the Sonar Derby Database and trying to migration all of my legacy data into Oracle 11.
Do your team have any documentation for type of migration?

Do you really have lot of data to migrate ? Indeed, it could be far easier to use the "sonar.projectDate" property in order to rebuild the history on each project. On my side, I don't know any solution to migrate Sonar data from a Derby DB to an Oracle one. 
 
Other Questions:
   
1. What is the required database configuration? Such as the database size, required memory, and other internal parameters to ensure proper configuration

About the DB size, for two years of activity and for each 1'000 LOC, around 600 Ko are required. So for instance, that means that for 6M LOC, 3.6 Go of disk space are required.

For all other parameters this is really up to your DB administrator.

 
2. What user(s) should be created in the database?

Only one user by Sonar instance and this is up to you to define the name of this user
 
3. How does SONAR talk/connect to Oracle database? Hence; what kind of information would be needed for SONAR to talk to Oracle?

Oracle JDBC thin client
 
 4. How do we get legacy data from the Gold environment?
 5.   What is a good configuration if I have 5 Sonar instances running on 5 different server to connect to 1 Oracle database? 
       5. a.  Would I be able to have 1 single location to view all of the reports from these 5 instances?   

No this is not possible, you should merge all your Sonar instances to work with only one.


Kind regards,
Freddy 

Thanks,

-Spencer


--

Thanks and Regards,

S. Richard Spencer

You cannot manage what you cannot control.
You cannot control what you cannot measure.
You cannot measure what you cannot define.


Freddy Mallet | 2 Oct 22:23 2011

Re: two odd things

Hello Ann,


If my understanding is correct you're currently facing bug http://jira.codehaus.org/browse/SONAR-2812 which has been fixed in Sonar 2.11.

Indeed the violation message of this Findbugs rule contains the line number. That means that if you slightly move the violation line, the message is also changed. Our algorithm to match old violations with new ones where not able to correctly handle such case prior to Sonar 2.11.

Kind regards,
Freddy

On Fri, Sep 30, 2011 at 4:19 PM, <ann.campbell-K67OQRCp/lRBDgjK7y7TUQ@public.gmane.org> wrote:
1) the file has not been renamed
2) the profile has been modified: I removed two rules - they were duplicates. (Findbugs vs PMD&Checkstyle.)


Ann Campbell
Engineer-Systems-IS Prod Sys-Shop Floor Sys
Shaw Industries Inc.
201 South Hamilton Street
Dalton, GA 30720
Email: ann.campbell-K67OQRCp/lRBDgjK7y7TUQ@public.gmane.org  Office: 706.275.3857

Please consider the environment before printing.



Date:        09/30/2011 10:14 AM
Subject:        Re: [sonar-user] two odd things



Hi Ann,

About the first issue, I know exactly what happens :

In the java bytecode there is absolutely no way to know what's the first line of a method declaration. The only available information is the line of the first statement in this method. That's why when Findbugs wants to report a violation on a method signature, this violation is in fact reported on the first statement in the method. 

About the second issue, do you confirm that :
  • The file hasn't been renamed recently
  • The quality profile hasn't been modified recently 

Kind regards,
Freddy

----------------------------------------
Freddy Mallet
www.SonarSource.org
twitter.com/FreddyMallet
----------------------------------------



On Fri, Sep 30, 2011 at 12:10 AM, Freddy Mallet <freddy.mallet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi Ann,

We must understand the first issue before taking care of the second one (because if the first issue happens only from time to time, this can lead to the second issue).

Could you send the file findbugs-result.xml located in the target/sonar directory of your project ?

Thanks
Freddy


----------------------------------------
Freddy Mallet
www.SonarSource.org
twitter.com/FreddyMallet
----------------------------------------



On Tue, Sep 27, 2011 at 2:56 PM, <ann.campbell-K67OQRCp/lRBDgjK7y7TUQ@public.gmane.org> wrote:
This screenshot illustrates two oddities.

One of them we've talked about before: the not-quite-right line is flagged with the error.

The other thing I've noticed twice in the last two days:
I asked for bugs added since prev. analysis, and it shows me something that CVS says has been there for quite a while (12 Aug 2011)
How does that happen? Why would it skip the error for so long and then find it? Or did it get flushed somehow & re-found? I did a find on the page for any line modified in Sept. & came up blank.




I'm running Sonar 2.10 & the update center says all my plugins are up to date.

In addition to the system plugins, I'm running these:
Branding 0.2
C# Core 1.0
C# FxCop 1.0
C# Gallio 1.0
C# Gendarme 1.0
C# Squid 1.0
C# StyleCop 1.0
JavaScript 0.3
LDAP 1.0
Quality Index 1.1.3
SCM Activity 1.3
SIG Maintainability Model 1.0.1
Sonar Cutoff Plugin 0.1
Switch Off Violations 1.0
Taglist 1.0
Technical Debt 1.2.1
Useless Code Tracker 0.4
Web 1.1
Xml 0.1  

Ann Campbell
Engineer-Systems-IS Prod Sys-Shop Floor Sys
Shaw Industries Inc.
201 South Hamilton Street
Dalton, GA 30720
Email: ann.campbell <at> shawinc.com  Office: 706.275.3857

Please consider the environment before printing.
**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company  or its subsidiaries.
**********************************************************



********************************************************** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. **********************************************************

Freddy Mallet | 2 Oct 22:35 2011

Re: Multi-module project analysis

Hi Andrew,


Unhappily, I don't have any solution to suggest except of manually modifying the artifactid/groupid of all past versions before launching the Sonar analysis.

Kind regards,
Freddy


On Fri, Sep 30, 2011 at 2:24 PM, Логвинов Андрей <monkegoist-o+MxOtu4lMCHXe+LvDLADg@public.gmane.org> wrote:
Hello,

I need to perform analysis of project's previous versions. In order for them to be displayed correctly, I use -Dsonar.projectDate option which is populated based on the date the tag was added to SVN.

I have come across the problem which was already mentioned here: http://old.nabble.com/Submodule-analysis-causes-errors-in-sonar-GUI-td31920924.html. Back in the days, the project I'm analyzing contained only 1 module - the main one. I was able to successfully get all the data for those versions.

One wonderful day, project's structure was reorganized and another module was added. Now there is one main module and 2 sub-modules (one of them used to be the main module).

Right now, the following thing happens. If I analyze some version of the project with new structure, it is added and displayed in "Events" section of the "Dashboard" and I can select it in the time machine. But, I can no longer select any of the previous versions (when project had 1-module structure). I get error message (it is available via the above mentioned link, so I won't duplicate it here).

If I analyze some version of the project with old structure, it also breaks the time machine. Now I can select this version and all the rest when the project had old structure, but I cannot select any of the versions of the new structure project.

Can you suggest me something to deal with this problem?

2 notes:
1) It's the simpliest project that I started with. I have several other projects that contain up to 50 modules each and I need to analyze them too.
2) Again, this is the simpliest project, so there are only 90 versions that I need to analyze :)

Thanks for your assistance!

Best regards,
Andrew

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

   http://xircles.codehaus.org/manage_email



Andrew Logvinov | 2 Oct 22:51 2011
Picon

Re: Multi-module project analysis

Hi Freddy,
 
Thanks for your reply. Well, since I'm doing all the analysis using bash script, this option is also valid.
 
My current project settings:
- main module - group_name:artifact1:pom
- submodule1 - group_name:artifact2:war
- submodule2 - group_name:artifact3:pom 
 
Former project settings:
- main module - group_name:artifact2:war 
 
Can you please specify what exactly do I need to modify before the analysis?
 
N.B. I also thought that this might had something to do with rootProjectId database field but I had no time to check this on Friday.
 
Thank you in advance,
Andrew.
03.10.2011, 00:35, "Freddy Mallet" <freddy.mallet <at> sonarsource.com>:
Hi Andrew,
Unhappily, I don't have any solution to suggest except of manually modifying the artifactid/groupid of all past versions before launching the Sonar analysis.
Kind regards,
Freddy

On Fri, Sep 30, 2011 at 2:24 PM, Логвинов Андрей <monkegoist <at> yandex.ru> wrote:
Hello,

I need to perform analysis of project's previous versions. In order for them to be displayed correctly, I use -Dsonar.projectDate option which is populated based on the date the tag was added to SVN.

I have come across the problem which was already mentioned here: http://old.nabble.com/Submodule-analysis-causes-errors-in-sonar-GUI-td31920924.html. Back in the days, the project I'm analyzing contained only 1 module - the main one. I was able to successfully get all the data for those versions.

One wonderful day, project's structure was reorganized and another module was added. Now there is one main module and 2 sub-modules (one of them used to be the main module).

Right now, the following thing happens. If I analyze some version of the project with new structure, it is added and displayed in "Events" section of the "Dashboard" and I can select it in the time machine. But, I can no longer select any of the previous versions (when project had 1-module structure). I get error message (it is available via the above mentioned link, so I won't duplicate it here).

If I analyze some version of the project with old structure, it also breaks the time machine. Now I can select this version and all the rest when the project had old structure, but I cannot select any of the versions of the new structure project.

Can you suggest me something to deal with this problem?

2 notes:
1) It's the simpliest project that I started with. I have several other projects that contain up to 50 modules each and I need to analyze them too.
2) Again, this is the simpliest project, so there are only 90 versions that I need to analyze :)

Thanks for your assistance!

Best regards,
Andrew
Freddy Mallet | 2 Oct 22:53 2011

Re: Coverage not calculated for multiple source directories

Hi Aditya,


You're right there is the bug with the Sonar Ant task : http://jira.codehaus.org/browse/SONARPLUGINS-1397.

The temporary workaround is to use the deprecated "sources" property :

    <sonar:sonar workDir="${build.dir}/sonar-work" key="org.sonar.ant.tests:custom-layout" version="0.1-SNAPSHOT"/>
      <sources>
        <path location="src1"/>
        <path location="src2"/>
      </sources>
    </sonar:sonar>

Kind regards,
Freddy


On Thu, Sep 29, 2011 at 11:42 AM, Aditya S <s.aditya-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi,

I'm new to sonar. My task at work is to import our existing legacy code-base to sonar. I have written Ant scripts to capture emma code coverage for every project. However, certain projects have multiple source directories. I have set the source directories as a comma separated string in the "sonar.sources" property in the Ant script as suggested here.

On executing the Sonar ant task, I'm getting the surefire reports and emma coverage data (.ec files). The sources are also imported to sonar as I can browse them through the dashboard. However, the components page on the sonar dashboard is displaying coverage data only for the first source directory listed in the sonar.sources property. Consequently, the data shown in the coverage widget is also only for the first source directory. Generating reports from the *.ec files and the *.em files gives the proper data.

I have also tried other ways (like using <sources></sources> within the sonar ant task call) as suggested elsewhere in the mailing list archive, to no avail. Please point me in the right direction on how to use multiple source directories and calculating coverage.  

Thanks,
Aditya


Gmane