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.
We have a large EAR application, consisting of many EJB JAR modules and WAR modules. All those modules share a common jar (a project consisting of entity classes and a persistence.xml). Until now, it was packaged in the root of the EAR file (Netbeans did that for us). It worked great: all modules shared one big persistence unit, and we were so able to avoid various packaging and cache problems. We are planning to migrate to Glassfish 3, and we need to have Model.jar in /lib directory of the generated EAR (this has been observed experimentally and is actually part of Java EE 6 specifications). I tried to figure out how it works: 1) created an ear project 2) added an ejb project to it 3) added a war project 4) added Model.jar (entities + persistence.xml) to war+ejb After building EAR: In ear module: Model.jar found in build/ AND build/lib/ In ejb module: Model.jar found in build/classes/ (not in dist) In war module: Model.jar found in build/lib/ AND build/web/WEB-INF/lib/ a)Tried removing the jar from ejb project (+clean each module) In ear module: Model.jar found in build/ AND build/lib/ In ejb module: Model.jar not found In war module: Model.jar found in build/web/WEB-INF/lib/ only b)Tried removing the jar from war project (and adding back to ejb) (+clean each module) --> same After building EAR: In ear module: Model.jar found in build/ AND build/lib/ In ejb module: Model.jar found in build/classes/ (not in dist) In war module: Model.jar found in build/lib/ (still there! please note that ejb project is added in war for compilation, not for packaging) It is inconsistent, and I couldn't find any documentation or explanation.
I cannot find the issue in which this was implemented but NB has been changed (a while ago, definitely in 6.9.1 perhaps even in 6.8) to place #1) J2EE modules into the root of EAR and #2) all other jars to EAR's lib subfolder. I just quickly tested it on 6.9.1 (eg. EAR with EJBJAR and WAR; and JavaLibrary project which is on classpath of WAR and EJBJAR) and it works as expected I would say - if I look into MyEnterpriseApplication1/build folder I can see there both WAR and EJBJAR and there is also lib folder containing my JavaLibrary1.jar which is used by both WAR and EJBJAR. Just ignore what's in WAR/build and EJBJAR/build as all that is intermediate. If you do build clean on your EAR project what is the result? Perhaps there is a bug depending on how you structure your EAR and EE modules? Provide more details please and I will help you resolve your issue.
I confirm this work as you say for a new project. I'll try with my existing one once again and compare the projects if it doesn't work as you said.
Ok, I tried it again. It definitely is in build/ AND build/lib/ of ear project, for my existing project... as well as for a new one. But it isn't in dist/myproject.ear/ (ear root), only in dist/myproject.ear/lib , which is what I was trying to achieve anyway. So, it seems I have a working solution. Is the fact that the files is present two times A couple of questions regarding this, just to understand: - what are the relevant ant's build.xml file parts from which libraries and java ee modules are copied? - how does netbeans see if a project is a java ee module or a simple jar? Thanks
Still, there are problems. I tried with various smaller projects, each using the shared lib. BTW, a colleague has the same problem. clean & build works as expected: ear file is ok. The first run after a clean, and if glassfish has been stopped, works well. All subsequent runs create an empty Model.jar under build/ dir in our ear project, as well as under gfdeploy/ Can't explain. Tried to add ant tasks to remove, but it seems to happen after the file is deployed. I can't even know if it's netbeans or glassfish. Something creates a zero-sized jar at some point. Additional hint: after this happens, it seems impossible to clean the project because glassfish locks this file: [xxx]build-impl.xml:580: Unable to delete file D:\dev\epc-dev\xxx\dist\gfdeploy\EpcModel.jar May be related: when it works (stop glassfish, clean, run), netbeans loads the browser while the application is deployed once again (has already been deployed once). Just waiting and refreshing the browser gives the application screen.
further info... it seems that the file is created in build/ *after* ant has run. I added some checkpoints in build.xml. I found that, even if the file isn't there at post-dist target or if the ant file is interrupted after deleting the file (which I checked had happened), it is recreated (again, with size 0).
I can reproduce creation of 0 sized jar file. Compile/Deploy on Save seems to be the culprit - disabling it makes problem go away. I'm investigating. Thanks for testing and reopening this issue.
Petr, my debugging leads to WebProject.ArtifactCopySupport and EjbJarProject.ArtifactCopySupport so I'm passing this issue to you. What's the purpose of EjbJarProject.ArtifactCopySupport?? It does not make any sense to copy jars which EJB project depends on to ejbjar/build/classes folder, no? I'm also attaching test case project. The steps to reproduce are: * clean & build EnterpriseApplication1 project and check that EnterpriseApplication/build/JavaLibrary2-libo.jar does not exist * modify aaa.NewClass and save it (JavaLibrary2-libo project) * build EnterpriseApplication1 project again The last step always results into creation of EnterpriseApplication/build/JavaLibrary2-libo.jar which is wrong and in addition the file has always size 0. Here is one piece of information which you may need: when jars are copied into EAR folder structure some of them end up in EAR's root, some in EAR's lib folder and some may not be copied at all. There is some every simple logic which decides what should go where and result of this decision is stored in project.xml (so that user may customize it if necessary). To be able to read that info from project.xml have a look at my last comment in issue 163971. So far this information is used only from XSD transformation which is used to generate build-impl.xml and so there is no API for it. If you would need to access this info for example from WebProject.ArtifactCopySupport then I'm happy to enhance ClassPathSupport.Item for you. Just let me know. Or feel free to do it yourself. I'm raising this to P2 to resolve it for 7.0 Beta2 (ideally). Let me know if you need hand with it.
Created attachment 104776 [details] test project
I confirm it works ok if "deploy on save" is disabled. However, this requires to redeploy on each change in jsf xhtml pages. Is there a workaround to allow us to work (thus without generating this 0-sized file) and still be able to see changes in jsf facelets pages?
Projects are getting soo complicated and EAR especially. I think artifact copy support is there to duplicate ant's "copy my jars out of modules to EAR" and to propagate jar to dir-deployed EAR (gfdeploy). I guess it worked until the fix for issue 163971. I look into that.
Should be fixed in web-main 4852a6d58680.
Integrated into 'main-golden', will be available in build *201101220001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/4852a6d58680 User: Petr Hejl <phejl@netbeans.org> Log: #194041 Erratic packaging of library jar in ear