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):
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.
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.