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