I am building an Eclipse RCP-based product, and I am running into an issue where when I try to use the built-in p2 UI to install updates to the product, I get an error message in the dialog that "Insufficient access privileges to apply this update."
I have debugged into Eclipse and found that the 'root cause' is that there is a p2 .profile file that has xml that includes this snippet:
<iuProperties id='com.datical.db.ui.product' version='1.33.0.201412032223'>
<properties size='4'>
<property name='org.eclipse.equinox.p2.internal.inclusion.rules' value='STRICT'/>
<property name='org.eclipse.equinox.p2.type.root' value='true'/>
<property name='org.eclipse.equinox.p2.type.lock' value='3'/>
<property name='org.eclipse.equinox.p2.base' value='true'/>
</properties>
</iuProperties>
The relevant line is the one that says <property name='org.eclipse.equinox.p2.type.lock' value='3'/>
I'm not sure what I am doing wrong - I think I must have something awry in my product definition or my feature definition or in my install process that is causing this line to be there.
When I step through the Eclipse code (our target environment is 3.7/Indigo) I see that the profile is being written inside org.eclipse.equinox.internal.p2.engine:SurrogateProfileHandler:addSharedProfileBaseIUs (which is private static.) That is called from SurrogateProfileHandler:createProfile
The product's p2 repository is being built using the tycho plugins, version 0.15.
We finally discovered another piece of information that may be relevant. We were using a custom OSGI directory name. When we removed that, everything started working as expected.
It seems that you have a shared install where the product you would like to update is (potentially) used by many installations as a base - and therefore cannot be updated.
This kind of problem goes beyond what can be answered well on stackoverflow because you'd really need to provide an example project and exact steps to reproduce the problem.
The most plausible cause for the symptoms you are seeing is some kind of file system permission problem. This documentation mentions that you need write permission to the installation directory for running Eclipse with -initialize. Maybe you are lacking some permissions making some of the -initialize procedure fail and leave the installation in an inconsistent state.
Related
I have a msi component which deploys a file MyFile.dll. I have a test machine in which my product already deployed MyFile.dll, which has version 09.99.99.99.
Now I'm writing a major upgrade which will deploy a new version of MyFile.dll with version 05.23.76.123. After execution on the test machine, MyFilee.dll is removed... I need to change or repair to correctly deploy it.
How can I force the deployment of MyFile.dll regardless of its injected version number?
PS: This is happening on our test machines only. The product we delivered to our users has files with version numbers consistent with release history.
There are several ways in Windows Installer to do this but they all have their complications. IMO I would just rebuild the same source code as the old DLL but with a newer higher version and keep it simple.
This is perfectly possible. As said here, you may specify the REINSTALLMODE property and set it to "amus" or "dmus" depending on whether you want to always overwrite files or simply overwrite files with different version:
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
Note that you'll get this warning when compiling your installer though:
warning LGHT1076: ICE40: REINSTALLMODE is defined in the Property table. This may cause difficulties.
Downgrading a file isn't really straightforward and has issues. As pointed out earlier, you can change the component GUIDs and get this to work. However, it really depends on where your RemoveExistingProducts is sequenced. If its sequenced at a point where the older product is removed and the newer product is installed, then it might work.
There is not really a straight forward and documented way. All the available options are just hacks.
Is this just for your test environment?
If yes, then you could use REINSTALLMODE="amus" in the property table and achieve what you are looking to.
However, this is just for your testing and is not advised to be suggested to your end users.
Regards,
Kiran Hegde
I've inherited a C#/NHibernate/MS SQL Server project and am new to NHibernate. One of the first tasks given to me was to migrate the database from MS SQL Server (2008 R2) to Postgresql 9.2. I'm using the Npgsql 2.0.12 (.net 2.0 version). The Mono.Security.dll and Npgsql.dll are included in my project References and they exist in my bin directory. When the code executes the following line:
SessionFactory.OpenSession();
an exception is thrown with the message
"Could not create the driver from NHibernate.Driver.NpgsqlDriver."
Searching the web, gave me a few ideas but none have worked. This code I've inherited is in production at several clients with no issues using MS SQL Server. Here is my hibernate.cfg.xml file:
<?xml version="1.0" encoding="utf-8"?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.PostgreSQLDialect</property>
<property name="connection.driver_class">NHibernate.Driver.NpgsqlDriver</property>
<property name="connection.connection_string">server=localhost;Port=5432;Database=vehicletracker;User Id=postgres;Password=********;</property>
</session-factory>
</hibernate-configuration>
I did not forget to include "using Npgsql;", it is there. Any suggestions?
Regards,
B
I found the answer to my own question. There were several issues specific to my work environment but ultimately the Mono.Security.dll and Npgsql.dll were not available in my final output directory. The two files were present in the bin directory of my Data Access Layer (a class library) but not in the bin directory of my Test Project that called the class library. Everything is working fine now.
If you're using NuGet for the nhibernate libraries try uninstalling the packages and reinstall them. I'm sure there is a more efficient way someone knows of to fix this kind of issue but for me it solved this exact issue.
I'm producing plugin's for eclipse - but for some reason when I build a new version of the plugin - the update site isn't noticing it.
The build process says that the plugins should be at version 1.1.0.201209191506, but when I access to install I'm shown these versions:
The XML file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<site>
<feature url="features/supportStructuresForCSFEditing -_1.1.0.201209191506.jar" id="supportStructuresForCSFEditing -" version="1.1.0.201209191506">
<category name="plancomps"/>
</feature>
<feature url="features/supportStructuresForCSFEditingTest -_1.1.0.201209191506.jar" id="supportStructuresForCSFEditingTest -" version="1.1.0.201209191506">
<category name="plancomps"/>
</feature>
<category-def name="plancomps" label="plancomps"/>
</site>
and this happens if I'm installing from local or from the web - any idea what might be happening? Or diagnostic tricks I could try?
EDIT - there have been restarts of the machine - and attempts from machines that have never seen the plugin's before - all have shown the old versions. :(
I'd check two things.
1) I think that due to a bug, sometimes features are removed from category (if you use GUI to update your site). So you might be looking at your plug-ins in your category, when latest version is at top level or vice-versa.
2) Eclipse caches current state of update site. So you need to restart, to make it show newer versions.
Most likely, your cache is not being updated. p2 will often cache update site content information. It looks like you are using old style update sites and that you do not have a content.xml(or .jar) and a artifact.xml(or .jar), which is not really supported any more and may make it harder to delete the cache.
Here are somethings you can try:
Help -> Install new software -> Available software sites -> (Select your update site) -> Reload
Delete and re-add your update site
Restart eclipse with the -clean option to clear out the configuration area
But, really you should be making sure that you are creating artifact.xml and content.xml (or .jar) and creating proper update sites.
Okay, so coming back to this I have a reason and a workaround.
Eclipse's caching is pretty aggressive. But something I was doing wasn't helping and I thought I'd share.
When I was building a new version of the plugin, I was deleting the previous one (which made sense to me, generally the previous one was an internal buggy thing and I could have always reconstructed it from the svn). However when I started leaving the previous versions in, the update site started working much more as expected.
I imagine the issue is already solved for the OP, but I thought I'd share:
I just spent 2+ hours fighting with a very similar problem and finally managed to solve it. I'm not sure whether my solution can be applied to this case. My case was like this:
I created some plugins and uploaded them to a software site I had also created.
In a default.target file I added the plugins from that software site.
I realized there was an error in one of the plugins, created it again, uploaded it to the software site, and clicked "Update" for that site in my default.target.
The plugin never got reloaded. Even when I deleted the update site, eclipse "magically" still saw it and pretended to update from there when I clicked update. Fun fun fun.
I tried all kinds of things and this is the only one that worked for me in the end (I'm going to assume that you have a default.target as well):
Remove the plugins that aren't being updated from your default.target.
Exit eclipse (at least the instance for the problematic workspace).
Backup your workspace, or at least default.target and <pathToYourWorkspace>\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\. It may be difficult to revert the following changes if you need to.
In <pathToYourWorkspace>\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\:
Open artifacts.xml and delete all references to the plugins that aren't being updated. Note that there may be multiple references to each plugin; for example in my case I have one with 'classifier='org.eclipse.update.feature' and one with classifier='osgi.bundle' (I'm using OSGi).
Open subdir features and delete the folders corresponding to the plugins that aren't being updated. (Sorting by date may help. Btw, in my case the "date modified" for those jars showed that they had only been downloaded the first time and never updated again)
Open subdir plugins and delete the jars corresponding to the plugins that aren't being updated. (Sorting by date may help. Ditto)
Open eclipse again, with the options -clean and -data <pathToYourWorkspace> so that it cleans the workspace.
Add the plugins to default.target.
If there are still problems try selecting the plugins or update site and clicking "Update", and/or restarting eclipse.
This almost drove me crazy. I hope this helps someone.
I think you first use a fresh copy of eclipse to add a plugin,if that plugin is already installed.Copy eclipse.zip in new folder,unzip it ,run eclipse and then start using update site to do this please
Help-->Install new software-->"paste update site url"-->It will catch updates-->click ok-->accept license-->"continue process"-->It gives a warning press Ok " now you are success in updating.
Note:An internet connection should be properly available.
I just spent a half hour debugging some new code that's not broken because I forgot to check (again!) my logs for this dreaded message:
WARN openjpa.Enhance - Creating subclass for ...
I'm running OpenJPA 2.1.0 inside an OpenEJB 3.2 snapshot build, Java 1.6.0_25, and Eclipse Helios. My entities are enhanced using the ant PCEnhancerTask.
My META-INF/openjpa.xml contains
<property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" />
<property name="openjpa.DynamicEnhancementAgent" value="false" />
Is there anyway with this EE configuration to have OpenJPA enforce the RuntimeUnenhancedClasses option as it does in an SE configuration?
I suspect my 'real' problem stems from an Eclipse svn update that sometimes touches my JPA entity source, causing a build that overwrites my enhanced classes.
It's frustrating how often I run a unit test from the IDE that fails in some weird way, and I go digging through my code looking for a problem when all I need to do is run the enhancer.
Put the <property name="openjpa.RuntimeUnenhancedClasses" value="unsupported" /> META-INF/persistence.xml.
Looks like we're logging this action on debug level (maybe it should be info level), but OpenEJB will set that property to the default as it was in OpenJPA 1.x so that apps that worked with OpenEJB 3.1.x/OpenJPA 1.x will still work without modification in 3.2.x. If the property is already set in the persistence.xml it will never be overridden, so setting it there will have the effect you want.
Open to suggestions on how to save others in the same boat some time in the future. Seems either looking in the openjpa.xml file and seeing the property set already or issuing the log message on info would do it -- or both.
It sounds like for whatever reason your properties aren't being picked up when running in the container.
I have a number of possible solutions:
Try setting your properties in META-INF/persistence.xml. I assume you have these properties in the openjpa.xml file for a reason, but it might help us figure out where the real problem is.
Set -Dopenjpa.RuntimeUnenhancedClasses=false as a JVM property. This will apply to all PUs for a given JVM.
Move to a version of OpenJPA that is >= 2.0.0. RuntimeUnenhancedClasses was turned off as the default behavior in that release.
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).