Quantcast

Two reasons for NonUniqueResultException

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Two reasons for NonUniqueResultException

Daniel Jeliński
Hello,
I just found two ways to cause NonUniqueResultException. It happens
when two projects with the same key are analyzed simultaneously. In C#
it is easy to achieve:
1) if you set your project key as [1] suggests and any project in the
solution has the same name as <artifactId>, you will get the exception
during every analysis but the first.
2) also if you set your project key as [1] suggests and several
solutions contain projects with the same name and these solutions are
analyzed simultaneously, you will get the exception.

The simple solution to both of these problems is to use different
naming convention. Using a project key in the form of [project]:sln
(<groupId>[project]</groupId>  <artifactId>sln</artifactId>) should be
safe. However, it would be better if Sonar handled these situations
correctly, for example by assigning project keys for subprojects and
project files in a different manner.

Regards,
Daniel

[1]: http://docs.codehaus.org/display/SONAR/Analyse+with+Maven

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Fabrice Bellingard-4
Hi Daniel,

thanks for your feedback.

Indeed, we know this possible issue with keys, and it's true that most of the time, we never have this problem in the Java world as almost every multi-module project has a unique groupId. However, I see this problem in the C# and PHP worlds, so we'll definitely have to do something with this.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com



On Sat, Dec 10, 2011 at 09:00, Daniel Jelinski <[hidden email]> wrote:
Hello,
I just found two ways to cause NonUniqueResultException. It happens
when two projects with the same key are analyzed simultaneously. In C#
it is easy to achieve:
1) if you set your project key as [1] suggests and any project in the
solution has the same name as <artifactId>, you will get the exception
during every analysis but the first.
2) also if you set your project key as [1] suggests and several
solutions contain projects with the same name and these solutions are
analyzed simultaneously, you will get the exception.

The simple solution to both of these problems is to use different
naming convention. Using a project key in the form of [project]:sln
(<groupId>[project]</groupId>  <artifactId>sln</artifactId>) should be
safe. However, it would be better if Sonar handled these situations
correctly, for example by assigning project keys for subprojects and
project files in a different manner.

Regards,
Daniel

[1]: http://docs.codehaus.org/display/SONAR/Analyse+with+Maven

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Freddy Mallet
Hi Fabrice,

In fact if my understanding is correct there are potentially two issues :
  • Project naming conflict between two different solutions. Which means that we must define a kind of namespace by solution. Why not for instance re-using the artifactId of the solution to build the kees of project in this solution ?
  • Potential naming conflict between the solution and one of its project. I guess the previous proposal should also cover this case.
cheers
-----
Sonar for Continuous Inspection



On Tue, Dec 13, 2011 at 3:53 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Daniel,

thanks for your feedback.

Indeed, we know this possible issue with keys, and it's true that most of the time, we never have this problem in the Java world as almost every multi-module project has a unique groupId. However, I see this problem in the C# and PHP worlds, so we'll definitely have to do something with this.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com



On Sat, Dec 10, 2011 at 09:00, Daniel Jelinski <[hidden email]> wrote:
Hello,
I just found two ways to cause NonUniqueResultException. It happens
when two projects with the same key are analyzed simultaneously. In C#
it is easy to achieve:
1) if you set your project key as [1] suggests and any project in the
solution has the same name as <artifactId>, you will get the exception
during every analysis but the first.
2) also if you set your project key as [1] suggests and several
solutions contain projects with the same name and these solutions are
analyzed simultaneously, you will get the exception.

The simple solution to both of these problems is to use different
naming convention. Using a project key in the form of [project]:sln
(<groupId>[project]</groupId>  <artifactId>sln</artifactId>) should be
safe. However, it would be better if Sonar handled these situations
correctly, for example by assigning project keys for subprojects and
project files in a different manner.

Regards,
Daniel

[1]: http://docs.codehaus.org/display/SONAR/Analyse+with+Maven

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

   http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Fabrice Bellingard-4
On Tue, Dec 13, 2011 at 22:33, Freddy Mallet <[hidden email]> wrote:
Hi Fabrice,

In fact if my understanding is correct there are potentially two issues :
  • Project naming conflict between two different solutions. Which means that we must define a kind of namespace by solution. Why not for instance re-using the artifactId of the solution to build the kees of project in this solution ?
  • Potential naming conflict between the solution and one of its project. I guess the previous proposal should also cover this case.

Yep Freddy, that's definitely the solution I was thinking of.


 
cheers
-----
Sonar for Continuous Inspection



On Tue, Dec 13, 2011 at 3:53 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Daniel,

thanks for your feedback.

Indeed, we know this possible issue with keys, and it's true that most of the time, we never have this problem in the Java world as almost every multi-module project has a unique groupId. However, I see this problem in the C# and PHP worlds, so we'll definitely have to do something with this.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com



On Sat, Dec 10, 2011 at 09:00, Daniel Jelinski <[hidden email]> wrote:
Hello,
I just found two ways to cause NonUniqueResultException. It happens
when two projects with the same key are analyzed simultaneously. In C#
it is easy to achieve:
1) if you set your project key as [1] suggests and any project in the
solution has the same name as <artifactId>, you will get the exception
during every analysis but the first.
2) also if you set your project key as [1] suggests and several
solutions contain projects with the same name and these solutions are
analyzed simultaneously, you will get the exception.

The simple solution to both of these problems is to use different
naming convention. Using a project key in the form of [project]:sln
(<groupId>[project]</groupId>  <artifactId>sln</artifactId>) should be
safe. However, it would be better if Sonar handled these situations
correctly, for example by assigning project keys for subprojects and
project files in a different manner.

Regards,
Daniel

[1]: http://docs.codehaus.org/display/SONAR/Analyse+with+Maven

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

   http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Freddy Mallet
Cool Fabrice, so I guess we should create some JIRA tickets to try to fix (or at least improve) this issue on next versions of those two PHP and C# plugins. 

-----
Sonar for Continuous Inspection



On Wed, Dec 14, 2011 at 8:44 AM, Fabrice Bellingard <[hidden email]> wrote:
On Tue, Dec 13, 2011 at 22:33, Freddy Mallet <[hidden email]> wrote:
Hi Fabrice,

In fact if my understanding is correct there are potentially two issues :
  • Project naming conflict between two different solutions. Which means that we must define a kind of namespace by solution. Why not for instance re-using the artifactId of the solution to build the kees of project in this solution ?
  • Potential naming conflict between the solution and one of its project. I guess the previous proposal should also cover this case.

Yep Freddy, that's definitely the solution I was thinking of.


 
cheers
-----
Sonar for Continuous Inspection



On Tue, Dec 13, 2011 at 3:53 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Daniel,

thanks for your feedback.

Indeed, we know this possible issue with keys, and it's true that most of the time, we never have this problem in the Java world as almost every multi-module project has a unique groupId. However, I see this problem in the C# and PHP worlds, so we'll definitely have to do something with this.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com



On Sat, Dec 10, 2011 at 09:00, Daniel Jelinski <[hidden email]> wrote:
Hello,
I just found two ways to cause NonUniqueResultException. It happens
when two projects with the same key are analyzed simultaneously. In C#
it is easy to achieve:
1) if you set your project key as [1] suggests and any project in the
solution has the same name as <artifactId>, you will get the exception
during every analysis but the first.
2) also if you set your project key as [1] suggests and several
solutions contain projects with the same name and these solutions are
analyzed simultaneously, you will get the exception.

The simple solution to both of these problems is to use different
naming convention. Using a project key in the form of [project]:sln
(<groupId>[project]</groupId>  <artifactId>sln</artifactId>) should be
safe. However, it would be better if Sonar handled these situations
correctly, for example by assigning project keys for subprojects and
project files in a different manner.

Regards,
Daniel

[1]: http://docs.codehaus.org/display/SONAR/Analyse+with+Maven

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

   http://xircles.codehaus.org/manage_email






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Fabrice Bellingard-4
Yep Freddy, I've created http://jira.codehaus.org/browse/SONARPLUGINS-1566 for C# Plugins.

For PHP, multi-module is not supported yet, so no issue to create for the moment.

Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com



On Wed, Dec 14, 2011 at 11:11, Freddy Mallet <[hidden email]> wrote:
Cool Fabrice, so I guess we should create some JIRA tickets to try to fix (or at least improve) this issue on next versions of those two PHP and C# plugins. 

-----
Sonar for Continuous Inspection



On Wed, Dec 14, 2011 at 8:44 AM, Fabrice Bellingard <[hidden email]> wrote:
On Tue, Dec 13, 2011 at 22:33, Freddy Mallet <[hidden email]> wrote:
Hi Fabrice,

In fact if my understanding is correct there are potentially two issues :
  • Project naming conflict between two different solutions. Which means that we must define a kind of namespace by solution. Why not for instance re-using the artifactId of the solution to build the kees of project in this solution ?
  • Potential naming conflict between the solution and one of its project. I guess the previous proposal should also cover this case.

Yep Freddy, that's definitely the solution I was thinking of.


 
cheers
-----
Sonar for Continuous Inspection



On Tue, Dec 13, 2011 at 3:53 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Daniel,

thanks for your feedback.

Indeed, we know this possible issue with keys, and it's true that most of the time, we never have this problem in the Java world as almost every multi-module project has a unique groupId. However, I see this problem in the C# and PHP worlds, so we'll definitely have to do something with this.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com



On Sat, Dec 10, 2011 at 09:00, Daniel Jelinski <[hidden email]> wrote:
Hello,
I just found two ways to cause NonUniqueResultException. It happens
when two projects with the same key are analyzed simultaneously. In C#
it is easy to achieve:
1) if you set your project key as [1] suggests and any project in the
solution has the same name as <artifactId>, you will get the exception
during every analysis but the first.
2) also if you set your project key as [1] suggests and several
solutions contain projects with the same name and these solutions are
analyzed simultaneously, you will get the exception.

The simple solution to both of these problems is to use different
naming convention. Using a project key in the form of [project]:sln
(<groupId>[project]</groupId>  <artifactId>sln</artifactId>) should be
safe. However, it would be better if Sonar handled these situations
correctly, for example by assigning project keys for subprojects and
project files in a different manner.

Regards,
Daniel

[1]: http://docs.codehaus.org/display/SONAR/Analyse+with+Maven

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

   http://xircles.codehaus.org/manage_email







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Jorge Costa
Hi Fabrice,

sonar.dotnet.key.generation.strateg=safe brakes the skipmodules property in Sonar. If setting it to false the skipmodules are not considered.

Can you double check this problem to see if you have same behaviour. Sonar 3.5 and latest C# release.



Best Regards
Jorge Costa
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Fabrice Bellingard-4
Hi Jorge,

this should normally work, even if indeed the "safe" mode changes a bit what you must put in the "sonar.skippedModules" property.

Let's say the Sonar key of your solution is "org.mycompany:mySolution", and it has a project called "myProject".
  • In "normal" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myProject" to skip the module
  • In "safe" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:mySolution:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myCompany:myProject" to skip the module
Does that work?



Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 2:45 PM, Jorge Costa <[hidden email]> wrote:
Hi Fabrice,

sonar.dotnet.key.generation.strateg=safe brakes the skipmodules property in
Sonar. If setting it to false the skipmodules are not considered.

Can you double check this problem to see if you have same behaviour. Sonar
3.5 and latest C# release.







-----
Best Regards
Jorge Costa
--
View this message in context: http://sonar.15.x6.nabble.com/Two-reasons-for-NonUniqueResultException-tp3193118p5012235.html
Sent from the Sonar user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Jorge Costa
Hum,

So in my pom.xml:
<sonar.skippedModules>
tekla.ext_dot_apps:Concrete.Rebars,
tekla.ext_dot_apps:Model.Common
</sonar.skippedModules>

And with strategy=false i have:
....
[DEBUG] [16:57:55.344]   - Adding Sub Project => SetRebarAttributes
[INFO] [16:57:55.344] Apply project exclusions
[WARN] [16:57:55.360] H2 database should be used for evaluation purpose only
[INFO] [16:57:55.361] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [16:57:55.431] Testing JDBC connection
[INFO] [16:57:55.438] Initializing Hibernate

With strategy not set and pom:

<sonar.skippedModules>
Concrete.Rebars,
Model.Common
</sonar.skippedModules>

I have the modules correctly excluded.
....
[DEBUG] [17:00:21.112]   - Adding Sub Project => SetRebarAttributes
[INFO] [17:00:21.112] Apply project exclusions
[INFO] [17:00:21.124] Exclude project: Concrete.Rebars [tekla.ext_dot_apps:Concrete.Rebars]
[INFO] [17:00:21.124] Exclude project: Model.Common [tekla.ext_dot_apps:Model.Common]
[WARN] [17:00:21.129] H2 database should be used for evaluation purpose only
[INFO] [17:00:21.129] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [17:00:21.200] Testing JDBC connection

Not sure what's going on here. I tried initially without tekla.ext_dot_apps with same result 






On Tue, May 7, 2013 at 4:43 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Jorge,

this should normally work, even if indeed the "safe" mode changes a bit what you must put in the "sonar.skippedModules" property.

Let's say the Sonar key of your solution is "org.mycompany:mySolution", and it has a project called "myProject".
  • In "normal" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myProject" to skip the module
  • In "safe" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:mySolution:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myCompany:myProject" to skip the module
Does that work?



Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 2:45 PM, Jorge Costa <[hidden email]> wrote:
Hi Fabrice,

sonar.dotnet.key.generation.strateg=safe brakes the skipmodules property in
Sonar. If setting it to false the skipmodules are not considered.

Can you double check this problem to see if you have same behaviour. Sonar
3.5 and latest C# release.







-----
Best Regards
Jorge Costa
--
View this message in context: http://sonar.15.x6.nabble.com/Two-reasons-for-NonUniqueResultException-tp3193118p5012235.html
Sent from the Sonar user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email




Best Regards
Jorge Costa
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Fabrice Bellingard-4
I don't get something: why are you talking about "strategy=false"? As you can see on http://docs.codehaus.org/display/SONAR/sonar-dotnet-plugin, the strategy can be set to "safe" or unset, but "false" is not an option.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 4:03 PM, Jorge Costa <[hidden email]> wrote:
Hum,

So in my pom.xml:
<sonar.skippedModules>
tekla.ext_dot_apps:Concrete.Rebars,
tekla.ext_dot_apps:Model.Common
</sonar.skippedModules>

And with strategy=false i have:
....
[DEBUG] [16:57:55.344]   - Adding Sub Project => SetRebarAttributes
[INFO] [16:57:55.344] Apply project exclusions
[WARN] [16:57:55.360] H2 database should be used for evaluation purpose only
[INFO] [16:57:55.361] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [16:57:55.431] Testing JDBC connection
[INFO] [16:57:55.438] Initializing Hibernate

With strategy not set and pom:

<sonar.skippedModules>
Concrete.Rebars,
Model.Common
</sonar.skippedModules>

I have the modules correctly excluded.
....
[DEBUG] [17:00:21.112]   - Adding Sub Project => SetRebarAttributes
[INFO] [17:00:21.112] Apply project exclusions
[INFO] [17:00:21.124] Exclude project: Concrete.Rebars [tekla.ext_dot_apps:Concrete.Rebars]
[INFO] [17:00:21.124] Exclude project: Model.Common [tekla.ext_dot_apps:Model.Common]
[WARN] [17:00:21.129] H2 database should be used for evaluation purpose only
[INFO] [17:00:21.129] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [17:00:21.200] Testing JDBC connection

Not sure what's going on here. I tried initially without tekla.ext_dot_apps with same result 






On Tue, May 7, 2013 at 4:43 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Jorge,

this should normally work, even if indeed the "safe" mode changes a bit what you must put in the "sonar.skippedModules" property.

Let's say the Sonar key of your solution is "org.mycompany:mySolution", and it has a project called "myProject".
  • In "normal" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myProject" to skip the module
  • In "safe" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:mySolution:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myCompany:myProject" to skip the module
Does that work?



Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 2:45 PM, Jorge Costa <[hidden email]> wrote:
Hi Fabrice,

sonar.dotnet.key.generation.strateg=safe brakes the skipmodules property in
Sonar. If setting it to false the skipmodules are not considered.

Can you double check this problem to see if you have same behaviour. Sonar
3.5 and latest C# release.







-----
Best Regards
Jorge Costa
--
View this message in context: http://sonar.15.x6.nabble.com/Two-reasons-for-NonUniqueResultException-tp3193118p5012235.html
Sent from the Sonar user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Jorge Costa

Need to check again, but I think of course I meant safe.

On May 7, 2013 5:36 PM, "Fabrice Bellingard" <[hidden email]> wrote:
I don't get something: why are you talking about "strategy=false"? As you can see on http://docs.codehaus.org/display/SONAR/sonar-dotnet-plugin, the strategy can be set to "safe" or unset, but "false" is not an option.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 4:03 PM, Jorge Costa <[hidden email]> wrote:
Hum,

So in my pom.xml:
<sonar.skippedModules>
tekla.ext_dot_apps:Concrete.Rebars,
tekla.ext_dot_apps:Model.Common
</sonar.skippedModules>

And with strategy=false i have:
....
[DEBUG] [16:57:55.344]   - Adding Sub Project => SetRebarAttributes
[INFO] [16:57:55.344] Apply project exclusions
[WARN] [16:57:55.360] H2 database should be used for evaluation purpose only
[INFO] [16:57:55.361] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [16:57:55.431] Testing JDBC connection
[INFO] [16:57:55.438] Initializing Hibernate

With strategy not set and pom:

<sonar.skippedModules>
Concrete.Rebars,
Model.Common
</sonar.skippedModules>

I have the modules correctly excluded.
....
[DEBUG] [17:00:21.112]   - Adding Sub Project => SetRebarAttributes
[INFO] [17:00:21.112] Apply project exclusions
[INFO] [17:00:21.124] Exclude project: Concrete.Rebars [tekla.ext_dot_apps:Concrete.Rebars]
[INFO] [17:00:21.124] Exclude project: Model.Common [tekla.ext_dot_apps:Model.Common]
[WARN] [17:00:21.129] H2 database should be used for evaluation purpose only
[INFO] [17:00:21.129] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [17:00:21.200] Testing JDBC connection

Not sure what's going on here. I tried initially without tekla.ext_dot_apps with same result 






On Tue, May 7, 2013 at 4:43 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Jorge,

this should normally work, even if indeed the "safe" mode changes a bit what you must put in the "sonar.skippedModules" property.

Let's say the Sonar key of your solution is "org.mycompany:mySolution", and it has a project called "myProject".
  • In "normal" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myProject" to skip the module
  • In "safe" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:mySolution:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myCompany:myProject" to skip the module
Does that work?



Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 2:45 PM, Jorge Costa <[hidden email]> wrote:
Hi Fabrice,

sonar.dotnet.key.generation.strateg=safe brakes the skipmodules property in
Sonar. If setting it to false the skipmodules are not considered.

Can you double check this problem to see if you have same behaviour. Sonar
3.5 and latest C# release.







-----
Best Regards
Jorge Costa
--
View this message in context: http://sonar.15.x6.nabble.com/Two-reasons-for-NonUniqueResultException-tp3193118p5012235.html
Sent from the Sonar user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email





Best Regards
Jorge Costa
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Jorge Costa
yep, safe all the way.


On Tue, May 7, 2013 at 5:47 PM, Jorge Costa <[hidden email]> wrote:

Need to check again, but I think of course I meant safe.

On May 7, 2013 5:36 PM, "Fabrice Bellingard" <[hidden email]> wrote:
I don't get something: why are you talking about "strategy=false"? As you can see on http://docs.codehaus.org/display/SONAR/sonar-dotnet-plugin, the strategy can be set to "safe" or unset, but "false" is not an option.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 4:03 PM, Jorge Costa <[hidden email]> wrote:
Hum,

So in my pom.xml:
<sonar.skippedModules>
tekla.ext_dot_apps:Concrete.Rebars,
tekla.ext_dot_apps:Model.Common
</sonar.skippedModules>

And with strategy=false i have:
....
[DEBUG] [16:57:55.344]   - Adding Sub Project => SetRebarAttributes
[INFO] [16:57:55.344] Apply project exclusions
[WARN] [16:57:55.360] H2 database should be used for evaluation purpose only
[INFO] [16:57:55.361] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [16:57:55.431] Testing JDBC connection
[INFO] [16:57:55.438] Initializing Hibernate

With strategy not set and pom:

<sonar.skippedModules>
Concrete.Rebars,
Model.Common
</sonar.skippedModules>

I have the modules correctly excluded.
....
[DEBUG] [17:00:21.112]   - Adding Sub Project => SetRebarAttributes
[INFO] [17:00:21.112] Apply project exclusions
[INFO] [17:00:21.124] Exclude project: Concrete.Rebars [tekla.ext_dot_apps:Concrete.Rebars]
[INFO] [17:00:21.124] Exclude project: Model.Common [tekla.ext_dot_apps:Model.Common]
[WARN] [17:00:21.129] H2 database should be used for evaluation purpose only
[INFO] [17:00:21.129] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [17:00:21.200] Testing JDBC connection

Not sure what's going on here. I tried initially without tekla.ext_dot_apps with same result 






On Tue, May 7, 2013 at 4:43 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Jorge,

this should normally work, even if indeed the "safe" mode changes a bit what you must put in the "sonar.skippedModules" property.

Let's say the Sonar key of your solution is "org.mycompany:mySolution", and it has a project called "myProject".
  • In "normal" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myProject" to skip the module
  • In "safe" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:mySolution:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myCompany:myProject" to skip the module
Does that work?



Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 2:45 PM, Jorge Costa <[hidden email]> wrote:
Hi Fabrice,

sonar.dotnet.key.generation.strateg=safe brakes the skipmodules property in
Sonar. If setting it to false the skipmodules are not considered.

Can you double check this problem to see if you have same behaviour. Sonar
3.5 and latest C# release.







-----
Best Regards
Jorge Costa
--
View this message in context: http://sonar.15.x6.nabble.com/Two-reasons-for-NonUniqueResultException-tp3193118p5012235.html
Sent from the Sonar user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email






Best Regards
Jorge Costa
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Fabrice Bellingard-4
OK, so we'll have to investigate (see http://jira.codehaus.org/browse/SONARDOTNT-10).


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 5:51 PM, Jorge Costa <[hidden email]> wrote:
yep, safe all the way.


On Tue, May 7, 2013 at 5:47 PM, Jorge Costa <[hidden email]> wrote:

Need to check again, but I think of course I meant safe.

On May 7, 2013 5:36 PM, "Fabrice Bellingard" <[hidden email]> wrote:
I don't get something: why are you talking about "strategy=false"? As you can see on http://docs.codehaus.org/display/SONAR/sonar-dotnet-plugin, the strategy can be set to "safe" or unset, but "false" is not an option.


Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 4:03 PM, Jorge Costa <[hidden email]> wrote:
Hum,

So in my pom.xml:
<sonar.skippedModules>
tekla.ext_dot_apps:Concrete.Rebars,
tekla.ext_dot_apps:Model.Common
</sonar.skippedModules>

And with strategy=false i have:
....
[DEBUG] [16:57:55.344]   - Adding Sub Project => SetRebarAttributes
[INFO] [16:57:55.344] Apply project exclusions
[WARN] [16:57:55.360] H2 database should be used for evaluation purpose only
[INFO] [16:57:55.361] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [16:57:55.431] Testing JDBC connection
[INFO] [16:57:55.438] Initializing Hibernate

With strategy not set and pom:

<sonar.skippedModules>
Concrete.Rebars,
Model.Common
</sonar.skippedModules>

I have the modules correctly excluded.
....
[DEBUG] [17:00:21.112]   - Adding Sub Project => SetRebarAttributes
[INFO] [17:00:21.112] Apply project exclusions
[INFO] [17:00:21.124] Exclude project: Concrete.Rebars [tekla.ext_dot_apps:Concrete.Rebars]
[INFO] [17:00:21.124] Exclude project: Model.Common [tekla.ext_dot_apps:Model.Common]
[WARN] [17:00:21.129] H2 database should be used for evaluation purpose only
[INFO] [17:00:21.129] Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
[DEBUG] [17:00:21.200] Testing JDBC connection

Not sure what's going on here. I tried initially without tekla.ext_dot_apps with same result 






On Tue, May 7, 2013 at 4:43 PM, Fabrice Bellingard <[hidden email]> wrote:
Hi Jorge,

this should normally work, even if indeed the "safe" mode changes a bit what you must put in the "sonar.skippedModules" property.

Let's say the Sonar key of your solution is "org.mycompany:mySolution", and it has a project called "myProject".
  • In "normal" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myProject" to skip the module
  • In "safe" mode, you will see in Sonar your root project with "org.mycompany:mySolution" as a key and one module with "org.mycompany:mySolution:myProject" as a key
    • In this case, you must use "sonar.skippedModules=myCompany:myProject" to skip the module
Does that work?



Best regards,

Fabrice BELLINGARD | SonarSource
http://sonarsource.com


On Tue, May 7, 2013 at 2:45 PM, Jorge Costa <[hidden email]> wrote:
Hi Fabrice,

sonar.dotnet.key.generation.strateg=safe brakes the skipmodules property in
Sonar. If setting it to false the skipmodules are not considered.

Can you double check this problem to see if you have same behaviour. Sonar
3.5 and latest C# release.







-----
Best Regards
Jorge Costa
--
View this message in context: http://sonar.15.x6.nabble.com/Two-reasons-for-NonUniqueResultException-tp3193118p5012235.html
Sent from the Sonar user mailing list archive at Nabble.com.

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

    http://xircles.codehaus.org/manage_email







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Two reasons for NonUniqueResultException

Jorge Costa
Ok,
Ive now voted for this, thanks for taking a look.
Best Regards
Jorge Costa
Loading...