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.
| Summary: | Additional Webresources are not shown in the project view in Other Sources | ||
|---|---|---|---|
| Product: | javaee | Reporter: | kuschelf |
| Component: | Maven | Assignee: | Martin Janicek <mjanicek> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dschulten, fhopf, mkleint |
| Priority: | P1 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| URL: | http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Attachments: |
Second part of the fix
Second part of the fix - updated equals/hashcode |
||
I support this enhancement request. However I would like to make some observations concerning generated web resources.
The additional web resources should not only *appear* in the Other Sources folder, but they should be picked up by Netbeans editors. In my case, I have a generated faces configuration xml, which contains JSF beans that are not picked up by Netbeans EL Code Completion in JSF views. Based on this webResources enhancement request, I could at least add my generated faces configuration.
The additional web resources should appear with the path given in the directory element, as shown below.
Examples:
1. Additional webapp files from profile
<directory>profiles/${profileName}/src/main/webapp</directory>
would become
Other sources
+-- profiles/myprofile/src/main/webapp
2. Generated resources
<directory>generated-webresources/fornax-oaw-m2-plugin/
would become
Other sources
+-- generated-webresources/fornax-oaw-m2-plugin
A similar thing has been done for the build helper plugin. If you add a src or resource directory there, it is added to the java classpath and the java resources of the IDE. The files are placed in target/classes and target/{war-folder}/WEB-INF/classes and the IDE sees them there.
In the same manner as src folders can be added with the buildhelper plugin, the IDE should see the web resources in target/{war-folder}/WEB-INF/. That way, one could add additional resources using the <webResources> element. I must admit, I have no idea how to pull this off in Netbeans, maybe the files can be linked to the VFS somehow?
In the case of *generated* web resources, there is the long-standing issue that there is no convention in Maven for generated webresources. Unfortunately, generated webresources have always been a second class citizen and never got their own convention, as opposed to generated sources and generated resources.
The convention for plugins that generate Java-related sources is to use
generated-sources/fornax-oaw-m2-plugin/com/mycompany/package
as noted by mkleint in http://maven.40175.n5.nabble.com/generated-sources-resources-path-conventions-td109308.html
Similarly there is a generated-resources convention. Files there automatically end up in the classpath, together with the .class files, and Netbeans shows them in generated-resources. But last time I checked, there is no
generated-webresources
folder convention for generated things that should end up in the WEB-INF directory.
I don't think this will change anytime soon. But for now, the proposed enhancement covers both purposes, additional sources and generated sources.
An additional remark: When I copy my generated faces-config-generated.xml to src/webapp/WEB-INF, the jsp editor starts to see these beans after restarting Netbeans. Just to confirm that it would make sense to implement this issue. I have opened a request to establish a generated-webresources convention in the war plugin: http://jira.codehaus.org/browse/MWAR-266 *** Bug 188389 has been marked as a duplicate of this bug. *** First part fixed by change-set: web-main #f9777d4e9af3 Additional resources are now visible in project view (there will be second Web Pages node --> if you think it would be better to have all web resources merged under one Web Pages node, I can change the behavior) What is still missing is proper support for the additional web resource (we will need some API changes in order to be able to accomplish such feature, because current infrastructure doesn't count with something like that) Integrated into 'main-silver', will be available in build *201310040001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/f9777d4e9af3 User: Martin Janicek <mjanicek@netbeans.org> Log: #182407 - Additional Webresources are not shown in the project view in Other Sources Created attachment 140941 [details]
Second part of the fix
Milosi could you take a look at the patch? There are small changes in projectapi module (just adding equals/hashcode to GenericSources.Group), do you think it's fine to do that? (In reply to Martin Janicek from comment #8) > Milosi could you take a look at the patch? There are small changes in > projectapi module (just adding equals/hashcode to GenericSources.Group), do > you think it's fine to do that? comparing groups based on icon's hashcode is fairly suspicious. can you elaborate why you need it? Not really sure if it's needed. For my use case it's not important, I will be fine with comparing project, root folder, name and display name only. I just wasn't sure if that might be a general usage or if it's just my case. (In reply to Martin Janicek from comment #10) > Not really sure if it's needed. For my use case it's not important, I will > be fine with comparing project, root folder, name and display name only. I > just wasn't sure if that might be a general usage or if it's just my case. Sorry I did not express myself clearly. Why do you need the equals method implemented at all? Created attachment 140944 [details]
Second part of the fix - updated equals/hashcode
(In reply to Milos Kleint from comment #11) > Sorry I did not express myself clearly. Why do you need the equals method > implemented at all? I'm using it, to check if there are any differences in source groups when the pom.xml were changed (see J2eeMavenSourcesImpl.hasChanged() method), so the listeners can gets aware of those changes. (In reply to Martin Janicek from comment #13) > (In reply to Milos Kleint from comment #11) > > Sorry I did not express myself clearly. Why do you need the equals method > > implemented at all? > > I'm using it, to check if there are any differences in source groups when > the pom.xml were changed (see J2eeMavenSourcesImpl.hasChanged() method), so > the listeners can gets aware of those changes. then please create a wrapper class in your own code that will calculate the hashcode/equals for you. That way the change will be localized to your code only. Ok, changed and pushed as web-main #2be39fafaa4b |
Additional Webresources are not shown in the project view in Other Sources. We use this to enable profile based customization. The pom.xml looks like: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <configuration> <webResources> <resource> <directory>profiles/${profileName}/src/main/webapp</directory> <filtering>false</filtering> <includes> <include> **/* </include> </includes> </resource> </webResources <archive> <manifestEntries> <X-Compile-Source-JDK>${maven.compile.source}</X-Compile-Source-JDK> <X-Compile-Target-JDK>${maven.compile.target}</X-Compile-Target-JDK> </manifestEntries> </archive> </configuration> </plugin> A possible work around is to use resource entries like: <resource> <directory>profiles/${profileName}/src/main/webapp</directory> <filtering>false</filtering> <targetPath>${project.build.directory}/${project.build.finalName}</targetPath> <includes> <include> **/* </include> </includes> </resource> I think this is unsupport so this should be marked as enhancement.