This looks great to me, a lot of it is what I was hoping for when I
tried messing with the build :-)
Just in case I find myself with time on my hands before you get back,
do you think it would be more appropriate to update your J2-M2-REDUX
to the current code base or start over?
thanks
david jencks
On Jul 19, 2007, at 6:13 PM, Ate Douma wrote:
Ate Douma wrote:
Dear community,
With finally the release for Jetspeed-2.1.2 behind us, the time
has come
to think of and start some large scale enhancements and changes.
Some of the biggest improvements and features on my wish list, and
for
which I already know others have interest in too, are:
- moving from our maven-1 and maven-2 hybrid build environment to
*one*,
<snip/>
As promised, I'll provide my view on and experiences so far with
creating a new maven-2 only build system for Jetspeed-2.
I already started out experimenting with a clean maven-2 build in a
separate branch, J2-M2-REDUX, end March and a little bit more in
April and May.
Note: because of lack of time then, this branch doesn't yet provide
a a complete working environment in which you can build a full portal.
I'll start the discussion with the list of the features and goals I
had then, and which I still think we need to realize with a new
maven-2 build system.
1) Recognize the fact we have two main groups of users:
- developers working directly off the source tree, this includes
the jetspeed committers
- end-users and integrators building a customized portal
We've had a lot of complaints from people out of the latter
group who don't like maven (1 & 2), and/or have a hard time
customizing/tuning it to their needs.
The general complaint is: maven is too complex, too unreliable,
and there are too many settings to configure, most of them under
documented or require deep
knowledge of the build environment to make proper use of.
I think (a maybe large) part of their problems are caused by our
weird (mis)use of maven (1 & 2), but besides that, for users/shops
mostly familiar with ant
maven is still viewed as an ugly and too far over-engineered beast.
For the first group, the "core" developers, we usually manage
(and are allowed!) to tweak our own environments and mostly get
along even with our current
build system.
Derived from these experiences, David Taylor and I concluded we
should:
a) try to reduce the number of settings needed to be customized
as much as possible
b) try to keep usage of maven-2 profiles as small as possible
c) move the applications *and* portal projects out of the main /
core build project
d) provide sets of easy to extend/adapt assembly projects for
creation of a custom portal, with the "default" and "demo" portals
as well as the installers
being just examples of those
e) provide custom maven-2 plugins to help, automate and simplify
complex configuration/build steps for end-users, integrators and
core portal developers
f) try to provide an ant script library which can be used to
setup ant based build environments, and "hide" maven-2 by using the
maven tasks for ant tools
Important note: it is *not* my goal to replace maven-2 with
ant for the jetspeed-2 project development itself but just to
provide an alternative solution
for the end-users and integrators.
2) Provide a straightforward solution for generating database
schema's and bootstrapping and seeding a database, including for
component (JUnit) tests.
Our current build system is dramatically broken in this regard
and even makes it impossible to build with maven-1 from scratch
without "bootstrapping"
the maven-1 repository first because we're stuck with circular
dependencies and some components just don't compile otherwise.
Right now, if I need to start a new Jetspeed-2 version, I first
build with maven-2, then copy over all the installed jars into the
maven-1 repository.
And only after this "bootstrapping" it is possible to build with
maven-1 again.
And for running testcases on a certain component, you need to do
a full build first too as we dropped our handcoded sql data seed
scripts
(which I find a good thing by the way) and now "seed" the data
from xml with the JetspeedSerializer. But the current
JetspeedSerializer component depends on
almost all other (database related) components thereby
introducing very nasty circular dependencies.
This is a clear design error which needs to be fixed, which I
think I already managed to do in the J2-M2-REDUX branch but I had
to almost completely
rewrite the JetspeedSerializer for it.
3) Restructure our project and sub project source and resource
folders in compliance with the recommended maven-2 foldering.
We're still using what I think is pre-maven-1.0 folder
structures and this makes our project/pom definitions far more
complex than needs be.
4) Provide (at least) proper Eclipse debugging and WTP support for
easy building, deploying and testing the portal, portlet
applications and our JUnit tests
from within Eclipse. Providing other IDE support like maybe for
Netbeans and IntelliJ is also fine by me.
Our current build setup makes it very difficult to run JUnit
tests from within Eclipse as soon as for instance database or other
configurations are needed.
And our current Eclipse (maven-1 based) classpath setting is a
manually maintained single classpath for the whole of the project.
I know Eclipse - maven-2 integration isn't perfect, especially
when using subprojects as Eclipse still cannot handle that
properly, but I definitely think
we need to switch to using the maven-eclipse plugin to generate
our projects.
5) Provide a proper solution to "package" and "deliver" our default/
required portal resources as well as making it easy to extend and/
or override subsets of it.
For setting up a Jetspeed-2 portal, a lot of resources are needed:
- database ddl scripts
- initial database seed data
- specific application server (e.g. Tomcat/Jetty/whatever),
database (driver, url) configurations and possibly even an embedded
LDAP (ADS) server
- the Jetspeed-2 Spring assemblies
- decorators
- standard/demo psml files (possible to be loaded into a database)
Some of these resources are now scattered through the code base.
For maven-1, we package these in our maven plugin itself which more
or less works, but for
maven-2 we don't even have a proper solution yet.
This is a diffcult issue to solve in a satisfactory way, for the
J2-M2-REDUX branch I moved all of these to a new subproject
(jetspeed-portal-resources).
The jetspeed-portal-resources project delivers a .jar artifact
containing all of the above. And, by using a custom maven-2 plugin
you can "install"
pattern based selected resources from this artifact in your own
project target.
I'm still not satisfied by this solution those, even though it
works. For one, this solution probably makes proper WTP much more
difficult.
6) Drop torque schema generation for DDLUtils which I think has
more momentum and much better runtime support.
In the J2-M2-REDUX branch I wrote a maven-2 plugin for this as
well as an ddl and sql scripts executing plugin for creating
databases.
I hope the above makes a little sense, and I'd like to hear what
others opinions are.
I'm sure I haven't touched every aspect we should cover for a new
maven-2 environemnt, and I also don't think I did everything right
in the J2-M2-REDUX branch.
But I would like to ask those interested in all this to please
check it out, try building it and review it a bit.
I'm not an maven-2 expert and had to learn a lot by trial and error
as some maven plugins behave weird in my view, but probably because
of my lack of experience with them. I'm sure there are others much
more experienced with this and I hope they will help and point out
the stupid mistakes I made :)
I'm definitely not sure yet I choose the right way to go so any
type of critics is welcome!
I will be gone on a 3 weeks summer holiday after tomorrow, and most
likely won't touch or even see a keyboard during that time.
So any feedback is welcome, but it'll be a few weeks before I'll be
able to respond again.
Just don't wait for me to respond and discuss :)
Regards,
Ate
---------------------------------------------------------------------
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]
