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 56701 - Creation of end-user-ready application bundles
Summary: Creation of end-user-ready application bundles
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker with 1 vote (vote)
Assignee: Tomas Zezula
Depends on:
Reported: 2005-03-21 00:23 UTC by manawiz
Modified: 2011-08-31 14:05 UTC (History)
5 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description manawiz 2005-03-21 00:23:14 UTC
Developing in Netbeans is great, but many users struggle with the transition out
of the development environment into production.  At least these issues exist:

  1.  For standard application projects, there is no support in the ide for
generating a production manifest, bundling required subjars, or setting up a
proper classpath for distributing unbundled required subjars.

  2.  For web applications, NB sets the docBase to an absolute path into the
project directory, which doesn't exist in the production environment, and so
does not support the creation of portable war files.

  3.  Some users need to build outside of NB, but the NB-generated build scripts
use special NB tasks that require NB to be installed, and require special ant

I haven't used some of the other project types, but based on nbusers comments
believe there are similar issues in other cases (applets, enterprise apps, etc.).

This is a critical feature for the ide to support well!  The transition to
production should be seamless.  I suggest an approach like this:

1.  The ide should support generation and execution of production build scripts
that are separate from the development build scripts.  These build scripts
should run with ant and not require any nb extension tasks.

2.  The ide should provide some (interactively specifiable) settings to generate
the production build scripts.  For web apps, the docBase should be specifiable
and default to /<projectname>.  For executable jar generation, it should be
possible to specify how to treat the subjars (bundle then or not, set up a
proper Class-Path entry in the manifest in either case, etc.).

Other project types may have similar needs.  The main points of this RFE is that
Netbeans should provide first class support for generating production build
scripts and production builds.  The result should be a seamless transition out
of the development environment.
Comment 1 Jesse Glick 2005-03-21 10:43:56 UTC
This is several distinct issues in one. Reporter, next time please file each
individual item as a separate issue. When I have some time (right now I don't) I
will close this out in favor of separated issues, though some are already filed
Comment 2 manawiz 2005-03-21 16:51:44 UTC
The main point of this issue is that build-for-production should be a separate
top-level action, having stature in standard project properties at the same
level as Sources, Build (for NB) and Run do now.  It should also have its own
documentation section.  Every project reaches the point where it is necessary to
distribute the work product for use outside of NB, and this operation needs
first-class support.  Carving this up into separate issues may lose the forest
for the trees, which is the current situation in NB.
Comment 3 krahe 2005-03-21 22:05:11 UTC
Part of this is certainly related to <A
HREF="">Issue #56402</A>,
which has been folded into <A
HREF="">Issue #49636</A>.

I think the fact that Sun has endorsed this product has brought a lot of new
people into the NB fold (myself included), who, perhaps for the same reason,
expect that support for production builds should already be there.
Comment 4 superplinio 2005-07-19 10:22:48 UTC
I could be a good idea to config the classpath of the jar automatically from the
libraries included in the project.

This will avoid the need to create a custom manifest for the jar file.
Comment 5 Jesse Glick 2005-07-19 13:29:25 UTC
superplinio: you must add yourself to CC to see replies to your comments.

Re. adding Class-Path to unrelated to anything else in this issue
report, and not a good idea anyway. The IDE cannot predict the relative paths of
JARs you deploy *at runtime* unless it is also using a packaging technology of
some sort. When we have JNLP support, that will do it, but the Class-Path style
is unusable for the IDE. If you have a specific deployment structure in mind,
you can manually add Class-Path entries to match that structure.
Comment 6 rmacedon 2005-12-15 07:26:48 UTC
I'm using the beta version 5.0 and it has the same issue, which I suppose is an
obvious statement. Anyway, my issue is that the ide can run my standard
application that includes an external jar just fine, but I can't run it as a
standalone app. 
Comment 7 jskubick 2006-02-06 21:30:37 UTC
Netbeans' workflow for going from "app that runs inside the IDE" to "app capable
of running via 'java -jar jarfile.jar'" has *always* been needlessly tedious,
painful, and annoying. 

I can think of two workflows that would make just about everyone who uses
Netbeans to build apps capable of executing from jarfiles happy:

* Having Netbeans automatically generate the required Class-Path line in the
manifest by assuming that all of the required jarfiles in the 'compile' path
(regardless of whether they're from library-referenced jarfiles, built from
projects, or otherwise somehow associated with the current project) will be
present in the current directory at runtime (or, ideally, gives the ability to
optionally specify some subdirectory of the current directory where the jarfiles
will presumably be present at runtime). Ideally, there would be a sub-option to
have Netbeans copy all of those jarfiles to the 'dist' directory (or whatever
subdirectory were optionally specified as the location for the thirdparty
jarfiles). Then, all that would be necessary to run the app on a computer with
sufficiently modern JVM is to copy the entire 'dist' directory's contents to
some directory on the computer where the app will run, make that the current
directory, and launch the jarfile. Let's call this option "Clean and Build for
Distribution (Multijar)".

* Having Netbeans give the option of going a step further to create a single,
monolithic, plug and play jarfile that includes the contents of every last
jarfile needed to run it in the IDE (by unzipping them all into the 'build'
directory, then zipping them all into the final huge jarfile. If it makes the
academics and lawyers happy, Netbeans could throw up a dialog box that sternly
warns that what he's doing might potentially violate the terms of a license
(with a "shut up and never bother me about this again" checkbox at the bottom).
Let's call this option, "Clean and Build for Distribution (One Big Jar)".

No, it's not inconceivable that someday, somewhere, someone might finally want
to use a different third-party jarfile at runtime vs development, or want to put
them in some other place besides the current directory... but for god's sake,
please humor the 99.999985% of us who just want to be able to copy the whole
'dist' directory to the target computer somewhere and not spend 20+ minutes
playing "which of the 37 required jarfiles did I forget to explicitly reference
in the manifest or buildfile, or forget to copy over?"

As far as the IDE being unable to predict the runtime path goes... well, I
disagree. Make it painless and easy to copy the required jarfiles to the same
directory as the main jar, and that's exactly where everyone will throw them
because it'll be one less problem to worry about if they do. Grab an iterator to
whatever object the IDE uses to represent compile-time libraries, iterate
through it and get the File object pointing to the jarfile it ultimately
represents, copy that File to the dist directory, and tack the File's name and a
space onto a StringBuffer that starts with "Class-Path: ". Like this:

Class-Path: log4j-1.2.8.jar jdom.jar JSAP_1.03a.jar {... and 37 more jars...}

Tack the StringBuffer onto the manifest, and when the entire 'dist' directory
gets copied somewhere and run from it, everything will painlessly and
effortlessly work. No, it won't be a loosely-coupled work of abstract elegance
and beauty... but it WILL spare Netbeans users from lots of pointless grief and

As for licensing concerns... fine. Put a stern popup warning that says something
like, "WARNING: repackaging thirdparty jarfiles might violate licensing
agreements. [Continue|Cancel]". Just don't forget the most important part of the
popup: the little checkbox followed by "Shut up and don't bother me about this
Comment 8 Milos Kleint 2007-07-09 08:47:44 UTC
not project infrastructure related, relates mainly to ant scripts generated by the IDE. moving to -> ant/project

re 1:
please note, that you could write the relevant script sections yourself. Either for the single project or as a netbeans
module for any of your projects. Alternatively you could use build tools like Maven that also shall be capable of doing
what you propose. I doubt we will be capable of presenting a solution to "production deployment" that will satisfy everyone.

re 2+3: filed separately elsewhere.
Comment 9 lucrus 2007-07-09 12:33:13 UTC
mkleint wrote:
 please note, that you could write the relevant script sections yourself [...] I doubt we will be capable of
 presenting a solution to "production deployment" that will satisfy everyone

However I agree with jskubick that the solutions he's proposed would satisfy 99.999985% of us.
Comment 10 Jesse Glick 2007-07-09 20:34:55 UTC
There are a lot of different techniques in wide usage for creating distribution-friendly bundles of Java programs.

NB already does copy required JARs to the dist area when you build a (main-class) j2seproject's JAR, which is a crude
beginning. The Java Web Start support in NB 6 can also be helpful. Other proposals have been to use OneJAR, etc.

The main issue is that there really is no single, generally accepted packaging tool for Java SE applications. JSR 277
hopes to supply one, but that is far off. It is unclear if a single tool will ever be generally accepted, anyway; for
example, Mac users rightly expect a Mac-specific application "icon" (*.app dir) they can drag onto the desktop and run
with a double-click.

In the meantime, NB (or third-party modules or extensions) could provide support for particular tools which have proven
popular. (The contrib/packager module was a stalled attempt at this.)
Comment 11 manawiz 2007-07-10 02:47:52 UTC
Most of the problems I raised when opening this bug over 2 years ago have since been addressed.  Netbeans now makes it
easy to run an application outside the ide and tells you how to do it.  Wars can be dropped into any tomcat webapps
directory.  Building outside the ide is simpler due to things like default relative library paths in project files,
although it still requires the nb ant extension tasks.

Distribution of a project to users will generally involve creation of packages and/or installers.  Support for
developing major types of those would be great to have in nb, but not expected.