portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject RE: [J2] Build Process Summer Time Clean Up
Date Tue, 05 Jul 2005 13:39:01 GMT
+1 all the way.  Both the build and the plug-in (my fault) are way out of
hand.  I also took a look at M2 the other week and I really do like the idea
of developing plugins in Java or BeanShell as opposed to coding in XML,
which IMOHO, was a bad idea to begin with.

p.s.

David, how is the Jetspeed Eclipse plugin coming along?  I recently spent a
week writing a plugin to do web page conversions from .asp/.shtml to
Velocity, so it is fresh in my mind if you need any help.

Regards,
Scott T Weaver

> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Monday, July 04, 2005 7:32 PM
> To: Jetspeed Developers List
> Subject: Re: [J2] Build Process Summer Time Clean Up
> 
> 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



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