+1 for Ant as the primary build. But could we get iBATIS into the Maven repository somehow so we could stop all the whining from Maven mavens? :-)
Jeff Butler On 2/13/07, Clinton Begin <[EMAIL PROTECTED]> wrote:
+1 for Slava...oh wait, you all know my opinion already. Do I only get one? On 2/13/07, Slava Imeshev <[EMAIL PROTECTED]> wrote: > My preference for a build to be self-contained and not to require > to go out to run. > > > Using Maven will prevent those having no Internet connection > from building iBATIS. > > Regards, > > Slava Imeshev > www.viewtier.com > > > ----- Original Message ----- > From: "Brandon Goodin" <[EMAIL PROTECTED]> > To: <dev@ibatis.apache.org> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, February 13, 2007 9:16 AM > Subject: Re: Maven for Build? > > > > 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 > > > > > > > > > > > > > > > > > >
