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.
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 configuration. 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.
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 elsewhere.
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.
Part of this is certainly related to <A HREF="http://www.netbeans.org/issues/show_bug.cgi?id=56402">Issue #56402</A>, which has been folded into <A HREF="http://www.netbeans.org/issues/show_bug.cgi?id=49636">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.
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.
superplinio: you must add yourself to CC to see replies to your comments. Re. adding Class-Path to manifest.mf: 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.
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.
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 agony. 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 again".
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.
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.
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.)
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.