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.
If a project targets a server that supports directory deployment, the processing for 'Deploy' or 'Run' should not spend time creating archives that will not be used. As projects transition from prototype to enterprise scale the time necessary to create these archives starts to consume a significant amount of time.
this applies to all source-based project types in the j2ee that support directory deployment: ear, ejb and web
66120150
Not planned for 7.0
I recall a similar bug for Nb 5.5 or nb 6.x, and at that time it was fixed, because it was killing the directory deployment experience. So this would be a regression. It should even fixed before NetBeans 7.0, in a patch update of NetBeans 6.5 Please, invest time to find the regression, and retract the previous comment:-) Thanks.
Sorry.. didn't know the seriousness of this issue. It will be fixed in (or before) 7.0. Thanks.
Can you look into this please ?
Seems like more than an EJB issue, Trey, please evaluate, thanks -Jayashri
For the web project the ant task compile-jsps is causing the war file to be created. Specifically it is the use of the JspC class. It looks like the class org.apache.jasper.JspC is what is creating the war file. I am still looking into the rest of the projects.
Ok after more investigation I no longer think the jspC is the problem.
For the web project the problem is that the call Deployment.getDefault().canFileDeploy(instance, mod); is returning false. Therefore the build scripts do not think that directory deployment is possible. Now this is strange. If you do a clean first then execute the deploy action or the run action is when this method will return false. If you do not perform the clean first the call will return true.
For the web project is in the Deployment.canFileDeploy(...) method. The method not only checks if the server can handle server deployment, but also makes sure that the build/web directory is available. The first time a project is build, or when the users does a clean before deploying the build/web directory is now available. The change was made in the change set. http://hg.netbeans.org/main/rev/66f17c625d6e
I do not know if I agree entirely with ludo's comment. It looks like logic was put into the web project build to keep the jar from being built, but it was never put into the enterprise projects.
part of fix : http://hg.netbeans.org/main/rev/67faf0ddb79b
Integrated into 'main-golden', will be available in build *200812121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/67faf0ddb79b User: vince kraemer <vkraemer@netbeans.org> Log: #152724: minor contribution to final fix. code too protective of canFileDeploy()
The EJB Project and the Web Project is now working correctly. However the ear project is not. This seems to be more of a deployment issue. So I am going to reassign this issue to the deployment area. http://hg.netbeans.org/main/rev/8ba0432dbb7e http://hg.netbeans.org/main/rev/c56b369a573e
BTW, is this server-specific, or is this an issue with some servers only? Do the v3 daily builds support EARs yet?
this issue was originally filed against j2ee/code... I do not know why Trey moved it to web. So, it isn't really a regression... i would guess that we would have to say this is GlassFish specific, since none of the other server integrations support directory deployment of ear projects...
Assigning to j2eeserver per Trey's comment. Petr H, can you please evaluate? If you decide the fix should be done on the ear project side, please reassign to ear project. Thanks.
I've added similar logic to EAR - main 07910258ef1e. David please can you check? However GFv2 is returning false when asking IncrementalDeployment.canFileDeploy() - reassigning.
Petr, your fix looks fine to me.
your code change triggered an NPE: issue 159641. I fixed the NPE.
Created attachment 77742 [details] output from Deploy action on EAR project
watched the return values from the plugin's canFileDeploy() method while doing the deploy. the ant output is attached to the issue. never saw a false.
Integrated into 'main-golden', will be available in build *200903060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/07910258ef1e User: phejl@netbeans.org Log: #152724 Unnecessary archives being created
Steps to reproduce: 1) stop the server 2) deploy the application 3) canFileDeploy() returns false
I have spent about three hours trying various interpretations of your 'Steps to reproduce', but have not been successful. Would you please step into canFileDeploy(Target,J2eeModule) and tell me which line sets retVal to false. Additional details like the JDK and OS may be important, too.. How about the project, too... Which version of GF are you using when you get the false? I am using jdk 5 update 7, Solaris 10 and GF 2.1 (b60e)
The incomplete may be blocking the attention this needs. Petr: please assign back to me once you have provided requested info.
Ok. I'll try to be more accurate. 1) Register GFv2 2) Create EAR (including web and ejb) in the IDE, nothing more 3) Push Run button 4) Line 265 in DirectoryDeploymentFacade return false because checkIssue2999 is false. Happens only when server is stopped (and maybe on the first IDE run). Reproducible on current trunk, JDK 1.6.0_10, GF version reported in log is "Sun Java System Application Server 9.1_02 (build b04-fcs)". Ubuntu 8.10. I don't think it is platform or JDK specific. Perhaps checkIssue2999 is always false when server is not yet running.
phejl: thanks for the additional info.
http://hg.netbeans.org/web-main/rev/3aa8bf1ecf0c but, I still see archives being created...
The impact of this issue is now match lower. Archives are not created for web and ejb and EAR archive is not created for EAR project. However for EAR project war and ejb archives are created - this is by design. Need some more time be resolved properly.
Integrated into 'main-golden', will be available in build *200903191401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3aa8bf1ecf0c User: Vince Kraemer <vkraemer@netbeans.org> Log: #152724: canFileDeploy was returning false..
Do we need the war archives that are part of a directory deployed EAR? They may be easy to eliminate. I am pretty sure the ejb jar files are used as part of classpaths and the like, so stopping them from being created may be a bit more complex.... WAR files don't usually end up being part of those situations, though.
War files are not created anymore - web-main 6a4c78f78bd2. David, Vince can you verify the solution? I had to fix couple of old bugs here and there...
Actually changeset is 496c9d786232 (I had some issues with commit ;) ).
Integrated into 'main-golden', will be available in build *200904080201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/496c9d786232 User: phejl@netbeans.org Log: #152724 Unnecessary archives being created
Integrated into 'main-golden', will be available in build *200904081400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/496c9d786232 User: phejl@netbeans.org Log: #152724 Unnecessary archives being created
*** Issue 132537 has been marked as a duplicate of this issue. ***
This is not a j2eeserver issue anymore. For EAR I build script has to be adapted to not to create subproject's jars and to delete existing subproject's jars (however it should copy other libraries) when doing directory based deployment.
Created attachment 104899 [details] proposed patch Testing this issue I noticed that jars are still being created and copied around. I decided to fix it but complexity of existing build scripts make this really hard. First patch which does improve the situation and works in misc scenarios I tested it on. Any feedback or suggestion on my changes is appreciated! I will have a second look at it later this week before integrating. Thanks, David.
Further testing revealed some problems: for example if EAR packages extra jars (Packaging panel in proj props) these were not copied after my patch was applied. It is possible to distinguish projects EAR depends on from these which should be just packaged into EAR but I'm not sure it is worth all the complexity added to build script. For now I'm putting this issue on back burner unless there is a strong demand for it.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss