Community
Participate
Working Groups
I would like to see a programmatic way of participating in adding JSF implementations to a project. The current approach of subclassing JSFLibraryArchiveFilesDelegate is sound but there are a number of scenarios which it will not cover adequately. Ideally adding some sort of (optional) "post-copy" IRunnable operation will let an implementation provider make further necessary modifications to a project's configuration. Examples where such functoinality is needed: -Resources other than just WEB-INF/lib jarfiles may need to be copied into a project (for example, .css files) -Different IRuntime targets on a project may result in different files being copied into the project. For example, one version of a test server may already include some JSF implementation dependencies such as Apache Commons or JSTL hars while a different server may not. (Some servers will already include an entire JSF implementation as well). -Some projects will not use the default Faces Servlet configuration (which is not controllable by the delegate). For example, on a portal server this servlet would not get defined but a Faces Portlet would need to be declared instead. -Some JSF implementation want/require additional context parameters defined in web.xml. I think the existing delegate structure is sufficient for basic cases but an addition to the extension point that allowed a plugin-provider to contribute executable code is needed to handle more exotic cases cleanly. Adding a runable operation which was executed after the defined archives were copied could solve the problems above. Obviously the current IProject would also need to be provided to this executable code since some aspects of a successful "install" depend very much on the project's IRuntime target.
The ability to specify a post-copy IRunnable operation is a sound one, but is too limited. This ability should not be available to just plugin-provided JSF Libraries, it should be available to all, plugin-provided or otherwise. Also, this specific use case requires a post-copy operation, but we can't say with certainty that a pre-copy operation would not also be useful. For these reasons, I would like to seriously consider some form of lifecycle surrounding use of JSF Libraries, into which the user can register for callback on specific events and execute code as required.
Deferred for 1.5. We will review this functionality for the next release and support complete life-cycle events.
re-opening to change resolved-later to open-Future
Deferred due to lack of resources. Contributions from the community would be welcomed.
See Bug 246448 which might result in a broader solution for this requirement.
Item 2 in the original request list would be addressed by 246448.
