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

[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

[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

-----

twitter.com/FreddyMallet

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

[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

-----

twitter.com/FreddyMallet

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

[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. 

-----

twitter.com/FreddyMallet

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

-----

twitter.com/FreddyMallet

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

[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. 

-----

twitter.com/FreddyMallet

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

-----

twitter.com/FreddyMallet

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

[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.

[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

[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

[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

[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

[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

[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

[Jorge Costa]

Ok,
Ive now voted for this, thanks for taking a look.