+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:[EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > [office] +01 707 773-4646 > [mobile] +01 707 529 9194 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
