What could cause Eclipse to ignore plugins in the dropins catalog?
I've created a dummyplugin based on the Eclipse wizard, exported it to a jar. When dropping it into the drop-ins catalog of a fresh Eclipse installation, it works fine.
When I do the same thing but on a custom Eclipse installation, it doesn't work. The plugin doesn't even show up in the plugin registry view. No error messages or anything like that.
I've tried:
Running with -clean
Running with -clean -consoleLog but no errors were printed
Starting up with -console, and checking if the plugin is seen with the command ss, no luck.
Running with -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:\Program\Eclipse\eclipse3.6\dropins\
Changing name of the eclipse catalog from eclipse3.6 to eclipse, in case I had run into a variation of an Eclipse bug
It's not due to dependency issues (like this question), since the plugin isn't even found
Update Copied the eclipse.ini from the working eclipse installation to the custom one, with the same result; The plugin wasn't found. So the issue isn't in the ini file
Update Thought the issue might be some rights issue, since I my user wasn't the owner of the custom installation. So I made a copy of the entire dir of the custom installation to make sure I was the owner with full rights. No change
Update Starting with a new workspace doesn't make any difference
Is it possible to define that Eclipse should ignore the dropins catalog? How?
The custom version of Eclipse defines a lot of variables, but nothing that seems related to p2 or the behaviour of dropins.
The dropins/ folder is a best effort, totally optional, silently failing legacy leftover. Not big on the diagnostics, as you've found.
If you use the director to install your bundle into your custom eclipse, at least you'll be able to get an error message that will tell you what the problem is.
I'd suggest exporting your jar with some minimal p2 metadata.
Then you use something like:
eclipse/eclipse \
-application org.eclipse.equinox.p2.director \
-noSplash \
-repository \
file://$HOME/eclipseUpdate \
-installIUs \
org.dojotoolkit/1.6.1.v201105210659
If p2 can't find some dependency, it should spew out the confusing error messages it can generate.
Hi #Fredrick I've made my own plugin and I've added to my eclipse in this way:
Export the plugin as Deployable plug-ins and fragements.
(Right click on the plugin project - Export - Plugin Development - Deployable plug-ins and fragements)
That will generate a .jar file that file you have to copied into \eclipse\plugins
Restart eclipse.
I'd say that will be all.
Related
So I keep getting this error when trying to run my program:
Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.controls not found
I'm using a mac with eclipse, and my VM argument is:
--module-path /Users/myname/Desktop/javafx-sdk-11.0.2_3/lib --add-modules javafx.controls,javafx.fxml
I've tried everything, javafx.controls.jar and the other .jar file are in my lib folder. I've reinstalled the javafx program, changed my file path around hundreds of times, and I've tried to install plugins. Does anyone have any idea as too what can be happening? JavaFX is also an added library in my project, and all the .jar files assocated with it are added to it. Please let me know if anyone has an idea. Best!
I had success with the following additional step.
In the Run Configuration->Dependencies tab, click the "ModulePath" and then add the JavaFX JDK's jars (or the /lib folder that holds the jars) to the list.
You can inspect the generated command line, and check that these are included in the -p option.
IDK why this step should be needed. I would think Eclipse should be smart enough to include something on the dependency module path if it were in the project's Build Path Library list.
I have questions about this at eclipse.org and gluon. Maybe there will be an explanation, or fix so that this step isn't needed, or an edit to the documentation to let us know we need to do this.
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 have created an Eclipse feature set, composed of various plugins. One of these plugins contains an executable file that gets called from the plugin. The feature.xml file sets unpack="true" for this plugin, so it is installed as a directory rather than a jar.
But when Eclipse tries to launch the executable, it throws a "permission denied" error. Running chmod on the exectuable fixes this ... but I need this to happen automatically when people install the Eclipse plugin.
I've ensured that the executable file has the correct permissions before I build the plugin.
I'm thinking maybe there's a way to add installation tasks to a feature.xml, perhaps?
Figured it out, p2 TouchPoint instructions enable the execution of commands during the installation of a plugin.
http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instructions_35
I am currently trying to get my headless pde-build working but I am stuck on a point where I do not know how to continue.
The problem is how to define the related target platform to compile the plugins against.
I have a build.bat with the following call (all in one line!):
java -jar D:\target\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
-application org.eclipse.ant.core.antRunner
-f D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml
-Dbuilder=c:\pde-build\scripts %*
I tried to create the target eclipse platform from different parts: The eclipse SDK, RCP SDK, Delta Pack, PDE-SDK in all combinations but none of them worked well.
I got the following error:
BUILD FAILED
D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml:18: Cannot fin
d ${eclipse.pdebuild.scripts}/build.xml imported from D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_2010011
4\scripts\productBuild\productBuild.xml
where the variable ${eclipse.pdebuild.scripts} does not got resolved. I also tried to give this parameter via the command line but then I got another error regarding missing svn task which is absolutely confusing as this is working with my local eclipse installation referenced.
When I replace the path from d:/target/eclipse to my local eclipse installation the pde build works as expected!
This leads my to the point that the configuration of the target eclipse is not correct but in the moment I have no idea how to configure this!
My goal is the automate the pde build first on my local site without referencing my local eclipse and later on integrate this building process into our running cruisecontrol instance.
As I saw already another question about defining the target eclipse I would be happy if anyone can contribute hints or facts regarding the problem.
Regards,
Andreas
When performing a headless build, the target can be separate from the eclipse that is actually running the build itself. The problem you had here is that the eclipse that you were using to run the build did not have PDE/Build properly installed.
This is why the ${eclipse.pdebuild.scripts} was not set, because PDE/Build was not installed into that eclipse instance, the org.eclipse.pde.build bundle was not resolved and the code that sets this property never got called. Similarly, the necessary ant classpath entries for PDE/Build tasks would not have been set up properly either.
You need the Eclipse with PDE installed inside to run the build, but the target for the build can be separate from this.
In the build.properties file found under -Dbuilder=c:\pde-build\scripts you can set several properties:
baseLocation This is a path to an eclipse that is your target.
buildDirectory This is where the build will actually take place, source is fetched to plugins/ and features/ subfolders, but if there are already binary plugins located here then those become part of the target as well.
pluginPath This is a list of paths (separated with ';' on windows or ':' on linux) containing other locations that should be considered as part of your target. These locations can be several things:
The root of an eclipse-like install with plugins/ and features/ subfolders. This is a good way to provide the delta-pack instead of just unzipping it on top of an eclipse install.
The root of a workspace-like folder, where all subfolders are treated as plugins or features depending on the presence of a manifest or feature.xml.
The root of a bundle or feature, or the jar for a bundle.
If you are doing a p2 build (p2.gathering = true) you can also provide p2 repositories under a ${repoBaseLocation} which will be transformed and placed under ${transformedRepoLocation} and will become part of your target, and the p2 metadata there will get reused during the build.
after some more time of investigation I found out, what I did wrong so far. As I mentioned above defining the target platform is not that easy as copying the SDK and plugins in into one location (as it was in early times of eclipse dev).
The working solution by now is the following: Copying the eclipse SDK into the target location and run this version. Install inside this the neccessary PDE-Tools to enable plugin development. After that, close the IDE and copy the delta pack + the respective svn plugin (I used org.eclipse.pde.build.svn-1.0.1RC2 from sourceforge) into the target platform and you're done.
Now my automated PDE build is running as expected.
Only minor issue now is the following: The result product contains eclipse-specific menu entries which are not there when I ran this from inside my dev-eclipse.
Any hints on that?
I just posted an answer to my question on this kind of topics, may be this can help you:
Plugin product VS Feature product
I downloaded the source code for the EMF based UML2 Plugin and changed a class in the org.eclipse.uml2.uml.edit project to remove special characters when returning string representations. Now when I export the projects and place the jar files either in the dropins directory or replace my current uml2 plugin jar files in plugins directory, The UML files are no longer recognized, in short my modified plugin does not install correctly (no error is thrown and I can see the files being picked up under Plugins->Target Platform) .
However, When I run the plugin as an eclipse application (from the workspace) I can see the changes I made being reflected in the new instance of eclipse.
What can I do to ensure that the plugin installs correctly?
Is there a documented procedure of how to build the uml2 plugin (or any comparable plugin) after modification?
Select the project and open the context menu. There is an entry PDE near the bottom of the menu. In there, you can find an entry to build the plugin for deployment. This gives you the features and plugins directory with the fixed files. Copy both into your Eclipse install.
Unless the UML2 plugins require some kind of magic build script, exporting the one plugin you changed and overwriting the original in your Eclipse installation should be the easiest solution. One potential problem which comes to mind is conflicting plugin version numbers: make sure you don't have two identical versions of your modified plugin in your Eclipse installation.
When debugging plugins which apparently don't work properly at runtime, I always look at Help > About Eclipse Platform > Configuration Details. This lists all the plugins found by Equinox during startup, along with their status (see the Javadoc of the org.osgi.framework.Bundle interface for explanation).
I faced the exact same problem as you describe here . I dont have any answer to your problem but i am sharing what worked for me .
I created a local update site of the plugin on my system. Create update site for your plug-in article explains very very nicely the steps needed to accomplish this .