Whenever I run workspace.xml it updates the revisions stated in my project's module.revisions file. How can I stop this?
You need to set the EBuild property update-upstream to false.
To do this, edit workspace.xml and find it, making it look like the following:
<property name="update-upstream" value="false"/>
Related
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.
The question says it all. i'm using jrebel (5.5)
for hibernate plugin it says: "Enables automatic schema updating if hibernate.hbm2ddl.auto=update or schemaUpdate=true on org.springframework.orm.hibernate3.LocalSessionFactoryBean."
how can i disable it (or change)? it deletes and recreates (incorrect) my database schema on every start/stop and clean...
thx
Pardon,
i've found out that my full text search failed badly.
there was another setting for this in the persistence.xml. feeling dumb right now.
<property name="hibernate.hbm2ddl.auto" value="create-drop" />
change it to:
<property name="hibernate.hbm2ddl.auto" value="none" />
did it for me
I'm using a Postgresql database with eclipselink2.3 provider in JOnAS (Java environment). My configuration is :
persistence.xml:
...
<property name="eclipselink.ddl-generation" value="create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="database"/>
<property name="eclipselink.target-database" value="POSTGRESQL"/>
...
Postgresql version is
Version : 8.4.11-0squeeze1
JDBC driver version is
postgresql-8.4-703.jdbc3.jar
When database is empty, there is no problem.
My problem is when eclipselink.ddl-generation is set to create-tables and tables are already existing in data base, an error is occured and process doesn't not continue with the next statement as explained here.
Does anyone see a solution for that?
I don't see any property that would prevent throwin error in your case. So i would suggest the following. You should have 3 persistence.xml files for 3 different environoments: development, testing and production.
In development environoment you want to work with clean database, so
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
The same with testing environoment, but in this case I would use DBUnit to fill database with test data.
In production you don't want to mess with database structure so
<property name="eclipselink.ddl-generation" value="none"/>
is the right choice.
If you use ant or maven such configuration is fairly easy to accomplish (you might find examples in the net, since this is pretty standard approach).
I guess you will not like this answer ;), since this looks like quite a lot of additional work, but in the long run clean configuration and separation would pay off.
The "create-tables" option does not fail if the table already exists. It will log the error, but continue.
If you don't want to see the error, you can turn off logging.
What error do you get?
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.
Every time a new update is released for an application with click once, the variables in the app.config file are destroyed
<userSettings>
<app.My.MySettings>
<setting name="Email" serializeAs="String">
<value />
</setting>
<setting name="UserName" serializeAs="String">
<value />
</setting>
</app.My.MySettings>
</userSettings>
How can i prevent that?
Is there any way of feching the variables from the previous application version?
Do you have the "Applications should check for updates" option checked?
Have a look at Exploring Secrets of Persistent Application Settings (the section titled "Maintaining Settings Between Program Versions"):
For any settings from the current
version that match settings in the
prior version, this routine will
import them into the current version's
user.config file:
At the entry point to your program, place the following code.
if (Properties.Settings.Default.UpgradeSettings)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpgradeSettings = false;
}
Note that UpgradeSettings is a boolean user setting (not application) that you need to add yourself, and you want the default value to be True.
If you use user-level settings instead of application-level settings, it will copy them forward when a new version is retrieved.
The safest thing to do, though, is to separate this data from the ClickOnce update, uh, "experience". See if this helps:
http://robindotnet.wordpress.com/2009/08/19/where-do-i-put-my-data-to-keep-it-safe-from-clickonce-updates/