Re: [jboss-user] [JBoss Tools Development] - Portlet Development is Effectively Unusable in JBoss Tools

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