Comments on: Buildr Still Not Ready for Prime Time http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time (permanently in beta) Sun, 29 Aug 2010 20:01:44 -0700 http://wordpress.org/?v=2.9.2 hourly 1 By: Daniel Spiewak http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3718 Daniel Spiewak Thu, 05 Jun 2008 18:35:58 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3718 To be honest, I know next-to-nothing about it. I've looked at their project page briefly, and it seemed interesting, but the syntax looked almost too heavy-weight for a proper build system. Even Buildr can be a bit too much at times. That was just my impression though, I'm sure there's a lot about it that I'm missing. To be honest, I know next-to-nothing about it. I’ve looked at their project page briefly, and it seemed interesting, but the syntax looked almost too heavy-weight for a proper build system. Even Buildr can be a bit too much at times. That was just my impression though, I’m sure there’s a lot about it that I’m missing.

]]> By: Ittay Dror http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3713 Ittay Dror Thu, 05 Jun 2008 10:53:06 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3713 Do you mind sharing your thoughts on Gradle? Do you mind sharing your thoughts on Gradle?

]]> By: Andrew Binstock http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3578 Andrew Binstock Mon, 12 May 2008 22:04:29 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3578 Gant and Gradle are two possibilities. They both use Groovy as the scripting language and they eschew XML. Gant is the build engine used by Grails, so it clearly works on large complex projects. Just a thought. Gant and Gradle are two possibilities. They both use Groovy as the scripting language and they eschew XML. Gant is the build engine used by Grails, so it clearly works on large complex projects. Just a thought.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3577 Daniel Spiewak Mon, 12 May 2008 22:02:10 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3577 While I agree that there are some cases were transitive dependencies can be a major pain / totally crippling, I still think that they are a *critical* feature for any dependency management system. They eliminate a lot of redundancy and make it much easier to work with major packages like Hibernate and Wicket. While I agree that there are some cases were transitive dependencies can be a major pain / totally crippling, I still think that they are a *critical* feature for any dependency management system. They eliminate a lot of redundancy and make it much easier to work with major packages like Hibernate and Wicket.

]]> By: Paul Brown http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3576 Paul Brown Mon, 12 May 2008 21:57:32 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3576 I can definitely see where your criticism of the feature comes from, seeing as it doesn't currently work well, but it's ironic because transitive dependencies are in many cases undesirable. The cleanliness and correctness of the POMs buried deep beneath the other POMs that you rely on can have undesirable effects, e.g., putting JUnit or three different versions of commons-logging in your web application... I can definitely see where your criticism of the feature comes from, seeing as it doesn’t currently work well, but it’s ironic because transitive dependencies are in many cases undesirable. The cleanliness and correctness of the POMs buried deep beneath the other POMs that you rely on can have undesirable effects, e.g., putting JUnit or three different versions of commons-logging in your web application…

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3575 Daniel Spiewak Mon, 12 May 2008 19:30:14 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3575 @Assaf I'm looking forward to it! 1.4 is going to be a great release. @Assaf

I’m looking forward to it! 1.4 is going to be a great release.

]]> By: Assaf http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3574 Assaf Mon, 12 May 2008 19:23:51 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3574 From what I could tell it would deal with SWF and SWC correctly, the problem is only with master POMs that a few (but pretty damn useful) projects use. Hopefully we'll fix that for the transitive method soon enough. Separately, watch the buildr-dev list. Looks like we have agreement on doing transitive dependencies rfor 1.4. From what I could tell it would deal with SWF and SWC correctly, the problem is only with master POMs that a few (but pretty damn useful) projects use. Hopefully we’ll fix that for the transitive method soon enough.

Separately, watch the buildr-dev list. Looks like we have agreement on doing transitive dependencies rfor 1.4.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3573 Daniel Spiewak Mon, 12 May 2008 15:49:52 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3573 Hmm, SWF artifacts might be a problem. You could actually reuse the same `pom_only` method since actually it's doing a generic mock of a JAR file. In fact, you would have to use this method on any artifact which does not contain a JAR, not just artifacts which are POM only. As an aside, I'm not sure that Buildr knows how to properly download SWF artifacts. It's fairly hacky right now, the way it parses the POM and figures out what to download. You may have to write some special logic for this above and beyond the workaround for JAR-less artifacts. Hmm, SWF artifacts might be a problem. You could actually reuse the same `pom_only` method since actually it’s doing a generic mock of a JAR file. In fact, you would have to use this method on any artifact which does not contain a JAR, not just artifacts which are POM only.

As an aside, I’m not sure that Buildr knows how to properly download SWF artifacts. It’s fairly hacky right now, the way it parses the POM and figures out what to download. You may have to write some special logic for this above and beyond the workaround for JAR-less artifacts.

]]> By: Tim O'Brien http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3572 Tim O'Brien Mon, 12 May 2008 15:09:29 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3572 What about stuff like SWF and SWC artifacts. Would I have to write a workaround that handles all the different types of dependencies I might want to retrieve from the remote repository? What about stuff like SWF and SWC artifacts. Would I have to write a workaround that handles all the different types of dependencies I might want to retrieve from the remote repository?

]]> By: Erik Tjernlund http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time/comment-page-1#comment-3571 Erik Tjernlund Mon, 12 May 2008 07:26:54 +0000 http://www.codecommit.com/blog/java/buildr-still-not-ready-for-prime-time#comment-3571 I like Schmant (http://www.schmant.org/) as a build tool. I like Schmant (http://www.schmant.org/) as a build tool.

]]>