Plugins folder during sonar upgrade - sonarqube

What is a good way for extension/plugins during sonar upgrade? I am upgrading sonar from 4.0 to 4.5.1 second time.In first time, I copied the old extension/plugins folder into new sonar version.It so happened that during first time, there was a C# plugins and during database upgrade step, we got the message of "Impossible to upgrade Database". On removing this plugin, the database upgrade didn't happen and we were taken directly to the login page. As a results projects were missing on sonar dashboard though the LDAP users got imported.So I would like to know what is the right way out of below ?
1. Copy the old plugins folder from sonar 4.0 (old) folder to sonar 4.5.1 (new) folder.
2. Don't copy the old plugin folder. Just download the new plugins which are required post sonar upgrade.

Don't do #2! It will screw up your rule profiles.
You started out correctly by copying the plugins folder. But you have to go a little farther.
You need to read the upgrade notes for each intervening version. They're all children of this general guide to upgrading. They should mention all plugin incompatibilities & you'll have to deal with those manually. You may be able to do some of the upgrades via the update center in the old version before you shut it down. The rest you have to handle by deleting/replacing the old plugin jars.

Related

OSGI plugin development with Domino Designer 10

Up to date I was using IBM Domino Designer V9.0.1 FP8 to develop an OSGI plugin. With this version everything was working as intended. I've created a plugin project, a feature project and an update site project. Selecting "Build all" in the update site project created all the the corresponding jar files.
Today I've installed IBM (HCL) Domino Desinger V10 FP2 (fresh install i.e. I've deinstalled V9.0.1 and deleted the old "workspace" directory in NotesData, but I kept the NotesData itself).
Now if I open my plugin projects, I can edit the plugin, save the Java classes without any errors. Up to this point everything is working as usual. But now, if I use "Build all" in the update site project I see a screen with "generating ant script" and then the build process is finished, but no jar files are generated.
Any ideas why this is happening? Am I missing some files? Am I missing some configurations?
BTW: if I use standard eclipse to build the plugin all jar files are generated.
Domino Designer is a customised version of Eclipse. 9.0.1 FP9 and lower is a very old version of Eclipse, 9.0.1 FP10+ is a much newer version, so not comparable to what was happening before. It's possible there are differences in the customisation of Eclipse that are affecting it. But every Domino OSGi plugin developer I'm aware of uses standard Eclipse.
Follow the steps for setting up your environment here https://github.com/OpenNTF/XPagesExtensionLibrary/wiki/Development-Environment. In the documentation there I've tried to document why steps are done and what they achieve, as well as just the steps themselves. The intention is to pass on understanding to a broader set of developers, for future proofing.

Artifacts missing after version upgrade to 2.14

I want to upgrade my nexus repo from 2.10.0-02 to latest 3.x edition.
So I followed the documentation which states I should first upgrade it to latest 2.y edition (which is nexus-2.14.13-01).
I followed the steps as mentioned in the documentation, viz.
Stop old version nexus server.
Extract nexus-2.14.13-01.zip at same location as previous nexus, so 'sonatype-work' becomes the sibling directory.
Point soft links and env variables to new nexus.
Start new nexus server.
Change owner to nexus user. (as in previous version)
But in my new nexus-2.14.13-01 instance, I cannot see my personal artifacts, be it proxy or hosted.
Although I can still see all my artifacts in /sonatype-work/nexus/storage folder.
What am I missing? Please suggest
Thank you
The browse storage UI in Nexus Repo 2.x displays what is on disk. It's as simple as that. So if the artifacts are not visible it means the work directory is not set to the right location. Edit $installdir/conf/nexus.properties and set "nexus-work=/sonaytype-work/nexus".

Magnolia Upgrade from maven

I have Magnolia 5.4.9 release and I want to upgrade it to 5.4.18 from maven pom file. The problem is that in nexus repository there are pom files til the release 5.4.10. If I try to reach 5.4.11 or later, then I get this error:
Is there any solution to upgrade 5.4.11 and later?
'Maintenance releases for previous major versions of Magnolia are available to Magnolia On-Premises customers only (i.e. customers that have an active subscription to Magnolia On-Premises).' https://www.magnolia-cms.com/support/maintenance-policy.html, Unfortunate enough that's the policy.
In this case I see two alternatives:
Sending an email to info#magnolia-cms.com
or you want to upgrade to later release anyway, just giving it a shot in test env. or similar.
Should you an enterprise user: please login to Magnolia Nexus and get the version you wish. If your maven settings are accurate, you should have no problem fetching those dependencies as well. https://wiki.magnolia-cms.com/display/DEV/Maven+setup
Cheers,

How to rename projects in Sonar Qube

I have a few projects which use pom.xmls to run the sonar analysis. Their names are:
Myproject1
Myproject2
Myproject3
Myproject4
I want to rename them on the sonar dashboard:
MyprojectA
MyprojectB
MyprojectC
MyprojectD
whats the simplest way to achieve this? I know that we can update the key, and then on-board the project with the desired name. Is it possible for me to use the same key and update the project display name?
P.S: I use sonarqube version 6.1
I had to eventually change the project name in the settings.xml file. This contained my sonar.projectname and sonar.projectkey. Then, I had to onboard the app on the sonar dashboard with the new details and run the analysis. However, i still feel that a simple renaming feature could have been easy.
Since it is more of an enterprise version of sonar we are not allowed to upgrade the sonar version immediately.

How should I move NuGet artifacts to a new TeamCity server?

We've been using TeamCity as a NuGet server with great success. Last week I migrated TeamCity to a new server machine. The database remained where it was on an external server. I copied the artifacts folder to the new server and I can see them all listed on the project configuration page. However, the old packages are not showing up in the NuGet package feed. What else do I need to do to get the new TeamCity server to list those old packages in the feed?
Other projects that depend on older versions of these packages are currently broken because they can't be found.
New builds of those NuGet packages are showing up in the feed, but I also need all the old ones.
thanks demis. you put me on the right path to resolving this for me.
to make the answer here a little more complete and formal:
overwriting the following files:
provider-nuget.data
provider-nuget.index
in \system\caches\buildsMetadata
with the same files from the old build server worked for me (before creating new builds - not sure you'd be able to get a merge done after the fact).
I don't remember now exactly what I did to fix this, but it had something to do with the files inside this folder on the server running TeamCity: C:\ProgramData\JetBrains\TeamCity\system\caches\buildsMetadata
Did you move the old artifacts from older builds as well?

Resources