Despite all the discussions that have been held about the many web frameworks that have enriched the world, about their contrasts and similarities, there are two things that are undeniably true but that I have never heard mentioned—probably because most people don't look at web frameworks from the perspective of tooling in general, or IDEs in particular. The first general observation from a tooling point of view is—all frameworks are pretty similar, despite their differences. From a tooling perspective, each web framework comes with a set of JARs that need to be put on an application's classpath, each web framework has certain expectations regarding the source structure of an application, each web framework needs one or more file templates, and most, but probably not all, have some kind of configuration file, be it XML, Java, or otherwise. So, from a tooling perspective, there's not much difference.

The second general observation is that those who know most about a web framework are typically not the same as those who know most about how to provide tooling. For example, you may have created a fantastic web framework, but chances are that you don't know all the Eclipse APIs, or NetBeans APIs, or whatever tool's APIs, necessary for creating the tooling support in question, assuming you want your tools to be integrated into one of the existing IDEs.

Both these general observations point to a rather obvious conclusion—since tooling for web frameworks is fairly regular and since those who know most about the framework don't necessarily know (nor should they be expected to know) much about how to integrate the framework into an IDE, it would be cool if an IDE would provide a wizard that the web framework provider would be able to click through, to create a plugin that wraps their JARs, creates some ui for the end user to select the JARs, and so on. At the end of the wizard, the web framework provider would then have a plugin, which could potentially be extended. But, at least the basis of the web framework plugin would be complete.

Today I created exactly this wizard. Here's how it works, in this case for Geert Bevin's RIFE. So, now I'm pretending I'm Geert Bevin, ignorant of all the wonders of the NetBeans APIs, but very eager to bring my web framework closer to the end user (i.e., by creating a NetBeans IDE plugin for them):

1. I started out by going to the RIFE site and downloading their JAR.
2. Next, I create a plugin source structure, by going to File | New Project, choosing NetBeans Modules | Module, and then clicking Next. I type "RIFESupport" as the Project Name. I click Next and then I click Finish.
3. I now have my plugin's source structure. Now I right-click the project node and choose New | Other. I choose NetBeans Module Development | Web Framework Support (which is the name of the new wizard) and I click Next. I click Manage Libraries and then I use the Library Manager to create a library called RIFE. I click Add JAR/Folder and then the RIFE JAR is available. I click OK to exit the Library Manager.
4. Now I select the RIFE library from the drop-down list and... I check the magical "Use in New Web Framework" checkbox, as shown below:

   

5. I click Next. I leave all the defaults unchanged, so that RIFE will be used as the prefix for the classes and files that will be generated. I click Finish. And now what do I have? All of this:

   

   The plugin is good to go. Module dependencies have been set, the framework has been registered in the layer, the bundle has been populated with new entries, and the Java classes are all compilable. No post processing in any shape or form is needed.

6. Now I can right-click the project node and choose "Create NBM". The NBM is a binary file that I can then distribute to my users. I can say to them: "Use the Plugin Manager to install this NBM file. Then create a new web application and you will see a new entry in the final panel of the Web Application wizard." This is what it looks like, by the way:

   

   And when the user clicks Finish above, the JAR is visible in the Libraries node, indicating it is on the application's classpath and the user can start using the framework right away:

   

It is not hard to imagine extensions to the above wizard, such that the wizard would generate some templates and provide other artifacts that the framework might require. The Web Framework Support wizard would let Geert Bevin select the artifacts on his disk, i.e., pick and choose the files that he wants to make available to the users of his plugin.

Then, the basis being laid, the plugin would be ready for distribution. More likely is the scenario where the plugin provider would want to tweak some parts of the plugin or provide some customizations that are relevant for the particular framework. And most frameworks have some very particular demands on an IDE's editor, such as hyperlinking from one artifact to another. (Though even there wizards could be used to generate the basic source code.)

At the end of the day, clearly, without typing a single line of code, Geert Bevin (and all the other Geert Bevins out there) would be able to use this wizard to provide their users with a plugin for their web framework. I am cleaning up some of the underlying code, but want to make the plugin that provides the wizard available soon.