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.
See also related issue 46483. Most existing real life Ant scripts that people use do not have targets that are used for tight IDE integration, e.g. single file compilation, debugging, fix-and-continue, JSP compilation, and sometimes even for things like deployment to the server. These actions are IDE-specific, and are not required for command-line use of the Ant script. The consequence is that such actions are not available on most freeform projects. The IDE could make these features available by generating the missing targets - probably to a separate script, so the original user-supplied script is not polluted by IDE implementation details. To summarize: this enhancement request proposes generating Ant targets for IDE-specific actions (single file compileation, JSP compilation etc.) in freeform projects, so these actions are available.
After a night spent with querying articles, faqs, mailing list etc. on "freeform" issues, I agree fully - the first paragraph just hits the point. Whatever the _technical_ solution(s) on issues like "linking IDE actions to Ant targets", "tighter IDE integration", or "enable library adding to freeform projects" will be in the future (as described in "Build System Design", ch. "Freeform Projects"), most of all a summary on hand-editing the project.xml in these cases will do for the meantime. What about the /ant/freeform/eg/simple/* files I found in issue #46483? Please, publish an article on a subject like: "How to integrate (missing) IDE dependent targets to a freeform build.xml", handling the usual suspects like "compile.single", "test.single", "debug" etc.
A guide to editing freeform project.xml files is under preparation but not yet ready, please be patient.
From the user's point of view, the usage of Ant as the underlying building mechanism should be *completely* transparent. The IDE should not expect the user to perform any manual editing to the project meta info including the generated Ant script. Nor should the IDE pose any limitation on what the user can or cannot do due to the reason that Ant, the underlying build engine, poses the same limitation. Using an IDE, the user to should be able to perform any reasonable IDE operation to a single Java file (compile, run, dubug, run test...), regardless the type of the project - j2se, web, or the "freeform" which eventually should be gotten rid of since the user should be able to use the IDE to work with the "form" of project the user actually has in reality.
To wqtnetbeans: nice thoughts but there is no known way to achieve that state, sorry. If you think otherwise, feel free to draft a detailed proposal for how it would ultimately work.
I wonder what should be that hard to simply provide these defaults (also for final 4.0). Required things like build-output path, classpath are already defined in the properties of a free-form project. The samples from http://www.netbeans.org/kb/articles/freeform-config-40.html could be a good starting point for the implementation. If there are no custom definitions for compile.single, run.single, and debug.single in project.xml they obviously could be defined as follows: # compile.single Compiles one or more \.java$ files with the default java compiler into the folder already specified as build-output in project properties. # run.single Compiles one \.java$ file with the default java compiler into the folder specified as build-output in project properties and then runs it in a forked process with the classpath speciefied in project properties. # debug.single Respectively Whether to implement this by providing an extra default build file for those actions or simply hard-coding it should not matter. This would satisfy a lot of people which complain about the out-of-the-box-experience of NB4 and does not contradict the principles of the new build system: It would be much more simple to quickly setup a freeform project and the immediately compile, run or debug a single class. Also a starter with NB4 could start frome somewhere where hes has been already in 3.6 I don't see any reason which speaks against this (also if actively reading all discussion about that topic on the list)
from a unrelated, non-ant perspective: for example in maven, compiling single files is not supported at all. (intentionally AFAIK, the maven infrastructure should allow that as well) on top of that, when compiling a project, all tests are run automatically by default (can be switched off). while that is somewhat extreme, I believe that compiling single files is error prone and should be avoided if possible. If the build of the project takes too much time, it should be split into multiple projects in the ideal case. Having automatically generated or hardcoded compile-single target as is suggested in one of the comments can lead to other out-of-synch usecases, for example when the java files are pre-processed or post-processed through xdoclet, jdo or any other custom tools.
If somebody setup pre-and-postprocessing of Java sources - I don't think he'd forget to adapt compile.single... - he'd be happy to be able to do so. He's not addresseed with this issue. Also why only talking about super-mega-monster-ultra-big... projects. What about the lot of sample code classes and snippets around in the world? I quickly want to see what it does, change something and run it again quickly. Do I really have to spent at least 10 minutes for setting up a project to do so (later wiping all the overhead files again)? In 3.6 I simply double-clicked such a file! Do I have to use some second minimal IDE for such use cases?
I'd say compile-single is one of the less critical subitems of this issue, run and debug (and perhaps compile-jsps) are much more important. Most users will be happy with the run and debug capabilities, even if we don't provide compile-single. As to why this can't be done for NetBeans 4.0, the problem is that we really need to focus on NB 4.0 bugfixing, and we don't have time to implement additional features, however easy they are. First we need to address all the "MDR corrupted" states etc., so you can work with the IDE for a week without having to delete your userdir.
I understand this and feel much better with these words than reading "It's to hard to implement" as final comment although the importance of this issue should not be marginalized with respect to Netbeans competition with other IDEs.
This would *greatly* increase the utility of free-form projects. Also, compile-single (and clean-single!) are *critical* when dealing with really large projects.
Definitely considered for 4.1 but not yet committed; in particular, need to consider UI consistency with web/J2EE applications, which would probably be more difficult to implement. Detailed UI spec not available, but would probably involve making all known actions enabled on freeform projects; if user selects an action with no existing binding, some kind of wizard would guide user in creating a binding (TBD how).
*** Issue 50684 has been marked as a duplicate of this issue. ***
*** Issue 52750 has been marked as a duplicate of this issue. ***
UI spec available.
Investigating feasibility.
Implemented for compile.single ("Compile File") as a beginning. If the project has no binding for this command yet, then the action is nonetheless made enabled on any Java source file(s). If you invoke it, the alert mentioned in the UI spec is displayed. If you accept, nbproject/ide-targets.xml is created, with a very basic target implementation that tries to glean information from existing data in your project.xml: the compilation units, their package roots, source levels, compile-time classpaths, output dirs, and ${project.dir} (for projects with external sources). The script is opened for you in the editor and a matching binding is made in project.xml. Any further edits to the impl and/or binding of compile.single is up to the user. Tested on Apache Ant dev sources, with a freeform project with external source location and all relevant info already configured in the GUI (package roots, classpaths, output locations, source levels), and it seemed to work OK. committed 1.2 ant/freeform/src/org/netbeans/modules/ant/freeform/LookupMergerImpl.java committed 1.2 ant/freeform/src/org/netbeans/modules/ant/freeform/spi/LookupMerger.java committed 1.2 ant/freeform/test/unit/src/org/netbeans/modules/ant/freeform/spi/ProjectNatureTest.java committed 1.28 ide/golden/deps.txt committed 1.6 java/freeform/nbproject/project.xml committed 1.3 java/freeform/src/org/netbeans/modules/java/freeform/Bundle.properties committed 1.4 java/freeform/src/org/netbeans/modules/java/freeform/Classpaths.java added 1.1 java/freeform/src/org/netbeans/modules/java/freeform/JavaActions.java committed 1.5 java/freeform/src/org/netbeans/modules/java/freeform/JavaProjectNature.java added 1.1 java/freeform/test/unit/src/org/netbeans/modules/java/freeform/JavaActionsTest.java
UI clarification from Jano: when automatic selection for Debug Project is implemented, then it should no longer be listed in the Build & Run panel of the project properties dialog.
Cf. http://www.netbeans.org/kb/articles/freeform-config-40.html#debugj2se
Added Debug Project automatic binding. Removed Debug from list of commands displayed in properties dialog. committed 1.13 ant/freeform/nbproject/project.xml committed 1.18 ant/freeform/src/org/netbeans/modules/ant/freeform/ui/Bundle.properties committed 1.14 ant/freeform/src/org/netbeans/modules/ant/freeform/ui/TargetMappingPanel.form committed 1.31 ant/freeform/src/org/netbeans/modules/ant/freeform/ui/TargetMappingPanel.java committed 1.32 ide/golden/deps.txt committed 1.4 java/freeform/src/org/netbeans/modules/java/freeform/Bundle.properties committed 1.2 java/freeform/src/org/netbeans/modules/java/freeform/JavaActions.java committed 1.2 java/freeform/test/unit/src/org/netbeans/modules/java/freeform/JavaActionsTest.java committed 1.312 usersguide/javahelp/org/netbeans/modules/usersguide/Map.jhm
Note that Debug Project generation operates in one of two modes: 1. If the project already bound Run Project, to exactly one target which had exactly one <java> task in it, the IDE creates a script which imports the main build.xml and makes a near-copy of the existing run target, just adding <nbjpdastart> and the appropriate JVM args. In many cases such a binding will work immediately with no further edits needed by the user. 2. Otherwise, the IDE cannot make a safe guess as to what it should do; so a different script is created (the same script as Compile File uses) which copies property defs from project.xml, and a simple impl of main class debugging is inserted, with comments warning the user that at least some edits will be necessary in order to make the target work in the desired way. In any event, after binding generation both project.xml and the generated Ant script are opened in the editor, with the caret placed at the beginning of the newly added text, so the user can see what the IDE just did and make any needed corrections.
Implemented the simpler category of alerts that just asks you to pick an existing target, for actions which are not expected to be IDE-specific (such as Run or Test or Generate Javadoc): committed 1.4 ant/freeform/build.xml committed 1.10 ant/freeform/src/org/netbeans/modules/ant/freeform/Actions.java committed 1.14 ant/freeform/src/org/netbeans/modules/ant/freeform/Bundle.properties committed 1.19 ant/freeform/src/org/netbeans/modules/ant/freeform/ui/Bundle.properties committed 1.32 ant/freeform/src/org/netbeans/modules/ant/freeform/ui/TargetMappingPanel.java added 1.1 ant/freeform/src/org/netbeans/modules/ant/freeform/ui/UnboundTargetAlert.form added 1.1 ant/freeform/src/org/netbeans/modules/ant/freeform/ui/UnboundTargetAlert.java committed 1.4 ant/freeform/test/unit/src/org/netbeans/modules/ant/freeform/ActionsTest.java added 1.1 ant/freeform/test/unit/src/org/netbeans/modules/ant/freeform/ui/UnboundTargetAlertTest.java
So summary of features implemented for E: 1. First alert in UI spec fully implemented: if a non-IDE-oriented action (like Run Project) is attempted on a freeform project without such a binding, the user is simply prompted to pick an Ant target for it. Note that "Generate Javadoc" is also covered (forgotten in UI spec). 2. Second alert in UI spec fully implemented, but only for some actions: Debug Project, and Compile File (which was also forgotten in the UI spec). Not yet implemented: Run File, Debug File, Test File, Debug Test for File, and Fix (again, forgotten in UI spec). Current plans are to leave the impls of RF, DF, TF, DTfF, and Fix for promotion F, since we just ran out of time for E, and the earliest I could spend any time on the remaining actions is the second week of March. (Implementing additional actions will certainly be much easier now that the infrastructure is in place, but will not be trivial.) Jano I would appreciate it if you could update the UI spec to mention the forgotten actions: Generate Javadoc (Alert #1), Compile File (#2), and Fix [& Continue] (#3).
Jan, any interest in continuing this? I think the basic infrastructure is already set up (including unit testing infrastructure), so it would probably not be too hard to finish, but I'm not sure.
*** Issue 59874 has been marked as a duplicate of this issue. ***
*** Issue 47508 has been marked as a duplicate of this issue. ***
*** Issue 71904 has been marked as a duplicate of this issue. ***
Changing the default component owner to tzezula.