Mailing-List: contact jetspeed-dev-help@portals.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42C9C6DD.3090608@bluesunrise.com>
Date: Mon, 04 Jul 2005 16:31:41 -0700
From: David Sean Taylor <david@bluesunrise.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@portals.apache.org>
Subject: Re: [J2] Build Process Summer Time Clean Up
References: <20050703044528.65832.qmail@web54709.mail.yahoo.com>
In-Reply-To: <20050703044528.65832.qmail@web54709.mail.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Le Strat wrote:
> All,
> 
> I finally got some time to get back to J2. I have a
> proposal for some summer time J2 build process clean
> up.
> 
> Jetspeed2 current build process is a bit confusing. 
> Through the various evolutions of J2 build process,
> many targets have been accumulated that make it
> difficult to easily understand the build process flow.
> 
> h2. Cleaning up the build process
> 
> Using J2 in its current form requires an in-depth
> understanding of how J2 build internals operate.
> 
> As an example, an integrator wanting to get starting
> with J2 will want to start with the portal web
> application and customize it from there.  It should be
> made easy for integrators to get started with the web
> application without requiring an in-depth
> understanding of the various sequences in the build
> process.
> 
> A typical implementation will want to create a project
> as described below:
> 
> {noformat}
> \sample-portal
> +---\etc                 Contains the build
> dependencies definition.
> +---\portal-webapp       Contains the portal web
> application being built.
> +---\src                 Contains the portal
> initialization source (db scripts, etc).
> {noformat}
> 
> Building the portal in this structure should be
> possible by leveraging the deployed Jetspeed
> dependencies:
> 
> * Components: All libraries (jars) required for the
> runtime operation of the portal engine.
> * Portlets: All web libraries (wars) required for the
> runtime operation of the portal engine.
> 
> Integrator using Jetspeed2 should be able to do so
> easily and to easily get (through dependencies) the
> latest versions of the release Jetspeed components
> (libraries as well as portlets).
> 
> The current maven-plugin and portal build
> implementation rely on the source build (target
> directories) rather than the dependencies for the
> assembly of the portal engine, making it more
> difficult to get quickly started and to keep up with
> enhanced components.
> 
> h2. Proposed changes
> 
> The proposed changes below clean up the build process
> and slightly reorganize some elements to more easily
> achieve the goals outlined above.
> 
> The first changes restructure the portal directory as
> follow.
> # Remove all non web related dependencies from portal:
> ## Move the portal java source and java tests to
> components/portal.  This becomes a component that will
> be released as jetspeed-(version).jar

+1 in general, but don't all components follow a naming pattern of
jetspeed-{COMPONENT_NAME}-{VERSION}.jar?


> ## Rename the web application to portal-webapp and the
> artifact id to jetspeed-portal (to remove conflict
> with the jetspeed component artifact).

Maybe this artifact should be jetspeed-{VERSION}.war

> ## Move the test directory under portal-webapp to
> components/portal/test as it support the portal
> components tests.

+1

> ## Add org.apache.jetspeed.PortalTestConstants to
> centralize initialization of JETSPEED_PROPERTIES_PATH
> and PORTAL_WEBAPP_PATH.
> 
> Clean up the portal-webapp (previously portal) build
> and maven-plugin.

I think that all build goals should be a part of the plugin.
Why have both plugin goals and maven.xml goals?

I'd also like to propose moving to Maven-2 as a part of this refactoring.
I think we should consider project archetypes for quickstarts and 
replacing the current build with a M2 build.

Overview (from my notes at JavaOne):
* Super-POM: defaults across all projects
* transitive dependencies
* dependency scoping
* dependency management
* better control over snapshots
    - only check one snapshot per build
    - or check snapshot once per time period (day, hour..)
* post/pre goals removed
* build is now based on a lifecycle
* maven.xml, project.properties deprecated
* parent projects can be declared, no more ../..
* plugins configurable, POM based, auto-downloaded
* Plugin languages supported: Java Beanshell, Marmalade
* Explicit definiition of multiprojects
    <modules>
	<module>subproject-1</module>
	<module>subproject-2</module>
         ....
* Project archetypes for quickstarts

> # Clean portal/maven.xml:
> ## Remove commented calls to targets.
> # The deploy and undeploy calls in the portal-webapp
> (previously portal) build process should be using the
> maven-plugin to do so.  Multiple deploy, undeploy,
> register, unregister behaviors create confusion. 
> Therefore, I propose to perform the following cleanup
> in the portal-webapp (previously portal):
> ## Remove pam.template.deploy.  This is not used.
> ## Remove pam.unregister.  Depends on
> pam.template.register which is not being used.
> ## Remove pam.template.register. This is not used.
> ## Remove pam.template.undeploy. There is a
> jetspeed2:undeploy target in the jetspeed plugin.
> ## Rename pam.register to pam.layoutdeploy.  This
> really deploys the layout portlet and should be
> consistent with the other deploy targets.
> ## Rename pam.deploy to pam.demodeploy.  This deploys
> the demo application.
> ## Rename pam.undeploy to pam.demoundeploy.  This
> undeploys the demo applications.
> ## Rename pam.rss to pam.rssdeploy for consistency
> purpose.
> ## Modify the pam.(portlet)undeploy targets to use the
> jetspeed maven plugin jetspeed2:undeploy target.
> ## Remove deployJar and deployClasses.  portal-webapp
> now uses dependencies for the portal component
> library.
> ## Remove jar:jar target.
> ## Clean plugin.jelly: jetspeed2:register and
> jetspeed2:unregister.  Not used.
> 

+1, remove all Jelly, move to M2

> Have portal-webapp depend on the built Portlet
> dependencies rather that the build target directories.
> # Modify the maven.xml pam.(portlet)deploy target and
> the maven-plugin to use the archived portlet war
> deployed to the repository (maven install).
> 

I like this idea of the portal-webapp, since its great for starting new 
projects where the goal is to customize the portal with your own skins, 
and your own build.

> Let me know if you are alright with the proposed
> changes and I will go ahead and create an issue as
> well as implement the changes. I am almost doen.  I
> just need to perform some final testing locally and
> get everyone's blessing.
> 
You have my +1, although I propose going a step further and moving to M2

-- 
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194

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