This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
when doing a clean and build on a web project the ide undeploys the project from the application server (glassfish v2UR2) on the remote host , but does not redeploy the project after the build has been done. If the build process is not going to redeploy the the process should NOT undeploy the application. This behavior does not apear to be configurable and occurs regardless of the "Deploy on Save" feature in the project properties being checked or not.
Reassigning to web.
Any idea PetrH?
This is intentional. The "Clean and Build" is nothing more that Clean and Build literally. So if you are cleaning the project you are effectively cleaning the artifacts server is using. Other reason is that in most cases clean would not be successful at all (due to jars locked by server). You can always use standalone Build or Run. Clean should definitely undeploy the project.
This has not been the behavour prior to this release. We have a set of automated unit tests constantly running on an environment , the fact that a developer want to do a local clean and build prior to deployment to make sure all artifacts build correctly, should NOT affect the currently running unit test by undeploying the existing build. This is especially an issue when more than 1 developer is using a single development environment. I believe that this behavour should be at least configurable, if not removed. Regards Tim
We can agree that this could be avoided for remote deployed apps. For directory based deployments the clean without undeployment does not make much sense and it is almost sure it will fail in windows environments. The workaround for your testing environment is to remove undeploy-clean dependency from clean target.
I agree for local directory deployment, you are right it doesn't make sense not to undeploy the application, windows does complain if the application is not undeployed first, Thanks for the work around.
changing this enhancement. We need to handle remote deployment as a special case.
I STRONGLY disagree with this new behavior. I understand the need for undeploy on file system server and having it default that way for those projects is fine, but this is a BUG with regards to remote app (and a change from all previous behavior). Having to go back and check out an old revision of sources so you can (hopefully) quickly recompile and redeploy the production system before you get fired, simply because you forgot to switch your run settings to QA from production when you compiled does not seem like an enhancement to me. I don't even want it undeploying on our remote QA server simply for a clean and build as it will break tons of cross dependencies that other developers may be working on. Local filesystem deployment is not an option because the local workstations don't have direct access to the resources that the servers do. To me, the filesystem server is the special case not the remote server. Code compilation and application deployment are two entirely different acts and should be decoupled, other than where you are doing test deployments on the local install of the server. With this the way it is, all 100 or so of our projects will have to be opened up in 6.5, have the build script edited, and recommited to svn and all developers local sources updated so that zznewguy doesn't bring down qa when he checks out a project that hasn't been thusly modified and hits clean and build. Sorry, this just doesn't make any sense to me at all. Please, please, mark this as a defect, not an enhancement. (sorry for being a whiner)
*** Issue 159392 has been marked as a duplicate of this issue. ***
*** Issue 160069 has been marked as a duplicate of this issue. ***
I guess this really needs to be assigned to someone that works on the product....
I think this applies to all the various Java EE project types (ear, ejb jar, web app... and maybe app client)
*** Issue 153240 has been marked as a duplicate of this issue. ***
Fixed in web-main abd993ff3a8b.
Integrated into 'main-golden', will be available in build *200907080200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/abd993ff3a8b User: phejl@netbeans.org Log: #152594 clean and build undeploys webproject