Jetspeed build is too big and unwieldy, mostly because of historical reasons:
- different technologies and demos have been tried, and the code has been accumulating in the main build - we abuse the SNAPSHOT dependency mechanism, and we have not been able to isolate changes in different artifacts until recently A partial solution came with the movement of a substantial part of the code to the bridges repository. Basically, the bridges repository contains portals code which is independent of jetspeed or pluto, code which serves to enable portlet development with other servlet frameworks or even cgi based code. This simplified the build a lot, but the job is not yet finished. jetspeed builds several demo/showcase webapps together with the core: - php-demo, a demo of the php bridge - perl-demo, a demo of the perl bridge - struts-demo, a demo of the struts bridge - jpetstore, another struts application that works as a portlet - jsf-demo, including small JSF demos - jsf-demo-myfaces, small JSF demos using myfaces - demo, assorted small portlets - rss, two different rss demos - gems (?) In addition, there are internal webapps: - layout-portlets/jetspeed-layout - security - palm - pam To be honest, the maintenance and handling of dependencies for such a big set is driving us crazy. We need to do something. My proposal is as follows: In a first stage, make people taking care of a given bridge take care of the associated demos too. They would serve as black-box tests, as well as enabling quick examples of the bridge use. The only reasonable way to attain this goal is to move the projects at applications/* to portals-bridges/, and change the jetspeed build so that it imports, if any, the .war(s) produced by the bridge. Before (or after) we move the demos to bridges, some refactoring might be justified, for instance grouping together the two jsf demo wars, deleting some irrelevant portlets, grouping, commenting, etc. Also, where the framework is already supporting reasonably a bridge, we could just use their demos, and do some social work so that they release and maintain a demo war that we can simply use for test and demo purpose. Don't forget that, while the demo portlets started mainly to test and explore the frameworks, currently their main goal is to serve to people new to portals to learn by example. In addition, as we release J2-M4, we could release bridges-0.4, and as soon as this is done, stop using SNAPSHOT artifacts as dependencies, and have jetspeed-2 and the different bridges release independently. I.E., the struts bridge and jsf bridge release cycles would be fully independent, starting their releases with the 0.4 release. Bugs and updates to the bridges code would bring new releases of just the involved artifacts, not pulling a big release of J2 or bridges as a whole. For this to be workable in the short term, if would be handy to have a way for the involved bridges demo to deliver PSML pages showing the portlets demoed. While this is not portable as of JSR-168, the PSML format is simple enough to be used as a mean to understand what is intended for demo in a war file. As already commented, we could just use pages in /WEB-INF/pages in the war, and the deployer *could* take care of creating them in the portal, or else the build process could take them from there to construct the demo portal. In following steps, we could try to have a repository where complex webapps could be maintained, starting with the admin portlets themselves (security, pam, palm) Also, to clean, document and make sure that demo portlets are actually showcasing core portlet-api and jetspeed features, and that they serve this purpose with minimal fuss. I'd recommend starting with the easy steps: moving php, perl, struts-demo, jpetstore, jsf-demo, and jsf-demo-myfaces to places under portals-bridges/ In a first go, the psml pages using those portlets would remain in jetspeed/src/webapp/WEB-INF/pages I had the idea to move the wars to bridges/<framework>/src/webapp ..., but it would possibly be better something like bridges/<framework>/<framework>-demo instead. This can be done with a simple server side move, but the project.xml /properties would need some adjustment, both for jetspeed to depend and take the war artifacts in the "full" goals, and for bridges to build them. What do you think? Santiago -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
