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 facelets component resides on an external jar (dependency on a Maven project), it won't be recognized by the editor. For instance, let's assume: xmlns:myns="http://java.sun.com/jsf/composite/components" and then: <myns:myComponent /> Even though there is a jar with META-INF/resources/components/myComponent.html , the page that uses it will be marked as containing errors. Product Version = NetBeans IDE Dev (Build 20121220-4f53a116c76b) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.7.0_07 Runtime = Java HotSpot(TM) 64-Bit Server VM 23.3-b01
*** Bug 196107 has been marked as a duplicate of this bug. ***
Reproducible, though I cannot say for sure if this isn't just a maven configuration issue. Surely the proper location for the META-INF/resources/components/myComponent.html (refered as PATH in the text below) folders/file is in the root of the jar artifact where the server expects it. However if I put the PATH to src/main/resources, the resulting jar doesn't contain the PATH at the expected location. To achieve this, I need to put the PATH to the src/main/webapp folder. Then the jar artifact has correct content, however netbeans support for the composite component library doesn't work well as reported in this issue. The problem seems to be most likely the implementation of SourceForBinaryQueryImplementation for maven web project, which does return just src/main/java and src/main/resources as source roots when a SFBQ is asked for sources on the library project binary artifact. As the obtained source roots don't contain the folder where the composite libraries are stored (its location is src/main/webapp/META-INF/resources/.../...) the JSFIndex doesn't see the composite components and hence it doesn't create the composite component library abstraction and the editor features like completion, error checks don't work properly. It would work via the jsf's binary indexer (there are three jsf indexers - custom, binary and embedding) as it can also find the composite component libraries, but since the SFBQ returns SOME source roots, it is not used at all and just embedding indexer runs. If I put the PATH to both locations: src/main/webapp and src/main/resources then netbeans jsf editor support works correctly and the jar artifact has correct content. I'd like to kindly ask Milos Kleint as our great maven expert what is his opinon on this topic and what should be the expected behavior, or possibly fix the SFBQImplementation so it contains also the webapp folder. Thanks in advance Milosi.
we do handle src/main/webapp folder in SourceClassPath, not in SFBQ result though apparently. Only possible problem I can see is that while src/main/webapp ends up in the war archive's root, src/main/resources end up in WEB-INF/classes I believe. So for resources the path to resource within the archive doesn't match the path in sourceClassPath or SFBQ result. Is that ok? In that sense I'm not sure the problem evaluation done by mfukala is exact. *If* there is a JAR (not WAR) with META-INF/resources/components/myComponent.html resource, the SFBQ result would return everything correctly. Only if one depended on a WAR, only the the problem described by mfukala would appear. Depending on a JAR should work fine even now as far as SFBQ is concerned. a sample project setup demonstrating would help.
Cc'ing also Martin J.
I can confirm that the component library support works fine if the composite components library is located in a maven java project (jar artifact). I'm not sure if the scenario web project depends on web project is even correct (as I already mentioned). I'd say it could possibly work (as it is likely to work in runtime), but definitively not critical issue. Even the original report was about "dependency on Maven project" which is not completely clear, lets assume maven java project was meant. Since with such configuration the issue is not reproducible, closing as worksforme. Reporter, please reopen if you meant dependency on a maven web project and you have some reasons for that configuration. Thank you.
I find it interesting that you, mfukala, has been able to reproduce the issue before, so I cannot understand how you guys close it with WORKSFORME. What I have is a Maven web project (war) that relies on a jar dependency that contains the composite. xhtml files in the web project that refer to the components contained in the jar dependency fail to be parsed correctly.
misterm, I was able to reproduce the issue in the scenario when one web maven project depends on another web maven project. Which is as I understand it now, NOT your case. If I create a maven java project, put the CC files/folders into proper location and add a dependency to this project into a web maven project, then everything works fine. Please attach some testing projects or give me some additional details so I can reproduce. Thanks for understanding.
I have tried to reproduce it using a vanilla project but couldn't. I've tried to compare the specific project to my other ones, done several changes, but it still fails only with the original, which I cannot share. Is there any fine level debugging property I could set to produce a log you guys can analyse?
Would it be possible to send me the project privately? Or maybe just dump the project structure (find .) + attaching the POM? Can you also try to clear your netbeans userdir?