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.
While the Introduction in chapter 3 of the NetBeans Field Guide (IDE Project Fundamentals) hints that production builds of Java applications are expected to be done outside the IDE, a lot of developers, including myself, come to NetBeans expecting to be able to do production builds with it as they did with prior-generation IDEs (in my case VisualCafe and CodeWarrior), and bristle at the thought of having to learn another tool (Ant) just to reliably and repeatably build deployable versions of their applications. I would like to see support for alternate builds added to NetBeans, and apparently there has been talk of this (see follow-up comment on http://www.netbeans.org/issues/show_bug.cgi?id=56224 ), but there are some fundamental yet puzzling limitations in NetBeans' Projects that to me are going to make this very difficult. As an example, my product consists of a handful of libraries and a couple top-level desktop client applications that depend on them. My build requirements are: 1) A debug build of the libraries and client apps with debugging information for use in development and initial testing of the application. The debug builds should be compiled with flags for deprecation and other warnings turned on. 2) A release/production build of the libraries and client apps without debugging information for deployment. The release builds should be compiled with the optimization flag on and without the compiler warning flags that the debug version is built with. The client applications must be built with the release versions of the libraries in the compiler's classpath. Additionally, the release builds should copy the resulting jar files to a separate distribution directory (that is never cleaned) where they can go through additional post-processing (e.g. have resources substituted for particular customers) and be archived in CVS (so the version shipped with any particular release can be quickly and easily recalled). As I implied earlier, I can accomplish this in the other IDEs I've used (VisualCafe and CodeWarrior) by defining separate "debug" and "release" projects for each library and client application. I've also been able to do this in NetBeans 4.0, though with some caveats since it's not fully supported. It is my understanding that NetBeans 4.1+ won't support this arrangement at all, so I'm stuck at 4.0 until this is addressed (or it looks like it's not going to happen and I switch to a different IDE). I find the imposition of a one-project-per-source-directory limitation to be most perplexing. The reason for it is certainly not obvious to me. Perhaps it descends from some school of thought with which I'm not familiar. Or perhaps there are technical obstacles that led to it. In any case, I have been unable to find any kind of explanation or justification for it, though I would very much appreciate one. To me, the most obvious solution is to allow the definition of multiple projects per source directory. The fact that things like debug and warning flags and compiler options are attributes of projects (at least in NB 4.0 - not sure if the same is true for 4.1+) also suggests that this is the correct solution. If there remain sound reasons for not doing this, however, then some additional level of project abstraction is necessary, such as a Project-Build, of which things like compiler flags and options are attributes, along with build and dist directory paths. The tough one to manage with this scheme would be the compiler classpath, however. If the classpath remains an attribute of the Project rather than the Project-Build, then the issue is determining which build of the Projects on the classpath the compiler should use. This could be solved by only supporting fixed types of Project-Builds (e.g. only Debug and Release). This would be rather inflexible, however. Every other solution I've thought of (e.g. defining relationships between Project-Builds in addition to Projects) seems overly complex and mistake-prone. If the classpath is an attribute of the Project-Build, on the other hand, in which case classpath entries would refer to Project-Builds rather than Projects, then you run the risk of having inconsistent classpaths for different Project-Builds in the same Project. (Admittedly, you run the same risk if you allow separate Projects, but in that case at least you haven't saddled academic and other users who don't need separate builds with an extra layer of project abstraction.) I don't know how much consideration this issue has gotten, or what the potential of addressing it in the near future is. Perhaps you will decide that supporting multiple builds is beyond the intended scope of the IDE, in which case I encourage you to try to make that clear to potential new NetBeans users. As for me, the lack of support for alternate builds precludes my "upgrading" to newer NB versions, and is a major impediment to my continued use of NB 4.0. I have to believe other developers out there are finding themselves in the same position.
Just a note, I sometimes use "IDE" and "GUI" interchangeable. Several references to "IDE" in the description above, and the Summary of this issue, should really read "GUI". Sorry if I confused anyone.
I think what you are looking for is build/run configurations supported in the GUI. You can can certainly make such configurations yourself (and switch between them) in NB 4.0, but you have to make a few changes to build.xml and deal with the .properties files manually, rather than using the GUI, so it is cumbersome. Issue #49636 requests full GUI support for this kind of thing (as is already done in e.g. J2ME projects, which needed it much more urgently than J2SE projects). You can also just leave the regular GUI config in "debug" mode and write wholly separate targets for production builds, though this is more cumbersome. Your special post-processing and archiving steps are surely your own business and not something the IDE can predict. Write Ant targets for these things if you need them. Defining two different classpaths for the same source root doesn't make much sense - what should code completion offer you?? If you had some special reason to do so (can't think of any offhand, but it is conceivable) you could use Ant to do it. No plans to ever support that in the GUI. I am not sure what you mean by NB 4.1 losing some ability present in NB 4.0. I am not aware of any such case. Again, sharing one source dir between projects will never be supported, as it would make the IDE's implementation and UI much more complex, and there is no known reason to do so, other than as a temporary workaround for missing features that can be done properly in some other way. *** This issue has been marked as a duplicate of 49636 ***
Defining two different classpaths for the same source root isn't necessary (and I agree doesn't make much sense) as far as code completion is concerned, but different classpaths are necessary for compiling different builds. (Otherwise, how would you make sure that the production version of a client app. is compiled with the production builds of the libraries it depends on, rather than debug builds?) Once explicit support for alternate builds has been added to NB, then the same classpath could be used, as long as NB/ANT knows which build of the libraries to use for compilation. NB 4.1 didn't lose any particular ability that NB 4.0 has regarding projects. However, it is my understanding (haven't tried it myself) that NB 4.1 more strongly enforces the restriction that different projects cannot share the same source directory. While NB 4.0 doesn't support this, it doesn't prevent it, it largely works okay, and my current development configuration depends on it. Based on your comments, I can see that having the same source file present in two open projects could present a problem . (e.g. Given a source file open in the editor, to which project does it belong?) However, couldn't that have been addressed by simply not allowing the user to open or create a project that shares a source file with an already-open project? That might be a little confusing or aggravating, but at least those of us who use the GUI to create our builds (for whom the Project _IS_ the build) wouldn't be hamstrung by a one project (read "one build") per source directory limitation. As far as my post-processing and archiving steps, they are my business, and I would never expect the GUI to handle anything specific like that. Right now I do these in -post-jar targets in build.xml. I only mentioned them because I need to do different things in -post-jar for a debug build than I do in a production build, and want to make sure that that is accommodated when this enhancement is implemented.