I may have a few more minutes to work on jetspeed so I started looking into the archetypes and plugins and realized I don't have a very clear idea of what they are supposed to do and how. So, I'll write down what I think and hope for corrections from anyone who actually knows something about this :-) Keep in mind that I don't know much about how portals are developed in the real world.
Here are some possible goals or purposes: 1. Set up a development environment for maven2 for developing a portal and related portlet applications. It looks to me as if this is the main function of the m2 archetypes. This sort of implies that a portal is going to be deployed with a fixed set of portlet applications and when the portlet apps change the entire portal will be rebuilt and redeployed. Is this accurate or in actual use do the portlet applications come and go while the portal remains running? 2. Provide maven2 tools for assembling a portal application by combining standard jetspeed2 parts and portal-specific parts. It looks to me as if this is the main function of the m1 jetspeed2 plugin. Simplifying this would be a side effect of adopting and completing my previous proposal about separating the pieces that get combined here. 3. Build artifacts ready to deploy on a specific app server. IMO it is better to distinguish between app servers than to try to force them all to look exactly like tomcat. For instance, some classes need to be shared among the portal and all the portlet apps. How to do this depends on the app server involved. The set of jars to be shared is the same, but the mechanism for installing so that they get shared is different. Similarly, some app servers can deal with ears and others cannot. 4. Build the jetspeed2 demo portal. Having constructed all this helpful machinery (at least in our minds) we should consider using it to construct the demo portal. To me this seems fairly straightforward for (2) and (3) but not for (1). Perhaps a functional test for (1) could be constructed by something like: a. use the archetype to construct an environment, check it into svn, and actually develop the demo portal in it (so it's in svn) b. in the build, run the archtype plugin to construct the test environment c. copy over selected bits from (a) into (b) d. build the modified environment from (c) and check that it works. In order to make (c) plausible we'd have to keep the environment (a) up to date with what the archetype plugin is creating. Comments? Additions? Subtractions? many thanks david jencks --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
