More on build tools!

[Jason Nerothin]

Great podcast guys. 

Almost 45 minutes on build tools. I think I must have missed something that went unstated: Why was maven (more or less) ignored? Has the world just agreed that it's too [insert something I'm missing here] to even make the discussion?

I've become something of an expert lately. Enough so that I'm beginning to have my doubts. But I didn't hear any Really Good Alternatives.

JPN

[zentr...@yahoo.co.uk]

Good point. 

I'm slowly becoming a maven in maven and I really like the guy. 

m2e makes my life easier and when I saw this I was so so happy to learn you can do these things with just a maven plugin.

I'd like to hear more from people with more experience.

[Fabrizio Giudici]

On Wed, 25 Jul 2012 09:29:10 +0200, zentr...@yahoo.co.uk
<zentr...@yahoo.co.uk> wrote:

> Good point.
>

> I'm slowly becoming a maven in *maven *and I really like the guy.
> m2e makes my life easier and when I saw this <http://slidesha.re/ABZRx> I

> was so so happy to learn you can do these things with just a maven
> plugin.

There are many "these things" in the presentation... what are you
referring to? Automated deployment?



--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[zentr...@yahoo.co.uk]

you're right, sorry.

I was mainly thinking of Maven Release Plugin.

[Jan Goyvaerts]

Personally, I don't consider Maven to be too slow. Because however "slow" it is, it only does the whole build cycle when releasing, doing CI, ...

For development that doesn't matter because today's IDE are doing a lot to improve the speed. Even for Maven-based projects. And for Maven-based Scala projects Intellij's FSC (Fast Scala Compiler) makes it very agreeable to develop in Scala. It is as fast as for Java. It looks however like it's hacking with a dedicated process. But Intellij 12 should provide proper incremental compiler support. Hopefully also for Scala.

So, for me, it's Maven !

--

You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/z3iOjX8q87AJ.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Henrique M. Gontijo]

zentropa80

   Maven Release plugin really does a great job for release. Actually it's used for automated release and not for automated deployment.

Cheers,

- Henrique

[Carl of the Posse]

To respond to the original question: I think we didn't get into talking about Maven because I (and I think) Tor don't have much experience with it. Dick does, I know, but I guess he didn't have much to say about it.

I looked at it briefly when figuring out how to evolve our build system at Netflix, but rejected it as too disruptive. Our teams are very independent, and it would have been a difficult sell to some of them. It also seemed that trying to adapt or extend Maven in ways it didn't agree with would be an exercise in pain.

I instead opted for a gradual evolution of our ad-hoc Ant-based build files into a simple Ant framework with Ivy dependency management and lots of Groovy doing the hard work. Almost all projects have tiny build files that leverage the common framework. Now we are in a position and in the process of migrating to Gradle, which I think takes a better, more scalable approach to the build problem than Maven's do-it-my-way-or-suffer approach.

--carl

[Rakesh]

using Gradle and loving it.

Rakesh

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/PL7_zcRa1vYJ.

[Carlus Henry]

I really enjoyed the conversation regarding build tools...

I have been using Maven for a number of years now, and I have found that it is the build tool of choice for me.  I am a big fan of the declarative style of Maven as opposed to the imperative style of Ant.  Instead of focusing on tasks like "move this file here, and copy these resources there, and compile this code here and run this test there", it just works - and that is what I look for in a build tool.  Something that just works and doesn't get in the way.

I don't have any experience with Gradle, but I have lived through the horror days of Ant, and I will definitely not go back to that.  Now, I have to admit that there has been a time or two when I have had to resort to the Maven ant plugin in order to do something very unique (like delete the local database prior to running tests), but beyond that, I have been using a pure Maven approach and have found that it meets all of my needs.

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.

Happy Coding.

Carlus

[Fabrizio Giudici]

On Tue, 31 Jul 2012 03:39:53 +0200, Carlus Henry <carlu...@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...).

[Ricky Clarkson]

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.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.