Bug 93509 - Extensible build scripts for projects
Extensible build scripts for projects
Product: projects
Classification: Unclassified
Component: Ant Project
All All
: P2 (vote)
: 6.x
Assigned To: Milos Kleint
plan60 nbide
Depends on: 101710 101716 101718 101850
Blocks: 72091 100660
  Show dependency treegraph
Reported: 2007-01-30 06:04 UTC by Srividhya Narayanan
Modified: 2007-04-20 17:42 UTC (History)
9 users (show)

See Also:

ant project api changes (49.65 KB, patch)
2007-04-06 14:59 UTC, Milos Kleint
Details | Diff
webstart as a sample extender api usage (5.88 KB, patch)
2007-04-06 14:59 UTC, Milos Kleint
Details | Diff
sample (non-final) j2se project changes to enable extensibility (25.55 KB, patch)
2007-04-06 15:01 UTC, Milos Kleint
Details | Diff
updated javadoc of ant/project (261.30 KB, application/octet-stream)
2007-04-06 15:37 UTC, Milos Kleint
new ant/project diff (48.96 KB, patch)
2007-04-19 10:22 UTC, Milos Kleint
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Srividhya Narayanan 2007-01-30 06:04:00 UTC
The existing project build system in NB is not easily extensible. The process
today to extend the build script involves working with the individual project
module owners to agree on required changes to the build xslt file and getting
approvals to commit the changes. The current recommended practice is to add the
minimal hooks needed to have these extension points on the projects's build xslt
file and maintain the rest of the feature specific functionality in a separate
metadata file. The projects's build.xml file is then modified at runtime to have
this feature specific metadata file "imported" before the build-impl.xml file so
that the relevant targets get invoked on the newly imported metadata file. There
are some drawbacks to this approach both technically and process wise. Everytime
the existing feature needs to extend the support for a new project type or want
new interception points on existing project types, this process is followed

Some potential problems with the existing approach are:
- The import facility only allows one override of the target so when scaling the
solution there could be inadvertent hiding of targets.
- This requires touching two places in the build script (the dependency list of
the target) and the import area.
- The tight coupling prevents low touch partnering in NetBeans.

Example of features that use this functionality currently:
- Web Services support for all the java EE project types (web, ejb, ear) and
java proejcts.
- Profiler
- Access Manager (Identity) tooling for web services security

There are few other projects that are interested to extend the build
functionality including:
- Java EE service engine from composite application
- JaxB support

The suggested approach would be to make the build system extensible. There could
be several ways this can be designed. The ideal solution should be implementable
by as many project types as possible so that this becomes truly extensibly and
any feature that wants to leverage this on several projects has an option to do
so. This would provide the existing projects that currently use other ways to
extend the build system to extend the functionality seemlessly to newproject
types. This would also enable the newly planned features to use the extensible
build system without having to work with individual module owners.

Some of the design ideas discussed in conjunction with the J2EE team during
their MPK visit in Jan 2007 are:
- Provide pre-defined hooks(nb modules only, user exposed etc) in the build
system for the most commonly extensible targets like deploy, dist etc.
- Provide APIs to directly modify the project's build transformation capability
Comment 1 Srividhya Narayanan 2007-01-30 19:26:47 UTC
Adding one additional requirement. This comes from web services modules.

1/ ability to add/insert build targets (with ability to set target dependences)
2/ ability to modify build.properties

Examples :
1/ We'd like to add "wsimport" target to build-impl.xml without modifying
project's specific xslt script
2/ To persist "wsimport" options we'd like to have an ability to modify
project's build.properties (or another .properties) 
Comment 2 Petr Jiricka 2007-02-02 12:48:53 UTC
Reassigning to the "projects" module.
Comment 3 Jesse Glick 2007-02-02 19:02:41 UTC
Petr please use the button " Reassign issue to owner of selected subcomponent".
Comment 4 Milos Kleint 2007-02-08 13:27:30 UTC
can't have a P1 subtask of a P2 one.
Comment 5 Jesse Glick 2007-02-08 23:12:02 UTC
Obviously this is a major area with a lot of history, going right back to 4.0
when we considered providing such an SPI but rejected it in favor of having
something that worked quickly. There are numerous other features which need an
SPI like this, or could be improved by it, e.g. Emma code coverage, DBX debugger
integration, Java Web Start support, creation of JNI components in a Java
project, obfuscation, SFTP/SSH/WebDAV deployment, ANTLR/JavaCC, ad nauseam.

I do not know whether we have plans to do it or when. For example, a completely
different strategy that should be considered is to move to Maven as the build
tool, which already has a reasonably mature and broad plug-in system with at
least modest acceptance.

There is an experimental tool developed by Petr Zajac:


There are likely interactions with issue #89629. See obstacle #3 in that issue
for an idea of what I mean. We would like for a build script fragment to be
"read-only", i.e. not dependent on details of the project that imports it, so
that it can be shared by many projects. This may be tricky if you want to inject
dependencies into targets; Ant is not exactly designed for this.

The major difficulty to my mind is that it is not clear that you can always
write a build fragment in Ant which will make sense in a broad range of project
types, or in conjunction with other plug-ins. For example, if I have Emma and
RetroGuard extensions active in the same project, should they both be run to
postprocess my bytecode, and if so in which order? If I have written a Java Web
Start extension which I tested against plain Java projects, and I then try to
use it in a NetBeans module project, will it do anything useful or just produce
garbage? If I have added JNI support to my project so that a .dll is created,
will the code to run TestNG tests know to invoke a forked JVM with the right
library path? The combinatorial nature of an SPI like this makes it very hard to
know what use cases are valid.

Maven copes with this problem (to the extent it can) because plug-ins are
normally written as Java code, which can be much more flexible than an Ant
script, and because the system also defines a rich set of metadata in the POM
which permits different pieces of code to discover what they need to know about
the project in detail. I suspect that any attempt to reinvent a system like this
(by people with IDE experience but little applicable experience in enormous
build systems) will fail, unless its ambitions are very strictly limited.
Comment 6 pzajac 2007-02-22 09:47:38 UTC
>I suspect that any attempt to reinvent a system like this
>(by people with IDE experience but little applicable experience in enormous
>build systems) will fail, unless its ambitions are very strictly limited.

I agree with Jesse that writing SPI for ANT based project natures is very 
complicated and it's just only ugly workaround. Somethink like maven is 
future.  I wrote prototype (Project Extensions). It's not well documented now. 
I wrote Wizard to apisupport project. Short demo how to create nature for rmic 
compiler is here:

More complicated implementation is hibernate support with xdoclet.

It works, but contains a lot of horrible hooks:-). 

Main features :
    * Adding new ant tasks to project's build script
    * Specification of ant tasks dependencies in project's build script, for 
example the ant task is executed before -post-compile task.
    * SPI for ant targets. A nature is plugable to the other. 
    * Extending the classpatpath of project.
    * Allow to either download libraries from remote library repository (for 
example maven1) or specify root of repository on local filesystem (for example 
hibernate installation).
    * A project extension is represented with a node in Project Extensions 
    * Customizer for Project extension
In development version is implemented persistence of natures to 

But there are many problems:
- From my experience compatibility of project in different  NetBeans releases 
is problem. I maintain a web application for few years. I had to many times to 
clean project.properties. 

- Standard buildscripts are overcomplicated. Only experienced ant's developer 
understand them. A little change breaks everythink.  I cannot imagine how to 
develop compatible natures.  Don't forget that a nature contains SPI. Who will 
test the interaction between natures?

Finally I vote  rather for migration to Maven than writing natures for ant. 
Don't do the same mistake :-))
Comment 7 Chris Webster 2007-02-22 18:59:29 UTC
What about limiting the scope of build script extensibility such that a simple
solution exists? A more flexible extensibility solution such as Maven could be
the long term strategy, but having something may be helpful for extending
projects even in a limited fashion.
Comment 8 Roderico Cruz 2007-02-27 18:50:16 UTC
Following is a description of the role of the build script in web service
creation in Netbeans.
Two ant tasks, wsimport and wsgen are used for generating web service artifacts.
These tasks correspond to tools (of the same name)  provided by jaxws-ri. 
Since code generation is involved, the destination directory of the generated
artifacts are first created and its location is persisted in the
project.properties file.
For EE projects, the ant task classes come from jars that are provided by the
attached Glassfish server. The location of these jars are persisted in the
user's private properties file. Thus, the initialization of wsimport (including
the taskdef) will look something like:
<target name="wsimport-init" depends="init">
        <mkdir dir="${build.generated.dir}/wsimport/client"/>
        <mkdir dir="${build.generated.dir}/wsimport/binaries"/>
        <taskdef name="wsimport" classname="com.sun.tools.ws.ant.WsImport">

Here ${build.generated.dir} is stored in the project properties file, while
${j2ee.platform.wsimport.classpath} is stored in the private properties file.

The target for invoking the wsimport tool will look something like:
<target name="wsimport-client-AddNumbers"
        <wsimport sourcedestdir="${build.generated.dir}/wsimport/client"
extension="true" package="wsc"
wsdlLocation="file:/C:/wsdls/AddNumbers.wsdl" catalog="catalog.xml"/>
        <copy todir="${build.classes.dir.real}">
            <fileset dir="${build.generated.dir}/wsimport/binaries"

The generated files are then fed to the regular javac target for compilation.
Comment 9 Srividhya Narayanan 2007-02-27 20:53:55 UTC
For Access Manager tooling here is how we have extended the build system:

Extensions were done for web, ejb, ear and appclient projects. The extensions
done for web, ejb and appclient projects are all the same.

We have a special task -run-deploy-am which is added in the run-deploy target. `
    <target name="-run-deploy-am">
        <!-- Task to deploy to the Access Manager runtime. -->
    <target name="run-deploy"

The task is implemented by a special build_impl which is imported in the user
exposed build script. 

The only difference is in the ear project where individual included modules are
invoked. The required script is added to the core ear project's xslt file
itself. This individual ant calls on each module behaves exactly the same as
invoked from outside the ear itself. 


For REST tooling that we are planning for NB 6, here are the changes we need on
the build system:

Ability to perform some code gen prior to compilation. This interception
provides the ability to invoke REST specific apt which parses the annotations
from the POJO and generates required artifacts.

Further this behaviour should be the same for all projects with REST services
Comment 10 fkieviet 2007-02-28 06:00:31 UTC
For the JAXB wizard we would need an ant fragment with references to a meta data
file (XSD file), Netbeans library (for xjc), and an output directory. Other
wizards (encoders/decoders, jca's) would need similar functionality. We're
planning about a dozen of these code generating wizards.

We can live with the following restrictions:
- the sub-build does not interact or depend with the main build script (i.e. the
existing build-impl)
- no flexibility is needed as to when the sub-build is called

An implementation like the following would suffice: the existing build-impl
would call sub-ant on a subdirectory of nbproject. This call would happen in

The target directory (e.g. build/generated) would be set before calling sub-ant.
This target directory would automatically be included in the list of source

The wizards should be available in the java/jar project, war, and ejb projects;
the requirements are the same for all.
Comment 11 Milan Kubec 2007-03-01 08:53:00 UTC
Java Web Start support currently does the following:

- modifies project.properties file
- creates its own build script called jnlp-impl.xml, it contains all required
- the jnlp-impl.xml is then imported in build.xml
- and new "implementation" of '-post-jar' target is added to build.xml; it does
all jnlp related post jar steps
- new configuration is created (files are created in nbproject/configs and
nbproject/private/configs folders) and web start config is set as current using
ProjectConfigurationProvider API.
- the selected configuration affects which target is in fact executed by ant
when user clicks run and debug action in IDE (using special purpose properties
starting with $)

So in general it needs:
- modification of project properties
- plugging in own targets into specific stage of build process
- creating a configuration and setting it as current
- providing replacement for default targets (via special properties in the
config property file)
Comment 12 Milos Kleint 2007-03-02 11:08:08 UTC
re maven: I don't believe we should consider maven as replacement but rather a
complementary to ant. Even if we don't support maven completely now, we should
leave the door open for having 2 (or more) build systems at the backend. 

The rule of thumb for all project specific functionality shall be:
1. have UI visualizations, actions etc. that are built on top of defined domain
specific API.
2. defined an SPI for project types to implement that is as build tool agnostic
as practical.
3. only a separated subset of functionality is really tool specific, be it
customizer panels or their parts, plugs into the build systems or other project

that's already mostly the case, as I was able to prototype maven support for
webapps, persistence, netbeans modules or ejbs by plugging into the SPIs.
Comment 13 Milos Kleint 2007-03-02 11:55:31 UTC
rcruz: re webservices

1. it seems you have multiple targets per webservice, am I right? with any
added/removed webservice you need to edit the script. There's a also some kind
of way of disabling enabling the webservice.
2. you seem to be compiling the generated webservice code with a modified
classpath, adding libs.jaxws20.classpath there. is there a reason why the
jaxws20 library is not added to the compilation classpath of the project? IMHO
this could be a problem once we implement project versionability and headless
3. i've done a diff of clean j2se project and one with webservices and you seem
to be adding 
<compilerarg line="-Djava.endorsed.dirs=${jaxws.endorsed.dir}"/>
to the javac macro as well. 
Comment 14 Milos Kleint 2007-03-02 13:43:31 UTC
lets reiterate the goals for the api:
1. simplify integration of 3rd party build snippets. that measn reduction of
code and reduction of repeated errors.
2. unify the way modules integrate into the build script. it's obvious from the
examples that many different approaches have been chosen so far.
3. maintain a level of consistency of the build script to prevent failures or
conflicts and to allow future evolution of the core functionality.

anything else?
Comment 15 Pavel Buzek 2007-03-02 18:15:31 UTC
to expand on #3 ("prevent failures and conflicts") I think specifically we are
talking about:
a) extensions defined by modules should not interfere with extensions points in
build.xml designed for customization by the user
b) extensions defined by different modules should not interfere with each other
c) extensions defined by modules should have as loose dependency on the build
script generated for the project type; specifically overriding the standard
targets to add more dependencies (as in [1]) is problematic because if the
standard script adds more dependencies later they will not be added in the
extending script
d) (non requirements) cooperation between multiple extensions does not seem to
be required, defining relative order between multiple extensions also does not
seem to be required

[1] <target name="run-deploy"

Comment 16 Adam Sotona 2007-03-13 17:08:11 UTC
Take a look at the Mobility project - we've already implemented modular build
scripts with dynamic target dependencies.
This already allows us to plug in 3rd party modules with new technologies into
Mobility project or to support alternate build sequence for CDC and 3rd party
mobile environments, different for each project configuration. 
We can demonstrate our requirements, use cases and implemetation on some meeting.
Comment 17 Milos Kleint 2007-03-15 14:43:05 UTC
I've created a wiki page with the suggested API/SPI for this feature.

Comments welcome, either here or in the page.
Comment 18 Milan Kuchtiak 2007-03-19 17:06:09 UTC
I looked at the API proposal. So, as a feature provider, I need to use the Build
Script API, not SPI, right ?

Here is the problem I see with the proposal.

We'd like to proceed with our jax-ws.xml configuration file.

As I correctly understand we need to use the following schema :

USE CASE A: First web service is created (WS1) in a project
1. new <service name="WS1"> element is created in jax-ws.xml
2. create separate jaxws-build.xml build script (and file object for this file)
   - the jaxws-build.xml will contain 3 targets:
     <target name="wsimport-init" depends = "init">
     <target name="wsimport-service-WS1" depends = "wsimport-init">
     <target name="wsimport-service-generate" depends = "wsimport-service-WS1">
3. call AntBuildExtender:addExtension("jax-ws",jaxWsBuildFo);
4. call Extension addDependency("-pre-pre-compile","wsimport-service-generate");

USE CASE B: second WS is created (WS2)
1. new <service name="WS2"> element is created in jax-ws.xml
2. jaxws-build.xml build script is changed (will contain 4 targets)
     <target name="wsimport-init" depends = "init">
     <target name="wsimport-service-WS1" depends = "wsimport-init">
     <target name="wsimport-service-WS2" depends = "wsimport-init">
     <target name="wsimport-service-generate" depends = "wsimport-service-WS1,

For use case B, nothing need to be called from AntBuildExtender since nothing is
changed with dependencies in the main build script.

QUESTION : How can I tell AntBuildExtender that build-impl.xml should be

In another words, I am missing a method like :

Calling the removeExtension() and addExtension() looks impractical.
Comment 19 Milan Kuchtiak 2007-03-19 17:16:31 UTC
I am sorry for previous comment.
I didn't realize that build script doesn't need to be re-generated because it
consists of 2 (or more) build scripts.
Comment 20 Milan Kuchtiak 2007-03-19 17:36:45 UTC
Does it mean that calling one of the 4 methods :

will trigger the re-generation of the build script ?

Or do I need to call those methods in the right order :
AntBuildExtender.addExtension(...) must precede the 
Extension.addDependency(...) and 
AntBuildExtender.reemoveExtension(...) must be called after

In that case, only the addDependency(), removeDependency() should be enough for
triggering the build script re-generation process.
Comment 21 Milan Kuchtiak 2007-03-19 17:58:48 UTC
I have another 2 concerns about this API.

1. will that be possible to use ActionUtils.runTarget(...) for targets specified
in separate build script ? I suppose yes.

2. we(WS Feature) are adding specific parameter to "-init-macrodef-javac" target :
<compilerarg line="-Djava.endorsed.dirs='${jaxws.endorsed.dir}'"/>
I don't see a way how to do that using Ant Extension API.
Comment 22 Milos Kleint 2007-03-20 08:07:03 UTC
re mkuchtiak:
any of the add/remove methods called in the API shall trigger a project update
on the spi (project type side). Whether such metadata update triggers build
script regeneration immediately or we require an explicit call to
ProjectManager.saveProject() at the end of the transaction is yet to be defined
I guess. My preference goes towards the explicit saveProject() call though.

re your concerns:
1. ye, the external buildi scripts will be imported into the main script, I see
why it shouldn't work.
2. sorry, this usecase is out of scope for the API. Any modifications to the
main build script have to be done with cooperation by the project type owner on
a case-by-case basis.
Comment 23 Jesse Glick 2007-03-21 02:03:27 UTC
For the <compilerarg>: better to just modify javac.compilerargs in
project.properties, I guess?
Comment 24 Milos Kleint 2007-04-06 14:59:07 UTC
Created attachment 40555 [details]
ant project api changes
Comment 25 Milos Kleint 2007-04-06 14:59:54 UTC
Created attachment 40557 [details]
webstart as a sample extender api usage
Comment 26 Milos Kleint 2007-04-06 15:01:33 UTC
Created attachment 40558 [details]
sample (non-final) j2se project changes to enable extensibility
Comment 27 Milos Kleint 2007-04-06 15:37:30 UTC
Created attachment 40559 [details]
updated javadoc of ant/project
Comment 28 Milos Kleint 2007-04-06 15:46:02 UTC
here's the proposed API/SPI in ant/project module.
included also a sample reimplementation of javawebstart support and partially
rewritten j2se project type.
on the project type side we still need to define what targets are to be
pluggable and get remove/rewrite the jaxws related codebase that is not
compatible with the new api/code. Will will do that on branch before the issue
gets merged into trunk.

please review.
Comment 29 Milos Kleint 2007-04-06 15:50:35 UTC
I've commited the changes to a branch, to checkout, run:
cvs -q update -r mkleint_93509 ant/project/ java/j2seproject/ javawebstart/ 
Comment 30 _ gmpatil 2007-04-13 02:48:38 UTC
I tried to use the API and found working as expected. 
We would like target "-pre-compile" to be extensible in Java SE, Web and EJB

Also wondering whether we need to restrict the list of target to be extensible
as we may not be able to foresee what target will be required to be extensible.

To allow project type implementor not list target specifically, we may need in
AntBuildExtenderImplementation one more method isAllTargetsExtensible() along
with getExtensibleTargets().

Or if we think it is easy for project implementor to come-up with list of target
to restrict,

Comment 31 Milan Kubec 2007-04-13 12:46:40 UTC
The API looks good to me. Minor comment: there should be probably some way to
check or better force uniqueness of the extension target, ... the prefix might
be generated from ID? Other thing is that the implementation has probably some
bug in it, because j2seproject created in IDE from the branch doesn't compile
java source files.
Comment 32 Milos Kleint 2007-04-17 21:22:07 UTC
1. yes, the list of extendable targets is yet to be defined for the individual
project types.
2. I believe it's best to leave the decision which targets to allows for
extension to th project type owner. I suppose the process for adding a target to
the list for a given project type would be to file a RFE at the project type's
issuezilla component.

mkubec: yes, targets in extension build scripts shall have names based on the
extension id. No idea how to enforce it other than by parsing the build script
xml which seems like an overkill. 
I will make sure it appears in the documentation. That should be enough.
Comment 33 Milos Kleint 2007-04-17 21:25:27 UTC
thanks for the review, I will commit the api part in ant/project tomorrow. 
I will leave the j2se project type implementation in branch until it's
stabilized however. Commiting the api part will allow other project types to
start implementing the spi part of the contract. I will file separate issues for
each of the potencially affected project type (j2se, ejb, web, ear + more?)
Comment 34 Jesse Glick 2007-04-18 02:54:42 UTC
[JG01] "Extendable" is not a word. Use "Extensible".

[JG02] I recommend that the <buildExtensions> be in a single standard namespace,
not defined per project type, and that there be helper methods to create & read
this fragment.

[JG03] "public static final" is redundant on interface constant fields.

[JG04] Project.getLookup Javadoc ought to mention AntBuildExtender.

[JG05] Does the patch to GeneratedFilesHelperTest actually test anything? It's
not clear to me what.

BTW you need to edit your CDDL license text in Templates Manager to not say that
you can edit it in Templates Manager, and to mention Sun Microsystems and
NetBeans etc. I wish this could be automated so that nb.org developers would not
need to make this customization in each new user dir.
Comment 35 Milos Kleint 2007-04-18 07:45:29 UTC
JG01,3,4: will do.

JG02: I have though the same way, decided against for these reasons:
1. when placed in it's own namespace , it can be accessed by
AuxiliaryConfiguration and bypass the API.
2. project types need to upgrade their primary namespace anyway and the current
setup forces them to.

JG05: not really testing extensibility stuff right now, it was just updated to work.
Comment 36 Jesse Glick 2007-04-18 12:01:39 UTC
For JG02:

1. The same is true of any fragment, e.g. <references>.

2. Why would project types need to upgrade their primary namespace if build
extensions were handled in a separate namespace?

By the way I would like to introduce an API change in AntProjectHelper
permitting it to deal with namespace upgrades in an easy manner. Just haven't
found time for it yet.
Comment 37 Milos Kleint 2007-04-18 12:27:58 UTC
I didn't know that it's a common practice to do so, I'm not entirely convinced
it's ok, but can rewrite it I guess. It would solve the issue with updating of
primary project schema.. (eg. now everyone has to copy the same schema snippet
to their primary conf.

the primary upgrade is neccessary because we can't allow to have the
build-impl.xml be regenerated once the extensions are used. 
AFAIK that's only doable ow using the Project's UpdateHelper instances and by
increaing the version..
Comment 38 Jesse Glick 2007-04-18 12:36:43 UTC
"we can't allow to have the build-impl.xml be regenerated once the extensions
are used" - I'm not sure I understand. Are you referring to part 3 of issue
#42735? If so, it should be fixed independently I guess. Surely we should not
create a new project.xml schema identical to the previous one but with a higher
Comment 39 Milos Kleint 2007-04-18 12:58:19 UTC
the GeneratedFilesHelper checks the antbuild extensions and inject the import
statement and target dependencies into build-impl.xml accordingly.
if we keep the same version of project definition and someone opens the project
in 5.5 afterwards, the 5.5 version of GeneratedFilesHelper will not do that and
remove all the extensions from the build script.

Re: issue #42735. This one might be obsolete as the only reason the jaxws people
copied the GeneratedFilesHelper was to get their extension into the main build
script. Now they can/should have it externally.

Comment 40 Jesse Glick 2007-04-18 14:48:14 UTC
Currently *any* useful improvement in a build-impl.xml can be reverted by
opening in an IDE which is too old. That is not specific to this issue, and the
damage is undone when reopened in the current IDE. For issue #42735 I was
referring to the third and most important point in the original issue
description, not the jaxws issue. (Yes, it should be split up into separate issues.)
Comment 41 Milos Kleint 2007-04-19 10:22:58 UTC
Created attachment 41230 [details]
new ant/project diff
Comment 42 Milos Kleint 2007-04-19 10:34:03 UTC
JG02: attached is the updated ant/project diff. with using
AuxiliaryConfiguration the spi part got fairly easier to implement on the
project type side.

commited to trunk. Also included is j2se project type adaptation of the new spi.
I've filed issue 101710 for a more complex rewrite of how j2se project generates
build-impl.xml. javawebstart was used as a sample codebase to use the new api.

filed issues against j2ee and web to write the spi and integrate the feature in
the respective project types.

IDE: [4/19/07 9:57 AM] Committing started
Checking in src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java;
 <--  GeneratedFilesHelper.java
new revision: 1.18; previous revision: 1.17
Checking in src/org/netbeans/spi/project/support/ant/AntBuildExtenderSupport.java;
 <--  AntBuildExtenderSupport.java
new revision: 1.2; previous revision: 1.1
Checking in src/org/netbeans/spi/project/support/ant/package.html;
/cvs/ant/project/src/org/netbeans/spi/project/support/ant/package.html,v  <-- 
new revision: 1.4; previous revision: 1.3
Checking in nbproject/project.xml;
/cvs/ant/project/nbproject/project.xml,v  <--  project.xml
new revision: 1.23; previous revision: 1.22
Checking in src/org/netbeans/api/project/ant/AntBuildExtender.java;
/cvs/ant/project/src/org/netbeans/api/project/ant/AntBuildExtender.java,v  <-- 
new revision: 1.2; previous revision: 1.1
Checking in src/org/netbeans/api/project/ant/AntBuildExtenderAccessorImpl.java;
 <--  AntBuildExtenderAccessorImpl.java
new revision: 1.2; previous revision: 1.1
Checking in src/org/netbeans/spi/project/ant/AntBuildExtenderImplementation.java;
 <--  AntBuildExtenderImplementation.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  GeneratedFilesHelperTest.java
new revision: 1.10; previous revision: 1.9
Checking in
 <--  AntBuildExtenderTest.java
new revision: 1.2; previous revision: 1.1
Checking in
 <--  AntBasedTestUtil.java
new revision: 1.23; previous revision: 1.22
Checking in src/org/netbeans/modules/project/ant/AntBuildExtenderAccessor.java;
 <--  AntBuildExtenderAccessor.java
new revision: 1.2; previous revision: 1.1
Checking in apichanges.xml;
/cvs/ant/project/apichanges.xml,v  <--  apichanges.xml
new revision: 1.17; previous revision: 1.16
Checking in manifest.mf;
/cvs/ant/project/manifest.mf,v  <--  manifest.mf
new revision: 1.20; previous revision: 1.19
Checking in test/unit/src/org/netbeans/spi/project/support/ant/data/extension1.xml;
 <--  extension1.xml
new revision: 1.2; previous revision: 1.1
IDE: [4/19/07 9:57 AM] Committing finished

Comment 43 Jesse Glick 2007-04-19 23:28:13 UTC
BTW I don't think AntBuildExtenderImplementation and AntBuildExtenderSupport
should be in different packages; you cannot use one without the other.
Comment 44 Milos Kleint 2007-04-20 07:55:30 UTC
fine with me.. so what about moving AntBuildExtenderSupport to
org.netbeans.spi.project.ant and rename it to AntBuildExtenderFactory (as the
only thing it doesn is creating instances of AntBuildExtender)?
Comment 45 Jesse Glick 2007-04-20 17:42:09 UTC
Yes, that makes the most sense to me (move + rename).

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