Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 209961 - [72cat] Treat standard Maven resource directories as special Nodes instead of "Other [Test] Sources"
[72cat] Treat standard Maven resource directories as special Nodes instead of...
Status: RESOLVED WONTFIX
Product: projects
Classification: Unclassified
Component: Maven
7.2
All All
: P4 with 2 votes (vote)
: 7.3
Assigned To: Tomas Stupka
issues@projects
: UI
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-22 20:30 UTC by crazyjavahacking
Modified: 2016-07-07 08:39 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description crazyjavahacking 2012-03-22 20:30:57 UTC
It will be useful to not treat standard Maven resource directories 'src/main/resources' and 'src/test/resources' as 'Other [Test] Sources', but provide a special nodes for them as I believe that vast majority is really using just the resource directories and the current name is confusing...
Comment 1 Jesse Glick 2012-03-23 16:21:05 UTC
Fixing NetCAT prefix.
Comment 2 Milos Kleint 2012-04-02 13:35:24 UTC
The problem with resource roots is in the detail and corner cases.

src/main/resources is more or less ok.
but people can add multiple other roots to resources, like src/main/resources-filtered etc..
or even ${basedir}/../../ with LICENSE.txt as the only include.
Comment 3 crazyjavahacking 2012-04-02 13:41:02 UTC
(In reply to comment #2)
> The problem with resource roots is in the detail and corner cases.
> 
> src/main/resources is more or less ok.
> but people can add multiple other roots to resources, like
> src/main/resources-filtered etc..
> or even ${basedir}/../../ with LICENSE.txt as the only include.

Sure, but is it difficult to respect <project> <build> <resources> content?
Comment 4 Jesse Glick 2012-04-02 15:07:36 UTC
I think default src/{main,test}/resources/ should be displayed nicely; anything more customizer can be shown with some more generic label.
Comment 5 Milos Kleint 2012-05-03 06:41:54 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > The problem with resource roots is in the detail and corner cases.
> > 
> > src/main/resources is more or less ok.
> > but people can add multiple other roots to resources, like
> > src/main/resources-filtered etc..
> > or even ${basedir}/../../ with LICENSE.txt as the only include.
> 
> Sure, but is it difficult to respect <project> <build> <resources> content?

yes, it can have significant influence on the UI of the projects view. We currently have at least 6 subnodes if I count correctly. The number can now rise up to 8 or 10 based on the number of various language source roots or generated source roots. With each resource node having it's own node, we might shoot at 12+. 

We do use the resource definitions from the pom but add them as subnodes to "Other source root". That one lists are resource roots along with any src/main/FOO directories where FOO is not any of the known roots. That way we make the the majority of possible project content available in the projects view. Including various configuration files and files associated with plugins.
Comment 6 Jesse Glick 2012-05-03 18:07:00 UTC
I think it is better to have more top-level subnodes than force the user to dig into subsubnodes to find resource roots, since we only display nodes for roots that actually exist, and if they exist there is usually a good reason for them - though not in cases like the LICENSE.txt example.

But even leaving that aside, src/{main,test}/resources/ are important and common enough to merit display at the top.
Comment 7 Jesse Glick 2012-06-08 22:09:05 UTC
Past UI freeze.
Comment 8 Martin Balin 2016-07-07 08:39:30 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo