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.
NetBeans 4 lacks a "build selected files" action (i.e. clean+compile for a set of files). This is a serious regression for 2 reasons: 1) NetBeans 3.6 users will accidentally and repeatedly build the entire project by hitting F11 when they intend to build just a few files -- which can be a critical mistake when dealing with a huge codebase. 2) There is serious need for a "build selected files" action to force a clean build of a few selected files, e.g. when timestamps can't be trusted and when the project is big enough to make "build all" useless. This is somewhat related to the fact that for huge projects "build" cannot be assumed to involve JAR or WAR creation. Compiling to a directory is *it*. Thus to implement this feature, all that is necessary is an Ant mapper from the sources to the results in the build directory for a delete, followed by a javac. I will be filing a separate bug on the "compile to directory bit" as it really is separate. If nothing else a hidden "build selected files" action should be added that will show up in menus if and only if it is mapped to a Ant target. This will allow those who need it to add appropriate logic for it in their Ant projects!
The enhancement for building one dir is already filled and we plan that for 4.1 I think. I really don't see why you would not trust the time stamps.
When is 4.1? My guess is a bit late for our usage. We need Java 5 support ASAP. Is there any possibility of just adding a hidden action that only appears when mapped into Ant *now* (i.e. in NB 4)? Also, we need more than just "build one directory" but also "build the selected 'n' files and/or 'm' directories" as we had in NB 3.6. Why not trust timestamps? Well... For starters, the source files may be reverting to an older source version [e.g. by changing ClearCase config spec] and thus have an older timestamp. In this case one needs to force the changed files to be cleaned and compiled -- not the whole [huge] projejct. Also, various files sometimes pass through more chaotic processes when heck breaks loose. Plus the directory is built in integration and then incrementally compiled into / on top of due to size, etc.
If you really need it and if you have one large project. I think you will have to go with the workaround. Where you modify the build.xml that way that the compile-single file will try to delete the classes first and then call the original target. Well, i'm not sure how to do that because you will have to replace the .java with .class very likely. Other way would be to run touch on the .java files before calling the original compile-single target. (Which is probably cleaner)
Touch is a no-go as the modification dates are important aspects of the ClearCase view. Having compile always do a clean is an option (I can certainly do the java to class mapping -- I'm not a complete idiot when it comes to Ant). The issue is that having this be the only option will result in much slower response when I select 5 directories and mean "compile", not "clean+compile". I guess all I really *need* is 2 built-in actions "compile selected" and "clean compile selected". I can take the latter from there if need be. [If it is simple enough to add such a contextual action to *any* project type, then I guess I could do this myself. If not, there *should* be such a simple way to add a contextual action.]
For a freeform project, you can add any Ant target to the context menu of the project, but that does not help for file-sensitive actions. Currently there is no way in the GUI to add a new file-sensitive action using a given command name. Would not be hard, I think, to make such functionality, if we had a decent UI for it. Essentially it is just a matter of registering an action using a single static method call. You might even be able to do without writing "code", using .nbattrs files. Also it would be possible just to provide an action with command string "clean.compile.files" which could be implemented by freeform projects (and I guess standard in j2seproject as well), and publish the action in the Actions/Project/ pool for optional addition to menus, toolbars, KB accelerators. Too late for 4.0 as we are past feature freeze and only bugfixes are now permitted. As an aside, would suggest that such enormous source trees be split up into manageable compilation units with specific interdependencies, which would largely obviate the need for such an action.
Couldn't all Ant actions pass a files variable / ref id containing the currently selected files to Ant? I know this would not make the menu disappear / disable when appropriate, but it would be a start... The option of just providing the "clean.compile.files" action is quite attractive. Though I think the more general purpose contextual Ant action is really important overall, the loss of this particular action is a regression from 3.6 and is sorely missed. Your aside regarding enormous source trees is well taken. Work is underway, but it will take a long, long time as the enormity of the source tree is very easy to work around with with NetBeans 3.6 and other tools, just not NetBeans 4.0. As an aside of my own, someone should look at CodeWarrior's projects and targets. It did a very nice job of providing multiple inter-related targets within a project and allowing multiple projects with dependencies. It also is one of the few IDEs I knew of prior to NB 4 that had any serious issues with large source trees -- primarily due to its issues with using an existing directory of classes to compile against...
"Couldn't all Ant actions pass a files variable / ref id containing the currently selected files to Ant?" - wouldn't help; if you added a context menu item to the project, the selected node would be the project, not any files in it.
Hmmm... On further thought is some way of registering a contextual action *and* its filter applicable here? For instance, one could have a project preference listing such targets and each could have a corresponding "isApplicable" Ant target run when selecting the contextual menu. This would not be extraordinarily fast, though. It would seem better to have a simpler way to map from file/tree-node types to applicable contextual Ant targets. Again the project preferences could be used to establish such a mapping... A combination, wherein the fast map handles most cases and a special delegate handles the oddities might be the best overall...
Possibly obsolete as of 6.0 (due to e.g. <depend>), needs to be reevaluated.
<depend> realistically depend on all file modification dates being correct? The major use case for this feature is when you know or suspect that these dates are incorrect. Sure, you could do a full rebuild of the project, but for a really large project this can be dreadfully slow when all you want is "forcibly recompile these [selected] files" notion. Since many Ant tasks naturally skip their activity if/when files are "up-to-date" based on their internal logic, it becomes necessary to do a "clean selected files" when this logic is thrown off due to bad data. Sure it would be best never to do anything that louses up file modification dates like this -- and certainly much of the time it can be avoided. When it can't, however, NetBeans is sorely missing any means to deal with the issue.
As of NB 6.0, F9 on a j2seproject always (re-)compiles the selected files, using the new <force-recompile> macro. For a freeform project, you can make as many actions as you like which do whatever you like, if you use the facility to create custom actions present in the Freeform Project Extras module.