MyEclipse :: View topic - User Ant Script Causes Inconsistent Project [Closed]

MyEclipse: User Ant Script Causes Inconsistent Project [Closed]

smacfarlane - Jul 28, 2003 - 06:11 PM
Post subject: User Ant Script Causes Inconsistent Project [Closed]

Occasionally (several times per day) after editing a source file and saving it, I suddenly have my tasks window full of errors and usually one of the first errors contains the message "Project May Be Inconsistent". In order to proceed the only work-around I have found is to delete the entire project from Eclipse and re-import it. After re-importing, all errors are gone as expected and I can continue as normal. This is quite frustrating and I have not been able to determine any predictable way of reproducing this yet. Can you elaborate on what this error means or what are the potential root causes?

wk5657 - Jul 28, 2003 - 09:26 PM
Post subject:

I have seen this error when something is edited with a non-eclipse editor. I try to never edit anything with non-eclipse editors.

Wayne

smacfarlane - Jul 28, 2003 - 09:32 PM
Post subject: re: Project May Be Inconsistent

I only use the built-in Eclipse editor so there must be other circumstances that can cause this problem.

support-scott - Jul 28, 2003 - 10:00 PM
Post subject:

Quote:

Well, I've checked around with the staff and not only is this not one of our messages, no one has ever seen or heard of it before. Which is really odd considering we've all been using Eclipse daily since day one.

Did you try refreshing the project and then rebuilding it? This will cure most ills.

Do you have external plugins in your Eclipse installation?

What's your platform, Eclipse version and build id, and JDK version?

What's the setting of Window > Preferences > Workbench > Perform Build Automatically on Resource Modification? Both before and after the problem is encountered? Yes, sometimes this setting seems to "change itself".

What's odd about your environment that you're not telling us? ;-)

--Scott
MyEclipse Support

smacfarlane - Jul 28, 2003 - 10:18 PM
Post subject:

Refreshing and re-building the project doesn't fix this one. I need to delete and re-import.

I am using the Checkstyle plug-in v 3.1.1 and the Metrics plug-in v1.3.3 but also noticed it with earlier versions of these plug-ins.

I am using Windows, Eclipse version 2.1.1, build id: 200306271545, JDK 1.4.2 but also noticed it with earlier versions of all of the above.

Perform build automatically on resource modification is checked on. I'll check next time whether that value changes after the error occurs.

I suppose this could be a Checkstyle or Metrics issue? I'll check those forums for any related posts.

Thanks for any possible feedback on this - it's quite irritating.

support-scott - Jul 28, 2003 - 11:15 PM
Post subject:

Quote:

I suppose this could be a Checkstyle or Metrics issue?

Those would be my suspects. I've never seen the problem with Eclipse itself. It seems that the internal state management for one of those plugins may be going into a non-recoverable state. Try running on a clean install (with MyEclipse installed, of course :-) and I can almost guarantee you won't see this again.

--Scott
MyEclipse Support

smacfarlane - Jul 29, 2003 - 11:21 PM
Post subject:

I have fully removed both Checkstyle and Metrics plug-ins and restarted the IDE but continue to see this problem. The actual text of the error message is:
"A class file was not written. The project may be inconsistent, if so try refreshing this project and rebuilding it."
As soon as this error happens it also starts reporting errors against virtually every import statement in every file in the project which all go away after re-importing the project.

I am using the JBoss 3.2.1 integration in MyEclipse and doing run-time debugging. But this problem happens when JBoss is not running as well as when JBoss is running.

I have a web project as well as an EJB project. The EJB project is deployed as a separate EJB.jar as well as it produces a library that I add to the lib directory of the web project which includes EJB client code and other common shared classes.

Any other ideas?

support-scott - Jul 29, 2003 - 11:27 PM
Post subject:

If it was me? I'd install a completely clean Eclipse 2.1.1 version from a fresh download off of our website, install MyEclipse, copy my projects to the new workspace, import them, and go from there.

Sometimes when the going gets this weird its a lot less expensive just to punt and start over. It really sounds like your Eclipse workspace has "gone bad" for some reason. I remember that Eclipse.org announced a workspace repair utility awhile ago, but personally, I'd just start fresh. In the end, I think this will be the fastest way to resolve this issue.

--Scott
MyEclipse Support

smacfarlane - Jul 29, 2003 - 11:32 PM
Post subject:

That's exactly what I did when I upgraded to 2.1.1 last week. I was seeing this problem before doing the fresh clean install of the latest version and I continue to see the problem now. Hmmm....

support-scott - Jul 30, 2003 - 12:07 AM
Post subject:

You know, now that I think about it, people have been reporting various problems with the combination of Eclipse 2.1.1 and JDK 1.4.2. Why don't you try downloading JDK 1.4.1 and see if using this clears things up? And, just to be clear, you were seeing this problem before and after you installed MyEclipse, correct?

Of course, it could be something environmental with your machine. Are there any exceptions in the log file (<workspace>/.metadata/.log) ?

--Scott
MyEclipse Support

smacfarlane - Jul 30, 2003 - 12:24 AM
Post subject:

I was seeing these errors previously when I used JDK 1.4.1.
I was seeing these errors before installing MyEclipse but at that time I was using the EASIE JBoss plug-in downloaded in April. Don't recall seeing these errors prior to using the EASIE JBoss plug-in but can't be sure.

I did find a few exceptions like the one included below in the log file. Not sure whether this is relevant or not. The source code for the 'ListDataBean.class' is in my EJB project.

This may be a bit of a stretch whether it is related but...
I have noticed that when I'm doing run-time debugging with a project deployed to JBOSS, MyEclipse allows me to edit source files, save them, and the changes immediately take effect without re-starting JBOSS. i.e. they are 'hot deployed.' This is a very convenient debugging feature. I was a little surprised that this works since I do JBOSS deployments with an Ant script so I'm confused how my code changes in Eclipse get hot deployed and supercede the previous ant deployment I did. Could this be causing Eclipse some confusion about where to find the .class files for compilation? May be running off on a tangent here but... ?

Here is the log file:
!SESSION Jul 29, 2003 16:05:05.145 ---------------------------------------------
java.version=1.4.2
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86 -install file:C:/eclipse/
!ENTRY org.eclipse.jdt.core 4 4 Jul 29, 2003 16:05:05.145
!MESSAGE JavaBuilder handling CoreException
!STACK 1
org.eclipse.core.internal.resources.ResourceException: File not found: C:\cvs\MedAccess\Framework\build\bin\net\medaccess\framework\integration\to\ListDataBean.class.
at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:398)
at org.eclipse.core.internal.resources.File.getContents(File.java:213)
at org.eclipse.jdt.internal.core.Util.getResourceContentsAsByteArray(Util.java:599)
at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileCheck(IncrementalImageBuilder.java:586)
at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.writeClassFileBytes(IncrementalImageBuilder.java:565)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.writeClassFile(AbstractImageBuilder.java:436)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.acceptResult(AbstractImageBuilder.java:111)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:350)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:195)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:145)
at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:110)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:205)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:133)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:427)
at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1006)
at org.eclipse.core.runtime.Platform.run(Platform.java:413)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:125)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:181)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:191)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:151)
at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1006)
at org.eclipse.core.runtime.Platform.run(Platform.java:413)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:165)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:243)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:212)
at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:884)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1600)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:2711)
at org.eclipse.jdt.internal.ui.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:183)
at org.eclipse.jdt.internal.ui.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:145)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:302)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:252)
at org.eclipse.jdt.internal.ui.refactoring.RefactoringWizardDialog2.run(RefactoringWizardDialog2.java:266)
at org.eclipse.jdt.internal.ui.refactoring.PerformRefactoringUtil.performRefactoring(PerformRefactoringUtil.java:53)
at org.eclipse.jdt.internal.ui.refactoring.RefactoringWizard.performFinish(RefactoringWizard.java:363)
at org.eclipse.jdt.internal.ui.refactoring.UserInputWizardPage.performFinish(UserInputWizardPage.java:119)
at org.eclipse.jdt.internal.ui.refactoring.RefactoringWizard.performFinish(RefactoringWizard.java:426)
at org.eclipse.jdt.internal.ui.refactoring.RefactoringWizardDialog2.okPressed(RefactoringWizardDialog2.java:383)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:256)
at org.eclipse.jface.dialogs.Dialog$1.widgetSelected(Dialog.java:423)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:89)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:81)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:840)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1838)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1545)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:583)
at org.eclipse.jface.window.Window.open(Window.java:563)
at org.eclipse.jdt.internal.ui.refactoring.actions.RefactoringStarter.activate(RefactoringStarter.java:70)
at org.eclipse.jdt.internal.ui.refactoring.RefactoringSupport$AbstractRenameSupport.rename(RefactoringSupport.java:168)
at org.eclipse.jdt.ui.refactoring.RenameSupport.openDialog(RenameSupport.java:98)
at org.eclipse.jdt.internal.ui.refactoring.actions.RenameJavaElementAction.run(RenameJavaElementAction.java:147)
at org.eclipse.jdt.internal.ui.refactoring.actions.RenameJavaElementAction.run(RenameJavaElementAction.java:110)
at org.eclipse.jdt.ui.actions.RenameAction.run(RenameAction.java:127)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:193)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:169)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:842)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:456)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent(ActionContributionItem.java:403)
at org.eclipse.jface.action.ActionContributionItem.access$0(ActionContributionItem.java:397)
at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent(ActionContributionItem.java:72)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:81)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:840)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1838)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1545)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1402)
at org.eclipse.ui.internal.Workbench.run(Workbench.java:1385)
at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:858)
at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.basicRun(Main.java:291)
at org.eclipse.core.launcher.Main.run(Main.java:747)
at org.eclipse.core.launcher.Main.main(Main.java:583)
!ENTRY org.eclipse.core.resources 4 271 Jul 29, 2003 16:05:05.145
!MESSAGE File not found: C:\cvs\MedAccess\Framework\build\bin\net\medaccess\framework\integration\to\ListDataBean.class.

smacfarlane - Jul 30, 2003 - 12:35 AM
Post subject:

Problem just occurred again and I checked the Eclipse log file again. There was a new entry similar to the one previously posted looking for the .class file in the build\bin... directory. I checked that directory only to discover it doesn't exist. My Project Properties|Java Build Path|Default output folder = Framework/build/bin. I re-built the project, the .class files were re-created in the correct build/bin directory and the problem went away.

So I guess the question I now have is what could be causing my output folder containing my .class files to be removed?

smacfarlane - Jul 30, 2003 - 01:03 AM
Post subject:

[Sheepishly] Gee, I just realized my Ant build script also uses Framework/build as it's working directory and it has a clean target which erases that whole directory including the Framework/build/bin. I've now changed by Default output folder to Framework/bin to keep the Eclipse working directory separate from my Ant script working directory. I'm pretty sure this was the cause of my problem.

When you pointed me to the Eclipse log file, I think that ultimately started me down the road to this solution. Thanks very much for your help! What a relief!

support-scott - Jul 30, 2003 - 01:15 AM
Post subject:

Quote:

So I guess the question I now have is what could be causing my output folder containing my .class files to be removed?

This is better as we at least know specifically what the cause is. I'll take a guess as to why this directory is deleted and why it showed up when you started using JBoss. Your Ant deployment script is deleting it. Perhaps by accident, but my money is betting that the Ant script, in an effort to "clean things up" for the build deletes your entire output directory when it kicks off. Check it out; it makes perfect sense and fits the pattern of behavior very well. Also, Eclipse will hat it when you whack the output directory out from under it, as you've found.

By the way, rather than recompiling all your sources for deployment, you really should just repackage the ones that are already in the build output directory. Better yet, quit using your Ant script completely and use the MyEclipse exploded or archive deployments. :-)

Please let us know what you find out.

--Scott
MyEclipse Support

smacfarlane - Jul 30, 2003 - 01:20 AM
Post subject:

Thanks again for your assistance. As you can see from my previous post, you were right on the money regarding the ant script. I have been meaning to look into using the MyEclipse deployments. I'll definitely give that a try.

support-scott - Jul 30, 2003 - 01:33 AM
Post subject:

I see you cleverly snuck in your findings while I was drafting my well crafted reply. ;-)

Glad we simultaneously solved the problem. Now, I'm going to move this entire thread to 'Old Posts' so it doesn't mislead anyone else. :-)

--Scott
MyEclipse Support

jwyant - Nov 03, 2004 - 11:50 AM
Post subject: Class file was not written error

Another problem that will cause this error is a path name to a class file that is too long.

rjst - Jul 27, 2005 - 03:55 PM
Post subject: similar problem

Hi,

I have a problem similar to this one. Shouldn't eclipse recreate the directories when a Clean all is done ? I am a MyEclipse customer, and while I know this is a bit off-topic, it looked like the best dicussion of the problem I could find.

thanks
Ricardo