6 Replies Latest reply on Jul 29, 2010 4:04 AM by maxandersen

    Portlet Development is Effectively Unusable in JBoss Tools

    factor3

      I am attempting to use JBoss  Tools to develop portlets, and its so- called "support" for portlets  does not work.

       

          I have read the documentation and have downloaded the tools that are  supposed to support portlet development. According to the documentation,  in order to begin portlet development we are supposed to create a  "Dynamic Web Project" and setup the project to work within a JBoss  runtime.

       

          Instead of using the default configuration for the server, we are  supposed to click "Modify" and, in the Facet window we are supposed to  select the checkbox for Portlet support.

       

         Trouble is: there is no "Portlet  support" checkbox!

       

         Without portlet support, any attempt to create portlets  to run within a Portal server creates failures. In fact, some of the  failures have been known to crash Helios.

       

         Note that thie problem of missing  Portlet support facets is not new to the latest Tools. This problem  also exists in versions designed for Eclipse 3.5 installations as well.

       

         Until  this problem is fixed, your tools are completely unusable for portlet  development. Note that for this reason, I will likely be using  OpenPortal tools for my portlet development until someone fixes thios  problem.

       

          Are there any plans to fix this problem?

        • 1. Re: Portlet Development is Effectively Unusable in JBoss Tools
          maxandersen

          Hi Robert,

           

          Hope you had a good weekend

           

          The portlet facet should be enabled if the runtime it is pointing to have a JBoss portlet runtime installed in it.

           

          If you are sure you got a JBoss portlet runtime installed then I would love to hear which one since then we might have a bug in the identification.

           

          In any case you can disabled the facet/runtime check in Preferences (JBoss Tools > JBoss Portlet > Check runtimes for portlet components)

          When that is disabled then portlet facet is possible to install on runtimes with no known Portlet implementation.

           

          I'm actually starting to think we should make that the default since users seem to be more confused by it...

          • 2. Re: Portlet Development is Effectively Unusable in JBoss Tools
            factor3

            Actually, I had an OK weekend, since I was attending the memorial service of a friend/brother who recently passed away. It could have beenbetter -- but it could have been worse. Thanks for asking.


            Anyway, yes I did download and utilize what should be a Portlet runtime: the JBoss (Gatein) Portlet Container runtime. I chose it because I needed to have a more lightweight system for development on the machines that I was using. This is structured like the full JBoss Gatein Portal, the only difference was the .WAR file(s) that are deployed to it.


            I would consider it a bug if the portlet component checker in the JBoss Tools plugin(s) did not recognize the Portlet Container as a legitimate Portlet runtime. It runs like a JBoss Portlet and even displays JBoss Portlet pages, and you can deploy portlets to it using the same methods as you would using the full Portal. Consequently, in my opinion if the Tools do not recognize the container as a real portlet runtime, then this is definitely something that should be rectified.


            Of course, I am not working on this stuff so it isn't my call. I can only suggest...


               As for the alternative: I did deactivate the "check runtimes... " checkbox and the portlet facets appeared. And frankly, I agree: you probably should make this disabled by default. Not just because of the confusion, and the fact that the documentation doesn't say a word about it, but because this check ties users into developing/testing portlets only for JBoss. If someone wants to make a portlet that can work under any Portal (which is what JSR-286 portlets are supposed to be able to do) the "check runtimes... " selection will make it impossible to test the portlet on other environments from within Eclipse. In other words, that selection is providing a form of "vendor lock- in" that you people are supposed to be avoiding.


            Unfortunately, there is another problem that I am encountering that is not in the documentation: the problem of having to select "user libraries" where none are available.


               There is a window in the Wizard called "JBoss Portlet Capabilities" where Eclipse tries to force me to select a "user library" in order to complete the portlet facet. I find this to be extremely annoying for two reasons: (1) I thought I was including the necessary libraries for portlets when I configured the facet in the first place (compare this wizard with the one provided by the Eclipse Portal Pack plugin which works with Webspace). An Eclipse facet is supposed to provide this kind of dependency automatically when selected (Eclipse Portal Pack certainly does!), so why the necessity for pointing to a user library??? (2) when this window comes up it displays an empty list of user libraries. So where am I supposed to find the user libraries that are required???


            I consider this a definite bug and a sign of improper implementation of an Eclipse facet. At least, you need to update the documentation so that a user can find and point to wherever the required JAR files are. A more acceptable solution would be to at least put the names and locations of appropriate user libraries into the Wizard so that a user can select one of them. Of course, the best solution would be to eliminate the "Portlet Capabilities" window entirely and create a proper facet that includes the correct libraries in the classpath when it is selected.


            In summary: I thank you for your help and information, but despite it JBoss Tools is still unusable for portlet development, as far as I can tell. Unless, of course, there is more information about the portlet setup that I am unaware of...


            Please advise.


            • 3. Re: Portlet Development is Effectively Unusable in JBoss Tools
              maxandersen

              Hi Robert,

               

              You really are having a bad week; lets see if I can make your week better

               

              1) Wizard not recognizing your portlet runtime. As said above, if you say you got a portlet runtime installed that we don't recognize then *please* open a jira with the details of what version and name of the Portlet container you used and what version of jboss tools so we can investigate. Our jira is at http://jira.jboss.org/browse/JBIDE Without that information my team can't really help since our test shows multiple version of JBoss Portal, GateIn and EPP as being recognized - of course our tests can't cover all combinations that you as an user might do but we can fix this but to know where to start looking please open jira with portal name and version.

               

              2) User libraries - I haven't seen the portal *force* me to select a user library; it should only be warning you that if you continue there are probably going to be compile errors since there is no located runtime (see #1). Note, if Portal is *forcing* you to select a runtime and not allowing you to continue then that is a bug and please report that in jira.

               

              3) Eclipse Facet are supposed to provide this kind of dependency automatically - that is partly true, but how do you expect the portlet facet to provide the runtime dependencies when it is not finding it ? (see #1). If we were to shove down on you a specific jboss portlet version distributed together with jboss tools then we would really be giving you vendor lockin and really bad dependency management (see this for background).

               

              4) I opened https://jira.jboss.org/browse/JBIDE-6719 and Snjezana came back answering:

               

              There are the following JBoss Portlet Runtimes:

              - JBoss Portal 2.x bundled with JBOss AS 4.x 
              - GateIn Portal 3.x bundled with JBoss AS 5.1
              - JBoss Portlet Container 2.0 bundled with JBoss AS 4.2 and Tomcat
              - GateIn Portlet Container 2.1 bundled with JBoss AS 4.2, JBoss AS 5.1 and Tomcat
              - EPP

              The Portlet engine recognizes all these containers except GateIn Portlet  Container bundled with JBoss AS 5.1. This server has a different name  for simple-portal directory (simple-portal.sar instead of  simple-portal).

               

              Can you confirm you are using GateIn Portal 3.x bundled with AS 5.1 ?

              • 4. Re: Portlet Development is Effectively Unusable in JBoss Tools
                snjeza

                Robert,

                 

                I am fairly sure you are using GateIn Portlet Container 2.1 with JBoss AS 5.1. Can you confirm that?

                The issue with this container is fixed within https://jira.jboss.org/browse/JBIDE-6719

                • 5. Re: Portlet Development is Effectively Unusable in JBoss Tools
                  factor3

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


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


                  • 6. Re: Portlet Development is Effectively Unusable in JBoss Tools
                    maxandersen

                    1) Great - so your specific issue should be fixed in trunk/nightly build and consequently the next release.

                     

                    2) Could you make a screenshot since I don't understand what you mean here - if you decided to not use an existing and known to use portlet library we are as far as my testing goes not forcing anything nor making life more difficult since you are basically choosing to not let the IDE configure it ?

                     

                    3) The seam and jsf jars are only if you enable the seam and jsf integration. There is no standard portlet spec API jar we can include that won't be different from what you are actually going to run against. And no, "necessary development jars" cannot easily be included in the plugin. The number of combinatorial combinations and megabytes of jars we would have to include would be massive. And i'm sure you or other users would then complain about the "gigantic IDE" or the fact we wouldn't be providing the right jars ....since we wouldn't because the jars we would bundle would be outofdate wihtin weeks/months. Sure, you would be able to compile - but all your test runs etc. would not be correct.

                     

                    This is an ever fighting battle we got and there just isn't a really good answer.

                    Our approach/assumption is that A) you are going to need a runtime anyway to test/run against the frameworks B) you want to have your development match your deployment as much as possible. A+B = lets use the jars from the actual runtime you already need to deploy.

                     

                    "Either set the classpath automatically within the facet (if you absolutely must have the portal environment detection)"

                     

                    isn't this what we do when the runtime gets detected !?

                     

                    "or include the jars with the  plugin and set a "development classpath" to those jars."

                     

                    Unittests etc. would be running against the wrong jars then.

                     

                    "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."

                     

                    So in the case we don't detect the runtime correctly or does not have the proper jars matching what you need you want us to say "sorry, user you cannot install portal facet" ?

                     

                    Note, I hate user libraries as much as you do - but it is unfortunately the only approach available inside Eclipse to let users control these things.

                    We also got Maven support cooking to hook into this allowing you to use proper dependency management.

                     

                    And for note, I like suggestions - and I can be convinced to change things based on them...but for this case right now, I'm more into making sure your projects are actually compiling and running against the *right* jars so it will work even a week from now and independent to updates to your tools.