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.
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" stringvalue="com.nuance.tools.speechproject.api.NewProjectServiceHook$Patch"/> </file> </folder> <folder name="sources"> <file name="SpeechSources.instance"> <attr name="instanceClass" stringvalue="com.nuance.tools.speechproject.SpeechSources"/> </file> </folder> <folder name="ui"> <!-- These nodes get placed as children of the logical root node --> <folder name="nodes"> <file name="SpeechDialogs.instance"> <attr name="instanceClass" stringvalue="com.nuance.tools.speechproject.ui.DialogRootNodeFactory"/> </file> <file name="DTT.instance"> <attr name="instanceClass" stringvalue="com.nuance.tools.speechproject.ui.DTTNodeFactory"/> </file> </folder> <!-- These panels get placed in the project properties UI --> <folder name="customizers"> <file name="foo.instance"> <attr name="instanceClass" stringvalue="com.nuance.tools.speechproject.ui.FooPanelFactory"/> </file> </folder> </folder> </folder> 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: sourcesHelper.addPrincipalSourceRoot(sgd.getRootFolder.getPath(), 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.
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.
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 ant/project?
I guess Pavel meant "project/projectuiapi or ant/project or java/project etc. acc. to whether the API is Ant- or Java-specific".
I think as well, that the "customizing" ui should not be part of web project api and should be solved on more general level.
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.
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 netbeans.org.
Agreed.
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.
FYI, the nodes portion of this is now described/implemented at http://www.netbeans.org/issues/show_bug.cgi?id=72441
for project customizer API, I've created this issue: http://www.netbeans.org/issues/show_bug.cgi?id=74373
Additional API usecase is the ability to add content to lookup.
i created a separate issue for lookup extensibility: http://www.netbeans.org/issues/show_bug.cgi?id=83343
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.
can we consider this issue to be fixed? The general apis for extending project types is in place.
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 instead.
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: http://www.netbeans.org/issues/show_bug.cgi?id=73352 WebProjectUtilities.createProject should have API for handling the Welcome page
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.
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.
The ability to extend the build script is another component of this, adding a dependency on issue 93509.
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.
All the subissues of this have been addressed, so marking this as fixed.