- This topic has 14 replies, 5 voices, and was last updated 14 years, 7 months ago by
.
-
Posts
-
Since upgrading to 7.5 the other day, I’ve been running into a very annoying issue. Sometimes when I to add a deployment in the Project Deployments popup, a workspace build will kick off and never end. When this happens, all the project that are dependents of the webapp projects get their .project files changed. It looks like MyEclipse is trying to build/deploy them even though they are not meant to be directly deployed. Is this a known issue? Are there plans on fixing this? When it happens, I have to turn off auto-deploy, stop the build (which usually takes about 3 or 4 attempts), stop the deploy, replace the .project files with the originals, turn back on auto-deploy, and then redeploy the webapp to get it to work.
Can you clarify:
1. What server are you deploying to?
2. Is Project->Build Automatically checked?
3. What is a structure of your deployment (i.e. “2 web modules – A and B, A uses Java project libA and B uses libA and libC)?
4. Is there any details in the ${workspace}/.metadata.log?
5. Is there any more specific tasks showing (Build Workspace usually has many subtasks – i.e. “Validation”).
6. What are the changes in the .project file?1, JBoss
2. Yes
3. It happens when I add a new deployment for a single webapp project that points to multiple java projects. Only the dependent projects will have their .project files changed.
4. No
5. It always shows two tasks. One is a task that says “Building workspace” and always seems to say “Deploying ….” The other says “Add Deployment (Blocked: The user operation is waiting for “Building workspace” to complete.)” and underneath it says “Deploying … to JBoss 4.x: Refreshing ‘…’.”
6. It adds a <buildCommand> called “com.genuitec.eclipse.ast.deploy.core.DeploymentBuilder” and a <nature> called “com.genuitec.eclipse.ast.deploy.core.deploymentnature”Just as a note, this only happens when you add a new deployment. Doing a redeploy does not cause it to happen. If I undeploy and then deploy again, it will happen 100% of the time. This problem did not happen in 6.0, 6.6, or 7.1.
Still can’t reproduce – might depend on project size/workstation performance…
Do you keep this change in the .project files or restore them from CVS? If you keep the change and restart the workbench – does it happen again?
I am restoring them from cvs every time. In an earlier test, I tried deploying with the modified .project files and experienced the problem but now I cannot reproduce it, so I guess the solution is to update all the .project files in cvs. If they have that builderCommand and nature then it seems ok. The problem just seems to happen if any dependent project doesn’t have it.
This builder and nature will be used by MyEclipse from now on for all projects that are part of the deployment. The build behavior is a bug I will report it to our bug tracker.
Just to clarify an observation…
We have a webapp that is dependent on numerous other projects. All of the dependent projects now have the com.genuitec.eclipse.ast.deploy.core.DeploymentBuilder and com.genuitec.eclipse.ast.deploy.core.deploymentnature in their .project file. Things are working/deploying ok except for one MAJOR annoyance: if we clean any one of the dependent projects, then the builder seems to be cleaning the webapp’s deployment and redeploying the entire webapp instead of just the files that were recompiled in the dependent project, i.e. all class files in the exploded war are updated. We have several webapps deployed that all depend on a similar set of projects. So if we clean a dependent project it is redeploying ALL webapps that depend on that project. To make things worse, if I clean 2 dependent projects at the same time, then it will clean and redeploy all webapps twice. 6 webapps + cleaning 4 projects = 24 redeploys. I’m also guessing that the multiple redeployments for every webapp is the cause of the never ending build noted in the original post.Please advise if there is anything we can do to bypass all of these unnecessary deployments. I did do a quick test of removing the builder and nature from a dependent project and noticed that the the deployments are skipped and only the dependent project’s updated class files are redeployed. However, I’m assuming that this will cause other issues and that myeclipse will just add the builder/nature back in as noted in the original posting.
Vegas,
We are going to evaluate how to improve this behavior towards the end of this week and see if we can get these heavy-handed cases to stop.
Out of curiosity, are you using exploded or packaged deployments?
We just tried MyEclipse 8.0 and experienced the same problem.
Cleaning 1 dependent project with 0 deployments = 45s
Cleaning 1 dependent project with 1 deployment = 1:25s
Cleaning 1 dependent project with 2 deployment = 1:50sCleaning 2 dependent projects with 0 deployments = 1:30s
Cleaning 2 dependent projects with 1 deployment = 2:40s
Cleaning 2 dependent projects with 2 deployment = 3:40svegas,
I just wanted to say that we have fixed this issue for 8.5 M2 which is due in under a month. Sorry for the inconvenience caused until then.
I’ll ping this thread when 8.5 M2 is available, – would appreciate it if your team could give it a spin and let us know if everything works as expected.
We appreciate your patience and help in tracking this down.
@Support-Brian wrote:
vegas,
I just wanted to say that we have fixed this issue for 8.5 M2 which is due in under a month. Sorry for the inconvenience caused until then.
I’ll ping this thread when 8.5 M2 is available, – would appreciate it if your team could give it a spin and let us know if everything works as expected.
We appreciate your patience and help in tracking this down.
I’ll have to do some more testing, but it looks like this was fixed in 8.5GA.
