I can finish the pom that i have right now so that it mirrors the functionality of the current ant script. It won't hurt anything to have the pom in the repo.
Brandon On 2/13/07, Jeff Butler <[EMAIL PROTECTED]> wrote:
I'm open to maven for the iBATIS build. It would help a certain group of our users to get iBATIS into the Maven repository. Also - I don't think you have to generate the site with maven, we could just use it for the build. I've looked at it for Abator. Abator doesn't have much of a dependancy issue for the build (just needs a JRE and Ant), but the test phase is a different story. Abator testing is difficult because the tests are not so much an Abator itself, but on the code that Abator generates. So the build looks like this: 1. Build the JAR 2. Run a few tests (only three or four right now) 3. Build a test DB 4. Generate code against the DB 5. Compile the generated code and also a set of tests against the generated code 6. Run the tests on the generated code (several hundred) The Abater build also behaves differently if you're running wuth JSE 5 or not - there are more tests if you are using a Java 5 JDK. The build.xml for Abator is more complex than I'd like because of all this - so if Maven could help, then I'd be open to using for Abator too. Jeff Butler 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 > > >
