I am encountering a problem here...our team is trying to port an eclipse Eclipse RCP project into the web and so the first step is to try to use Virgo to use the plugins. I have created all the correct things but when I try to use an extension point (an Eclipse concept) it gives me a null pointer exception on this call:
org.eclipse.core.runtime.Platform.getextensionregistry(); // null here
Does anyone have any experience when it comes to solving this problem?
Thanks,
Tom
UPDATE:
So I got a little further with this. I've added the org.eclipse...registry bundle along with its associated bundles to the repository/usr folder and had to manually login to the console to start it up after I start up my web app. However this is still a problem because now my app doesn't seem to have any of the extension points registered. Could it be the sequence in which the app is started? (ie. I have to start the registry bundle first)?
A first step would be to add the eclipse registry bundle to the initial artifacts for the user region; in org.eclipse.virgo.kernel.userregion.properties, change initialArtifacts to:
initialArtifacts=repository:plan/org.eclipse.virgo.kernel.userregion.blueprint,repository:plan
/org.eclipse.virgo.web.tomcat,repository:configuration/org.eclipse.virgo.apps.repository,repository:plan/org.eclipse.virgo.management,repository:bundle/org.eclipse.equinox.registry
This will at least ensure that the registry plugin is available while your eclipse plug-ins are being loaded.
What I am still struggling with is figuring out how to control which plugin.xml are loaded by the registry and what triggers that. Somehow some eclipse runtime will scan some plugins directory, but how to set that up while in Virgo is still unclear to me.
Related
I am writing an Eclipse Plug-in which requires me to add two new configurations to the ManagedProject upon mouse-click on a menu option. I basically runs on Android projects that has Native Support Added to it. I am trying to achieve this using ManagedBuildManager and Configuration classes from the CDT core plug-in interfaces.(org.eclipse.cdt.managedbuilder.core.* package).
To complete the task, I create two new Configurations for the project and run the exportArtifactInfo() method to complete the action. In the end, the configuration gets added but the project folder contains duplicate folders of all the original folders in the Project folder.
I looked up if there is a bug in CDT 4.0 and found that it is indeed a resolved bug.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=194395
But I cannot figure out what the actual fix is for this bug. If anyone has encountered and fixed it or knows how to fix this, please point me in the right direction.
I am using Eclipse Liferay IDE for making a hook to a Liferay native portlet. I mean a porlet that comes with default installation, eg. blogs, content management or similar.
I have done the steps like following:
Select new Liferay Project
Enter project name MyHook
Made configurations (found an SDK directory and Liferay Server instance for Runtime)
Selected Plugin type to Hook
My only option after that was Finish and I ended up having a project with certain structure without any class or properties file inside.
My problem is that I could only get an empty project and don't know how to make the modifications to the files of Liferay because no Liferay originated package names can be found if I make a new class file and try to start typing com.Liferay. or org.Liferay. Because this is a Liferay Hook project, I suppose some Liferay originating tips should normally pop up for my selection, but I didn't see any.
What I am making wrong? What I am missing? Should I know the filenames by myself or is there a trick somewhere to tell the IDE to give me some help?
I use Liferay 6.0 and my IDE version is 6.0.5. At least in my eyes they should match together.
In the IDE you first create a "Liferay Hook Project". This is indeed an empty project. Then you create a Hook, select the Hook project to create it in. You can do the second step manually, but there's a wizard helping you to do this. This might be what you've been missing
I made the same steps again and it worked! Somehow at first time I managed to do a Java project although the project should be interpreted as a Liferay project.
Maybe the IDE is not 100% working always. Whoever knows.
I've written an Eclipse RCP application that runs fine in Eclipse, however, packaging it to be a standalone application has been tricky. I've worked my way though a few class path errors, but now I'm getting a new one.
After running the export wizard and launching my application, it throws a ClassDefError and ClassNotFoundException, specifically it's looking for org.eclipse.ui.plugin.AbstractUIPlugin. I did not find this in my copy of the eclipse SDK, and I downloaded the SDK again to be sure, and still couldn't find it. I found a jar online that supposedly contained the fiel along with some other eclipse packages, however, I then got this:
NoSuchMethodError: org.eclipse.ui.plugin.AbstractUIPlugin: method ()V not found
I figure the problem is more I did something wrong rather than this class is actually missing, but I've gone though all the configurations and I'm sure all the required packages and dependencies are included. Any ideas?
Download and install the new version of adt plugin 21.0.0.
Does your application works when you run from Eclipse? If so then try to open your plugin.xml, go to Runtime and on the bottom right part of the window you should see Classpath. Try adding the required plugins there.
I am working on an RCP project based on eclipse. It has been working fine but recently I thought I'd upgrade it to use a new eclipse version (3.2 -> 3.5).
After a bit of trouble, it was running on the new platform. Then I did something. Don't know what. The end result is that I'm now getting a classpath error when one of my plugins (A) tries to access a class in one of the dependent plugins (B) (also one of mine).
As far as I can see, Plugin A has Plugin B in its' dependency list and the compiler shows no errors. To test, I created a new Plugin C with one class and accessed the class from Plugin A. That works fine.
Does anyone have any hints for troubleshooting such issues? A checklist of settings to check? I've been struggling with this for hours and getting nowhere! Particularly frustrating as it was working until I changed something!
Thanks
Update
I should also say that the project is quite old and uses the plugin.xml and not the manifest. Could this be a problem? Is there a way to upgrade?
Some ideas:
Clean-and-build every project (maybe after a restart of Eclipse)
Check, whether the required packages are also exported
Check the Error log, maybe there is some unloadable plug-in, etc.
Check the Run configuration, whether every required plug-in is present there
If the problem does not happen in a Runtime workbench, but in an Exported RCP app, then check whether you compile the project with the same settings during export than in Eclipse
I hope, something helps about these.
You can try the following in your run configuration:
In the Main tab check Clear (workspace) under Workspace Data
In the Configuration tab check clear the configuration area before launching under Configuration Area
This helps me every time I encounter some strange ClassNotFound errors.
If I understand you correctly you have no compiler errors but when you run you get class not found exceptions? You could try PDE Tools > Update Classpath from the project's context menu to see if you declared any dependencies outside of the MANIFEST.MF file, which would result in compiling code that fails at runtime.
I developed for RCP quite a long ago, but if I'm not wrong, since 3.4 or 3.5 you have to declare in the plugin configration which packages/classes are exported for dependent plugins and which are not.
This is unlike the old convention of using 'internal' in the package to mark non-exported packages.
Since you have plugin.xml from very old version of eclipse, it might be the problem, as exported resources from one plugin to another were not enforced in Eclipse RCP 3.2.
One more complement, hope it helps.
Open plugin.xml, check "build" tab, see how "binary build" are configured. It affects which files will compiled and exported.
See binary build here : http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Feditors%2Fmanifest_editor%2Fbuild.htm
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.