On 2/13/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
Really? I think our build is great. We just cloned it for a project we're working on.
Ouch, yeah, I hate it. :-D After working with maven for a few months, it seems really overcomplicated.
No external dependencies or extra steps, and preferrably no downloading.....argh. I hate maven.
But we *do* have external dependencies already. We just jump through some extra hoops to pretend that we don't (devsrc).
And I'm a -10000 for Maven generated website. Remember, we have .NET and Ruby projects too.
Heh, yeah, OK, I can't argue that, even w/o .net and ruby...maven generated sites are, well, hideous.
Cheers, Grumpy Clinton On 2/13/07, Larry Meadors <[EMAIL PROTECTED]> wrote: > I like the idea - it makes the checkout faster, and "mvn idea:idea" is > worth it's weight in gold, and our current build.xml is a bugger, I > hate it. > > So, I wonder if we can skin the generated site to make it not look > like crap^H^H^H^H every other maven generated site. :-) > > Larry > > > On 2/12/07, Brandon Goodin <[EMAIL PROTECTED]> wrote: > > Hey Guys, > > > > I wanted to throw a bone out to everyone and ask the question "Should we use > > Maven for our build?". I put together a POM today that makes use of the > > current iBATIS SQL Map structures. It is pretty darn simple and required > > very little effort. The largest amount of my time was spent refactoring the > > TestCL (Test Classloader) to use the current thread classloader as a parent > > due to some incompatibilities with how Maven runs it's test. That aside, I > > was surprised at how little effort it took to get the iBATIS SQLMap jar > > built. Plus, Because of the dependency management of Maven I was able to > > avoid having to use the oscache devsrc for oscache and avoid using the > > devlib jars. I only used Maven to build the Data Mapper/SQL Map. I wasn't > > familiar enough with Abator's build process to wire in Maven for it. > > > > Benefits: > > > > * I thought it would be good to aid in reducing the complexity of our > > current build/deploy. If we want to provide our jars to the Maven crowd we > > would be tasking the deploying member with taking the final jar built from > > ant and running deploy:deploy-file for it. I have to say that I looked > > through our release process and I really wouldn't want to add yet another > > step. Seems like maven can consolidate this for us. > > * We can run ant from within Maven if we so desire to continue performing > > tasks that maven doesn't provide for. > > > > Additional benefits, thoughts, or concerns? > > > > Thanks, > > Brandon > > >
