I created two different plug-ins to load into the plug-in manager in Petrel 2018.
They are coming from the same "code base" even if they are in two different solutions.
So I have two different PIP with different : name, version and all the categories you can find in the plugin.xml.
My problem is that when I load both of them, Petrel (2018) is automatically uninstalling/disabling the first one.
Then, my question is, how does Petrel find that plug-ins are related and that it needs to remove one to install the other one ?
This would allow me to change one of this two plu-ins to be able to have them at the same time in Petrel.
Thank you in advance !
Victor
I would check to make sure that your plug-ins are registered with Petrel correctly by checking the PluginManagerSettings.xml. Verify that the PluginId property is different between both plugins.
I suspect that the issue is with the Slb.Ocean.Core.IModule. Are you reusing the same module?
Thank you for your answer !
My PluginId properties are differents in PluginManagerSettings.xml but you are right this probably comes from IModule. What should I put in Initialize() method to be sure that I create a new one when I generate a PIP ?
Thank you again !
Victor
Related
I am using VS Code on Manjaro and have setup a solution with 2 projects, a webapp and a test project.
Each time I do a build it appears to generate a new _PublishedWebsites folder with NetCoreApp underneath it. I am surprised that nobody else seems to have encountered this issue. Can anyone tell me why this is happening and how to fix it?
Many thanks.
You should check your csproj file, particularly PublishDir element which is your specified location for publishing output files and change that if your like.
However, I think this is required behavior for .net core support in app harbor, find more details in the support webpage over here.
I have created a eclipse product using product configuration (.product) file. I want to display a dialog before the eclipse splash screen(the product screen) appears for some validation.Since am launching the product from the configuration(.product) file,i dont have an IApplication implementation to do the same.
Usage of startup extension is not useful as the control is given to startup extension only after loading the workbench.How this usecase can be supported ? Any help is appreciated.
Thanks,
Santhosh
The startup extension is the earliest place you could get control because, for performance reasons, your plugin won't be started until the user explicitly requests some action that requires your plugin. If you have to run some validation earlier, your two choices are to modify the base Eclipse code and deliver a modified Eclipse platform with your product or perform the validation when you install your plugin.
For completeness, I'll also note that some repackagers of the Eclipse platform (IBM Rational comes to mind. Others have done this, too) have at times included a licensing component that you might be able to plug in to.
This blog describes how to add a login-dialog as part of the splash-screen. Is this what you want to accomplish?
In order to modify an eclipse plugin, what are the steps to find its editable code ?
I read and debug source provided with eclipse distribution but to try a fix in org.eclipse.jdt.internal.corext.codemanipulation behavior I need to make it editable.
Well, the source repository is available at eclipse.org, the plugin compiled with the source should be available from the standard eclipse update site.
I'm guessing you are considering changing the source, recompiling and using your plugin instead of the standard one? There is a different way to change functionality, its with fragments. For example, look at a question I asked earlier, follow the links in my text and Andrews answer for more information.
Working Eclipse features and plugins, I have a problem with building two separate features (lets call them One and Two) where Two contains plugins that depend on plugins in One. I use PDE Build and ideally would like to have the option to build just One or Two (assuming One was built at some previous point in time).
However, having built One and then trying to build Two I run into the problem that classes that were built in One cannot be resolved. I am trying to get the second build to use the .jar files which were the output of building One, but have had no success. It simply seems it ignores the build output from One.
I've tried various solutions, like using build.properties pluginPath property to refer to the .jar files I depend on. Copying the already built plugins into buildDirectory is not a good option either, since the environment I am working in is a bit messed up and the build directory also contains other plugins that are not to be built (including the plugins built with One).
Any suggestions are welcome!
Cheers,
Anders
In PDE, features are just sets of plugins. This is meaningful during installation but not during build. So you can't say "plugin X depends on feature Y", you can only say "plugin X depends on plugin Z"
So what you need to do is this:
Add dependencies to the plugins in Two which mention the plugins from One
Add One to the "target platform definition". This is basically a list of plugins which will be available when the plugins of Two will be installed at some time in the future.
This blog post should get you started how to create your own target platform.
[EDIT] These two blog posts might also be useful:
http://pweclipse.blogspot.com/2011/02/pde-build-as-workspace-export.html
http://www.vogella.de/articles/EclipsePDEBuild/article.html
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.