What are the goals of the jetspeed archetypes/plugins?

[David Jencks <da...@yahoo.com>]

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

Re: What are the goals of the jetspeed archetypes/plugins?

[David Sean Taylor <da...@bluesunrise.com>]

David Jencks wrote:
> 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.
> 
Some documentation here:

http://wiki.apache.org/portals/Jetspeed2/Maven2BuildSupport

There are several archetypes

portal-archetype - create a custom Jetspeed Portal project
application-archetype - create a portlet application project
component-archetype = create a spring component project
portal-component-archetype - create a jetspeed component project

So yes, these are project templates for the Jetspeed artifacts
Whereas the installer is great for demos, anyone who is going to 
maintain a portal will get started with customizing their portal's build 
with the custom portal-archetype. Similar for portlet applications
I've been speaking to a lot of developers lately
The majority would prefer to have better Eclipse integration for this 
kind of maintenance. Of course you can generate the project with 
eclipse:eclipse from the command line, but since the Maven-2 plugin for 
Eclipse is broken and of no use at this point until some bugs get fixed, 
  developers still go to a shell to build Jetspeed.

I have a tutorial here
Im scheduled to work on getting it checked in Friday
The tutorial covers a lot of your issues below
Why don't you try it out and let me know what you think

> 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?

Entirely up to the policy of the portal administrator.
We can deploy portlets 'live'. In fact we are working on a Remote 
Portlet Application Deployer portlet for that scenario

The custom build would normally deploy the core portlet applications 
that are a part of your project. If you follow the directory structure 
we have setup for a custom portal, your portlet apps go under the 
applications directory.

> 
> 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.
> 

Yes, its really a framework for customization of

a) spring components and seed data - overriding security 
implementations, or pipeliness for example, as well as defining custom 
security constraints and permissions, seed data, initial roles, all 
stuff that is different on a per custom portal basis

b) customization of the portal experience - layouts, decorators, skins, 
and the overall site (portal folders and pages)

So there are really two kinds of customization that the custom portal 
supports. This is covered in the tutorial as well

> 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.


A custom build has an application-servers directly meant for this 
purpose. Right now, yes, only Tomcat supported. Contributions welcome 
for other app servers.

Custom builds can also create EAR files that deploy to Websphere for 
example (not Geronimo, the other one). I've never tested the EARS in 
Geronimo. See the enterprise subproject in a custom build. We've been 
deploying and running on Websphere 6.1 for a while now. Some nice 
features there for shared class libraries. We don't have that part 
automated, but we do have some decent documentation for doing deploying 
to Websphere, setting up data sources, etc. Be nice if this all could 
get automated, but frankly I don't know enough about Websphere 
deployment scripting and anyway I don't think the tools required would 
be Apache-license friendly.

> 
> 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?


Also consider that we have profiles
There is the 'min' profile, which builds a portal + j2-admin, with a 
minimal set of pages. This is really just a starting point for custom 
apps and I use it as the starting point for all my apps
The 'full' profile builds an entire 'demo' portal
I would really like to get away from that 'default' demo portal, as its 
confusing to many users. Many of the portlets there are programming 
examples. I would prefer that Jetspeed had a way to configure different 
portals based on what you want to see, including defining your skins as 
well as which portlet applications are included and which portlets go on 
the welcome page

IMO, the archetypes may not be the best solution
Im still not sure how to keep all the resources in sync, and its not 
clear to me how to migrate to new versions of Jetspeed with the Maven-2 
archetypes. With the Maven-1 plugin, I have projects that can easily be 
updated to the latest implementation and configuration without 
disruption to the production systems.

I think the current Maven-2 'custom' build based on archetypes, works 
well, and Randy did a great job of repeating almost *all* the 
functionality from the Maven-1 plugin, as that was our initial goal

Wouldn't a Jetspeed Maven2 plugin would be better? Archetypes have 
issues and are some what limited. No one has stepped up to write a 
Jetspeed Maven2 plugin yet


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org