Allow adapting artifact and group id of projects

Here is the SQL request to execute in order to retrieve the rows that need to be updated :

select * from projects where key = "${groupId}:${artifactId}"

OK, thanks. Of course that query is really....

 
select * from projects where kee = "${groupId}:${artifactId}"

So, if I want to maintain the history of measures on packages, then I'll need to update those as well, I figure.

 
SELECT * FROM projects WHERE kee LIKE "${groupId}:${artifactId}:%"

The SQL update command in this Jira can be used as a workaround for this issue when the new project has yet to publish its data to Sonar. Is there a sequence of SQL commands that can be used as a workaround to this issue when the old and new projects already have their data published to Sonar?

I ask because I’m trying to consolidate the metrics from two projects that already have their data published to Sonar. I’ve run the SQL update command mentioned in this Jira and restarted the Sonar service, but the results aren’t what I expected; both projects still appear on the Sonar home page. Even worse, attempting to deploy Sonar metrics with the new project’s groupId and artifactId results in the following exception:
-----------------------------------------------------------------
[INFO] ------------- Analyzing kblaney
[INFO] Selected quality profile : [name=Sonar way with Findbugs,language=java]
[INFO] Configure maven plugins...
[INFO] Sensor JavaSourceImporter...
[WARN] NonUniqueResultException on entity ResourceModel with criterias : key,com.kblaney.b:kblaney:com.kblaney
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Can not execute Sonar

Embedded error: The resource 'com.kblaney.b:kblaney:com.kblaney' is duplicated in the Sonar DB.
-----------------------------------------------------------------

Here’s what I did to get this error:
1. Create a project with Maven group ID com.kblaney.a and Maven version 1.
2. Deploy project metrics to Sonar.
3. Change the project’s Maven group ID to com.kblaney.b and Maven version to 2.
4. Deploy project metrics to Sonar.
5. Stop the Sonar service, run the SQL update command, and restart the Sonar service.
6. Change the project’s Maven version to 3.
7. Deploy project metrics to Sonar.

Just been hit by this, and managed to lose recorded data. In a multi-module Maven project I renamed only aggregator/parent module, changed it's artifactId from "foo.bar:foo.bar.parent" to "foo.bar:foo.bar", and updated all the submodules parent reference. After rename, and fresh build, new project appeared in sonar, along with the old one. Then I found this ticket and related Oliver's blog entry and in effort to just keep old project in sonar and update it's definition in sonar db, I decided to deleted new project first. Problem is when deleting new sonar project, sonar deleted also all the recorded data for submodules - their kee didn't change, even though their parent did change. Massive fail.

When adding/updating/deleting Maven module in sonar, sonar should check

if module has a parent reference and there is sonar project keyed as referenced parent signature
    create/update/delete sonar project with kee as module signature, and rootId equal to found parent sonar project id
else
    create/update/delete sonar project with kee as module signature

If this was the case, sonar would treat submodules referencing parent with changed signature as new sonar projects just as it treated parent module as new project because its signature changed, and my recorded data would not have been lost. Separate ticket for this?

Hi Stevo, in fact your issue should be fixed with Sonar 2.8 and tickets SONAR-2311 and SONAR-2329.

The best solution for this would be to add a service in the settings of the project that would enable to change the key of the project / module. That way, you would keep historical data and future analysis of you projects all together to have a single history.

What about registering the migration information in pom.xml, just like in this POM manual section?

I think developing a sonar project merging plugin would be alternative.

A workaround can be found at http://jira.codehaus.org/browse/SONAR-2743. But I haven't tried it.

The work-around in ticket SONAR-2743 works for projects where we create the pom.xml for our Ant based projects just for running the Sonar analysis. The advantage of our Ant build is that we have a single artifactId for all Eclipse projects as we copy all sources and class files from the workspace into one folder for the analysis step.
A typical Maven project is more complex as there is one groupId and different artifactIds for each Maven project. Depending on the pattern of the Maven Module artifactIds it is possible to automate the renaming process.

Our idea was to use the Jenkins Job name as the branch name like this:

<sonar.branch>${env.JOB_NAME}</sonar.branch>

This makes sure that a new Jenkins Job for a different branch gets its own Sonar project. But with this change we had to update the Sonar projects.kee entry to make sure that analysis results get published to the already existing Sonar projects and no new projects are created.

The difficulty was to extend the projects.kee column by the <sonar.branch> name. For the case, described above, where there is only one artifactId, the solution from SONAR-2743 was used. For the Maven projects, having a pattern like "parent[-child0..N]":

• parent
• parent-child1
• parent-child2
  ...
• parent-childN

the following solution is used:

-- find entries with 1 colon
select
   CONCAT(
     SUBSTRING_INDEX(kee, ":", 1), 
     ":", 
     SUBSTRING_INDEX(kee, ":", -1), 
     ":prj1-", 
     IF(
       (LENGTH(kee) - LENGTH(REPLACE(kee, '-', ''))) >= 1, 
       SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -1), "-", 1), 
       SUBSTRING_INDEX(kee, ":", -1)
     ),
     "-trunk")
from projects where kee like "com.company.ams.prj1%" and (LENGTH(kee) - LENGTH(REPLACE(kee, ':', ''))) = 1 limit 0,5000;

-- update branch name
update projects set kee =
     CONCAT(
     SUBSTRING_INDEX(kee, ":", 1), 
     ":", 
     SUBSTRING_INDEX(kee, ":", -1), 
     ":prj1-", 
     IF(
       (LENGTH(kee) - LENGTH(REPLACE(kee, '-', ''))) >= 1, 
       SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -1), "-", 1), 
       SUBSTRING_INDEX(kee, ":", -1)
     ),
     "-trunk")
where kee like "com.company.ams.prj1%" and (LENGTH(kee) - LENGTH(REPLACE(kee, ':', ''))) = 1;

-- check result: now 2 colons, so include only those with "trunk" in name
select distinct
   kee from projects where kee like "com.company.ams.prj1%trunk%" and (LENGTH(kee) - LENGTH(REPLACE(kee, ':', ''))) = 2 limit 0,5000;


-- find entries with 2 colons
select
   CONCAT(
     SUBSTRING_INDEX(kee, ":", 1), 
     ":", 
     SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -2), ":", 1), 
     ":prj1-", 
     IF(
       (LENGTH(kee) - LENGTH(REPLACE(kee, '-', ''))) >= 1, 
       SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -2), "-", 1), 
       SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -2), ":", 1)
     ),
     "-trunk:", 
     SUBSTRING_INDEX(kee, ":", -1))
from projects where kee like "com.company.ams.prj1%" and kee not like "%trunk%" and (LENGTH(kee) - LENGTH(REPLACE(kee, ':', ''))) = 2 limit 0,5000;

-- update branch name
update projects set kee =
   CONCAT(
     SUBSTRING_INDEX(kee, ":", 1), 
     ":", 
     SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -2), ":", 1), 
     ":prj1-", 
     IF(
       (LENGTH(kee) - LENGTH(REPLACE(kee, '-', ''))) >= 1, 
       SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -2), "-", 1), 
       SUBSTRING_INDEX(SUBSTRING_INDEX(kee, ":", -2), ":", 1)
     ),
     "-trunk:", 
     SUBSTRING_INDEX(kee, ":", -1))
where kee like "com.company.ams.prj1%" and kee not like "%trunk%" and (LENGTH(kee) - LENGTH(REPLACE(kee, ':', ''))) = 2;

-- check result: now 3 colons, so include only those with "trunk" in name
select distinct
   kee from projects where kee like "com.company.ams.prj1%trunk%" and (LENGTH(kee) - LENGTH(REPLACE(kee, ':', ''))) = 3 limit 0,5000;

That means the rename operation is more complex than described above. If there are multiple Maven projects in one Sonar project, then you have multiple artifactIds.
And you should be able to ste the sonar.branch property in case that has not been used before (like in our case).

Could you also apply the following changes :

• The title of the page should always be "Update Key"
• The first sentence should appear just after this title : "This administration page allows to change the key of project and of its modules. Those changes must be done BEFORE analyzing the project with the new keys otherwise this operation will fail."
• Could you extend the size of the new key input fields to 80 ?
• Make the Bulk change section appears at the bottom of the page when available
• Use the following description for this Bulk change section "The bulk update allows to replace the beginning of the key(s) by another string on the current project and all its modules - if applicable."
• I would remove the sentence "The key of the "SonarSource :: Language Recognizer" project is currently "org.codehaus.sonar.sslr:sslr"." as this information will be provided above this section.

Could you also provide some examples to fill the Replace and By fields :

• Replace : ex: org.forge
• By : ex: com.myCompany

For the Bulk change operation I guess it would be better :

• to try matching the input string whatever is its location in the key(s) -> this will provide more flexibility.
• to display all impacts when displaying the confirmation page and not only the impact on the root project
• to provide the ability to update some module keys even if the root project key is not impacted

Works well Fabrice, but :

• there isn't any index on the projects.root_id column so response time of this page can be very long when the Sonar DB contains a lot of projects
• In the confirmation page of a bulk update, a whitespace is missing between Rename and Cancel actions.

Index added on projects.root_id

Manually tested !

ITs added.