Community
Participate
Working Groups
In WTP 3.1 we will deprecate the JSF Libraries framework in favor of adopting the new Library Provider Framework. The new framework will provide adopters with a separate lifecycle for configuring libraries for use with JSF, while giving end-users better library support than could be provided using JSF Libraries (references to Source, Javadoc, etc.) among others benefits. This will mean the following major changes: 1) All JSF Library UI will be removed. 2) The JSF Libraries framework, including all API related to both user and plugin-defined JSF libraries, will deprecated and will no longer be supported. 3) Users who currently rely on JSF libraries will NOT be broken and will be provided a non-undoable forward-only migration step to the new way of doing JSF libraries. End-User Impact: 1) New JSF projects will still be created using the Dynamic Web Project wizard with the JSF facet selected. The JSF facet install page UI will add a new section that allows the user to select from available library providers and will automatically add the JSF runtime implementation to the project on Finish. Instead of creating JSF libraries for additional component and other support libraries, the page will also have new UI that allows selection of available JDT User Libraries. The user will have the option of whether to add the jars only to the design time classpath and also the deployment (JavaEE Module Dependency deploy flag) class path. 2) Adding new libraries to an existing JSF project should now be done by creating a new User Library, adding it to the classpath and optionally enabling the entry from the JavaEE Module Dependencies properties page for deployment. 3) If the user has installed specific faceted support for JSF component libraries, then an additional install page can be made available by a third-party plugin to configure it as a separate, JSF-dependent facet. 4) Existing JSF projects will be supported but considered "legacy". A forward-only migration feature will also be available to migrate old projects to the new mechanism. Adopter Impact: 1) Existing plugin-provided JSF libraries are deprecated but will still work in WTP 3.1. Adopters should migrate to the new framework as soon as possible. 2) Creating support for the third-party component libraries (i.e. Tomahawk, Trinidad, IceFaces) should now be done by creating a separate facet and library provider for each component library.
This all looks quite good. While we're talking about these changes to the facet installation page, can I bring up the rest of the UI area below the Library Provider section. Currently the rest of the fields are: JSF Configuration File JSF Servlet Name JSF Servlet Classname URL Mapping Patterns With the new library provider mechanism, at least some of the default values in these fields can be potentially confusing or even wrong. For example, one of the scenarios I'm going to implement a library provider for is a Portal server target. In that case, there is actually no Faces Servlet. My implementation code will remove a defined Faces Servlet (if necessary) before setting up a Faces Portlet, so I'm not really concerned about changing the behavior of the facet installer logic. But given the added power that library providers will have, could we consider removing these fields from the UI (at the very least the 2 middle values regarding the servlet registration)? It's completely fine that the facet install uses these default values to set up the project, but for the exceptional cases where a particular library provider will need to do something else it makes for a misleading UI. I suspect users hardly ever change these defaults in the facet config page anyway, so for the very few cases where the defaults won't satisfy, changing them in the already-created project doesn't seem like an unnecessary burden.
Thanks for the input Scott. Although they are highly correlated, your comments refer more to the facet than to our adoption of the Libary Provider framework. Could I ask that you create a new enhancement request and outline your use case? How do you currently deal with portals/portlets, and how would you ideally prefer it to be handled?
I've opened Bug 255097 for my comments in #1.
I'm a WTP user and have one question. I use both a tomcat 6 and JBossAS (or full JavaEE5 featured server) for the JSF application development and testing. Tomcat 6 doesn't include JSF libarary and JBossAS does. So currently if I want to deploy to Tomcat 6, then J2EE module dependency needs to be checked, but to deploy to JBossAS, J2EE modulde dependency needs to be unchecked. So, my question is: Is it possible to the J2EE module dependency automatically be changed according to target runtime? If not, the feature, which automatically resolving the library dependencies according to target runtime, need to be added to the features of Library Framework. Thanks.
> I use both a tomcat 6 and JBossAS (or full JavaEE5 featured server) for > the JSF application development and testing. Tomcat 6 doesn't include JSF > libarary and JBossAS does. So currently if I want to deploy to Tomcat 6, > then J2EE module dependency needs to be checked, but to deploy to JBossAS, > J2EE modulde dependency needs to be unchecked. > So, my question is: > Is it possible to the J2EE module dependency automatically be changed > according to target runtime? See Bug 254536 that tracks improving the JBoss adapter that ships with WTP to correctly specify that it is able to provide the required libraries for JSF and JPA facets. Note that the server adapter that is part of JBoss IDE (separate install - google it) does this correctly already.
This work is effectively complete. One outstanding issue is being tracked by 255097.
