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.

Bug 56402 - Add support for production builds to IDE
Summary: Add support for production builds to IDE
Status: RESOLVED DUPLICATE of bug 49636
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 4.x
Hardware: All Windows ME/2000
: P1 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-14 21:07 UTC by krahe
Modified: 2005-03-16 15:39 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description krahe 2005-03-14 21:07:04 UTC
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.
Comment 1 krahe 2005-03-14 21:28:10 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.
Comment 2 Jesse Glick 2005-03-15 15:14:27 UTC
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 ***
Comment 3 krahe 2005-03-16 15:39:01 UTC
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.