David Sean Taylor wrote:
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
I'm +1 on this too (for starters) but like to add some additional ideas.
I looked into M2 for the first time this evening (but not tried it yet)
and I do like it so far.
But, I'm not sure its ready for use yet for J2. At least, the website docs
didn't give me that impression. Maybe in a month or two?
Anyway, I agree with David Sean Taylor that I'd like to see all portal
build/deploy/install etc.
goal functionality moved to the plugin *only*.
The way it now duplicates things I don't very much like.
But, I also don't like the way a specific plugin version is so much dependent
on a
specific Jetspeed configuration. I currently packs all configuration scripts,
dependency
definitions, sql scripts etc. inside the plugin.
In my own integration builds for clients I don't use the plugin but base my
portal setup
directly on an repo installed version of the jetspeed war.
For a specific portal, I extract the jetspeed.war in the project build folder,
run some ant filters
and/or replace assembly files and remove/overlay some others files (like new
decorators and
additional portlet applications etc.
I think we could provide a solution which has the benefits of both solutions
and without
the problems I see with the plugin.
The main idea of David Le Strat that we should provide an integration build
based on installed
components from the repository I'd like to extend to providing the integration
build *configuration*
too as installed (template) component (thus *not* embedded in the plugin).
What if we would build a jetspeed-portal-template-<VERSION>.jar (not .war)
which contained
the proposed portal-webapp as well as its dependency (pom) definitions, sql (or
schema) scripts,
app server templates (like the different tomcat context files,
JBoss/Webspere/BEA configs etc),
and a default build.properties.
Then the plugin could use that template to build a concrete portal,
support (merge) overlay definitions (if any) and *not* be dependent on the
concrete jetspeed component
resources itself but derive those from the template and/or from a custom user
build.properties.
For our current portal project we then could be a completely empty project
except for a project.xml and
a maven.xml executing nothing but the default plugin goals. A nice starter
project for integrators!
We can even add an integrators project template goal to the plugin setting up
such a project.
Stuff like portal name, context path and app server version can then be setup
already for you.
The plugin itself wouldn't need to be build and installed each and every time
again. Only when new
features to the plugin are added. It really can have its own release cycle and
version then, independent
from Jetspeed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
