I'm desperate. I try to install an extension for pAPI, and it downloads alright, but never registers. NO PLUGIN REGISTERS. The only 2 that do work are the ones that I have installed very early on for Scoreboard-Revision (Scoreboard plugin). These plugins are Player and Server, and I can unregister them, register them again, and so on. But for some reason, no other plugins want to register. Here's a photo:
Code
Some expansions of PlaceholderAPI Require a Plugin to be installed, make sure you have installed the required plugin so the expansion can work.
Information taken from the PlaceholderAPI Wiki F.A.Q
Related
People post some simple questions in the firefox-addon-sdk. I know nothing about sdk but can still answer it. I just need to be able to test things on the fly.
The way I usually test things is scratchpad. If I need bootstrap scope then I have a dummy on my github, I just edit the bootstrap.js and don't need to commit/save, just type in that text box and hit install with the GitHub Extension Installer addon and then it runs.
Now I want to do the same for addon-sdk addons. I need like a blank sdk addon that has everything in it. Lots of times in main.js I paste some code someone wants me to test and it fails because the xpi doesn't have the right authority.
Is there a link to a master xpi that is a sdk addon with everything in it but blank main.js?
I am having a small problem with plugins not staying installed with Coda 2.2 for Mac on OSX 10.6. Every time I close Coda and open it back up and then click on plugins half of them are gone even though the are in the plugins folder for the application. I have to close Coda and uninstall and reinstall the plugin then open it back up. That is only good until I close it then it starts all over again. Is there anything I can do or is there something I am overlooking that is causing this to happen?
-Thanks
I've been working with Panic support and we've discovered there's an issue with certain plugins. Most likely, it's only one that's problematic. For me, it was WVCPs plugin. Removing that from the plugin folder allows all other plugins to work fine.
I found it helpful looking at the Console app for messages from Coda and one by one dropped the plugins back into the plugins folder until I found the one that caused an error about incompatible architecture.
You can ignore the error about two plugins implementing the same class, that seems to be a mutual exclusion sort of warning but still allows the other plugins to work.
One other plugin had a different error but again, appears to work fine so probably it was just a warning.
This is probably your best solution until Panic push out an update, which I am assured is on the way.
Hope that helps!
We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?
I wrote a plugin using FireBreath, VS2010, for Windows, all browsers.
In FireBreath documentation I saw that I have to install WiX. I installed it.
I created the project using the automatic fbgen tool so it autmatically created a WiX for me.
I couldn't understand from the doc is waht to do now:
Do I have to edit the generated WiX source file? If yes, what to change there?
What to write in the object tag that will trigger the installation of the msi created?
Or at least say to the user that installation is needed and link him to a download?
10x!
With the WiX Toolkit installed, re-run the prep__.bat file to regenerate the installer project along with the main plugin project. Build the plugin project, then build the installer project named something like {YourPlugin}_WiXInstaller. The msi will be placed in Firebreath's \build\bin\{YourPlugin}\{Configuration} dir ( {Configuration} is Debug, Release, etc).
It's not necessary to edit the WiX file unless you really want to change a specific setting. One thing I can think of is changing the default per-user install to all users. Per-user is usually better because it avoids UAC issues.
Deploying it to the user is a bit trickier. For most browsers, the user must save & run the msi. On IE you can declare an object in the HTML body and point the codebase to a URL containing the plugin:
<object id="pluginid" type="application/x-yourplugin" width="0" height="0" codebase="/YourPlugin.msi" >
<param name="onload" value="pluginLoaded" />
</object>
However IE9's security seems to block MSI's here. It does work if the plugin DLL is used (codebase="/YourPlugin.dll"). This auto-install method only works in IE with signed binaries (unless IE's security options are cranked way down).
Hopefully a discussion thread on the MSI security issue will yield some answers.
Update:
As hinted by Richard / taxilian, an MSI must be packaged within a CAB file in order for IE to install it. Getting the INF right and creating the CAB takes some additional steps as documented by RB. And to add yet another wrinkle, Vista/Win7 do not allow the INF to call any binary outside of the CAB file, so a stub launching app must be used (see this thread and example code posted by Roey towards the bottom).
I have taken the org.eclipse.equinox.p2.examples.rcp.prestartupdate project and adapted it for use in my RCP application. I then setup an update repository that gets updated as part of my nightly build.
When I open my application it goes through the motions like it is updating - it finds the update site, generates an uninstall and install operand for each bundle correctly and says that it finished with no errors. The problem is that the plugins never actually get installed in the plugins folder even though the profile gets updated (a subsequent run states there are no updates). Next time my build runs it correctly identifies there are updates, but the same thing happens again.
I have spent days debugging and the only thing that looks out of the ordinary (not that I fully understand what is going on) is that during the final configure phase none of the TouchpointData objects have any instructions so it doesn't look like configure is doing what it should.
I really have no clue where to look next and would like to see if anyone else has any ideas.
Update:
I finally figured out what was going on.
The problem started when I built my product without the generating the metadata repository. When building through Eclipse I didn't check the "Generate metadata repository" in the export product wizards because I didn't need a p2 repository, just the product. The problem is that without checking that button the product does not install as P2 enabled causing side effects such as not generating a profile among other things.
I tried to compensate for this by manually creating a profile in code which I have since found out is a really bad idea. My original problems were created because my profile wasn't set up correctly.
Once I started exporting the product with "Generate metadata repository" checked the update started correctly installing the new plugins.
The problem I have now is that although the plugins are being installed correctly, the executable is getting trashed and I cannot launch my application any more. I am building my update site through Hudson and the binary folder which is present when I use the Eclipse Export Product wizard is missing. I am assuming that is what is going wrong now.
Any ideas why the binaries would not be building in my headless PDE build?
Figured this out also. I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.
I had assumed that all I needed was the individual launcher plugins for the platforms I wanted to build on. Since I was trying to understand the process I was copying over plugins one by one to the build server. It turns out to include the platform specific binaries in the build you need to have the org.eclipse.equinox.executable feature from the delta pack. Once I added that to the build the binaries started showing up in the output. With the binaries the update mechanism works exactly as intended.