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.
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 iteratively. 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
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)
Reassigning to the "projects" module.
Petr please use the button " Reassign issue to owner of selected subcomponent".
can't have a P1 subtask of a P2 one.
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: http://nbxdoclet.sourceforge.net/ 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.
>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: http://blogs.sun.com/xzajo/entry/project_extensions_wizard 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 window. * Customizer for Project extension In development version is implemented persistence of natures to nbproject/project.xml. 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 :-))
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.
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"> <classpath path="${java.home}/../lib/tools.jar:${j2ee.platform.wsimport.classpath}:${javac.classpath}"/> </taskdef> </target> 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" depends="wsimport-init,wsimport-client-check-AddNumbers" unless="wsimport-client-AddNumbers.notRequired"> <wsimport sourcedestdir="${build.generated.dir}/wsimport/client" extension="true" package="wsc" destdir="${build.generated.dir}/wsimport/binaries" wsdl="${basedir}/${conf.dir}/xml-resources/web-service-references/AddNumbers/wsdl/AddNumbers.wsdl" wsdlLocation="file:/C:/wsdls/AddNumbers.wsdl" catalog="catalog.xml"/> <copy todir="${build.classes.dir.real}"> <fileset dir="${build.generated.dir}/wsimport/binaries" includes="**/*.xml"/> </copy> </target> The generated files are then fed to the regular javac target for compilation.
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> <target name="run-deploy" depends="init,compile,compile-jsps,-do-compile-single-jsp,dist,-pre-run-deploy,-pre-nbmodule-run-deploy,-run-deploy-nb,-init-deploy-ant,-deploy-ant,-run-deploy-am,-post-nbmodule-run-deploy,-post-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 support.
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 -pre-compile. 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 directories. The wizards should be available in the java/jar project, war, and ejb projects; the requirements are the same for all.
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 targets - 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)
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 configurations. 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.
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 builds. 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.
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?
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" depends="init,compile,compile-jsps,-do-compile-single-jsp,dist,-pre-run-deploy,-pre-nbmodule-run-deploy,-run-deploy-nb,-init-deploy-ant,-deploy-ant,-run-deploy-am,-post-nbmodule-run-deploy,-post-run-deploy"/>
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.
I've created a wiki page with the suggested API/SPI for this feature. http://wiki.netbeans.org/wiki/view/BuildScriptExtensibility Comments welcome, either here or in the page.
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, wsimport-service-WS2"> 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 re-generated. In another words, I am missing a method like : AndBuildExtender.refreshBuildScript(); Calling the removeExtension() and addExtension() looks impractical.
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.
Does it mean that calling one of the 4 methods : AntBuildExtender.addExtension(...) AntBuildExtender.removeExtension(...) Extension.addDependency(...) Extension.removeDependency(...) 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 Extension.removeDependency(...) In that case, only the addDependency(), removeDependency() should be enough for triggering the build script re-generation process.
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.
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.
For the <compilerarg>: better to just modify javac.compilerargs in project.properties, I guess?
Created attachment 40555 [details] ant project api changes
Created attachment 40557 [details] webstart as a sample extender api usage
Created attachment 40558 [details] sample (non-final) j2se project changes to enable extensibility
Created attachment 40559 [details] updated javadoc of ant/project
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.
I've commited the changes to a branch, to checkout, run: cvs -q update -r mkleint_93509 ant/project/ java/j2seproject/ javawebstart/
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 projects. 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, getRestrictedTargets() isAllTargetsRestricted()
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.
gmpatil: 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.
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?)
[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.
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.
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.
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..
"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 version!
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.
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.)
Created attachment 41230 [details] new ant/project diff
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:------------------------------------------------- IDE: [4/19/07 9:57 AM] Committing started Checking in src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java; /cvs/ant/project/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelper.java,v <-- GeneratedFilesHelper.java new revision: 1.18; previous revision: 1.17 done Checking in src/org/netbeans/spi/project/support/ant/AntBuildExtenderSupport.java; /cvs/ant/project/src/org/netbeans/spi/project/support/ant/AntBuildExtenderSupport.java,v <-- AntBuildExtenderSupport.java new revision: 1.2; previous revision: 1.1 done Checking in src/org/netbeans/spi/project/support/ant/package.html; /cvs/ant/project/src/org/netbeans/spi/project/support/ant/package.html,v <-- package.html new revision: 1.4; previous revision: 1.3 done Checking in nbproject/project.xml; /cvs/ant/project/nbproject/project.xml,v <-- project.xml new revision: 1.23; previous revision: 1.22 done Checking in src/org/netbeans/api/project/ant/AntBuildExtender.java; /cvs/ant/project/src/org/netbeans/api/project/ant/AntBuildExtender.java,v <-- AntBuildExtender.java new revision: 1.2; previous revision: 1.1 done Checking in src/org/netbeans/api/project/ant/AntBuildExtenderAccessorImpl.java; /cvs/ant/project/src/org/netbeans/api/project/ant/AntBuildExtenderAccessorImpl.java,v <-- AntBuildExtenderAccessorImpl.java new revision: 1.2; previous revision: 1.1 done Checking in src/org/netbeans/spi/project/ant/AntBuildExtenderImplementation.java; /cvs/ant/project/src/org/netbeans/spi/project/ant/AntBuildExtenderImplementation.java,v <-- AntBuildExtenderImplementation.java new revision: 1.2; previous revision: 1.1 done Checking in test/unit/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelperTest.java; /cvs/ant/project/test/unit/src/org/netbeans/spi/project/support/ant/GeneratedFilesHelperTest.java,v <-- GeneratedFilesHelperTest.java new revision: 1.10; previous revision: 1.9 done Checking in test/unit/src/org/netbeans/spi/project/support/ant/AntBuildExtenderTest.java; /cvs/ant/project/test/unit/src/org/netbeans/spi/project/support/ant/AntBuildExtenderTest.java,v <-- AntBuildExtenderTest.java new revision: 1.2; previous revision: 1.1 done Checking in test/unit/src/org/netbeans/spi/project/support/ant/AntBasedTestUtil.java; /cvs/ant/project/test/unit/src/org/netbeans/spi/project/support/ant/AntBasedTestUtil.java,v <-- AntBasedTestUtil.java new revision: 1.23; previous revision: 1.22 done Checking in src/org/netbeans/modules/project/ant/AntBuildExtenderAccessor.java; /cvs/ant/project/src/org/netbeans/modules/project/ant/AntBuildExtenderAccessor.java,v <-- AntBuildExtenderAccessor.java new revision: 1.2; previous revision: 1.1 done Checking in apichanges.xml; /cvs/ant/project/apichanges.xml,v <-- apichanges.xml new revision: 1.17; previous revision: 1.16 done Checking in manifest.mf; /cvs/ant/project/manifest.mf,v <-- manifest.mf new revision: 1.20; previous revision: 1.19 done Checking in test/unit/src/org/netbeans/spi/project/support/ant/data/extension1.xml; /cvs/ant/project/test/unit/src/org/netbeans/spi/project/support/ant/data/extension1.xml,v <-- extension1.xml new revision: 1.2; previous revision: 1.1 done IDE: [4/19/07 9:57 AM] Committing finished
BTW I don't think AntBuildExtenderImplementation and AntBuildExtenderSupport should be in different packages; you cannot use one without the other.
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)?
Yes, that makes the most sense to me (move + rename).