IMO, David's assessment is right on the money. Personally, I have had my frustrations with maven in the past. However, this was only because it was new to me, not because there is anything wrong with maven.
Right now, I am basically using the techniques David describes. I have two main projects: my main JSR-168 compliant portlet application and then a second one that contains my custom jetspeed components. I use the maven plugin to build jetspeed from binaries (and also to update it to newer builds) and it works great. I then use ant to install my customizations into my jetspeed build. Finally, I use ant to build my own JSR-168 project and deploy it. I do everything in eclipse except the maven commands. These I run from the command line because I haven't quite got it to work via eclipse yet. This approach has worked wonderfully so far and it allows me to easily upgrade my jetspeed build and re-integrate my changes. The only reason I haven't switched to maven for everything is that I have been too busy/lazy to learn it so far. For my JSR-168 portlet application, it isn't such a big deal since it is pretty much independent from jetspeed. However, I should perhaps be using maven to build my customizations to ensure I am compiling against the same versions of some of the commons jars. On 2/21/06, David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > From my experience, Frank's use case seems about right. > I want to point out that Jetspeed is a component architecture, so the > goal is to have a component build where you override target components. > I find it best to have two kinds of projects in an overall Jetspeed > integration project: > 1) portlet application projects > 2) jetspeed integration projects (component overrides) > > With the first kind of project, you simply write your portlets to the > Portlet API and perhaps integrate with a Jetspeed service or two. I > don't see many problems in that area. > > The second kind of project is a little more complicated. > It requires building and/or deploying the portal, and integrating key > pieces, overriding configuration, setting up the database with custom > settings. > > What I've found in the development cycle, is that we make a change to > core, and then an integrator wants to pickup the change. We can achieve > this with: > > a) having the integrator rebuild the source code > b) have some kind of 'binary' integration (no compilation of source) > c) an installer > > While an installer is good for initial evaluations of Jetspeed, or > perhaps even for someone using Jetspeed out of the box, real life > projects have an integration life cycle. I think we need to identify > this life cycle, and try to create a tool for people to tap into that > life cycle with the least amount of disruption to their project as > possible. > > Binary integration is probably best. > Our Maven-1 plugin attempted to solve this. > In my opinion, it failed. Maven is just too much of an all-or-nothing > buy in to impose on integrators. > > With Maven-2, we were planning on building Jetspeed with Maven-2, and > then doing binary integrations with Ant. As Ralph pointed out, > integrators usually don't need the source, but we have found that, since > our integration procedure (Maven-1 plugin) was always breaking, everyone > was resorting to building the source instead. > > I think that integration pieces should be written in Ant. > I think we should really consider strong Elipse integration as a priority. > And, for the reasons repeatedly stated here by end users (and we should > *really* listen to our end users, its stupid to repeat the same mistake > twice), we should not force the "Maven way" on integrators and end users. > > As for using Maven-2 in the Jetspeed build, I think there is still a > valid argument to take this approach. As suggested more than once on the > dev list, maybe the problem isn't Maven, its really us. Anyone at > Mergere want to send the Jetspeed team and users to a Maven-2 training > session? > > >
