[
http://issues.apache.org/jira/browse/JS2-304?page=comments#action_12315712 ]
Rohnny Moland commented on JS2-304:
-----------------------------------
> The j2:deploy goal should not use ${jetspeed.groupId}, but pom.groupId. Same
> with jetspeed.version.
Sorry. I wanted to use the j2:deploy goal to deploy my own portlet modules, but
I dont think that is the
pupose of it.. Or I can set the jetspeed.groupId = pom.groupId before using it.
> 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]
