I think maven has it strength when using it the way maven suggests to do tasks. From my point of view it becomes very difficult when you have to customize the behavior.
Jetspeed needs a lot of tasks that are not provided by maven. So I think we pay more for using maven than we win. May be for jetspeed custom ant scripts are the better way. I can only speak for Maven 1. Martin 2006/2/22, Ate Douma <[EMAIL PROTECTED]>: > > Hmm, now I think the best build system should not be visibile to the > > user which > > means you just invoke "build.bat/build.sh" and are done - and this is > > regardless of using either ant or maven or whatever. And I think this > > should be possible with both ant or maven. > > The only real difference I see from a user pov is that maven requires a > > network connection the first time you build; but as someone already > > pointed out this is only required if you want to build maven from the > > source. For releases, jetspeed will provide binary versions anyway. > > > I keep seeing this point of view coming back again and again. > Let me repeat what has been said before: this is *not* the (most) intended > usage of jetspeed. > > If Jetspeed were a "blackbox" product one installs and uses as is, then I'd > say this whole > build system discussion would be pointless anyway. > AFAIK, the Jetspeed committers themselves never had big problems building > Jetspeed *locally* > for their specific environment using maven. > Neither was building a demo/binary with Tomcat and using an embedded > database. > > What I don't understand is why so many think that is all what is needed! > > As soon as one really is going to *use* Jetspeed, e.g. install your own > portal and tweak it > to your own requirements like the simplest of all customizations: using your > own portal name > instead of jetspeed, you're gonna need to *build* your own portal. > Create a new jetspeed.war (with probably a different name), use different > databases, add > services, change assembly settings, deploy on different platforms and > application servers, etc. > > Now please, if the maven advocates here can provide us with this neat maven > extension which > supports all of the above customizations (and more!), is flexible enough for > all our different > systems and requirements, easy to use and understand and, most importantly, > just WORKS, then > you *might* get my vote. > > Oh, and it should also nicely integrate in our IDEs so we can finally > properly debug and run our > unit tests again using it... > > I don't care for all the other nice projects which so perfectly build using > maven. > I say most, if not all, don't need customization *by the users* like > Jetspeed. > But, if someone can point me to a solution, or even better provide one, > which proves the contrary, > I'll give it my highest attention. > > As I said before (I think it was on the dev list though), for companies > which have a strict policy > and a high to absolute control on the development environments, maven might > be a gift from heaven. > But you'll need dedicated attention on keeping your environments healthy and > in sync with external updates. > > We, as Jetspeed committers, are not so lucky we can predict all end users > wishes, nor are we able > (and certainly not willing) to enforce or limit to one way of using it. > That would negate one of the most important features Apache and Jetspeed > provide: freedom of usage. > > I'll stick to my vote for dropping maven and move to ant for now. > > 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]
