I use maven in general, and SBT when on Scala-only projects. I see ant as legacy, and things that make ant prettier as lipstick on a pig.
Specifically, ant builds generally are harder to read and less likely to work in my experience than maven and SBT builds. I'm aware that you can use Ant with Ivy and do things in a better way than we did 10 years ago, but still when I come across a build.xml in my work I'm more likely to have upcoming problems than when I come across a pom.xml. I'd even rather see a build.sh than a build.xml Maven is frustrating on fresh machines, we probably have all seen it 'download the Internet' even to do mvn clean. But it's quick enough after that, and as long as you stick to its idea of one artifact per module it goes pretty smoothly. It also seems to give a lot more information to the IDE, meaning some/all IDE config can be skipped on a new project and people don't feel tempted to pollute version control with .project, .classpath, .settings, .idea, etc. SBT's complexity hasn't bitten me yet, but I'm ready for it. Despite what Dick said on the podcast it's not only Dick who doesn't like it. Its fast Scala compilation is being (has been?) ported to maven. As a side note, I wonder what programming styles lead to slow Scala compilation time. I'd imagine a lot of use of implicit conversions would cause that. I'd hope that implicit parameters don't, that sounds more like an O(1) lookup. On Tue, Jul 31, 2012 at 2:42 AM, Fabrizio Giudici < fabrizio.giud...@tidalwave.it> wrote: > On Tue, 31 Jul 2012 03:39:53 +0200, Carlus Henry <carlushe...@gmail.com> > wrote: > > > Perhaps it would be worth bringing on someone from Sonatype in order to >> discuss Maven as a build tool in Java projects. I would imagine that it >> would prove to be a very interesting conversation. >> > > I'm having a similar conversation about build tools in my JUG. The most > interesting people with discuss, in my opinion, are those who use the tools > in production. That is, us :-) > > I think that there's no winner, even ignoring bugs and specific pitfalls > of tools: unavoidably there's people that prefer a declarative approach, > like you and me, and people that prefer write scripts in some way. The > interesting point, in my opinion, is to challenge these approaches in > specific, real world cases. Which must also consider the level of the team > involved (skills, cohesion of the group, presence or absence of a leader, > etc...). > > > > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > fabrizio.giud...@tidalwave.it > http://tidalwave.it - http://fabriziogiudici.it > > -- > You received this message because you are subscribed to the Google Groups > "Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to javaposse+unsubscribe@** > googlegroups.com <javaposse%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/javaposse?hl=en <http://groups.google.com/group/javaposse?hl=en>. > > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
