I've read both of the threads on this and I have to admit that I have been swaying toward Ant. I have had my share of problems with maven. The thing I hate the most is wasted time. It always takes longer to run a maven command especially when downloading dependencies. But maven does not inhibit debugging remotely. I use the MAVEN_OPTS and I set up eclipse to do remote debugging. Add this to your MAVEN_OPTS environment variable.
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n Tomcat also supports this function. Run the catalina script like this ( 'catalina jpda run' ) and remote debugging will be set up. So debugging in maven is not an issue. I've overcome my maven problems by reading the code that I write before deploying it or while maven is running, saves time. Self quality assurance. As for my integration projects, I wouldn't waste much time developing the j2 plugin or archetype. I only ever use the quickStart goal. I just keep several checked out versions of jetspeed, one for each project. If I want to update from svn I do it, or I don't. And like scott I copy over files that are specific to my project. I vote for continuing with maven 2 now that there is discusion about using ant for integration. This means that people can choose an all maven way or just ant for integration. Seems the best way to go. On 2/22/06, Ate Douma <[EMAIL PROTECTED]> wrote: > > 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] > > -- Philip Donaghy donaghy.blogspot.com del.icio.us/donaghy/philip Skype: philipmarkdonaghy Office: +33 5 56 60 88 02 Mobile: +33 6 20 83 22 62 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
