portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject What are the goals of the jetspeed archetypes/plugins?
Date Thu, 21 Dec 2006 00:03:04 GMT
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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message