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.
This issue was originally reported by Daniel Harvey in 28/Mar/08 at codehaus.org - see more details at http://jira.codehaus.org/browse/MEVENIDE-617 Environment: All =========== Description: =========== Hi, I filter my Java source code as shown below. In this configuration, the Netbeans plugin assumed that the filtered source NOT my actual clean source is the location for the IDE. Can a configuration option be included within the plugin to cater for this behaviour? Great plugin! Cheers, Daniel. ... <build> <!-- the Java source needs filtering --> <sourceDirectory>target/filteredsrc/main/java</sourceDirectory> <resources> <!-- filtered Java source code --> <resource> <directory>src/main/java</directory> <targetPath>../filteredsrc/main/java</targetPath> <filtering>true</filtering> </resource> ... ---------------------------------------------- Comment by Milos Kleint [ 31/Mar/08 02:56 AM ] ---------------------------------------------- such setup will be actually very hard to get working unfortunately. There's no way to figure which "resource" is the one processing the java files. I don't want to add any kind of configuration panel in the project properties dialog, as the usecase is not common AFAIK and is not adding value to most developers. The resources cannot be annotated by properties or something that could help identifying the one special "resource". I'm wondering what are you actually filtering in the java files. ----------------------------------------------- Comment by Daniel Harvey [ 04/Apr/08 11:14 PM ] ----------------------------------------------- Thanks for the response. I'll need to consider another way of addressing the issue The reason I filter Java files relates to code that I want "compiled out" of the generated class files in some circumstances. For example: if(Config.includeFeatureX) { ... } where the includeFeatureX is a static final boolean enables the "..." code to be conditionally included/excluded at compile time. This is a mechanism that I use often, but I think I can address it another way... thanks anyway.
not to be addressed any time soon, considered to be a corner case. resolving later
NetBeans.org Migration: changing resolution from LATER to WONTFIX
Consider reopening and addressing this scenario. Daniel's legitimate scenario with a second generate-sources step: src/main/java/<source templates> --generate-sources--> target/filteredsrc/main/java/<filtered sources> --generate-sources--> target/generated-sources/java/<final source to be compiled> As a developer which files would you edit? Wait. Instead let us ask, which files would you NOT want to edit? You would NOT want to edit the target/filteredsrc files or the target/generated-sources files because NetBeans will clobber any changes you make the next time you build. Yet, by hiding the source templates in src/main/java and showing the filtered and final sources in the project tree, NetBeans encourages a developer in this scenario to do just that. In this case, NetBeans should show the source templates because those are the files that the developer should edit. (Another legitimate use case for Daniel's setup, by the way, is if you want to use a dynamic string in an annotation value: a version number, for example.) (Also, the filtered and generated source files should be read-only by default, but they are editable by default.) v7.3 RC1