Greetings, all:
1. Yes, as it turns out, the Gatein Portlet Container V3 with JBoss 5.1 is exactly what I have been using.
It figures! Of all the configurations available I would end up choosing the one configuration that JBoss Tools would not recognize. I sure would make a great test engineer... :D
2. As for the user libraries: OK, perhaps the word "force" was a little too strong. How does "make life difficult if you don't" sound?
3. I do see your point, if the tools cannot detect the container then how will it be able to "find" the appropriate Jars? The problem with this is: why should the facet be "finding" anything?
You make some good points about not wanting to "shove" a particular JBoss portlet version down people's throats. But consider what "user jars"you are having people select in an environment that the Tools detects: 1. the basic JSR-286 Portlet Jar, 2. JBoss Seam Jars, and 3. JSF Jars. I submit that you are already locking people in, because the only environments that you detect are JBoss environments.
Furthermore, the jars offered are (with the exception of Seam and Seam- specific JSF tags) pretty standard for all portlets. Providing the basic portlet-api jar with the facet wouldn't be locking anybody into anything, and the Seam jars are for JBoss environments and won't change regardless of the JBoss bundle used. So again: why should the facet be "finding" anything?
The necessary jars can easily be included (within the development environment) as part of the plugin. When the facet is chosen, the jars could then be added to the classpath. You can even include different versions of some standard jars (for example: a Portlet 1 API jar in case people want to make JSR-168 portlets). That is how the Eclopse Portal Tools plugin does its thing. It uses its own copies of the jars so that the code can compile without problems. When running the test portlet container it deploys the WAR without the Jars (which shouldn't be needed at runtime because the container should already load them). That way, I don't necessarily have to depend on the facet to "find" anything. If the necessary Jar(s) are not in the container's library, then I have no business using the container in the first place.
My only question here is: why don't you folks do something similar? It is ridiculous to have a facet which you can turn on and off, then have that facet depend on what amounts to external jars that are always going to be the same anyway. Either set the classpath automatically within the facet (if you absolutely must have the portal environment detection) or include the jars with the plugin and set a "development classpath" to those jars. Either way you can eliminate the need for a "user library" selection which, in the end, is clumsy from a UI standpoint and redundant in a complete and properly implemented facet.
This is, of course, just a suggestion, guys...