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.

Bug 72091 - API for extending projects types (eg. web) by 3rd party
Summary: API for extending projects types (eg. web) by 3rd party
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: apireviews
Keywords: UMBRELLA
Depends on: 72441 73198 74373 83343 86680 93509 99555
Blocks: 89772
  Show dependency tree
Reported: 2006-01-31 21:27 UTC by Rich Unger
Modified: 2007-06-12 17:12 UTC (History)
12 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Rich Unger 2006-01-31 21:27:08 UTC
For projects like Rave and V-Builder, and conceivably for plugins to support
particular server-side technologies, it is necessary to add functionality to the
web project type.

Everything I describe here I have in a working state in a patch to web/project
that I'm using in production code in V-Builder.

Firstly, I propose making the package "org.netbeans.modules.web.project.api"
public, rather than friendly.  Third-party modules should be able to
programatically create new web projects.
I propose 4 integration points for inserting functionality.  They are all
declared using factories in the system filesystem.  For example:

    <folder name="WebProject">
        <!-- Hook for running code at project-creation time -->
        <folder name="creation">
            <file name="NewProjectServiceHook.instance">
                <attr name="instanceClass"
        <folder name="sources">
            <file name="SpeechSources.instance">
                <attr name="instanceClass"
        <folder name="ui">
            <!-- These nodes get placed as children of the logical root node -->
            <folder name="nodes">
                <file name="SpeechDialogs.instance">
                    <attr name="instanceClass"
                <file name="DTT.instance">
                    <attr name="instanceClass"
            <!-- These panels get placed in the project properties UI -->
            <folder name="customizers">
                <file name="foo.instance">
                    <attr name="instanceClass"

1. WebProject/creation

Files in this folder denote instances of ProjectCreationHook:

public interface ProjectCreationHook
    void createProject( Project proj ) throws IOException;

...and are executed in NewWebProjectWizardIterator.instantiate().

2. WebProject/sources

Files in this folder denote instances of SourcesProvider:

public interface SourcesProvider
    SourceGroupDescriptor[] getSourceGroupDescriptors(FileObject projectRoot);

The interface SourceGroupDescriptor is:

public interface SourceGroupDescriptor
    FileObject getRootFolder();
    String getName();
    String getDisplayName();
    Icon getIcon(boolean opened);
    String getType();

...and these are read in WebSources.initSources(), where the following is executed:
sgd.getDisplayName(), sgd.getIcon(false), sgd.getIcon(true));
sourcesHelper.addTypedSourceRoot(sgd.getRootFolder.getPath(), sgd.getType(),
sgd.getDisplayName(), sgd.getIcon(false), sgd.getIcon(true));

3. WebProject/ui/nodes

Files in this folder denote instances of NodeFactory:

public interface NodeFactory
    Node createNode(Project p);
    Node findPath(Project p, Node root, Object target);

The factories are read into 2 lists: List<String> nodeKeys and List<NodeFactory>
nodeFactories.  In WebViews, the keys are added in buildKeys() and the
createNodes() method instantiates the nodes from the NodeFactory objects. 
WebPhysicalViewProvider.findPath() utilizes the NodeFactory.findPath() method.

4. Webproject/ui/customizers

Files in this folder denote instances of ProjectAwareUIFactory:

public interface ProjectAwareUIFactory
    String getCodeName();
    String getDisplayName();
    JComponent createComponent(Project p);

...which are read in CustomizerProviderImpl.init(), and added to the list of
categories and panels.
Comment 1 Pavel Buzek 2006-01-31 22:48:06 UTC
I think that all these APIs (nodes, sources, customizer) should be done in
ant/projects because they are generally useful, not only for web project.

Project creation is now only supported via any kind of API (i.e. fiend) in ejb
and web project so that is the right place for it.
Comment 2 Rich Unger 2006-01-31 23:11:17 UTC
Yeah, Jesse mentioned this to me.  I'm not sure I'm entirely clear on this,
however.  Let's take the example of the NodeFactory.  Each project type
currently has its own LogicalViewProvider and some class like
LogicalViewChildren for representing the children of the project root node.  Are
you suggesting that there should be a common abstract parent class for
LogicalViewChildren that has something like:

public String getNodeFactoryContext() {
  return "projects/web/ui/nodes";

If so, why wouldn't this abstract class reside in projectuiapi, rather than
Comment 3 Jesse Glick 2006-02-01 00:03:49 UTC
I guess Pavel meant "project/projectuiapi or ant/project or java/project etc.
acc. to whether the API is Ant- or Java-specific".
Comment 4 Petr Pisl 2006-02-01 09:13:15 UTC
I think as well, that the "customizing" ui should not be part of web project api
and should be solved on more general level. 
Comment 5 Jesse Glick 2006-02-01 14:57:37 UTC
This issue looks too big to review to me. I would suggest it be closed and split
into more digestible pieces - one issue for each separable SPI (e.g.
ProjectCreationHook). Each piece should be filed in the most general place where
it is realistic; possibly none in web/project. The friend SPI for ant/freeform
should be studied - the goal should be to replace some parts of that SPI with
new more generic SPIs.

It seems that the issue at this stage is an inception review, i.e. a request for
confirmation that the outlines of the SPI are sensible. A subsequent review
would be needed for actual patches, which would need to include: the SPI; impls
in all (or at least several representative) relevant project types;
documentation updates; and unit tests.

Please don't expect this to go quickly; this is not a minor enhancement. The
proposed SPIs are quite important for a lot of use cases and need to be done right.
Comment 6 Rich Unger 2006-02-01 19:38:28 UTC
Understood.  So, before I close this, let me get some input as to whether "the
outlines of the SPI are sensible" :)

I'm perfectly happy to do the lion's share of the coding/prototyping, though the
more modules this touches, the higher the documentation/testing burden, and I'll
probably want some help in that.  I really want to usher this stuff through, not
only because I'm patching netbeans to get V-Builder working the way I want, but
because I think these APIs (particularly the UI ones) will be very useful to
plugin writers who want to integrate things like Tapestry, Spring, Hibernate,
etc.  Also, I know Rave does similar patching currently.

Finally, I want a proof-of-concept for a non-Sun person to go through this
process.  I think that would be helpful in evangelizing
Comment 7 Jesse Glick 2006-02-01 20:06:24 UTC
Comment 8 Milos Kleint 2006-02-02 15:54:23 UTC
just wanted to point out existence of non-ant based project (eg. maven). So far
it seems to me like the proposed changes are build tool independent. Meaning a
maven-based project type can implement all of those safely. 

A more questionable contract is on the client side. what does plugging into the
UI of a project mean? I suppose at least for the customizer, there need to be
different implementations of the panel UI/persistence. the creation of a project
requires probably also different implementations.
Comment 9 Rich Unger 2006-02-09 01:53:10 UTC
FYI, the nodes portion of this is now described/implemented at
Comment 10 Milos Kleint 2006-04-04 13:04:16 UTC
for project customizer API, I've created this issue:
Comment 11 Milos Kleint 2006-08-17 09:49:14 UTC
Additional API usecase is the ability to add content to lookup.
Comment 12 Milos Kleint 2006-08-24 09:01:13 UTC
i created a separate issue for lookup extensibility:
Comment 13 Milos Kleint 2006-09-19 07:02:20 UTC
the api number 2. about extending Sources content in the project is solved by
the Lookup extendibility issue #83343.
The project type will drop a LookupMerger instance for Sources into the project
lookup and 3rd party plugins add their Sources implementations to lookup. These
will be merged into one instance.
Comment 14 Milos Kleint 2006-11-20 13:03:28 UTC
can we consider this issue to be fixed? The general apis for extending project
types is in place.
Comment 15 Rich Unger 2006-11-21 19:11:56 UTC
The only one I'm not aware of any action on is #1.  The web project currently
hard-codes the creation of the index.jsp file.  In V-Builder, at least, I'm
patching to remove that code and inserting my own code to create a voicexml file
Comment 16 _ potingwu 2006-11-21 20:07:15 UTC
Yes, I agree the web project should not default create the welcome page (i.e.,
index.jsp). Instead, the framework ownder should handle it there. Creator has
the same issue that it needs to remove (actually replace) the welcome page by
patching the codes.

I have filed an RFE on 03/07/2006 already:
WebProjectUtilities.createProject should have API for handling the Welcome page
Comment 17 Petr Pisl 2006-11-22 12:40:05 UTC
There is only one problem, the mentioned code which generates the index jsp.
This code will be removed in NetBeans 6.0 or can be provided in the condition -
only where there is not any welcome page set up by a framework.

I'm not going to introduce a new API for setting the welcome page, because is
already there for a few releases - J2EE DD API. I see one problem, that user can
select more frameworks and every selected framework can change the welcome page
and the last one, which is called during creating the project,  is the winner.
Comment 18 Rich Unger 2006-11-22 18:25:53 UTC
I'd say that, as long as the generation of index.jsp can be disabled without
patching, and I can do my own file creation with the DD api at project-creation
time, then that's fine.
Comment 19 Petr Jiricka 2007-02-02 12:41:53 UTC
The ability to extend the build script is another component of this, adding a
dependency on issue 93509.
Comment 20 Petr Jiricka 2007-05-29 08:32:06 UTC
TM -> M10.

Also, adding issue 99555 as a subissue of this enhancement. 99555 asks for the
ability to NOT create index.jsp when creating a web project, and is now implemented.
Comment 21 Petr Jiricka 2007-06-12 17:12:30 UTC
All the subissues of this have been addressed, so marking this as fixed.