I am currently building my integration project from a pre-existing jetspeed-2 war file, then overriding/removing as needed. I would be more than happy to submit my build script as an example of how to do integration builds without compiling the source code. I even have a custom ant task for doing dependencies like Maven.
Regards, -Scott > -----Original Message----- > From: David Sean Taylor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 21, 2006 7:08 PM > To: Jetspeed Users List > Subject: Re: RFC: J2 Build System > > Frank Villarreal wrote: > > Ralph Goers said: > > > >>Having said all that, I'm not sure why a Jetspeed customer really needs > >>to know about any build tool. I should be able to download a war or ear > >>file, install it into my container (perhaps with a configuration script) > >>and run it. I really should only be concerned about the build tool if I > >>want to modify Jetspeed source. > >> > > > > > > WOW. There sure are a LOT of assumptions in that paragraph. Have you > > worked with many portal projects in an enterprise environment for very > long? > > If so then you should probably know that more times than not, you end up > > customizing big pieces of the code in order to integrate with pre- > existing > > infrastructure ... not necessarily by choice. How many projects in the > > history of software development have accomplished 100% of what everyone > > wanted, 100% of the time? I'll tell you the answer is ZERO. So yes, > people > > need to modify the source. By nature, open source projects are ... > guess > > what ... OPEN!?! Meaning users (customers as you put it) can and should > be > > concerned about the build tool if they need or want to modify the > source. > > > > > >>If you buy into maven's way of doing things then you only have to write > >>"build logic" for things that are unique to your project. With ant you > >>have to write everything. > > > > > > Once again, this assumes that the developers have thought of everything > and > > will designate the "pockets of code" that can be customized. Then when > this > > turns out not to be the case (99% of the time), anyone wanting to > customize > > the source has to learn the complexities of these monstrous NESTED maven > > scripts. > > > > > 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? > > > > --------------------------------------------------------------------- > 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]
