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.
Summary: | Add support for production builds to IDE | ||
---|---|---|---|
Product: | projects | Reporter: | krahe <krahe> |
Component: | Generic Infrastructure | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | ||
Priority: | P1 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | Windows ME/2000 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
krahe
2005-03-14 21:07:04 UTC
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. |