I found this commentary to be a bit interesting:
We at TheServerside.com are still a little concerned, as the challenge of building a universal API for plugins that can integrate into any IDE is enormously complex, and we're not convinced that JSR 198 can deliver. In many ways, the plugin API must be strongly coupled to the design of the IDE itself. Thus, betting on JSR 198 as a way to compete with the Eclipse's plugin ecosystem seems iffy.
What is your basis for this analysis? At Compuware, we build plugins for OptimalJ into all the major IDEs (Eclipse, IntelliJ, NetBeans, JBuilder, WSAD), and we find the opposite to be true. In fact, we couldn't feasibly build all those plugins if it were as "enormously complex" as you suggest. The complexity, we find, is when we have to do the same thing in different IDEs, and there are similar but slightly different APIs. This problem would be solved with the JSR that Ted is describing.
To us at Compuware, this JSR is not as much as enabling IDE vendors to compete with Eclipse as it is giving plugin vendors the widest possible audience for their value-added offerings. This should provide the Java community with a rich set of IDEs and plugins that can be mixed and matched to meet the needs of each organization. Openness fosters competition, competition fosters innovation, and that is nearly always good for the consumer.