---

This is all experimental so far.

Introduction for Testers

This is a project type which tries to infer IDE information (mainly about the Java classpath) automatically from running Ant builds or from other passive sources.

It is not a modified freeform project type; it is completely independent of the existing freeform project type. It is also not intended to be functionally complete for what you would want out of a project type; you get the basic edit/test/debug cycle using "Compile on Save", i.e. Run/Debug/Profile File on a main class or unit test should work without needing to run an Ant build.

For now, it exists mainly to determine whether it is possible to pick up reasonably accurate information about user source code without intervention. "Reasonably accurate" means that few or no error badges appear (for sources which in fact compile), code completion appears where appropriate, Find Usages and cross-source Rename work, etc.

There is some minimal support for Java EE development: web application source structures may be recognized, enabling IDE features to help edit JSPs and deployment descriptors.

Basic usage instructions

1. Install Automatic Projects from updates in Plugin Manager. It is available in the Beta update center for NetBeans 6.5 Beta users (though Profiler support is missing in this version and there are a few bugs fixed in development versions). For 6.5 development build users, use the alpha update center. (No 6.1 backport planned.)
2. Use New Project and pick Java > Automatic Project to select the root folder of your project.
   • You have the option in this wizard to turn on automatic project detection mode, in which case any folder with a build.xml at top level will be considered a project and can be opened right away from Open Project. (Folders inside other projects do not count even if they have a build script.) This feature should be considered experimental.
3. Try to Build the project; you will asked to pick an Ant target. As it runs, source trees which have been compiled should start to appear in the Projects tab. JARs you use should start to appear under Libraries.
4. If you make build script changes affecting classpaths etc., just build again to refresh the IDE.
5. Run or debug main classes or JUnit tests just like in a regular Java project. Save classes when the debugger is running to reload them. Rerun failed test methods from the JUnit Test Results window.

How to report issues

Everything the module writes to disk is in $userdir/var/cache/autoprojects.properties which you can inspect to see what it "knows".

Please file bugs in the autoproject component in Issuezilla. (Bugs relevant to automatic projects but actually caused by other modules should be in the appropriate component with autoproject in the Status Whiteboard.) You can add autoprojects.properties as an attachment if it does not contain any confidential information.

You can also get the NetBeans Project Metadata Inspector module, available on development update centers, or as a direct NBM download. After installing, right-click a project node and select Inspect Project Metadata. You will see a dump in the Output Window of all kinds of relevant information. Pay attention to classpaths and associated sources in particular.

Major recent changes

Miscellaneous bug fixes and internal changes not listed.

• (Nov 11) new build published for 6.5 with various fixes, and including Profiler integration
• (Nov 05) association of sources with JARs made after compilation
• (Nov 05) automatic project detection mode configurable, disabled by default
• (Nov 05) classpath detection fixes
• (Sep 26) published on 6.5 Beta UC
• (Sep 19) Libraries node duplicates fixed
• (Sep 19) improved guessing of target name for actions
• (Sep 19) classpath detection fixes
• (Sep 16) miscellaneous Java EE support improvements
• (Aug 27) added basic Profiler integration
• (Aug 26) initial support for Java EE web application projects
• (Aug 25) basic Libraries node
• (Aug 04) rerun single test method
• (Jul 24) selection of special build script for action bindings
• (Jul 24) guess at plausible target names to bind to actions
• (Jul 21) supporting Quick Run (as used in Compile on Save projects)
• (May 05) New Project wizard can be used to mark top dir as autoproject
• (May 05) submenu with documented Ant targets
• (May 02) JUnit support

Development

Open issues

Related open issues

In contrib repo, in modules autoproject.*.

Some test cases: OSProjectsEvaluation

Call for test cases

AutomaticProjectsBrainstorming

To-do's (besides open issues listed above)

• More queries, etc. etc. - boilerplate stuff which can in some cases be copied from freeform projects.
• Running <junit> may not display results correctly in JUnit Test Results. Observed in JSPWiki sources. Need to specify <formatter type="brief" usefile="false"/> and even then individual passing tests do not seem to show up. Nor are stack trace lines hyperlinked, apparently. (Running an individual test should be fine, though.)

Background

ProjectTypeMusings

Old semi-proposal

A complete rethinking of the freeform project type might yield something of more value to a smaller number of people. (The expectation is that most users should be driven toward a more IDE-friendly project type, such as Maven.)

Stored configuration should be much slimmer, perhaps just a single netbeans.properties at top level with a few properties. Even that could be optional, the project being recognized solely by having a build.xml - so there would be no need for a New Project wizard whatsoever (you would just open the directory containing the build script and begin work). Or by default project configuration could be kept in the userdir, with a simple GUI option to move to netbeans.properties if you wanted to share the project setup.

Simple IDE action to Ant target bindings should be made lazily when the action is first run, prompting with

likely target names. Special actions (compile single, debug, ...) should normally be run directly from IDE code without Ant, and even routine Java compilation during editing might be better done this way (with project-wide Build continuing to run the Ant script to pick up any special processing stages). For special bindings, you could have a choice of Ant or scripting language, e.g.:

action.run=ant:build.xml:run-demo
# implicit param 'selection' is list of filename
action.run.single=script:ruby:selection.each |f| {load f}

All information about Java source roots, classpaths, and binary outputs should be gathered dynamically whenever targets are run successfully from the IDE (by tracing the Ant process), and cached in the user directory for future IDE sessions, but the user should never be made aware of this process. Similarly, information about web modules etc. should be inferred, never asked for explicitly. If the IDE cannot figure something out, it should give up silently and try to fall back to some harmless default behavior.

Source and Javadoc associations can probably be guessed with good accuracy if these files are physically located in the project; otherwise a simple context menu item would suffice to declare them, or even a hyperlink displayed in code completion when Javadoc is unavailable, or a dialog displayed when Go to Source fails prompting you to select the source location (would need a new small API).

The Projects tab display should normally be computed on the fly based on a quick runtime scan for source roots, web app docroots, files named README, etc.

For power users who want to set up a project for widespread use in a very particular way (e.g. Open JDK), an optional scripting binding could permit a small JavaScript or JRuby file to be associated with the project which would supply additional behaviors or customize its appearance. This would almost amount to a singleton project type accessible to developers willing to read a tutorial and do some experimentation, but without the need to understand any formal NetBeans APIs.

No Properties dialog is likely to be necessary. Whatever GUI is associated with the project type (ideally very little) should make it clear that all changes in the project's actual behavior are entirely up to the developer to make in Ant scripts and associated files.

VOC

• classpath analysis
  • better static analysis of the existing build.xml - even if it were not 100% accurate - something would be a start
• EAR projects (detection?)
• project dependencies (?)
• JUnit GUI (?)
• Ant script "customization" (editing? startup options?)
• should be no errors within a single source tree, at a minimum
• debugging support
• Libraries node should show entries from build.properties

Experiments

Ideally should try to (better!) handle everything in NetbeansReady.

OpenDS

Partially works. Lots and lots of source roots with terribly complex interrelationships.

Some generated. Some roots compiled piecemeal with a different classpath each time. Everything appears in Projects and mostly works, but still various error badges depending on which targets you ran, sometimes disappearing after files are opened. Perhaps impossible to fully support with current Java infrastructure.

GData-Java-Client

Doesn't really work. Samples use project dir as source root, whereas main sources use a subdir. Impossible to properly support in any project type.

Google-RFC-2445

Fairly simple. Seemed to work reasonably well. (build.xml has a bug - replace build.class.path with test.class.path in tests. Also need to add junit.jar to third_party/junit/.)

JSPWiki

Worked pretty well, except for problem displaying JUnit results (mentioned above). Also had up-to-date Eclipse metadata. Quick Run on unit tests does not take into account new modifications to tests, because build/JSPWiki-test.jar is added to the test CP, and BuildSniffer does not yet grok that this is an output of tests.

Genesis

Forget now, but some problems.

Guice

(Has IDEA metadata, build.xml, and a nonfunctional pom.xml.) One genuine compiler error and two genuine test failures. Running single tests (and test methods) works. Detected all source roots. Most look fine. spring/test etc. show error marks after doing a clean build since build/dist/guice-snapshot.jar was deleted, and the IDE does not realize this is a build product of src. Would be tricky for IDE to realize this, since build uses com.tonicsystems.jarjar.JarJarTask to create it. Some examples show error marks, but it does not seem possible to build them either.

Scala

(Has Eclipse metadata, complex build.xml.) Seems to work well.

Update Center 2

https://updatecenter2.dev.java.net/ seems to work fine if you delete the old freeform project metadata.

JAXP (in OpenJDK)

Need to use New Project and then run build target in make/build.xml. After that, seems to work fine.

Tomcat

Works (after you define jdt.jar to a meaningful path in build.properties). puretls and webservices packages are marked as erroneous; these are not in fact compiled. No obvious way to run tests.

Apache Ant

Works pretty well. (Also 1.7.x branch does not put junit.jar in classpath; fixed for 1.8.) Quick Run even works on most unit tests: BuildFileTest.configureProject has

File antFile = new File(System.getProperty("root"), filename);

which fortuitously works (the system property is unset but the CWD is in fact the project root). Some error badges, but just on optional tasks which in fact cannot be compiled without downloading some additional JAR. (Ideally these would be in their own source roots.) Running single test methods does not work, probably because this needs a patched version of Ant.

BeanShell

Looks to work OK.

(Note: when running on JDK 6, compilation from Ant and from editor is broken because BSH appears to ship with an obsolete version of JSR 223 with a different signature for Invocable.)

Langtools subproject of OpenJDK

Works after you define necessary properties in ~/.openjdk/build.properties as usual. JTReg-based tests cannot be run individually, and no classpath for these tests is available, but the freeform project is no better and the packageless structure of this tree makes it very hard for NetBeans to work with anyway.

Xerces-J 2

Does not work well, due to unnecessary build script hacks:

1. Special <xjavac> task (long since useless) prevents AP from recognizing that compilation is happening.
2. Sources are copied to a build dir before compiling, so build/src is treated as the source root rather than src.