I'm upgrading from Sonar 3.1.1 to SonarQube 4.0. I have the sonar-fb-contrib-plugin-1.2.jar file in my extensions/plugins directory. The startup fails with the following message:
2013.11.12 15:10:17 INFO org.sonar.INFO Install plugins done: 197 ms
2013.11.12 15:10:17 ERROR o.s.s.p.PlatformLifecycleListener Fail to start server
org.sonar.api.utils.SonarException: Fail to extend the plugin findbugs for fbcontrib
My understanding is that findbugs comes bundled with SonarQube (I can see the jar file under bundled-plugins). I'm not sure what the problem is here - it doesn't look like this works out of the box as it did for 3.1.1
I had a similar issue while upgrading from 3.6 to 3.7.3; the fbcontrib-plugin depends on the findbugs-plugin which is part of the sonar java-ecosystem.
In this case it is safe (and documented, point 6) to take a backup of the database and of the extensions directory before updating; then update and restart sonar having moved away any external contribution plugin, so that sonar can manage the update and come up back successfully. Another good tip is to not overwrite new configuration files with the old ones, instead manually editing them to bring over the old settings.
Then, add the plugins back and restart again; happy static analysis.
Related
I'm trying to deploy a Liferay rest-builder project. These are the steps I follow to do it:
I create a rest-builder project with Liferay Developer Studio wizard.
I edit the *-impl/rest-openapi.yaml file
I launch the buildREST Gradle task
BuildREST task ends successfully
I launch the deploy Gradle task
Deploy task ends successfully
When JAR tries to deploy, it lets this message in log:
Unable to start bundle: file:/C:/devs/testlr73/bundles/osgi/modules/com.liferay.training.service.rest.impl.jar
org.osgi.framework.BundleException: Could not resolve module: com.liferay.training.service.rest.impl [1368]_ Unresolved requirement: Import-Package: com.liferay.portal.vulcan.pagination; version="[1.4.0,2.0.0)"
I tried this operation with versions 7.1, 7.2, 7.3 and 7.4.
Only 7.4 deploys without a problem (after fix the version in the javax.xml.bind dependency).
I was trying found where is set the Import-Package to fix it but I can't found it.
There are two general approaches to fix your problem.
Initialize a new project based on your exact version of Liferay (and copy your code into the created projects)
Try to fix all dependencies manually
I would suggest to go with 1. as this seems the "cleaner" approach to me. But I will try to explain both ways here as much in detail as I can.
FIRST APPROACH: Initialize a new project
When creating a project with blade, you can give it 2 additional / optional parameters:
--product (dxp | portal - for the community version)
-v (version - like 7.2, 7.3,...)
The whole command for a DXP 7.3 would look like this:
blade create --product dxp -v 7.3 -t rest-builder automapper-service
As for the wizard in Dev Studio, you should be able to select the Liferay Version and the Flavor as well for your project - if you use a Liferay Workspace usually you select it once for the workspace.
DevStudio writes this information in your gradle.build of the workspace, so you can change it afterwards, its the liferay.workspace.product and liferay.workspace.target.platform.version variables.
Please have a look here for an exact walkthrough for creating a project in dev studio.
SECOND APPROACH: Manually updating the dependencies
Your package needs the Vulcan API as dependency. And as the deployment in 7.4 works, you seem to compile it for the 7.4 version.
So I would do following approach:
1 Check which version of Vulcan API Liferay is running in your desired Liferay
Startup a Liferay server.
Goto its Gogo Shell and execute:
lb vulcan
You should get some entries back, the correct one is the "Liferay Portal Vulcan API", in my case (DXP 7.3 SP3) it has the version 7.19.2
So you should remember / note that version.
2 Replace all occurences of that dependency in your gradle files
Liferay has an article here which explains more in detail on how to resolve bundle dependencies
Search in Dev Studio via Search -> File for com.liferay.portal.vulcan.api
For example in your build.gradle you will have something like this
compileOnly group: "com.liferay", name: "com.liferay.portal.vulcan.api", version: "9.3.1"
Update the version to your target version and save the file, so in my case it would look like:
compileOnly group: "com.liferay", name: "com.liferay.portal.vulcan.api", version: "7.19.2"
One note of warning for this approach: There might be further issues with other dependencies as well. You will have to resolve all of them to successfully deploy to your desired Liferay version. Good thing though, you can do it the same way I described above.
Background
I am working on a simple plugin, and have already deployed to the Plugin Repository once before (successfully).
Since my last successful deployment, I found that I had a lot of issues with the IDE. After completely upgrading, and modifying my plugin's directory structure, I have been able to get the plugin to Run again.
Issue
tl;dr - I have an updated plugin in the JetBrain's Plugin Repository that does not work as intended, and I cannot update it correctly!
When I run the plugin, a second instance of the IDE comes up with my plugin working correctly. I edit my code and run the plugin again - the plugin runs smoothly and the updates are applied!!
With all of this, I decided to deploy my updated plugin to the Repository again. Once that was done, I decided to download the plugin and try it out myself; just to make sure things worked.
The issue is that nothing can be found in the plugin file!! Just the updated plugin.xml file and Manifest.mf file. The total size of the archive file is around 500bytes. I know a correct archive would have more files in it, and in my case, the file size should be around 6kb (based on my first successful archive file).
So how can my local IDE instance find the files correctly, but the deployment feature cannot? How does the deployment feature actually work? I get the feeling I have the structure wrong, eventhough the new IDE instance works perfectly
Plugin
GitHub
JetBrain's Plugin Repository
When you install the plugin, the version is shown as v1.1; however, that is not true, in reality. One of the easiest features to determine the actual version of the plugin is the Folded Text foreground color.
v1.0 - RED
v1.1 - YELLOW
Deployment
Preparing Plugin Module for Deployment + resulting plugin.jar file
Contents of plugin.jar
It seems possible that because of the restructuring an old ChroMATERIAL.xml file was left somewhere in the build output. Somehow this could end up in the plugin jar. An invocation of Build > Rebuild Project should fix this problem.
There could also be problems in the project or module configuration, but the project files are not included in the GitHub repository, so that cannot be checked.
I'm using:
Eclipse Kepler
WSO2 Developer Studio v3.2 plugin
WSO2 esb v4.7.0
Maven 3.x
Java 1.7.x
Windows 7
And I'm having the following problems in Eclipse when using WSO2 Development Studio:
if I try to edit a file (via Design or Source view), the changes are not saved and are reverted back to the original values.
when I add a new Registry Resource to my Registry project, this resource is not added to the carbon file.
by deleting a resource file, the resource still exists in the project/Registry(path) and is not cleaned up well. I have to delete it manually from artifact.xml.
when I try to make a carbon file by running 'mvn clean install' from the command line, the build hangs. I've fixed this by changing the version of 'maven-car-plugin, wso2-esb-proxy-plugin, wso2-general-project-plugin' to 2.0.5 (default: 2.0.4).
And changes made to pom files are also not saved, they always revert back to original values.
Are these problems known and is there any solution available ?
Thx in advance and looking forward for a reply.
First of all I need to emphasize that WSO2 Dev Studio 3.2.0 is not tested and verified with Eclipse Kepler and the officially supported Eclipse version is Eclipse Juno SR2. Even-though Kepler is not tested, I do expect most of the features to work.
Following are the answers for your comments/questions:
Q.if I try to edit a file (via Design or Source view), the changes are
not saved and are reverted back to the original values.
Ans: What is the file you are referring here? Is it an artifact file? or an utility file such as pom.xml?
We have not come across this issue before that values are being reverted back to previous. However there is a known behavior that if you try to add a new element/value that is not being recognized by the ESB Editor, it will simply drop the newly added value from the source.But that behavior is specific to ESB Graphical Editor. Without knowing the type of file you are referring, I cannot 100% be sure what is going on.
Q. when I add a new Registry Resource to my Registry project, this
resource is not added to the carbon file.
Ans: Yes, That is the expected behavior. Rationale is that, In a given workspace there can be multiple C-App Projects existing at the same time. So we are not sure to which C-App project user wishes to include a given registry Resource. Adding the same registry resource or any other artifact to all the C-App projects does not seem right. Therefore we do not automatically include a Registry Resource or any other artifact in to C-App projects.
Another special scenario with Registry Resources is that, you can deploy a Registry Resource to any Carbon Server. Therefore we cannot 100% be sure about the correct Server Role for the Registry Resource.
After considering all the above facts we have decided not to include any artifact in to C-App Project and let users to add them.
Q. by deleting a resource file, the resource still exists in the
project/Registry(path) and is not cleaned up well. I have to delete
it manually from artifact.xml.
Ans: This could be due to a bug in the Refactoring component in Dev Studio. However we have done some modifications to the refactor components to improve it and fix some bugs in it for Developer Studio 3.3.0 Alpha 3 version. With those fixes, most of such issues will go away.
Q. when I try to make a carbon file by running 'mvn clean install' from
the command line, the build hangs. I've fixed this by changing the
version of 'maven-car-plugin, wso2-esb-proxy-plugin,
wso2-general-project-plugin' to 2.0.5 (default: 2.0.4).
Ans: There was serious a performance issue related to wso2-general-project-plugin and wso2 esb artifact plugins released with Developer Studio 3.2.0. We have identified this issue [1] and fixed in the latest versions of the plugins as you have discovered. So with those plugins, you will experience a greater performance improvements.
Q. changes made to pom files are also not saved, they always revert back to original values.
Ans: There is a known issue with updating properties section of the pom.xml of C-App project [2] and we are working on fixing this for the upcoming Dev Studio release.
Hope this clarifies some of the concerns you have and provide answers to your queries.
Thanks and Regards,
Harshana
I'll try keep this short. I have Eclipse with an installed M2E (Maven to Eclipse) plugin. I have a GAE (Google App Engine) project I'm working on. Everything is working ok apart from one really annoying thing: I have to stop/start the devserver every time I make a change.
If you have any experience with this setup then you might be able to answer this simple question?
I start the development server with "mvn appegnine:devserver" on the command line. Now I would expect that if I made changes to a *.jsp for example that those changes would automatically be updated on the devserver. Is this what happens with you?
I have noticed that if I make changes to *.jsp files under my target folder then devserver will see those changes and updates as I would expect. I think my problem lies with Eclipse not copying changes to target folder, but not sure if is even suppose to?
Does anyone have any suggestions on how I should progress investigating this? I've ran out of ideas :-/
I thank you in advance for any comments you may have.
P.s I know I can run "mvn package" to update files, but this is slow and the devserver runs out of memory after a do it twice.
This can be little painful, depending on how you want to work and which version of eclipse you're using.
Install the m2e-wtp plugin if you haven't. It's the secret sauce that makes appengine projects work in eclipse. Note this isn't m2e - but another plugin.
Install the GPE - the google plugin for eclipse if you haven't
Make sure your project is being managed by m2e as a maven project.
Go into your project properties - enable it as an appengine project using the GPE (listed under 'Google'). Don't forget to tick HRD while you're here.
Go to your project build path (Properties -> Java Build Path).
Ensure on the source tab that your src/main/resources doesnt have an ** exclusion.
Ensure on the libraries tab your have the three libraries 'JDK', 'Google Appengine' and 'Maven Dependencies' and nothing else
Ensure on the order and export tab that the appengine dependencies are above the maven dependencies.
It sounds pretty ridiculous - i'm not really sure why its still so painful, but that is a good recipe for success. Once that's done, this should allow you to run in debug from eclipse itself, with hotloading of code, jsps, css, scripts etc. I've had this work in helios, indigo and juno.
You can read more about the m2e-wtp setup instructions here. They refer to GWT but it's the same for appengine (I'm not sure why the emphasis on using GWT on GAE) because its actually about the correct setup of GPE and Maven.
You will also find that you may need to repeat some parts of step 5 pretty frequently - if your app isn't loading properly take a quick look to ensure that your resources haven't been excluded. This happens when you update your project configuration using the m2e plugin.
The wtp-m2e plugin updates the target folder as resources modified - so this should also resolve your issues running from the command line, but i can't vouch for that - I prefer to run straight out of eclipse.
I have the same problem as you, however I resolved with other way. I use FileSync plugin (which can be found in the market place).
With this plugin you configure an input directory (webapp) and output directory (target).
Any change made to the webapp will be passed to the target.
I have helped too.
You can use rsync like this:
rsync -r --existing src/main/webapp/ target/ROOT
where "ROOT" is the project build finalName.
The below point worked for me.
Ensure on the order and export tab that the appengine dependencies are above the maven dependencies.
I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.