I encounter some problems when I try to update Eclipse plug-ins at the start up of Eclipse. My program pops up the dialog at Help -> Check for Updates at the start up of Eclipse. But, when the user proceeds with the update quickly, Eclipse throws an exception saying that the p2 profile is in use. I believe this is because other Eclipse jobs are using the p2 profile at the start up and thus my program fails to use the p2 profile to update the plug-ins. How can I safely use the p2 profile? How can I use the p2 profile in isolation?
I've uploaded the minimal piece of code that is needed to reproduce the problem on github. And, I've described the problem and the steps to reproduce it in details in an issue on the github repository.
You can get the ProvisioningJob from your UpdateOperation, let it belongs to the family of running profile change job. See org.eclipse.core.runtime.jobs.Job.belongsTo(Object).
Besides I have two ideas to do it via using internal API,
try to test lock the profile to see whether it's being changed. org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.lockProfile(Profile)
run your like before, but catch IlegalStateException, then register a ProvisioningListener on the IProvisioningEventBus to be notified when the running profilechangeoperation is finished.
My commit opens the "Check for Updates" dialog by invoking the command "org.eclipse.equinox.p2.ui.sdk.update" instead of invoking the following method.
org.eclipse.equinox.p2.ui.ProvisioningUI.openUpdateWizard(boolean, UpdateOperation, LoadMetadataRepositoryJob)
Surprisingly, this change seems to fix the issue with the race condition in accessing the p2 profile. Does anyone have an explanation for how my commit removes the race condition?
Related
I'm having a hard time using eclipse because of the following issue.
It goes like this. I'll code and try to run it. Then, it will throw some errors (of any kind). And so, after I have changed a part of the code, comment out which codes I suspect makes the error, or delete something, I then restart the websphere application server in order to republish my work. Next is to test my work using SoapUI then all of a sudden eclipse throws an error which is the same as before. I've tried to search in here answers to this questions but it involves codes which don't need in my project and also answers that I can't understand well (since I am very new to programming). However, I have found a way to resolve this but it's very inconvenient. To be able for eclipse to detect changes in the src folder, I should restart eclipse after editing my codes then remove my project in the server, start the server and then publish my work in websphere all over again. It solves my problem but I do all of these stuff every now and then even if I only comment out a single line in the code. What I want is to avoid doing this process of resolving the issue since it consumes so much of my time whenever I republish the project in the server.
Can somebody help me with this? Any suggestions would be very helpful. Thanks a lot!
It is a bit strange that you need to restart eclipse. The normal way would be to just re run your application server.
Try only he 3 second steps you mentioned (remove my project in the server, start the server and then publish my work in websphere) and if that works try again without removing the project. Just restart the servers.
And let us know if that worked!
I am totally new to K2 and its very basic. I have installed the Incident Management accelerator. I am struggling hard to locate the workflow called “Incident Resolution” under the rules "when create button is clicked". I would like to modify this workflow to fit my purpose. Can anybody help to locate the workflow in K2 Studio? Any help on this is greatly appreciated.
Regards
George
First let me tell that it is not obvious, so new or not to K2, your question is legit :) It is very easy to do... once you know :)
If you already installed the accelerator, I suppose you already unzipped the package and used the K2 Package and Deploy to install it on your server.
Your first stop will be the K2 Workspace. For this, you must use Internet Explorer. The URL will usually be http://yourserver:81/Workspace
On your system, the port may differ dependending on your installation.
In the workspace, go to Management/Management console.
Expand your server then go to Workflow Server/Processes/Operations/Incident Resolution/Versions
By default, you should see a single version. Notice the download link next to the version. It allows you to download the process.
Download the process and save it somewhere. You will get a self-exctratible zip (.exe). Run that .exe and choose where the process should be extracted. It can be anywhere.
Browse to this location on your file system.
Double click the .k2proj project file. This will open the project containing the process using K2 Studio.
From here, you can now modify the process and deploy a new version on the server.
Please note, that at any time, if your new process ends up being 'not that good', you can go back to the versions screen in order to set another version of the process as the default one (the one that will be opened by the SmartForms). That gives you them time to fix your process and deploy a new version of the process that works better.
Let me know how it goes.
In attempting to use p2, whenever I execute an UpdateOperation.resolveModal call, I get the following error:
Cannot complete the install because of a conflicting dependency
After doing a little research I found out that this is a very poor way of equinox informing you that you don't have sufficient privileges to execute that command because when I run as administrator, updates work without a hitch.
My question is this. Is there a programmatic way in Eclipse for p2 to check to see if updates are available without considering whether the user actually has the permissions to perform the update?
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 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.