ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Maven for Build?
Date Tue, 13 Feb 2007 17:06:31 GMT
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
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 <lmeadors@apache.org> 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 <brandon.goodin@gmail.com> 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
> >

View raw message