Robert Brown III [
http://community.jboss.org/people/factor3] replied to the discussion
"Portlet Development is Effectively Unusable in JBoss Tools"
To view the discussion, visit:
http://community.jboss.org/message/554904#554904
--------------------------------------------------------------
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...
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/554904#554904]
Start a new discussion in JBoss Tools Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]