You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by Nathan Maves <na...@gmail.com> on 2008/05/07 06:34:47 UTC
Code Hierarchy and Build Process
The ideas/requests/demands just keep coming...
With a clean slate for IB3 I want to propose a few things. I have been
using Maven2 for a while now and even use it in my day to day development.
My first suggestion is to lay out the new source tree to map to the maven2
style of convention over configuration. Even if we choose not to use Maven
as the build/deployment process it is the most logical and thought out
hierarchy that I have seen.
On the topic of Maven2 I would like to nominate is as the build/deployment
process. Maven2 offers so many pre-built plugins for many useful things
from coverage reports to unit test results. If there is something that
Maven2 does not have I am sure we could write a quick plugin to get it
done. I have also been using a new CI tool with Maven2 (
https://hudson.dev.java.net/ ). Insanely easy to install and configure.
Just reads your pom file from maven and away you go. Like most it can poll
the svn repo for changes and make snapshots as we commit.
Let me know what you guys think
Nathan
Re: Code Hierarchy and Build Process
Posted by Nathan Maves <na...@gmail.com>.
+1 from me
On Wed, May 7, 2008 at 11:25 AM, Clinton Begin <cl...@gmail.com>
wrote:
>
> NM, found it! Yes, to all 3.
>
>
> On Wed, May 7, 2008 at 11:23 AM, Clinton Begin <cl...@gmail.com>
> wrote:
>
> >
> > Anyone know off hand if Maven can easily support FindBugs, Checkstyle
> > and/or Jalopy?
> >
> > Cheers,
> > Clinton
> >
> >
> >
> > On Wed, May 7, 2008 at 11:18 AM, Larry Meadors <la...@gmail.com>
> > wrote:
> >
> > > Hahah, I think it's a good sign that we all have enough passion for
> > > this stuff to argue about it, and that we are able to call each other
> > > names, but still get along well enough to play well together. ;-)
> > >
> > > Larry
> > >
> > >
> > > On Wed, May 7, 2008 at 11:15 AM, Clinton Begin <
> > > clinton.begin@gmail.com> wrote:
> > > > Vote is out.
> > > >
> > > > If it's positive, I'll switch the directory structure to the Maven 2
> > > > structure, but will update the Ant build and leave the /build,
> > > /devlib and
> > > > /lib until someone has a chance to configure the Maven project.
> > > Once it's
> > > > building nicely, I'll remove the old directories and Ant build.
> > > Ceremonies
> > > > for the old Ant build file to be held at Apache Funeral Services.
> > > Donations
> > > > supporting the Mental Case Anger Management fund appreciated.
> > > >
> > > > Clinton ;-)
> > > >
> > > >
> > > >
> > > > On Wed, May 7, 2008 at 11:09 AM, Larry Meadors <
> > > larry.meadors@gmail.com>
> > > > wrote:
> > > > > On Wed, May 7, 2008 at 11:07 AM, Brandon Goodin
> > > > >
> > > > > <br...@gmail.com> wrote:
> > > > > > Shutting up,
> > > > >
> > > > > Yeah, we'll keep dreaming. ;-)
> > > > >
> > > > > Larry
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Re: Code Hierarchy and Build Process
Posted by Clinton Begin <cl...@gmail.com>.
NM, found it! Yes, to all 3.
On Wed, May 7, 2008 at 11:23 AM, Clinton Begin <cl...@gmail.com>
wrote:
>
> Anyone know off hand if Maven can easily support FindBugs, Checkstyle
> and/or Jalopy?
>
> Cheers,
> Clinton
>
>
>
> On Wed, May 7, 2008 at 11:18 AM, Larry Meadors <la...@gmail.com>
> wrote:
>
> > Hahah, I think it's a good sign that we all have enough passion for
> > this stuff to argue about it, and that we are able to call each other
> > names, but still get along well enough to play well together. ;-)
> >
> > Larry
> >
> >
> > On Wed, May 7, 2008 at 11:15 AM, Clinton Begin <cl...@gmail.com>
> > wrote:
> > > Vote is out.
> > >
> > > If it's positive, I'll switch the directory structure to the Maven 2
> > > structure, but will update the Ant build and leave the /build, /devlib
> > and
> > > /lib until someone has a chance to configure the Maven project. Once
> > it's
> > > building nicely, I'll remove the old directories and Ant build.
> > Ceremonies
> > > for the old Ant build file to be held at Apache Funeral Services.
> > Donations
> > > supporting the Mental Case Anger Management fund appreciated.
> > >
> > > Clinton ;-)
> > >
> > >
> > >
> > > On Wed, May 7, 2008 at 11:09 AM, Larry Meadors <
> > larry.meadors@gmail.com>
> > > wrote:
> > > > On Wed, May 7, 2008 at 11:07 AM, Brandon Goodin
> > > >
> > > > <br...@gmail.com> wrote:
> > > > > Shutting up,
> > > >
> > > > Yeah, we'll keep dreaming. ;-)
> > > >
> > > > Larry
> > > >
> > >
> > >
> >
>
>
Re: Code Hierarchy and Build Process
Posted by Clinton Begin <cl...@gmail.com>.
Anyone know off hand if Maven can easily support FindBugs, Checkstyle and/or
Jalopy?
Cheers,
Clinton
On Wed, May 7, 2008 at 11:18 AM, Larry Meadors <la...@gmail.com>
wrote:
> Hahah, I think it's a good sign that we all have enough passion for
> this stuff to argue about it, and that we are able to call each other
> names, but still get along well enough to play well together. ;-)
>
> Larry
>
>
> On Wed, May 7, 2008 at 11:15 AM, Clinton Begin <cl...@gmail.com>
> wrote:
> > Vote is out.
> >
> > If it's positive, I'll switch the directory structure to the Maven 2
> > structure, but will update the Ant build and leave the /build, /devlib
> and
> > /lib until someone has a chance to configure the Maven project. Once
> it's
> > building nicely, I'll remove the old directories and Ant build.
> Ceremonies
> > for the old Ant build file to be held at Apache Funeral Services.
> Donations
> > supporting the Mental Case Anger Management fund appreciated.
> >
> > Clinton ;-)
> >
> >
> >
> > On Wed, May 7, 2008 at 11:09 AM, Larry Meadors <la...@gmail.com>
> > wrote:
> > > On Wed, May 7, 2008 at 11:07 AM, Brandon Goodin
> > >
> > > <br...@gmail.com> wrote:
> > > > Shutting up,
> > >
> > > Yeah, we'll keep dreaming. ;-)
> > >
> > > Larry
> > >
> >
> >
>
Re: Code Hierarchy and Build Process
Posted by Larry Meadors <la...@gmail.com>.
Hahah, I think it's a good sign that we all have enough passion for
this stuff to argue about it, and that we are able to call each other
names, but still get along well enough to play well together. ;-)
Larry
On Wed, May 7, 2008 at 11:15 AM, Clinton Begin <cl...@gmail.com> wrote:
> Vote is out.
>
> If it's positive, I'll switch the directory structure to the Maven 2
> structure, but will update the Ant build and leave the /build, /devlib and
> /lib until someone has a chance to configure the Maven project. Once it's
> building nicely, I'll remove the old directories and Ant build. Ceremonies
> for the old Ant build file to be held at Apache Funeral Services. Donations
> supporting the Mental Case Anger Management fund appreciated.
>
> Clinton ;-)
>
>
>
> On Wed, May 7, 2008 at 11:09 AM, Larry Meadors <la...@gmail.com>
> wrote:
> > On Wed, May 7, 2008 at 11:07 AM, Brandon Goodin
> >
> > <br...@gmail.com> wrote:
> > > Shutting up,
> >
> > Yeah, we'll keep dreaming. ;-)
> >
> > Larry
> >
>
>
Re: Code Hierarchy and Build Process
Posted by Clinton Begin <cl...@gmail.com>.
Vote is out.
If it's positive, I'll switch the directory structure to the Maven 2
structure, but will update the Ant build and leave the /build, /devlib and
/lib until someone has a chance to configure the Maven project. Once it's
building nicely, I'll remove the old directories and Ant build. Ceremonies
for the old Ant build file to be held at Apache Funeral Services. Donations
supporting the Mental Case Anger Management fund appreciated.
Clinton ;-)
On Wed, May 7, 2008 at 11:09 AM, Larry Meadors <la...@gmail.com>
wrote:
> On Wed, May 7, 2008 at 11:07 AM, Brandon Goodin
> <br...@gmail.com> wrote:
> > Shutting up,
>
> Yeah, we'll keep dreaming. ;-)
>
> Larry
>
Re: Code Hierarchy and Build Process
Posted by Larry Meadors <la...@gmail.com>.
On Wed, May 7, 2008 at 11:07 AM, Brandon Goodin
<br...@gmail.com> wrote:
> Shutting up,
Yeah, we'll keep dreaming. ;-)
Larry
Re: Code Hierarchy and Build Process
Posted by Brandon Goodin <br...@gmail.com>.
Geez I'm really sorry to fire off yet another...
Yet another point. Ant integration has become quite nice with maven. So, it
is possible we can augment maven insufficiencies with Ant.
Shutting up,
Brandon
On Wed, May 7, 2008 at 12:05 PM, Brandon Goodin <br...@gmail.com>
wrote:
> Sorry for the spotty emails. just stuff coming to my mind. Another point
> would be the whole deploying to the maven repository can be made easier. We
> want to be able to provide users with source artifacts and jar artifacts all
> properly packaged with maven. I can do this manually. But, i'd rather not.
> So, if we can accomplish all that the ant tool does and get the artifacts
> out to the maven repo, it would be all that much better.
>
> Brandon
>
>
> On Wed, May 7, 2008 at 12:03 PM, Brandon Goodin <br...@gmail.com>
> wrote:
>
> > The other thing that can be nice about maven is for ibatis extension
> > development. We are making iB3 more accessible. This means that we are
> > likely to have more people wanting to write against ibatis. Maven makes it
> > nicer to create dependencies on nightly builds/snapshots.
> >
> > Brandon
> >
> >
> > On Wed, May 7, 2008 at 11:54 AM, Clinton Begin <cl...@gmail.com>
> > wrote:
> >
> > > >> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > > >> additional dependencies or configuration)" - how's this going to
> > > work,
> > > >> via telepathy? :-D
> > >
> > > Trusted hosts (or same host) and a continuous integration server with
> > > a manually invoked distribution target. CI server runs as the "deploy" user
> > > which is a trusted signatory of the Apache distribution system.
> > >
> > > Clinton
> > >
> > >
> > > On Wed, May 7, 2008 at 10:46 AM, Larry Meadors <
> > > larry.meadors@gmail.com> wrote:
> > >
> > > > On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
> > > > <br...@gmail.com> wrote:
> > > > > As a follow up to all who are reading this thread. Let me be very
> > > > clear. Any
> > > > > aggressive comments are made in jest and fun. We are all good
> > > > friends here
> > > > > and enjoy the big brother banter. Please don't take this as an
> > > > opportunity
> > > > > to truly dig on any one of us.
> > > >
> > > > ...well, except for Brandon. He really is a butthead. ;-)
> > > >
> > > > Funny how everyone gets so worked up about how we'll implement
> > > > build.sh, isn't it? :-)
> > > >
> > > > Since everyone has an opinion on this, here's mine: I think we
> > > > should use Maven.
> > > >
> > > > I agree with Clinton that there aren't *problems* with the current
> > > > iBATIS build, but at the same time, it would simplify how we do
> > > > releases, because as we are seeing, there are more requests (even
> > > > from
> > > > us) for maven artifacts by our users, and mavenizing our build will
> > > > make meeting our needs easier.
> > > >
> > > > IMO, the things that Clinton is asking for are not unreasonable, but
> > > > they are not uber-critical either.
> > > >
> > > > Let's be really honest here: How critical is it that we are able to
> > > > "echo arbitrary information to the command line, such as classpath
> > > > in
> > > > use and current version being built"? Seriously? :-/
> > > >
> > > > Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > > > additional dependencies or configuration)" - how's this going to
> > > > work,
> > > > via telepathy? :-D
> > > >
> > > > It's going to be different if we use a different tool. Neither tool
> > > > is
> > > > perfect, so yes, it'll suck. But ant sucks, too - just in a
> > > > different
> > > > way.
> > > >
> > > > My vote is we arrange the source tree to fit what maven expects.
> > > > Clinton: I don't care if you don't have to do that with ant. :-P
> > > > Then,
> > > > lets see how close we can get to all of the current ant script. If
> > > > we
> > > > can't get 100%, I'm OK with that, if we can get close and work
> > > > towards
> > > > that goal.
> > > >
> > > > At the end of the day, which ever one makes it easier for me to use
> > > > iBATIS (I really don't care about anyone else, sorry) is the one I
> > > > want. For me, that means Maven is the better choice. This is a one
> > > > time task, so maintenance is not that big of a deal, and it'll
> > > > output
> > > > the jar (like ant does) and the maven artifacts (like ant does not).
> > > > It does more, and is a one time investment, let's just get it done
> > > > and
> > > > move on.
> > > >
> > > > Larry
> > > >
> > >
> > >
> >
>
Re: Code Hierarchy and Build Process
Posted by Brandon Goodin <br...@gmail.com>.
Sorry for the spotty emails. just stuff coming to my mind. Another point
would be the whole deploying to the maven repository can be made easier. We
want to be able to provide users with source artifacts and jar artifacts all
properly packaged with maven. I can do this manually. But, i'd rather not.
So, if we can accomplish all that the ant tool does and get the artifacts
out to the maven repo, it would be all that much better.
Brandon
On Wed, May 7, 2008 at 12:03 PM, Brandon Goodin <br...@gmail.com>
wrote:
> The other thing that can be nice about maven is for ibatis extension
> development. We are making iB3 more accessible. This means that we are
> likely to have more people wanting to write against ibatis. Maven makes it
> nicer to create dependencies on nightly builds/snapshots.
>
> Brandon
>
>
> On Wed, May 7, 2008 at 11:54 AM, Clinton Begin <cl...@gmail.com>
> wrote:
>
> > >> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > >> additional dependencies or configuration)" - how's this going to
> > work,
> > >> via telepathy? :-D
> >
> > Trusted hosts (or same host) and a continuous integration server with a
> > manually invoked distribution target. CI server runs as the "deploy" user
> > which is a trusted signatory of the Apache distribution system.
> >
> > Clinton
> >
> >
> > On Wed, May 7, 2008 at 10:46 AM, Larry Meadors <la...@gmail.com>
> > wrote:
> >
> > > On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
> > > <br...@gmail.com> wrote:
> > > > As a follow up to all who are reading this thread. Let me be very
> > > clear. Any
> > > > aggressive comments are made in jest and fun. We are all good
> > > friends here
> > > > and enjoy the big brother banter. Please don't take this as an
> > > opportunity
> > > > to truly dig on any one of us.
> > >
> > > ...well, except for Brandon. He really is a butthead. ;-)
> > >
> > > Funny how everyone gets so worked up about how we'll implement
> > > build.sh, isn't it? :-)
> > >
> > > Since everyone has an opinion on this, here's mine: I think we should
> > > use Maven.
> > >
> > > I agree with Clinton that there aren't *problems* with the current
> > > iBATIS build, but at the same time, it would simplify how we do
> > > releases, because as we are seeing, there are more requests (even from
> > > us) for maven artifacts by our users, and mavenizing our build will
> > > make meeting our needs easier.
> > >
> > > IMO, the things that Clinton is asking for are not unreasonable, but
> > > they are not uber-critical either.
> > >
> > > Let's be really honest here: How critical is it that we are able to
> > > "echo arbitrary information to the command line, such as classpath in
> > > use and current version being built"? Seriously? :-/
> > >
> > > Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > > additional dependencies or configuration)" - how's this going to work,
> > > via telepathy? :-D
> > >
> > > It's going to be different if we use a different tool. Neither tool is
> > > perfect, so yes, it'll suck. But ant sucks, too - just in a different
> > > way.
> > >
> > > My vote is we arrange the source tree to fit what maven expects.
> > > Clinton: I don't care if you don't have to do that with ant. :-P Then,
> > > lets see how close we can get to all of the current ant script. If we
> > > can't get 100%, I'm OK with that, if we can get close and work towards
> > > that goal.
> > >
> > > At the end of the day, which ever one makes it easier for me to use
> > > iBATIS (I really don't care about anyone else, sorry) is the one I
> > > want. For me, that means Maven is the better choice. This is a one
> > > time task, so maintenance is not that big of a deal, and it'll output
> > > the jar (like ant does) and the maven artifacts (like ant does not).
> > > It does more, and is a one time investment, let's just get it done and
> > > move on.
> > >
> > > Larry
> > >
> >
> >
>
Re: Code Hierarchy and Build Process
Posted by Brandon Goodin <br...@gmail.com>.
The other thing that can be nice about maven is for ibatis extension
development. We are making iB3 more accessible. This means that we are
likely to have more people wanting to write against ibatis. Maven makes it
nicer to create dependencies on nightly builds/snapshots.
Brandon
On Wed, May 7, 2008 at 11:54 AM, Clinton Begin <cl...@gmail.com>
wrote:
> >> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> >> additional dependencies or configuration)" - how's this going to work,
> >> via telepathy? :-D
>
> Trusted hosts (or same host) and a continuous integration server with a
> manually invoked distribution target. CI server runs as the "deploy" user
> which is a trusted signatory of the Apache distribution system.
>
> Clinton
>
>
> On Wed, May 7, 2008 at 10:46 AM, Larry Meadors <la...@gmail.com>
> wrote:
>
> > On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
> > <br...@gmail.com> wrote:
> > > As a follow up to all who are reading this thread. Let me be very
> > clear. Any
> > > aggressive comments are made in jest and fun. We are all good friends
> > here
> > > and enjoy the big brother banter. Please don't take this as an
> > opportunity
> > > to truly dig on any one of us.
> >
> > ...well, except for Brandon. He really is a butthead. ;-)
> >
> > Funny how everyone gets so worked up about how we'll implement
> > build.sh, isn't it? :-)
> >
> > Since everyone has an opinion on this, here's mine: I think we should
> > use Maven.
> >
> > I agree with Clinton that there aren't *problems* with the current
> > iBATIS build, but at the same time, it would simplify how we do
> > releases, because as we are seeing, there are more requests (even from
> > us) for maven artifacts by our users, and mavenizing our build will
> > make meeting our needs easier.
> >
> > IMO, the things that Clinton is asking for are not unreasonable, but
> > they are not uber-critical either.
> >
> > Let's be really honest here: How critical is it that we are able to
> > "echo arbitrary information to the command line, such as classpath in
> > use and current version being built"? Seriously? :-/
> >
> > Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> > additional dependencies or configuration)" - how's this going to work,
> > via telepathy? :-D
> >
> > It's going to be different if we use a different tool. Neither tool is
> > perfect, so yes, it'll suck. But ant sucks, too - just in a different
> > way.
> >
> > My vote is we arrange the source tree to fit what maven expects.
> > Clinton: I don't care if you don't have to do that with ant. :-P Then,
> > lets see how close we can get to all of the current ant script. If we
> > can't get 100%, I'm OK with that, if we can get close and work towards
> > that goal.
> >
> > At the end of the day, which ever one makes it easier for me to use
> > iBATIS (I really don't care about anyone else, sorry) is the one I
> > want. For me, that means Maven is the better choice. This is a one
> > time task, so maintenance is not that big of a deal, and it'll output
> > the jar (like ant does) and the maven artifacts (like ant does not).
> > It does more, and is a one time investment, let's just get it done and
> > move on.
> >
> > Larry
> >
>
>
Re: Code Hierarchy and Build Process
Posted by Clinton Begin <cl...@gmail.com>.
>> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
>> additional dependencies or configuration)" - how's this going to work,
>> via telepathy? :-D
Trusted hosts (or same host) and a continuous integration server with a
manually invoked distribution target. CI server runs as the "deploy" user
which is a trusted signatory of the Apache distribution system.
Clinton
On Wed, May 7, 2008 at 10:46 AM, Larry Meadors <la...@gmail.com>
wrote:
> On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
> <br...@gmail.com> wrote:
> > As a follow up to all who are reading this thread. Let me be very clear.
> Any
> > aggressive comments are made in jest and fun. We are all good friends
> here
> > and enjoy the big brother banter. Please don't take this as an
> opportunity
> > to truly dig on any one of us.
>
> ...well, except for Brandon. He really is a butthead. ;-)
>
> Funny how everyone gets so worked up about how we'll implement
> build.sh, isn't it? :-)
>
> Since everyone has an opinion on this, here's mine: I think we should use
> Maven.
>
> I agree with Clinton that there aren't *problems* with the current
> iBATIS build, but at the same time, it would simplify how we do
> releases, because as we are seeing, there are more requests (even from
> us) for maven artifacts by our users, and mavenizing our build will
> make meeting our needs easier.
>
> IMO, the things that Clinton is asking for are not unreasonable, but
> they are not uber-critical either.
>
> Let's be really honest here: How critical is it that we are able to
> "echo arbitrary information to the command line, such as classpath in
> use and current version being built"? Seriously? :-/
>
> Reality check: "Signs, MD5, and Uploads to Apache dist (with no
> additional dependencies or configuration)" - how's this going to work,
> via telepathy? :-D
>
> It's going to be different if we use a different tool. Neither tool is
> perfect, so yes, it'll suck. But ant sucks, too - just in a different
> way.
>
> My vote is we arrange the source tree to fit what maven expects.
> Clinton: I don't care if you don't have to do that with ant. :-P Then,
> lets see how close we can get to all of the current ant script. If we
> can't get 100%, I'm OK with that, if we can get close and work towards
> that goal.
>
> At the end of the day, which ever one makes it easier for me to use
> iBATIS (I really don't care about anyone else, sorry) is the one I
> want. For me, that means Maven is the better choice. This is a one
> time task, so maintenance is not that big of a deal, and it'll output
> the jar (like ant does) and the maven artifacts (like ant does not).
> It does more, and is a one time investment, let's just get it done and
> move on.
>
> Larry
>
Re: Code Hierarchy and Build Process
Posted by Larry Meadors <la...@gmail.com>.
On Wed, May 7, 2008 at 10:15 AM, Brandon Goodin
<br...@gmail.com> wrote:
> As a follow up to all who are reading this thread. Let me be very clear. Any
> aggressive comments are made in jest and fun. We are all good friends here
> and enjoy the big brother banter. Please don't take this as an opportunity
> to truly dig on any one of us.
...well, except for Brandon. He really is a butthead. ;-)
Funny how everyone gets so worked up about how we'll implement
build.sh, isn't it? :-)
Since everyone has an opinion on this, here's mine: I think we should use Maven.
I agree with Clinton that there aren't *problems* with the current
iBATIS build, but at the same time, it would simplify how we do
releases, because as we are seeing, there are more requests (even from
us) for maven artifacts by our users, and mavenizing our build will
make meeting our needs easier.
IMO, the things that Clinton is asking for are not unreasonable, but
they are not uber-critical either.
Let's be really honest here: How critical is it that we are able to
"echo arbitrary information to the command line, such as classpath in
use and current version being built"? Seriously? :-/
Reality check: "Signs, MD5, and Uploads to Apache dist (with no
additional dependencies or configuration)" - how's this going to work,
via telepathy? :-D
It's going to be different if we use a different tool. Neither tool is
perfect, so yes, it'll suck. But ant sucks, too - just in a different
way.
My vote is we arrange the source tree to fit what maven expects.
Clinton: I don't care if you don't have to do that with ant. :-P Then,
lets see how close we can get to all of the current ant script. If we
can't get 100%, I'm OK with that, if we can get close and work towards
that goal.
At the end of the day, which ever one makes it easier for me to use
iBATIS (I really don't care about anyone else, sorry) is the one I
want. For me, that means Maven is the better choice. This is a one
time task, so maintenance is not that big of a deal, and it'll output
the jar (like ant does) and the maven artifacts (like ant does not).
It does more, and is a one time investment, let's just get it done and
move on.
Larry
Re: Code Hierarchy and Build Process
Posted by Brandon Goodin <br...@gmail.com>.
As a follow up to all who are reading this thread. Let me be very clear. Any
aggressive comments are made in jest and fun. We are all good friends here
and enjoy the big brother banter. Please don't take this as an opportunity
to truly dig on any one of us.
Muchos Gracias,
Brandon
On Wed, May 7, 2008 at 11:13 AM, Brandon Goodin <br...@gmail.com>
wrote:
> Comments are mixed in:
>
> On Wed, May 7, 2008 at 10:38 AM, Clinton Begin <cl...@gmail.com>
> wrote:
>
> >
> > I wasn't implying that Maven COULDN'T do anything.... I was just laying
> > out what I would want to see from a maven build.
> >
> > >> So, if you are saying we can't have an assembly config then gimme a
> > break.
> >
> > What I mean is that if I can't check it out and build without having to
> > perform some developer level/local config then forget it.
> >
>
> This would entirely depend on what we are doing. I don't believe iBATIS
> would ever require this unless we used a key for uploading artifacts to a
> location. In that case you would need to add the configuration to your
> settings.xml.
>
> There is also the initial installation of maven. But, most people will be
> installing ant as well to run any ant builds that we provide.
>
>
> > >> I don't think this is necessary. We can look into adding the build
> > number to the META-INF. But, this should be possible.
> >
> > Versions are important. The more clear we can be with our version
> > number the better. I'd like it in the filename, because it helps people,
> > including us. One of the reasons Java sucks these days is the lack of good
> > version control of JAR files. The best we can do is put the version number
> > in the name of the JAR file to help people know which version they're
> > using. It also helps us on support lists... recall the days when people
> > couldn't tell which version they were using because they copied it from
> > somewhere else. META-INF is a good second best... but I hear this Maven
> > thing is supposed to be good, so I'd expect it to be able to fill this
> > simple requirement.
> >
>
> Fair enough. I didn't say it was impossible. I just said it wasn't
> necessary to tack it onto everything.
>
>
> > I'm already not impressed with the excuses. I laid out what I think are
> > fairly simple requirements that any build system should support.
> >
>
> What excuses? I'm simply getting information and asking you to clarify
> your requests. On top of that I'm stating where I don't agree with your
> requirements.
>
>
> >
> > >> Getting up and going in my IDE
> >
> > I honestly don't want to mix the needs of the development tool with the
> > build tool. The build is a separate entity. Furthermore, let's not mix the
> > problems of other projects (which may very well be solved by Maven). iBATIS
> > does not have the problem you describe. It's a well structured and
> > organized directory. /devlib /lib /src /test...... there's no magic to it.
> > I understand what you're saying, but iBATIS simply doesn't have the
> > problem.
> >
>
> The beauty of this is that you get both. Can you say that about Ant?
> hint... nope.
>
>
> >
> > >> I think you need to take your blood pressure medicine.
> >
> > Let's not get too immature about it. I'm being open minded and fair. I
> > asked for very simple things that are achieved with a 260 line Ant file with
> > 14 well described tasks. I've yet to see:
>
>
> You're just a hater :D and you left of my wink from that quote.
>
> >
> >
> > 1) A major problem or flaw pointed out with the iBATIS Ant build. I
> > don't care about the general case of Maven vs. Ant and Project X -- what's
> > wrong with the *iBATIS* build?
>
>
> I still need to take the time to figure out the iBATIS ant build. I don't
> need to do that with maven. I know what tasks to run in order to build it.
>
>
> >
> > 2) A major advantage to using Maven for iBATIS (other than the
> > potentially easier one-time setup of the IDE -- neat, but one-time IDE
> > config vs. daily build maintenance...)
>
>
> Standard project layout is easy to get into and get going. A clearly
> defined structure that leaves no question about where future artifacts go.
> Unambiguous communication of required project structures is very important.
> So, why not go with a common, well known, and documented structure?
>
>
> >
> > 3) Confirmation that Maven can meet some very simple requirements I laid
> > out.
> >
> > Instead I hear excuses and borderline personal attacks (which I know
> > Brandon doesn't really mean, but it's still a shitty way to debate). Come
> > on guys. You're doing a piss poor job of making your case for Maven with
> > that approach.
> >
>
> I'll be honest here, no winks. You tone here is very aggressive. If you
> want to keep it civil you should put some winkies in there.
>
>
> >
> > Don't argue. Look at what the current build does. Do it with Maven
> > cleanly, and while meeting all of those simple requirements -- and you've
> > won your case.
> >
>
> I'm not arguing I'm providing information. As I stated before in my
> initial email. We had provided a build for maven on the current ibatis.
> There were some issues that we felt needed to be resolved. I'm pretty sure
> they have been resolved. But, we have to give it a go. Additionally, it
> would be good to have the folder structures conform to the maven
> specification. I would like to see this in place before we endeavor to write
> a pom and assembly for it.
>
> Brandon
>
>
> >
> > Clinton
> >
> >
> > On Wed, May 7, 2008 at 8:21 AM, Brandon Goodin <br...@gmail.com>
> > wrote:
> >
> > > Thanks for sharing your passions. My thoughts are below...
> > >
> > > #1...
> > >
> > > A. one "click" has never been a problem for maven. There seems to be a
> > > lot of insinuation that maven requires a lot of config files. I'm not sure
> > > where you are getting this. The only thing that we might need to do is break
> > > out the assembly config. But, that is because it is about packaging
> > > artifacts all together and not about building the individual jars. So, if
> > > you are saying we can't have an assembly config then gimme a break. Your
> > > request is denied because it requires something that is not possible and is
> > > not possible for a rational and organized reason.
> > >
> > > B. offline build... never been an issue for maven. So long as you have
> > > the needed jars locally. But this is true of any codebase.
> > >
> > > C. Are you referring to the final zipe file structure or the source
> > > tree. If you are referring to the source tree. You will be denied on that
> > > one as well because maven doesn't have dependencies in the local source
> > > tree. If you are talking about the final packaged output... we already
> > > demonstrated that with the current ibatis maven build.
> > >
> > > D. HTML Test Reports - Been possible for a long time
> > >
> > > E. Coverage Reports - Been possible for a long time
> > >
> > > F. Exploded Distributions - Not sure of what you are referring to
> > > here. If you are referring to seeing the final product of the zip file
> > > before it is zipped then that is just a matter of copying all the sources to
> > > a folder in the assembly config. We demonstrated that with the current maven
> > > build in ibatis.
> > >
> > > G. Zipped Distro - No problem
> > >
> > > H. I don't think this is necessary. We can look into adding the build
> > > number to the META-INF. But, this should be possible.
> > >
> > > #2 - Getting up and going in my IDE is a snap because of current IDE
> > > integration. Less than a minute. With Ant. I always have to checkout the
> > > project figure out what the heck people are doing in their ant script
> > > because EVERYONE does something different. Ramp up time sucks. I always
> > > enjoy how people will blend build artifacts with static artifacts. Can't
> > > simply delete the output folder. You always have to make sure you use their
> > > custom wacky ant scripts and hope you don't call the wrong task.
> > >
> > > #3 - See #2
> > >
> > >
> > > "I'm for simplicity over all else. No Ant isn't the best example of a
> > > build tool in history. But it's simple and it works." I am too. That is why
> > > i use maven :D I got tired of trying to figure out everyone's wacky Ant
> > > scripts.
> > >
> > > I think you need to take your blood pressure medicine. ;-) Maven is an
> > > acceptable build system. Instead of coming out with aggressive posturing,
> > > give your fellow developers the benefit of the doubt. Do you think we would
> > > use it if we thought it was a horrid pile of crap? Everything comes with
> > > it's strengths and weaknesses. I'll take the lack of a build number on the
> > > zip and jar any day over the amount of effort i expel trying to figure out
> > > ant scripts.
> > >
> > > Brandon
> > >
> > >
> > > On Wed, May 7, 2008 at 8:36 AM, Clinton Begin <cl...@gmail.com>
> > > wrote:
> > >
> > > > I currently hate Maven with a grand passion. But, I'm open minded
> > > > and am willing to be educated as to why people like it. I will make the
> > > > same offer I made before:
> > > >
> > > > Three requirements:
> > > >
> > > > #1 Create a maven build system for iBATIS that achieves the exact
> > > > same output, which includes:
> > > > - one "click" build -- I'm not exaggerating here, SVN checkout,
> > > > run ant or script...done. NOTHING else.. no config files, no nothing.
> > >
> > > - offline build -- no network connection required (perhaps after
> > > one build if it needs to grab dependencies initially)
> > >
> > > > - echo arbitrary information to the command line, such as
> > > > classpath in use and current version being built
> > > > - all dependencies must be versioned and organized into
> > > > developer dependencies (/devlib) and runtime/deploy dependencies (/lib)
> > > > - HTML test reports
> > > > - HTML coverage reports
> > > > - exploded distribution
> > > > - zipped distr
> > > > - version number stamped on ibatis JAR file(s) as well as the
> > > > zip distro
> > > > - all achieved by Ant today.
> > > >
> > > > #2 Show that it's simpler than Ant in at least one way. For
> > > > example:
> > > > - less XML configuration
> > > > - fewer requirements
> > > > - smaller overall source base size
> > > > - more/better compatibility with tools/frameworks/IDEs
> > > > - the current Ant build is 258 lines and integrates and runs
> > > > from any IDE
> > > >
> > > > #3 Show that it does something Ant doesn't. For example:
> > > > - Signs, MD5, and Uploads to Apache dist (with no additional
> > > > dependencies or configuration)
> > > > - ....
> > > >
> > > > I don't think these are unreasonable requirements. In fact if even
> > > > one is missed, it would make me wonder why the hell we'd even bother.
> > > >
> > > > I'm for simplicity over all else. No Ant isn't the best example of
> > > > a build tool in history. But it's simple and it works.
> > > >
> > > > Clinton
> > > >
> > > >
> > > > On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <
> > > > nathan.maves@gmail.com> wrote:
> > > >
> > > > > Brandon reply below.....
> > > > >
> > > > > I am completely for using Maven 2 and conforming our source tree
> > > > > to it. There were three issues, iirc, that (if they have not been fixed by
> > > > > the maven crew) will require a bit of compromise or plugin writing.
> > > > >
> > > > > #1 A serial number generator for builds does not easily exist for
> > > > > maven. We had talked about using the svn repo revision number.
> > > > > #2 We tried finding a way to add a date to our deployment zip
> > > > > file. Unfortunately maven did not provide an easy way to access a current
> > > > > date anywhere.
> > > > > #3 There have been issues with the coverage tools combining with
> > > > > the unit test tools. If we ran the unit tests, coverage tests, and also
> > > > > generated reports, the tests would wind up running 3 times.
> > > > >
> > > > > That being said, I think we should tackle these issues and make
> > > > > Maven our build tool. Maven has excellent IDE integration now (IDEA and
> > > > > Netbeans are both good). It makes it a snap to setup projects and get
> > > > > running. Additionally, the Apache nerds have some maven processes that can
> > > > > help us to more easily release software in accordance with Apache
> > > > > requirements.
> > > > >
> > > > > Brandon
> > > > >
> > > > > On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <
> > > > > nathan.maves@gmail.com> wrote:
> > > > >
> > > > > > The ideas/requests/demands just keep coming...
> > > > > >
> > > > > > With a clean slate for IB3 I want to propose a few things. I
> > > > > > have been using Maven2 for a while now and even use it in my day to day
> > > > > > development. My first suggestion is to lay out the new source tree to map to
> > > > > > the maven2 style of convention over configuration. Even if we choose not to
> > > > > > use Maven as the build/deployment process it is the most logical and thought
> > > > > > out hierarchy that I have seen.
> > > > > >
> > > > > > On the topic of Maven2 I would like to nominate is as the
> > > > > > build/deployment process. Maven2 offers so many pre-built plugins for many
> > > > > > useful things from coverage reports to unit test results. If there is
> > > > > > something that Maven2 does not have I am sure we could write a quick plugin
> > > > > > to get it done. I have also been using a new CI tool with Maven2 (
> > > > > > https://hudson.dev.java.net/ ). Insanely easy to install and
> > > > > > configure. Just reads your pom file from maven and away you go. Like most
> > > > > > it can poll the svn repo for changes and make snapshots as we commit.
> > > > > >
> > > > > > Let me know what you guys think
> > > > > >
> > > > > > Nathan
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Code Hierarchy and Build Process
Posted by Brandon Goodin <br...@gmail.com>.
Comments are mixed in:
On Wed, May 7, 2008 at 10:38 AM, Clinton Begin <cl...@gmail.com>
wrote:
>
> I wasn't implying that Maven COULDN'T do anything.... I was just laying
> out what I would want to see from a maven build.
>
> >> So, if you are saying we can't have an assembly config then gimme a
> break.
>
> What I mean is that if I can't check it out and build without having to
> perform some developer level/local config then forget it.
>
This would entirely depend on what we are doing. I don't believe iBATIS
would ever require this unless we used a key for uploading artifacts to a
location. In that case you would need to add the configuration to your
settings.xml.
There is also the initial installation of maven. But, most people will be
installing ant as well to run any ant builds that we provide.
> >> I don't think this is necessary. We can look into adding the build
> number to the META-INF. But, this should be possible.
>
> Versions are important. The more clear we can be with our version number
> the better. I'd like it in the filename, because it helps people, including
> us. One of the reasons Java sucks these days is the lack of good version
> control of JAR files. The best we can do is put the version number in the
> name of the JAR file to help people know which version they're using. It
> also helps us on support lists... recall the days when people couldn't tell
> which version they were using because they copied it from somewhere else.
> META-INF is a good second best... but I hear this Maven thing is supposed to
> be good, so I'd expect it to be able to fill this simple requirement.
>
Fair enough. I didn't say it was impossible. I just said it wasn't necessary
to tack it onto everything.
> I'm already not impressed with the excuses. I laid out what I think are
> fairly simple requirements that any build system should support.
>
What excuses? I'm simply getting information and asking you to clarify your
requests. On top of that I'm stating where I don't agree with your
requirements.
>
> >> Getting up and going in my IDE
>
> I honestly don't want to mix the needs of the development tool with the
> build tool. The build is a separate entity. Furthermore, let's not mix the
> problems of other projects (which may very well be solved by Maven). iBATIS
> does not have the problem you describe. It's a well structured and
> organized directory. /devlib /lib /src /test...... there's no magic to it.
> I understand what you're saying, but iBATIS simply doesn't have the
> problem.
>
The beauty of this is that you get both. Can you say that about Ant? hint...
nope.
>
> >> I think you need to take your blood pressure medicine.
>
> Let's not get too immature about it. I'm being open minded and fair. I
> asked for very simple things that are achieved with a 260 line Ant file with
> 14 well described tasks. I've yet to see:
You're just a hater :D and you left of my wink from that quote.
>
>
> 1) A major problem or flaw pointed out with the iBATIS Ant build. I don't
> care about the general case of Maven vs. Ant and Project X -- what's wrong
> with the *iBATIS* build?
I still need to take the time to figure out the iBATIS ant build. I don't
need to do that with maven. I know what tasks to run in order to build it.
>
> 2) A major advantage to using Maven for iBATIS (other than the potentially
> easier one-time setup of the IDE -- neat, but one-time IDE config vs. daily
> build maintenance...)
Standard project layout is easy to get into and get going. A clearly defined
structure that leaves no question about where future artifacts go.
Unambiguous communication of required project structures is very important.
So, why not go with a common, well known, and documented structure?
>
> 3) Confirmation that Maven can meet some very simple requirements I laid
> out.
>
> Instead I hear excuses and borderline personal attacks (which I know
> Brandon doesn't really mean, but it's still a shitty way to debate). Come
> on guys. You're doing a piss poor job of making your case for Maven with
> that approach.
>
I'll be honest here, no winks. You tone here is very aggressive. If you want
to keep it civil you should put some winkies in there.
>
> Don't argue. Look at what the current build does. Do it with Maven
> cleanly, and while meeting all of those simple requirements -- and you've
> won your case.
>
I'm not arguing I'm providing information. As I stated before in my initial
email. We had provided a build for maven on the current ibatis. There were
some issues that we felt needed to be resolved. I'm pretty sure they have
been resolved. But, we have to give it a go. Additionally, it would be good
to have the folder structures conform to the maven specification. I would
like to see this in place before we endeavor to write a pom and assembly for
it.
Brandon
>
> Clinton
>
>
> On Wed, May 7, 2008 at 8:21 AM, Brandon Goodin <br...@gmail.com>
> wrote:
>
> > Thanks for sharing your passions. My thoughts are below...
> >
> > #1...
> >
> > A. one "click" has never been a problem for maven. There seems to be a
> > lot of insinuation that maven requires a lot of config files. I'm not sure
> > where you are getting this. The only thing that we might need to do is break
> > out the assembly config. But, that is because it is about packaging
> > artifacts all together and not about building the individual jars. So, if
> > you are saying we can't have an assembly config then gimme a break. Your
> > request is denied because it requires something that is not possible and is
> > not possible for a rational and organized reason.
> >
> > B. offline build... never been an issue for maven. So long as you have
> > the needed jars locally. But this is true of any codebase.
> >
> > C. Are you referring to the final zipe file structure or the source
> > tree. If you are referring to the source tree. You will be denied on that
> > one as well because maven doesn't have dependencies in the local source
> > tree. If you are talking about the final packaged output... we already
> > demonstrated that with the current ibatis maven build.
> >
> > D. HTML Test Reports - Been possible for a long time
> >
> > E. Coverage Reports - Been possible for a long time
> >
> > F. Exploded Distributions - Not sure of what you are referring to here.
> > If you are referring to seeing the final product of the zip file before it
> > is zipped then that is just a matter of copying all the sources to a folder
> > in the assembly config. We demonstrated that with the current maven build in
> > ibatis.
> >
> > G. Zipped Distro - No problem
> >
> > H. I don't think this is necessary. We can look into adding the build
> > number to the META-INF. But, this should be possible.
> >
> > #2 - Getting up and going in my IDE is a snap because of current IDE
> > integration. Less than a minute. With Ant. I always have to checkout the
> > project figure out what the heck people are doing in their ant script
> > because EVERYONE does something different. Ramp up time sucks. I always
> > enjoy how people will blend build artifacts with static artifacts. Can't
> > simply delete the output folder. You always have to make sure you use their
> > custom wacky ant scripts and hope you don't call the wrong task.
> >
> > #3 - See #2
> >
> >
> > "I'm for simplicity over all else. No Ant isn't the best example of a
> > build tool in history. But it's simple and it works." I am too. That is why
> > i use maven :D I got tired of trying to figure out everyone's wacky Ant
> > scripts.
> >
> > I think you need to take your blood pressure medicine. ;-) Maven is an
> > acceptable build system. Instead of coming out with aggressive posturing,
> > give your fellow developers the benefit of the doubt. Do you think we would
> > use it if we thought it was a horrid pile of crap? Everything comes with
> > it's strengths and weaknesses. I'll take the lack of a build number on the
> > zip and jar any day over the amount of effort i expel trying to figure out
> > ant scripts.
> >
> > Brandon
> >
> >
> > On Wed, May 7, 2008 at 8:36 AM, Clinton Begin <cl...@gmail.com>
> > wrote:
> >
> > > I currently hate Maven with a grand passion. But, I'm open minded and
> > > am willing to be educated as to why people like it. I will make the same
> > > offer I made before:
> > >
> > > Three requirements:
> > >
> > > #1 Create a maven build system for iBATIS that achieves the exact same
> > > output, which includes:
> > > - one "click" build -- I'm not exaggerating here, SVN checkout,
> > > run ant or script...done. NOTHING else.. no config files, no nothing.
> >
> > - offline build -- no network connection required (perhaps after
> > one build if it needs to grab dependencies initially)
> >
> > > - echo arbitrary information to the command line, such as
> > > classpath in use and current version being built
> > > - all dependencies must be versioned and organized into developer
> > > dependencies (/devlib) and runtime/deploy dependencies (/lib)
> > > - HTML test reports
> > > - HTML coverage reports
> > > - exploded distribution
> > > - zipped distr
> > > - version number stamped on ibatis JAR file(s) as well as the zip
> > > distro
> > > - all achieved by Ant today.
> > >
> > > #2 Show that it's simpler than Ant in at least one way. For example:
> > > - less XML configuration
> > > - fewer requirements
> > > - smaller overall source base size
> > > - more/better compatibility with tools/frameworks/IDEs
> > > - the current Ant build is 258 lines and integrates and runs from
> > > any IDE
> > >
> > > #3 Show that it does something Ant doesn't. For example:
> > > - Signs, MD5, and Uploads to Apache dist (with no additional
> > > dependencies or configuration)
> > > - ....
> > >
> > > I don't think these are unreasonable requirements. In fact if even
> > > one is missed, it would make me wonder why the hell we'd even bother.
> > >
> > > I'm for simplicity over all else. No Ant isn't the best example of a
> > > build tool in history. But it's simple and it works.
> > >
> > > Clinton
> > >
> > >
> > > On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <na...@gmail.com>
> > > wrote:
> > >
> > > > Brandon reply below.....
> > > >
> > > > I am completely for using Maven 2 and conforming our source tree to
> > > > it. There were three issues, iirc, that (if they have not been fixed by the
> > > > maven crew) will require a bit of compromise or plugin writing.
> > > >
> > > > #1 A serial number generator for builds does not easily exist for
> > > > maven. We had talked about using the svn repo revision number.
> > > > #2 We tried finding a way to add a date to our deployment zip file.
> > > > Unfortunately maven did not provide an easy way to access a current date
> > > > anywhere.
> > > > #3 There have been issues with the coverage tools combining with the
> > > > unit test tools. If we ran the unit tests, coverage tests, and also
> > > > generated reports, the tests would wind up running 3 times.
> > > >
> > > > That being said, I think we should tackle these issues and make
> > > > Maven our build tool. Maven has excellent IDE integration now (IDEA and
> > > > Netbeans are both good). It makes it a snap to setup projects and get
> > > > running. Additionally, the Apache nerds have some maven processes that can
> > > > help us to more easily release software in accordance with Apache
> > > > requirements.
> > > >
> > > > Brandon
> > > >
> > > > On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <
> > > > nathan.maves@gmail.com> wrote:
> > > >
> > > > > The ideas/requests/demands just keep coming...
> > > > >
> > > > > With a clean slate for IB3 I want to propose a few things. I have
> > > > > been using Maven2 for a while now and even use it in my day to day
> > > > > development. My first suggestion is to lay out the new source tree to map to
> > > > > the maven2 style of convention over configuration. Even if we choose not to
> > > > > use Maven as the build/deployment process it is the most logical and thought
> > > > > out hierarchy that I have seen.
> > > > >
> > > > > On the topic of Maven2 I would like to nominate is as the
> > > > > build/deployment process. Maven2 offers so many pre-built plugins for many
> > > > > useful things from coverage reports to unit test results. If there is
> > > > > something that Maven2 does not have I am sure we could write a quick plugin
> > > > > to get it done. I have also been using a new CI tool with Maven2 (
> > > > > https://hudson.dev.java.net/ ). Insanely easy to install and
> > > > > configure. Just reads your pom file from maven and away you go. Like most
> > > > > it can poll the svn repo for changes and make snapshots as we commit.
> > > > >
> > > > > Let me know what you guys think
> > > > >
> > > > > Nathan
> > > >
> > > >
> > > >
> > >
> >
>
Re: Code Hierarchy and Build Process
Posted by Clinton Begin <cl...@gmail.com>.
I wasn't implying that Maven COULDN'T do anything.... I was just laying out
what I would want to see from a maven build.
>> So, if you are saying we can't have an assembly config then gimme a
break.
What I mean is that if I can't check it out and build without having to
perform some developer level/local config then forget it.
>> I don't think this is necessary. We can look into adding the build number
to the META-INF. But, this should be possible.
Versions are important. The more clear we can be with our version number
the better. I'd like it in the filename, because it helps people, including
us. One of the reasons Java sucks these days is the lack of good version
control of JAR files. The best we can do is put the version number in the
name of the JAR file to help people know which version they're using. It
also helps us on support lists... recall the days when people couldn't tell
which version they were using because they copied it from somewhere else.
META-INF is a good second best... but I hear this Maven thing is supposed to
be good, so I'd expect it to be able to fill this simple requirement.
I'm already not impressed with the excuses. I laid out what I think are
fairly simple requirements that any build system should support.
>> Getting up and going in my IDE
I honestly don't want to mix the needs of the development tool with the
build tool. The build is a separate entity. Furthermore, let's not mix the
problems of other projects (which may very well be solved by Maven). iBATIS
does not have the problem you describe. It's a well structured and
organized directory. /devlib /lib /src /test...... there's no magic to it.
I understand what you're saying, but iBATIS simply doesn't have the
problem.
>> I think you need to take your blood pressure medicine.
Let's not get too immature about it. I'm being open minded and fair. I
asked for very simple things that are achieved with a 260 line Ant file with
14 well described tasks. I've yet to see:
1) A major problem or flaw pointed out with the iBATIS Ant build. I don't
care about the general case of Maven vs. Ant and Project X -- what's wrong
with the *iBATIS* build?
2) A major advantage to using Maven for iBATIS (other than the potentially
easier one-time setup of the IDE -- neat, but one-time IDE config vs. daily
build maintenance...)
3) Confirmation that Maven can meet some very simple requirements I laid
out.
Instead I hear excuses and borderline personal attacks (which I know Brandon
doesn't really mean, but it's still a shitty way to debate). Come on
guys. You're doing a piss poor job of making your case for Maven with that
approach.
Don't argue. Look at what the current build does. Do it with Maven
cleanly, and while meeting all of those simple requirements -- and you've
won your case.
Clinton
On Wed, May 7, 2008 at 8:21 AM, Brandon Goodin <br...@gmail.com>
wrote:
> Thanks for sharing your passions. My thoughts are below...
>
> #1...
>
> A. one "click" has never been a problem for maven. There seems to be a lot
> of insinuation that maven requires a lot of config files. I'm not sure where
> you are getting this. The only thing that we might need to do is break out
> the assembly config. But, that is because it is about packaging artifacts
> all together and not about building the individual jars. So, if you are
> saying we can't have an assembly config then gimme a break. Your request is
> denied because it requires something that is not possible and is not
> possible for a rational and organized reason.
>
> B. offline build... never been an issue for maven. So long as you have the
> needed jars locally. But this is true of any codebase.
>
> C. Are you referring to the final zipe file structure or the source tree.
> If you are referring to the source tree. You will be denied on that one as
> well because maven doesn't have dependencies in the local source tree. If
> you are talking about the final packaged output... we already demonstrated
> that with the current ibatis maven build.
>
> D. HTML Test Reports - Been possible for a long time
>
> E. Coverage Reports - Been possible for a long time
>
> F. Exploded Distributions - Not sure of what you are referring to here. If
> you are referring to seeing the final product of the zip file before it is
> zipped then that is just a matter of copying all the sources to a folder in
> the assembly config. We demonstrated that with the current maven build in
> ibatis.
>
> G. Zipped Distro - No problem
>
> H. I don't think this is necessary. We can look into adding the build
> number to the META-INF. But, this should be possible.
>
> #2 - Getting up and going in my IDE is a snap because of current IDE
> integration. Less than a minute. With Ant. I always have to checkout the
> project figure out what the heck people are doing in their ant script
> because EVERYONE does something different. Ramp up time sucks. I always
> enjoy how people will blend build artifacts with static artifacts. Can't
> simply delete the output folder. You always have to make sure you use their
> custom wacky ant scripts and hope you don't call the wrong task.
>
> #3 - See #2
>
>
> "I'm for simplicity over all else. No Ant isn't the best example of a
> build tool in history. But it's simple and it works." I am too. That is why
> i use maven :D I got tired of trying to figure out everyone's wacky Ant
> scripts.
>
> I think you need to take your blood pressure medicine. ;-) Maven is an
> acceptable build system. Instead of coming out with aggressive posturing,
> give your fellow developers the benefit of the doubt. Do you think we would
> use it if we thought it was a horrid pile of crap? Everything comes with
> it's strengths and weaknesses. I'll take the lack of a build number on the
> zip and jar any day over the amount of effort i expel trying to figure out
> ant scripts.
>
> Brandon
>
>
> On Wed, May 7, 2008 at 8:36 AM, Clinton Begin <cl...@gmail.com>
> wrote:
>
> > I currently hate Maven with a grand passion. But, I'm open minded and
> > am willing to be educated as to why people like it. I will make the same
> > offer I made before:
> >
> > Three requirements:
> >
> > #1 Create a maven build system for iBATIS that achieves the exact same
> > output, which includes:
> > - one "click" build -- I'm not exaggerating here, SVN checkout, run
> > ant or script...done. NOTHING else.. no config files, no nothing.
>
> - offline build -- no network connection required (perhaps after one
> build if it needs to grab dependencies initially)
>
> > - echo arbitrary information to the command line, such as classpath
> > in use and current version being built
> > - all dependencies must be versioned and organized into developer
> > dependencies (/devlib) and runtime/deploy dependencies (/lib)
> > - HTML test reports
> > - HTML coverage reports
> > - exploded distribution
> > - zipped distr
> > - version number stamped on ibatis JAR file(s) as well as the zip
> > distro
> > - all achieved by Ant today.
> >
> > #2 Show that it's simpler than Ant in at least one way. For example:
> > - less XML configuration
> > - fewer requirements
> > - smaller overall source base size
> > - more/better compatibility with tools/frameworks/IDEs
> > - the current Ant build is 258 lines and integrates and runs from
> > any IDE
> >
> > #3 Show that it does something Ant doesn't. For example:
> > - Signs, MD5, and Uploads to Apache dist (with no additional
> > dependencies or configuration)
> > - ....
> >
> > I don't think these are unreasonable requirements. In fact if even one
> > is missed, it would make me wonder why the hell we'd even bother.
> >
> > I'm for simplicity over all else. No Ant isn't the best example of a
> > build tool in history. But it's simple and it works.
> >
> > Clinton
> >
> >
> > On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <na...@gmail.com>
> > wrote:
> >
> > > Brandon reply below.....
> > >
> > > I am completely for using Maven 2 and conforming our source tree to
> > > it. There were three issues, iirc, that (if they have not been fixed by the
> > > maven crew) will require a bit of compromise or plugin writing.
> > >
> > > #1 A serial number generator for builds does not easily exist for
> > > maven. We had talked about using the svn repo revision number.
> > > #2 We tried finding a way to add a date to our deployment zip file.
> > > Unfortunately maven did not provide an easy way to access a current date
> > > anywhere.
> > > #3 There have been issues with the coverage tools combining with the
> > > unit test tools. If we ran the unit tests, coverage tests, and also
> > > generated reports, the tests would wind up running 3 times.
> > >
> > > That being said, I think we should tackle these issues and make Maven
> > > our build tool. Maven has excellent IDE integration now (IDEA and Netbeans
> > > are both good). It makes it a snap to setup projects and get running.
> > > Additionally, the Apache nerds have some maven processes that can help us to
> > > more easily release software in accordance with Apache requirements.
> > >
> > > Brandon
> > >
> > > On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <na...@gmail.com>
> > > wrote:
> > >
> > > > The ideas/requests/demands just keep coming...
> > > >
> > > > With a clean slate for IB3 I want to propose a few things. I have
> > > > been using Maven2 for a while now and even use it in my day to day
> > > > development. My first suggestion is to lay out the new source tree to map to
> > > > the maven2 style of convention over configuration. Even if we choose not to
> > > > use Maven as the build/deployment process it is the most logical and thought
> > > > out hierarchy that I have seen.
> > > >
> > > > On the topic of Maven2 I would like to nominate is as the
> > > > build/deployment process. Maven2 offers so many pre-built plugins for many
> > > > useful things from coverage reports to unit test results. If there is
> > > > something that Maven2 does not have I am sure we could write a quick plugin
> > > > to get it done. I have also been using a new CI tool with Maven2 (
> > > > https://hudson.dev.java.net/ ). Insanely easy to install and
> > > > configure. Just reads your pom file from maven and away you go. Like most
> > > > it can poll the svn repo for changes and make snapshots as we commit.
> > > >
> > > > Let me know what you guys think
> > > >
> > > > Nathan
> > >
> > >
> > >
> >
>
Re: Code Hierarchy and Build Process
Posted by Brandon Goodin <br...@gmail.com>.
Thanks for sharing your passions. My thoughts are below...
#1...
A. one "click" has never been a problem for maven. There seems to be a lot
of insinuation that maven requires a lot of config files. I'm not sure where
you are getting this. The only thing that we might need to do is break out
the assembly config. But, that is because it is about packaging artifacts
all together and not about building the individual jars. So, if you are
saying we can't have an assembly config then gimme a break. Your request is
denied because it requires something that is not possible and is not
possible for a rational and organized reason.
B. offline build... never been an issue for maven. So long as you have the
needed jars locally. But this is true of any codebase.
C. Are you referring to the final zipe file structure or the source tree. If
you are referring to the source tree. You will be denied on that one as well
because maven doesn't have dependencies in the local source tree. If you are
talking about the final packaged output... we already demonstrated that with
the current ibatis maven build.
D. HTML Test Reports - Been possible for a long time
E. Coverage Reports - Been possible for a long time
F. Exploded Distributions - Not sure of what you are referring to here. If
you are referring to seeing the final product of the zip file before it is
zipped then that is just a matter of copying all the sources to a folder in
the assembly config. We demonstrated that with the current maven build in
ibatis.
G. Zipped Distro - No problem
H. I don't think this is necessary. We can look into adding the build number
to the META-INF. But, this should be possible.
#2 - Getting up and going in my IDE is a snap because of current IDE
integration. Less than a minute. With Ant. I always have to checkout the
project figure out what the heck people are doing in their ant script
because EVERYONE does something different. Ramp up time sucks. I always
enjoy how people will blend build artifacts with static artifacts. Can't
simply delete the output folder. You always have to make sure you use their
custom wacky ant scripts and hope you don't call the wrong task.
#3 - See #2
"I'm for simplicity over all else. No Ant isn't the best example of a build
tool in history. But it's simple and it works." I am too. That is why i use
maven :D I got tired of trying to figure out everyone's wacky Ant scripts.
I think you need to take your blood pressure medicine. ;-) Maven is an
acceptable build system. Instead of coming out with aggressive posturing,
give your fellow developers the benefit of the doubt. Do you think we would
use it if we thought it was a horrid pile of crap? Everything comes with
it's strengths and weaknesses. I'll take the lack of a build number on the
zip and jar any day over the amount of effort i expel trying to figure out
ant scripts.
Brandon
On Wed, May 7, 2008 at 8:36 AM, Clinton Begin <cl...@gmail.com>
wrote:
> I currently hate Maven with a grand passion. But, I'm open minded and am
> willing to be educated as to why people like it. I will make the same offer
> I made before:
>
> Three requirements:
>
> #1 Create a maven build system for iBATIS that achieves the exact same
> output, which includes:
> - one "click" build -- I'm not exaggerating here, SVN checkout, run
> ant or script...done. NOTHING else.. no config files, no nothing.
- offline build -- no network connection required (perhaps after one
build if it needs to grab dependencies initially)
> - echo arbitrary information to the command line, such as classpath in
> use and current version being built
> - all dependencies must be versioned and organized into developer
> dependencies (/devlib) and runtime/deploy dependencies (/lib)
> - HTML test reports
> - HTML coverage reports
> - exploded distribution
> - zipped distr
> - version number stamped on ibatis JAR file(s) as well as the zip
> distro
> - all achieved by Ant today.
>
> #2 Show that it's simpler than Ant in at least one way. For example:
> - less XML configuration
> - fewer requirements
> - smaller overall source base size
> - more/better compatibility with tools/frameworks/IDEs
> - the current Ant build is 258 lines and integrates and runs from any
> IDE
>
> #3 Show that it does something Ant doesn't. For example:
> - Signs, MD5, and Uploads to Apache dist (with no additional
> dependencies or configuration)
> - ....
>
> I don't think these are unreasonable requirements. In fact if even one is
> missed, it would make me wonder why the hell we'd even bother.
>
> I'm for simplicity over all else. No Ant isn't the best example of a
> build tool in history. But it's simple and it works.
>
> Clinton
>
>
> On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <na...@gmail.com>
> wrote:
>
> > Brandon reply below.....
> >
> > I am completely for using Maven 2 and conforming our source tree to it.
> > There were three issues, iirc, that (if they have not been fixed by the
> > maven crew) will require a bit of compromise or plugin writing.
> >
> > #1 A serial number generator for builds does not easily exist for maven.
> > We had talked about using the svn repo revision number.
> > #2 We tried finding a way to add a date to our deployment zip file.
> > Unfortunately maven did not provide an easy way to access a current date
> > anywhere.
> > #3 There have been issues with the coverage tools combining with the
> > unit test tools. If we ran the unit tests, coverage tests, and also
> > generated reports, the tests would wind up running 3 times.
> >
> > That being said, I think we should tackle these issues and make Maven
> > our build tool. Maven has excellent IDE integration now (IDEA and Netbeans
> > are both good). It makes it a snap to setup projects and get running.
> > Additionally, the Apache nerds have some maven processes that can help us to
> > more easily release software in accordance with Apache requirements.
> >
> > Brandon
> >
> > On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <na...@gmail.com>
> > wrote:
> >
> > > The ideas/requests/demands just keep coming...
> > >
> > > With a clean slate for IB3 I want to propose a few things. I have
> > > been using Maven2 for a while now and even use it in my day to day
> > > development. My first suggestion is to lay out the new source tree to map to
> > > the maven2 style of convention over configuration. Even if we choose not to
> > > use Maven as the build/deployment process it is the most logical and thought
> > > out hierarchy that I have seen.
> > >
> > > On the topic of Maven2 I would like to nominate is as the
> > > build/deployment process. Maven2 offers so many pre-built plugins for many
> > > useful things from coverage reports to unit test results. If there is
> > > something that Maven2 does not have I am sure we could write a quick plugin
> > > to get it done. I have also been using a new CI tool with Maven2 (
> > > https://hudson.dev.java.net/ ). Insanely easy to install and
> > > configure. Just reads your pom file from maven and away you go. Like most
> > > it can poll the svn repo for changes and make snapshots as we commit.
> > >
> > > Let me know what you guys think
> > >
> > > Nathan
> >
> >
> >
>
Re: Code Hierarchy and Build Process
Posted by Clinton Begin <cl...@gmail.com>.
I currently hate Maven with a grand passion. But, I'm open minded and am
willing to be educated as to why people like it. I will make the same offer
I made before:
Three requirements:
#1 Create a maven build system for iBATIS that achieves the exact same
output, which includes:
- one "click" build -- I'm not exaggerating here, SVN checkout, run ant
or script...done. NOTHING else.. no config files, no nothing.
- offline build -- no network connection required (perhaps after one
build if it needs to grab dependencies initially)
- echo arbitrary information to the command line, such as classpath in
use and current version being built
- all dependencies must be versioned and organized into developer
dependencies (/devlib) and runtime/deploy dependencies (/lib)
- HTML test reports
- HTML coverage reports
- exploded distribution
- zipped distr
- version number stamped on ibatis JAR file(s) as well as the zip distro
- all achieved by Ant today.
#2 Show that it's simpler than Ant in at least one way. For example:
- less XML configuration
- fewer requirements
- smaller overall source base size
- more/better compatibility with tools/frameworks/IDEs
- the current Ant build is 258 lines and integrates and runs from any
IDE
#3 Show that it does something Ant doesn't. For example:
- Signs, MD5, and Uploads to Apache dist (with no additional
dependencies or configuration)
- ....
I don't think these are unreasonable requirements. In fact if even one is
missed, it would make me wonder why the hell we'd even bother.
I'm for simplicity over all else. No Ant isn't the best example of a build
tool in history. But it's simple and it works.
Clinton
On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <na...@gmail.com>
wrote:
> Brandon reply below.....
>
> I am completely for using Maven 2 and conforming our source tree to it.
> There were three issues, iirc, that (if they have not been fixed by the
> maven crew) will require a bit of compromise or plugin writing.
>
> #1 A serial number generator for builds does not easily exist for maven.
> We had talked about using the svn repo revision number.
> #2 We tried finding a way to add a date to our deployment zip file.
> Unfortunately maven did not provide an easy way to access a current date
> anywhere.
> #3 There have been issues with the coverage tools combining with the unit
> test tools. If we ran the unit tests, coverage tests, and also generated
> reports, the tests would wind up running 3 times.
>
> That being said, I think we should tackle these issues and make Maven our
> build tool. Maven has excellent IDE integration now (IDEA and Netbeans are
> both good). It makes it a snap to setup projects and get running.
> Additionally, the Apache nerds have some maven processes that can help us to
> more easily release software in accordance with Apache requirements.
>
> Brandon
>
> On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <na...@gmail.com>
> wrote:
>
> > The ideas/requests/demands just keep coming...
> >
> > With a clean slate for IB3 I want to propose a few things. I have been
> > using Maven2 for a while now and even use it in my day to day development.
> > My first suggestion is to lay out the new source tree to map to the maven2
> > style of convention over configuration. Even if we choose not to use Maven
> > as the build/deployment process it is the most logical and thought out
> > hierarchy that I have seen.
> >
> > On the topic of Maven2 I would like to nominate is as the
> > build/deployment process. Maven2 offers so many pre-built plugins for many
> > useful things from coverage reports to unit test results. If there is
> > something that Maven2 does not have I am sure we could write a quick plugin
> > to get it done. I have also been using a new CI tool with Maven2 (
> > https://hudson.dev.java.net/ ). Insanely easy to install and
> > configure. Just reads your pom file from maven and away you go. Like most
> > it can poll the svn repo for changes and make snapshots as we commit.
> >
> > Let me know what you guys think
> >
> > Nathan
>
>
>
Re: Code Hierarchy and Build Process
Posted by Clinton Begin <cl...@gmail.com>.
>> A serial number generator for builds does not easily exist for maven. We
had talked about using the svn repo revision number.
SVN repo number would be great. It's a little long because it's Apache's
global repos, but it would be more useful than the somewhat meaningless
build number we have now. This would be an improvement. The caveat would
be that a build would always have to be done against an unmodified working
copy with means one of two things: svn status must return no changes before
the distro build, or the distro build always has to checkout a clean copy
from SVN.
>> We tried finding a way to add a date to our deployment zip file.
Unfortunately maven did not provide an easy way to access a current date
anywhere.
No need for the date on the zip file, just the Major.minor.bug-build
numbers.
>> There have been issues with the coverage tools combining with the unit
test tools. If we ran the unit tests, coverage tests, and also generated
reports, the tests would wind up running 3 times.
Ewww.... I'm sure there must be a way around that. Sounds like something
the rest of the world would complain about too.
Clinton
On Tue, May 6, 2008 at 10:35 PM, Nathan Maves <na...@gmail.com>
wrote:
> Brandon reply below.....
>
> I am completely for using Maven 2 and conforming our source tree to it.
> There were three issues, iirc, that (if they have not been fixed by the
> maven crew) will require a bit of compromise or plugin writing.
>
> #1 A serial number generator for builds does not easily exist for maven.
> We had talked about using the svn repo revision number.
> #2 We tried finding a way to add a date to our deployment zip file.
> Unfortunately maven did not provide an easy way to access a current date
> anywhere.
> #3 There have been issues with the coverage tools combining with the unit
> test tools. If we ran the unit tests, coverage tests, and also generated
> reports, the tests would wind up running 3 times.
>
> That being said, I think we should tackle these issues and make Maven our
> build tool. Maven has excellent IDE integration now (IDEA and Netbeans are
> both good). It makes it a snap to setup projects and get running.
> Additionally, the Apache nerds have some maven processes that can help us to
> more easily release software in accordance with Apache requirements.
>
> Brandon
>
> On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <na...@gmail.com>
> wrote:
>
> > The ideas/requests/demands just keep coming...
> >
> > With a clean slate for IB3 I want to propose a few things. I have been
> > using Maven2 for a while now and even use it in my day to day development.
> > My first suggestion is to lay out the new source tree to map to the maven2
> > style of convention over configuration. Even if we choose not to use Maven
> > as the build/deployment process it is the most logical and thought out
> > hierarchy that I have seen.
> >
> > On the topic of Maven2 I would like to nominate is as the
> > build/deployment process. Maven2 offers so many pre-built plugins for many
> > useful things from coverage reports to unit test results. If there is
> > something that Maven2 does not have I am sure we could write a quick plugin
> > to get it done. I have also been using a new CI tool with Maven2 (
> > https://hudson.dev.java.net/ ). Insanely easy to install and
> > configure. Just reads your pom file from maven and away you go. Like most
> > it can poll the svn repo for changes and make snapshots as we commit.
> >
> > Let me know what you guys think
> >
> > Nathan
>
>
>
Re: Code Hierarchy and Build Process
Posted by Nathan Maves <na...@gmail.com>.
Brandon reply below.....
I am completely for using Maven 2 and conforming our source tree to it.
There were three issues, iirc, that (if they have not been fixed by the
maven crew) will require a bit of compromise or plugin writing.
#1 A serial number generator for builds does not easily exist for maven. We
had talked about using the svn repo revision number.
#2 We tried finding a way to add a date to our deployment zip file.
Unfortunately maven did not provide an easy way to access a current date
anywhere.
#3 There have been issues with the coverage tools combining with the unit
test tools. If we ran the unit tests, coverage tests, and also generated
reports, the tests would wind up running 3 times.
That being said, I think we should tackle these issues and make Maven our
build tool. Maven has excellent IDE integration now (IDEA and Netbeans are
both good). It makes it a snap to setup projects and get running.
Additionally, the Apache nerds have some maven processes that can help us to
more easily release software in accordance with Apache requirements.
Brandon
On Tue, May 6, 2008 at 10:34 PM, Nathan Maves <na...@gmail.com>
wrote:
> The ideas/requests/demands just keep coming...
>
> With a clean slate for IB3 I want to propose a few things. I have been
> using Maven2 for a while now and even use it in my day to day development.
> My first suggestion is to lay out the new source tree to map to the maven2
> style of convention over configuration. Even if we choose not to use Maven
> as the build/deployment process it is the most logical and thought out
> hierarchy that I have seen.
>
> On the topic of Maven2 I would like to nominate is as the build/deployment
> process. Maven2 offers so many pre-built plugins for many useful things
> from coverage reports to unit test results. If there is something that
> Maven2 does not have I am sure we could write a quick plugin to get it
> done. I have also been using a new CI tool with Maven2 (
> https://hudson.dev.java.net/ ). Insanely easy to install and configure.
> Just reads your pom file from maven and away you go. Like most it can poll
> the svn repo for changes and make snapshots as we commit.
>
> Let me know what you guys think
>
> Nathan