Provides the basic infrastructure by which Ant-based projects can be created, read and write configuration parameters and properties from/to disk, satisfy common queries and interfaces, etc. See Javadoc and build system design document.Question (arch-overall): Describe the overall architecture. Answer: AntProjectAPI -
Mostly an SPI for creating project types centered around the Ant build tool.
Permits Ant-based project types to be registered and supplies various support
implementations to help satisfy the contract of
various optional interfaces.
Mostly an SPI for use by project type providers to create the project type. Also includes a small API/SPI for other projects to find what Ant build steps are necessary to create a certain build product, for use in inter-project dependencies.Ant project support faq:
You basicaly need to do two things. First create the representation of the project properties which can be used in the GUI. Second at some time convert the objects back to the ANT properties form and store them into the project.
Mostly complete; see Issuezilla for remaining items.Question (arch-quality): How will the quality of your code be tested and how are future regressions going to be prevented? Answer:
Should be covered by unit tests.Question (arch-where): Where one can find sources for your module? Answer:
The sources for the module are in the NetBeans Mercurial repositories.
Filesystems, Datasystems (limited use and only internally), Project API,
General Queries API, Utilities (e.g.
The default answer to this question is:
These modules are required in project.xml:
None.Question (dep-platform): On which platforms does your module run? Does it run in the same way on each? Answer:
Any.Question (dep-jre): Which version of JRE do you need (1.2, 1.3, 1.4, etc.)? Answer:
1.4+.Question (dep-jrejdk): Do you require the JDK or is the JRE enough? Answer:
JRE, though many Ant tasks likely to be used by the project do require the JDK.
Just a JAR.Question (deploy-nbm): Can you deploy an NBM via the Update Center? Answer:
Yes.Question (deploy-shared): Do you need to be installed in the shared location only, or in the user directory only, or can your module be installed anywhere? Answer:
Anywhere.Question (deploy-packages): Are packages of your module made inaccessible by not declaring them public? Answer:
Yes, only API and SPI packages are exported.Question (deploy-dependencies): What do other modules need to do to declare a dependency on this one, in addition to or instead of the normal module dependency declaration (e.g. tokens to require)? Answer: Nothing.
Supports localized project display names. Does not support I18N of Ant build
scripts, though I18N of build output is possible (not yet implemented) via
AntLogger in the Ant Module API.
There are no known generally accepted standards for project metadata, so no.Question (compat-version): Can your module coexist with earlier and future versions of itself? Can you correctly read all old settings? Will future versions be able to read your current settings? Can you read or politely ignore settings stored by a future version? Answer:
Projects are stored using namespaced XML so the schemas are versioned. Possible for project type providers to upgrade old projects.Question (compat-deprecation): How the introduction of your project influences functionality provided by previous version of the product? Answer:
Some individual methods are marked deprecated.
Yes. Since Ant deals only with disk files, many aspects of this module deal
Files. Other parts use
No.Question (resources-read): Does your module read any resources from layers? For what purpose? Answer:
XML schemas are read from
No.Question (resources-preferences): Does your module uses preferences via Preferences API? Does your module use NbPreferences or or regular JDK Preferences ? Does it read, write or both ? Does it share preferences with other modules ? If so, then why ? Answer:
A LRU list of CRC-32s of
project.xml files known to validate successfully
is kept to avoid the need to validate files just to load projects, especially during startup.
org.openide.util.Lookupor any similar technology to find any components to communicate with? Which ones? Answer:
Ant-based project type providers are searched for in lookup.
AntArtifactQuery looks for implementations in lookup.
The delegating singleton project factory is registered for the Project API to
There is a delegating implementation of
System.getProperty) property? On a similar note, is there something interesting that you pass to
java.util.logging.Logger? Or do you observe what others log? Answer:
Standard property evaluators mirror system properties, as does Ant.
netbeans.do.not.check.xalan - The "netbeans.do.not.check.xalan" property switches off the startup check for buggy Xalan. See issue #70130 for more information.Question (exec-component): Is execution of your code influenced by any (string) property of any of your components? Answer:
No.Question (exec-ant-tasks): Do you define or register any ant tasks that other can use? Answer:
No.Question (exec-classloader): Does your code create its own class loader(s)? Answer:
No.Question (exec-reflection): Does your code use Java Reflection to execute other code? Answer:
No.Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection? Answer:
No.Question (exec-process): Do you execute an external process from your module? How do you ensure that the result is the same on different platforms? Do you parse output? Do you depend on result code? Answer:
No. (The Ant module does run Ant, though in-VM.)Question (exec-introspection): Does your module use any kind of runtime type information (
instanceof, work with
java.lang.Class, etc.)? Answer:
A check for buggy Xalan is performed during startup. The test tries to lookup org.apache.xalan.Version class. If the class is not found, the buggy Xalan is not on the classpath. If the class can be resolved, other checks (not using Java reflection) are performed.Question (exec-threading): What threading models, if any, does your module adhere to? How the project behaves with respect to threading? Answer:
Uses the Project API's read-write lock for most purposes. Some classes, such as the file built query implementation, use ad-hoc synchronization.Question (security-policy): Does your functionality require modifications to the standard policy file? Answer:
No.Question (security-grant): Does your code grant additional rights to some other code? Answer:
Reads and writes project metadata as XML and as Java Properties files. XML files are controlled by namespaced schemas with a generic wrapper and extensible segments used by the project type and perhaps other modules. Writes Ant build scripts upon request.Question (format-dnd): Which protocols (if any) does your code understand during Drag & Drop? Answer:
None.Question (format-clipboard): Which data flavors (if any) does your code read from or insert to the clipboard (by access to clipboard on means calling methods on
No. Project types may however (re-)generate any necessary build scripts on startup or opening.
Moreover, a check for buggy Xalan is performed on the startup. The test should be very fast if the buggy Xalan is not detected. See issue #70130 for more information.Question (perf-exit): Does your module run any code on exit? Answer:
No. Project types would commonly save any outstanding changes on exit however.Question (perf-scale): Which external criteria influence the performance of your program (size of file in editor, number of files in menu, in source directory, etc.) and how well your code scales? Answer:
Size of project metadata, perhaps, though typically this would be small.
Number of files in the case of
None known.Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc. Answer:
Probably little for the project itself.
consumes a modest amount of memory per file.
No.Question (perf-progress): Does your module execute any long-running tasks? Answer:
No. (Ant builds run by the Ant module are run in the Execution Engine.)Question (perf-huge_dialogs): Does your module contain any dialogs or wizards with a large number of GUI controls such as combo boxes, lists, trees, or text areas? Answer:
No GUI.Question (perf-menus): Does your module use dynamically updated context menus, or context-sensitive actions with complicated and slow enablement logic? Answer:
No.Question (perf-spi): How the performance of the plugged in code will be enforced? Answer:
No special provisions.