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]
