Bug 46886 - [freeform] Support all IDE-specific actions even for incomplete freeform projects
[freeform] Support all IDE-specific actions even for incomplete freeform proj...
Status: NEW
Product: projects
Classification: Unclassified
Component: Ant Freeform
All All
: P2 with 12 votes (vote)
Assigned To: Tomas Stupka
buildsys-e-cand NbFeature1106
: 47508 50684 52750 59874 71904 (view as bug list)
Depends on:
Blocks: 42682 47160 89477
  Show dependency treegraph
Reported: 2004-08-04 09:56 UTC by Petr Jiricka
Modified: 2016-07-19 16:43 UTC (History)
14 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2004-08-04 09:56:01 UTC
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.
Comment 1 fuege 2004-08-24 23:20:18 UTC
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 
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.
Comment 2 Jesse Glick 2004-08-25 00:22:33 UTC
A guide to editing freeform project.xml files is under preparation but
not yet ready, please be patient.
Comment 3 wqtnetbeans 2004-08-26 00:50:27 UTC
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. 
Comment 4 Jesse Glick 2004-08-26 01:20:46 UTC
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.
Comment 5 _ moser 2004-10-06 09:09:05 UTC
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

# debug.single

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) 
Comment 6 Milos Kleint 2004-10-06 09:25:30 UTC
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.
Comment 7 _ moser 2004-10-06 10:04:17 UTC
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?
Comment 8 Petr Jiricka 2004-10-06 10:33:38 UTC
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.
Comment 9 _ moser 2004-10-06 10:44:50 UTC
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.
Comment 10 jessholle 2004-10-06 15:35:56 UTC
This would *greatly* increase the utility of free-form projects.

Also, compile-single (and clean-single!) are *critical* when dealing
with really large projects.
Comment 11 Jesse Glick 2004-12-02 20:58:40 UTC
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).
Comment 12 Jesse Glick 2004-12-02 21:03:01 UTC
*** Issue 50684 has been marked as a duplicate of this issue. ***
Comment 13 Jesse Glick 2004-12-22 16:37:11 UTC
*** Issue 52750 has been marked as a duplicate of this issue. ***
Comment 14 Jesse Glick 2005-01-13 17:35:36 UTC
UI spec available.
Comment 15 Jesse Glick 2005-01-18 20:07:08 UTC
Investigating feasibility.
Comment 16 Jesse Glick 2005-01-19 04:12:35 UTC
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 
committed 1.2 
committed 1.2 
committed 1.28 ide/golden/deps.txt
committed 1.6  java/freeform/nbproject/project.xml
committed 1.3 
committed 1.4 
added     1.1 
committed 1.5 
added     1.1 
Comment 17 Jesse Glick 2005-01-19 16:13:33 UTC
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.
Comment 19 Jesse Glick 2005-01-22 22:16:54 UTC
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 
committed 1.14 
committed 1.31 
committed 1.32  ide/golden/deps.txt
committed 1.4  
committed 1.2  
committed 1.2  
committed 1.312
Comment 20 Jesse Glick 2005-01-22 22:26:54 UTC
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.
Comment 21 Jesse Glick 2005-01-23 19:57:29 UTC
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
committed 1.14
committed 1.19
committed 1.32
added     1.1 
added     1.1 
committed 1.4 
added     1.1 
Comment 22 Jesse Glick 2005-01-24 17:34:25 UTC
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).
Comment 23 Jesse Glick 2005-04-21 15:22:12 UTC
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.
Comment 24 Jesse Glick 2005-06-24 11:08:03 UTC
*** Issue 59874 has been marked as a duplicate of this issue. ***
Comment 25 Jesse Glick 2005-12-22 18:31:05 UTC
*** Issue 47508 has been marked as a duplicate of this issue. ***
Comment 26 Jesse Glick 2006-07-11 23:56:46 UTC
*** Issue 71904 has been marked as a duplicate of this issue. ***
Comment 27 Antonin Nebuzelsky 2010-01-11 04:28:30 UTC
Changing the default component owner to tzezula.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo