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.
A 3.6 filesystem option was to ignore files based on regular expression. This expression has been moved to a project wide setting under IDE Configuration/System/System Settings. The problem is that even though the display may ignore some *.java files, ant will still attempt to compile them via project's default build task. This is functionally inconsistant with previous versions of Netbeans. I've submitted this at P2 because my project is currently unbuildable in 4.0 due to problem *.java files.
I think that 'Ignore Files' wasn't intended as exclude from compilation by ant. It's just about displaying files.
Agreed with Milan. You can customize your build script to omit some files from compilation. If you think it is important feature then please provide compelling usecase.
Please, check also issue 49026 which is very close to this one and feel free to comment there. Thanks.
An important feature in any build system is the ability to exclude files (or enumerate all include files). This was recognized as an important feature and 'Ignored Files' was added as a filesystem option. In my opinion removal of this feature is a regression in functionality. That is why I've filed this as a defect and not an enhancement. I use a revision control system based off of SCCS. This means that I have numerous files of the form s.<filename>.java. Default *.java glob include rules cause my project to horribly fail. I applaud efforts to move to ant internally. However a huge selling point of 4.0 is that although Netbeans is based on ant, users aren't forced to use or know about ant if they don't want to. This promise is now broken for folks like me who depend on the 'ignored files' filesystem semantics of 3.6 and earlier. In 4.0, it would be impossible for an SCCS project to be built using only options available within the IDE. I don't see the hesitation for this. Ant supports an exclude option. You have the setting stored within the IDE. Set an environment variable like single-file compile. That way if folks use the option it's supported, everyone else probably won't notice the difference. Please give me back functionality that is critical to my acceptance of 4.0.
Adding <target name="-pre-init"> <defaultexcludes add="**/s.*.java"/> </target> to build.xml file in the root of your project should solve the problem. We know that current project should be more customizable in UI and that we should not keep answering "customize your Ant script", but it is a matter of priorities. We cannot do everything in first release, we need to get it out of the door to get some feedback. We already started work on 4.1 in which we would like to remedy some of these problems. Please try the workaround and let me know if it works for you and is acceptable for 4.0.
This does work for me, thank you. However, that's only half the point. You say you want feedback but don't have the bandwidth to deal with the feedback you're getting from your Beta. From what I've read on TSS, JavaLobby and others, 4.0 will mark a significant marketing push by Sun/Netbeans to try and displace the IBM/Elipse machine. It does you no good to ship a product with only a half finished project system. Ant may be a great foundation, but what's built on top isn't ready for prime time. Based on what I've seen, with the current issues, 4.0 is setting itself up to be a flop. I personally am looking for the ability to: - Exclude single files, and exclude files by glob or preferably regular expression. (Available in 3.6) - Register non Java compilers with the system. Support for configurable Jikes, Acj and others. (Available in 3.6) - Register multiple JVMs. 1.3, 1.4, 1.5 VMs. With some files being compiled/executed by one VM and others by another. I have several codebases where some code is 1.3 and some requires 1.4. Same project, different compilers/packaging reqs. (Available in 3.6) - Ability to generate multiple project jars (with different recipies), and place them in any location. (Available in 3.6) - Ability to work on project source that depends on source in another location. (Available in 3.6. Maybe available in 4.0 with required projects, but I'm not sure. Would still require the overhead of creating a new project just to include) - Ability to compile JSPs in any project. That's for starters. These issues have been reported elsewhere in the system by other developers. I expect 4.0 to be functionally better than 3.6. I also expect Netbeans to keep it's promise that ant hackery won't be required to achieve 3.6 functionality. I expect that other developers will agree. I don't mind that 4.0 beta is in this state. I think you have a good starting point and I'm beta testing to try and help the 4.0 release, not rag on you guys. I'm in development too and understand the problems and pressures the project is under. I do think that I and other beta testers have raised some serious issues. Ant as a foundation is fine, but you need to finish building on top of it. 4.2 may indeed be a good product. However the current codebase as 4.0 will generate significant negative press. I'm not compelled to upgrade. In fact I think that Netbeans' priorities are very different from my own if they're willing to dish out a product they know has serious issues, just to generate feedback and buzz. If that's the way the project is going to treat it's older userbase, maybe we should start looking at alternatives. Instead, hold off on the release. Incorporate the constructive feedback you've received from the beta testers and release and market a solid product. This way buzz is positive and other developers and contributers return to Netbeans. This means more plugins and greater support for all users. Otherwise I fear the slow and ugly demise of the IDE I currently enjoy.
"I use a revision control system based off of SCCS" - I know very little about SCCS, but as I undestand it the s.* files are special files with all the revisions of file? Such a file should be stored in special subfolder like SCCS, right? I'm asking because Ant by default ignores both **/SCCS and **/SCCS/** (see end of <http://ant.apache.org/manual/dirtasks.html>) so from this point of view everything should work fine for SCCS. Is the problem in "based off of SCCS"? Re. your general comments about NB4.0: I'm not right audience for them nor this issue. Please, post your opinion on mailing list. "...to ship a product with only a half finished project system" - I disagree that it is half finished. Looking at the abilities you are personally looking for it seems to me that they are very specialized and that Ant script customized by hand is in your case the best for your own good. NB36 supports some of these, but had so many other problems that I personally would not dare to rely on it. With Ant script you now have absolute control and can get 100% reproducible builds and everything can be stored in your versioning system. Re. how much of these should be supported in UI is question for UI experts, but I personally doubt NB projects should be ever customizable in UI in such a detail. Some things might even not work correctly and you might end up helping user to shoot their own leg, for example "some files being compiled/executed by one VM and others by another", "exclude single files" - javac as part of its dependency check can decide to compile other files which you perhaps wanted to exclude or compile with different JDK. Anyway, I suggested simple workaround for your problem and it works. The NB4.0 is already in high resistence mode what means that only serious problems can be fixed now. I can see two solutions: downgrade priority to P3 (that's what I would like to do) and discuss how to fix it in 4.1 or keep it as P2 but ask for WAIVER.
I'll bump down to P3. The work around works well. I had some SCCS files outside the typical location. I think the default **/SCCS/** exclude rules work by default. I also had some non SCCS, but other SCCS like rules for excluding files. They were easy to eliminate in 3.6, needs ant hackery in 4.0. The ant hackery was pretty elegant, and effective. If 4.0 isn't going to eliminate ant hackery I think it would be nice to give a lot of examples of common fixes for advanced issues. I think in general a Netbean/ant primer, or a few ant snipits to fix common issues would be very nice.
Re. docs - agreed. However, I do not know about any concrete action/plan in this area.
Changing summary/status/etc. to reflect last few comments. The default excludes list that comes with Ant is intended to do what the great majority of people want. If you're one of the people for whom it doesn't, it is not too hard to correct it if you know what to do, but this sort of thing certainly belongs in a set of tips of some sort. I expect that such a "cookbook" should start to grow (Wiki??) after the release, with the most popular items being addressed directly by the GUI as time permits. Note that we do have under consideration an RFE to include only portions of a source tree, primarily for performance reasons on massive source trees. This would affect the Ant script (which you do yourself) and classpath scanning (which you couldn't do otherwise). However I think that is a somewhat different case. Here in this issue the question is ignoring certain kinds of files, rather than picking portions of a package tree to work on. *Possibly* both cases could be handled by a single GUI but I am not sure if this works well in combination with classpath scanning etc. Generally we need to take care when setting up any kind of excludes lists for Java sources, because unlike e.g. C/C++, calling javac on a list of sources does not guarantee that other sources will *not* be compiled anyway if they are referred to statically. It may be the case that /^s\./ is a reasonable addition to Ant's own default excludes, but I was under the impression that SCCS normally expects these files to be in an SCCS/ subdirectory to begin with. Also such a pattern is a little too close to a "real" filename to be comfortable for a default exclude; e.g. "s.txt" may be a plausible filename.
Since the version mentioned in this issue, a lot of things mentioned were implemented, such as those in the original request (excluding files from compilation). The current NetBeans documentation (up to 6.8) covers the issues mentioned: exclude files from compilation (javahelp and http://netbeans.org/kb/docs/java/project-setup.html), Ant, etc. So, unless further requests to docs are specified more specifically, I believe that the issue from the docs side is resolved. However, I am not sure about other RFEs mentioned in the discussion. So, reassigning to another component.
*** This bug has been marked as a duplicate of bug 49026 ***