[apcausey]

I recently upgraded to MyEclipse 5.0.1 GA and tried to create a WAR file for Tomcat for one of my projects that I’ve always been able to create a WAR file for in the past. When I try to create the deployment, I am getting the following error:

Deployment is out of date due to changes in the underlying project contents.  You'll need to manually 'Redeploy' the project to update the deployed archive.

I read through some other posts and tried what was suggested, but nothing worked. I also tried the following:

-stopping Tomcat, removing the deployment, refreshing the project, executing a clean all, and then redeploying

-I have also restarted MyEclipse several times and tried redeploying

-I have made sure that Tomcat isn’t running, etc.

I have tried all of the ‘obvious’ things to get this working – is this a known bug in the latest version of MyEclipse?

MyEclipse 5.0.1 GA
Eclipse 3.2
Windows XP SP 2
Tomcat 5.5.17
CVS for source control

[Riyad Kalla]

Is this project special in any way? Does it have other project dependencies or is it just a straight normal project? Did you try restarting using the -clean command line argument?

[apcausey]

@support-rkalla wrote:

Is this project special in any way? Does it have other project dependencies or is it just a straight normal project? Did you try restarting using the -clean command line argument?

It isn’t really special in any way, except I do have two other projects on the build path. It is using some JAR files contained in these other projects.

The weird thing is, I can create the WAR file okay using MyEclipse 4.1.1.

[Riyad Kalla]

Did you try refreshing all 3 projects, then going to Project > Clean and cleaning all 3 projects?
If so, can you check your log file (<workspace dir>\.metadata\.log) for any errors that might point us in the right direction?

[apcausey]

@support-rkalla wrote:

Did you try restarting using the -clean command line argument?

-clean doesn’t help either.

[apcausey]

@support-rkalla wrote:

Did you try refreshing all 3 projects, then going to Project > Clean and cleaning all 3 projects?
If so, can you check your log file (<workspace dir>\.metadata\.log) for any errors that might point us in the right direction?

I tried this, and the .log file contains this message after trying to build the war:

!SESSION 2006-09-07 16:18:28.510 -----------------------------------------------
eclipse.buildId=M20060629-1905
java.version=1.4.2_03
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments:  -product com.genuitec.myeclipse.product.ide
Command-line arguments:  -os win32 -ws win32 -arch x86 -product com.genuitec.myeclipse.product.ide

!ENTRY com.genuitec.eclipse.ast.deploy.core 1 0 2006-09-07 16:20:48.526
!MESSAGE Build Exception
!STACK 0
com.genuitec.eclipse.core.GenuitecCoreException: Exception deploying TSCommonJ2EE14
    at com.genuitec.eclipse.ast.deploy.ant.J2EEArchiveDeployer.privExportWebProject(Unknown Source)
    at com.genuitec.eclipse.ast.deploy.ant.J2EEArchiveDeployer.exportWebProject(Unknown Source)
    at com.genuitec.eclipse.ast.deploy.core.DeploymentPackager.exportWebProject(Unknown Source)
    at com.genuitec.eclipse.ast.deploy.core.WebDeployment.deployAsPackageArchive(Unknown Source)
    at com.genuitec.eclipse.ast.deploy.core.Deployment.deploy(Unknown Source)
    at com.genuitec.eclipse.ast.deploy.core.ui.wizard.NewDeploymentWizard$2.run(Unknown Source)
    at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
Caused by: org.eclipse.core.runtime.CoreException: Exception deploying TSCommonJ2EE14
    at com.genuitec.eclipse.ast.deploy.ant.J2EEArchiveDeployer$1.run(Unknown Source)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
    ... 7 more

[Riyad Kalla]

What is wrong with “TSCommonJ2EE14”? Is that a User Library you created? You might navigate to your build path and expand that container to see if there are any error or warning markers. The reason you might not have noticed this before (for example if you reinstalled Tomcat to a new dir, and all the paths in this container are now broken) is that Tomcat ships all these libs, so it might “run” fine, but having broken libs in your build path can cause the deployment manager to flip out.

[Author]

Posts