Geertjan's Blog

  • January 24, 2011

org.netbeans.spi.project.SubprojectProvider (Part 2)

Geertjan Wielenga
Product Manager
The purpose of the previous blog entry was to explain how you can add project types as subprojects to your own project types. However, what about the scenario where you want to add project types as subprojects of project types created by others? For example, let's imagine you have a dedicated project type that could be relevant to programmers creating web applications in NetBeans IDE. In this scenario, you did not create the web application project type, so how can you provide subprojects for it?

If you've read yesterday's blog entry, then you'll know the answer to the above problem—since subprojects are provided in the lookup of the containing project type, you need a way to provide your subproject in the lookup of an existing project. And, as the Project Type Extension Module Tutorial explains, this is possible, since it's possible to extend the lookup of existing project types.

Let's imagine we want to enable programmers to develop modular web applications—i.e., OSGi-based web applications (in Ant-based projects). Now you should know how to do that. Create a new project type for Ant-based OSGi-bundles, create a new subproject provider, and add it to the lookup of the web application project type, and then you have exactly what you need.

@LookupProvider.Registration(projectType = "org-netbeans-modules-web-project")
public class OSGiLookupProvider implements LookupProvider {
public Lookup createAdditionalLookup(Lookup lookup) {
Project prj = lookup.lookup(Project.class);
WebModuleProvider wmp = lookup.lookup(WebModuleProvider.class);
if (wmp != null) {
//Pass the project into the subproject provider,
//so that you can refer to it there:
return Lookups.fixed(new OSGiSubprojectProvider(prj));
return Lookups.fixed();

That's all. Now you're able to provide self-contained subprojects to existing project types:

Note that the above are not actually OSGi bundles at the moment, it's just a simple mock up to show what could be possible.

Join the discussion

Comments ( 1 )
  • Jesse Glick Monday, January 24, 2011

    The above code could be eliminated by just putting @ProjectServiceProvider on OSGiSubprojectProvider directly. (Assuming that the check for WebModuleProvider is redundant when the registration is only active on web projects to begin with.)

    Note that registering a SubprojectProvider on a foreign project type like this might \*override\* the native provider (based on e.g. project JAR references in the compile classpath). If the project type has not already done so itself, you may need to also use @LookupMerger.Registration on a LookupMerger<SubprojectProvider> so that your special subprojects can be appended to those normally associated with the project.

    (Currently there is no standard LookupMerger<SubprojectProvider> that I know of, since I have never heard of anyone injecting subprojects from another module before.)

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.