Application Version number being changed by Developer Studio


#1

Am am having a very annoying issue where Developer Studio is changing the application version I am setting to the previous value. For example, I open a project in my workspace, open generated.c, change the application version number from say 1.18.0 to 1.19.0. I save generated.c, and close the project. When I open the project again, the version number is set back to 1.18.0! This is extremely annoying, and is resulting in me releasing code with the incorrect version number embedded in the units.

[Edit] This might have something to do with SVN integration. I found that if I change the version number, then commit the code, close the project, re-open it then the version number is correct!


#2

Hi,

It should not be the case.If version number is changed in generated.c file and saved it.And after closing the project and reopening it,it should be the new(changed) version.

Did you check with other applications built on other OS packages.

Thanks.


#3

generated.c file is generated from metadata persisted in .settings/.ebsdata file.
The behavior you’re describing seems to show that metadata was not correctly saved to disk, making the source file to be re-generated with old metadata when it’s read from disk on project re-opening.
Is your .ebsdata file in read-only mode? (shouldn’t be… Anyway, in such a case DS should warning you with a warning marker on the project)


#4

Doesn’t appear to be.



#5

Is changing the generated file directly supported even?
I mean, does the metadata get updated if you manually change the c file?

Or is changes only supported through the Application Settings page?


#6

I’m pretty sure that any “manual” changes to the generated.* files just get overwritten from the metadata


#7

Indeed, generated.c doesn’t support manual edition.
If the way the code is generated is not suitable for any reason, sections of the files can be enabled/disabled is needed, or the code generation itself can even be completely disabled. But this means that the code usually handled by the Application Settings editor will have to be manually handled.

@tomridl
Can you check if there are exceptions in the workspace log, which could help us to analyze the behavior?
Fastest way to gather information: Help > Build Technical Report, add your project (eventually without the source code if it’s confidential) and export the report archive before posting it here (or in PM)


#8

So can we enable it initially so that a proper “outline” is auto-generated, and then disable it so that the generated.* files can be manually maintained :question:


#9

@daav PM’d you a technical report.

Seem to get this error in the log a lot:

!ENTRY com.wavecom.openat.ide.ebs.core 4 0 2013-04-15 09:46:46.238
!MESSAGE The resource tree is locked for modifications.
!STACK 1
org.eclipse.core.internal.resources.ResourceException: The resource tree is locked for modifications.
	at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:116)
	at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2282)
	at org.eclipse.core.internal.resources.Resource.deleteMarkers(Resource.java:844)
	at com.wavecom.openat.ide.ebs.core.macros.generic.LibraryFilesMacroResolver.getValues(LibraryFilesMacroResolver.java:62)
	at com.wavecom.openat.ide.ebs.core.macros.AbstractGenericMacroResolver.getMacro(AbstractGenericMacroResolver.java:74)
	at com.wavecom.openat.ide.ebs.build.core.BuildMacroSupplier.getMacroValue(BuildMacroSupplier.java:106)
	at com.wavecom.openat.ide.ebs.build.core.BuildMacroSupplier.getMacros(BuildMacroSupplier.java:160)
	at org.eclipse.cdt.managedbuilder.internal.dataprovider.ExternalExtensionMacroSupplier.getVariables(ExternalExtensionMacroSupplier.java:189)
	at org.eclipse.cdt.utils.cdtvariables.SupplierBasedCdtVariableManager.getVariables(SupplierBasedCdtVariableManager.java:56)
	at org.eclipse.cdt.managedbuilder.internal.dataprovider.BuildVariablesContributor.getVariables(BuildVariablesContributor.java:149)
	at org.eclipse.cdt.internal.core.cdtvariables.BuildSystemVariableSupplier.getMacros(BuildSystemVariableSupplier.java:115)
	at org.eclipse.cdt.internal.core.cdtvariables.CoreMacroSupplierBase.getVariables(CoreMacroSupplierBase.java:34)
	at org.eclipse.cdt.utils.cdtvariables.SupplierBasedCdtVariableManager.getVariables(SupplierBasedCdtVariableManager.java:56)
	at org.eclipse.cdt.internal.core.cdtvariables.CdtVariableManager.getVariables(CdtVariableManager.java:82)
	at org.eclipse.cdt.internal.core.settings.model.CConfigurationDescriptionCache.loadData(CConfigurationDescriptionCache.java:136)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescription.loadDatas(CProjectDescription.java:194)
	at org.eclipse.cdt.internal.core.settings.model.xml.XmlProjectDescriptionStorage.loadProjectDescription(XmlProjectDescriptionStorage.java:493)
	at org.eclipse.cdt.internal.core.settings.model.xml.XmlProjectDescriptionStorage.getProjectDescription(XmlProjectDescriptionStorage.java:235)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.getProjectDescriptionInternal(CProjectDescriptionManager.java:436)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.getProjectDescription(CProjectDescriptionManager.java:418)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.getProjectDescription(CProjectDescriptionManager.java:412)
	at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.getProjectDescription(CProjectDescriptionManager.java:405)
	at org.eclipse.cdt.core.CCorePlugin.getProjectDescription(CCorePlugin.java:1276)
	at com.swi.cdt.settings.project.AbstractCdtProjectHelper.getDescription(AbstractCdtProjectHelper.java:293)
	at com.swi.cdt.settings.project.AbstractCdtProjectHelper.getConfigHelpers(AbstractCdtProjectHelper.java:539)
	at com.swi.cdt.settings.project.AbstractCdtProjectHelper.refreshDependencies(AbstractCdtProjectHelper.java:810)
	at com.swi.cdt.settings.listener.ProjectDescriptionChangeListener.resourceChanged(ProjectDescriptionChangeListener.java:70)
	at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:291)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:285)
	at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
	at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:395)
	at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1530)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:45)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
!SUBENTRY 1 org.eclipse.core.resources 4 380 2013-04-15 09:46:46.238
!MESSAGE The resource tree is locked for modifications.

#10

Are you creating new projects so often that it is a pain to disable code generation after each creation?

Got it, and reproduced the issue.
It is not linked to exception, but something is clearly broken in the editor saving mechanism --> will ensure it will be fixed for the next version.
Meanwhile, a workaround: save the editor two times! (the second one by simply “forcing” the editor to become dirty, e.g. by entering any character in the version field + deleting it)


#11

Not really - just wondering if that’d be the way to do it?


#12

Ok, will try to remember :slight_smile: