[ http://issues.apache.org/jira/browse/JS2-304?page=comments#action_12315720 ]
Scott T Weaver commented on JS2-304: ------------------------------------ I would like to add the follwoing additonal clean-ups that I am working on: Replace the usage of usage of external entities (locator.ent, loctaor.path, etc.) in project files with a more elegant project descriptor inheritance hierarchy. I was recently reviewing the Maven site and they recommend you do not use them as they are diabling external entities in upcoming version of maven. Here is what the hierarchy currently looks like: project-info.xml: committers, standard project info, standard build info(src/unit test directories), standard reports, no dependencies. This is the base for all other descriptors. core-build.xml: Extends project-info.xml. All component dependencies have been moved here. However, all portlet apps retain individual dependency trees to avoid war file bloat of unneeded jars specified in core-build. All component project descriptors (except portal) extend this descriptor. full-portal.xml: Extends core-build.xml. Includes all of the Jetspeed 2 as dependencies, this is extended by /components/portal's project descriptor. Also, full-portal.xml can be extended by portal developers to create their on portal projects that are built upon Jetspeed 2. I have also refactored version entities into project properties as follows: jetspeed.version=2.0-M4-SNAPSHOT pluto.version=1.0-svn-201864 portals.bridges.common.version=0.4-SNAPSHOT portals.bridges.frameworks.version=0.4-SNAPSHOT portals.bridges.jsf.version=0.4-SNAPSHOT portals.bridges.perl.version=0.4-SNAPSHOT portals.bridges.php.version=0.4-SNAPSHOT portals.bridges.struts.version=0.4-SNAPSHOT portals.bridges.velocity.version=0.4-SNAPSHOT These are located in the project.properies file making it very easy for portal application developers to override version attributes in their own projects via there local build.properties in their home directory. > Build Process Clean Up > ---------------------- > > Key: JS2-304 > URL: http://issues.apache.org/jira/browse/JS2-304 > Project: Jetspeed 2 > Type: Improvement > Components: Project Build > Versions: 2.0-M4 > Reporter: David Le Strat > Assignee: David Le Strat > Fix For: 2.0-M4 > > 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: > \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). > 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 > ## Rename the web application to portal-webapp and the artifact id to > jetspeed-portal (to remove conflict > with the jetspeed component artifact). > ## Move the test directory under portal-webapp to components/portal/test as > it support the portal > components tests. > ## 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. > # 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. > 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). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
