Comments on: In Search of a Better Build System http://www.codecommit.com/blog/java/in-search-of-a-better-build-system (permanently in beta) Mon, 09 Jan 2012 20:21:24 -0800 http://wordpress.org/?v=2.9.2 hourly 1 By: Alexandre Bairos http://www.codecommit.com/blog/java/in-search-of-a-better-build-system/comment-page-1#comment-2624 Alexandre Bairos Thu, 03 Jan 2008 14:38:33 +0000 http://www.codecommit.com/blog/java/in-search-of-a-better-build-system#comment-2624 http://www.nabble.com/Project-Layouts-td14588782.html I didn 't test it. But Assaf announced the Project Layouts feature. http://www.nabble.com/Project-Layouts-td14588782.html

I didn ‘t test it. But Assaf announced the Project Layouts feature.

]]> By: Josh Rehman http://www.codecommit.com/blog/java/in-search-of-a-better-build-system/comment-page-1#comment-2583 Josh Rehman Sun, 16 Dec 2007 04:50:17 +0000 http://www.codecommit.com/blog/java/in-search-of-a-better-build-system#comment-2583 Nothing wrong with waiting until you need something before getting it. Just because many of our tools are "free software" doesn't mean that we 'infovores' shouldn't be wary of unchecked consumerism and greed! In fact we need to be even more careful of gorging because the barrier-to-consumption is so low. I wish you could be more specific in which ways you feel that Maven isn't maintaining focus. I've been reading about Maven, although haven't yet used it; I have a couple of strong developer friends who very much like Maven - they feel that the rigidity of the file structure is a small price to pay for the convenience the platform offers. And from the look of it, I tend to agree (although I have to say the 22-step build model is a bit intimidating!) WRT directory layout rigidity, there is something to be said for a one-size-fits all convention when it "doesn't really matter". Who cares where the directories are? If the world really agreed on suitable conventions our tools could nicely present our files to us however we like (and indeed, most IDEs can already do this). Nothing wrong with waiting until you need something before getting it. Just because many of our tools are “free software” doesn’t mean that we ‘infovores’ shouldn’t be wary of unchecked consumerism and greed! In fact we need to be even more careful of gorging because the barrier-to-consumption is so low.

I wish you could be more specific in which ways you feel that Maven isn’t maintaining focus. I’ve been reading about Maven, although haven’t yet used it; I have a couple of strong developer friends who very much like Maven – they feel that the rigidity of the file structure is a small price to pay for the convenience the platform offers. And from the look of it, I tend to agree (although I have to say the 22-step build model is a bit intimidating!)

WRT directory layout rigidity, there is something to be said for a one-size-fits all convention when it “doesn’t really matter”. Who cares where the directories are? If the world really agreed on suitable conventions our tools could nicely present our files to us however we like (and indeed, most IDEs can already do this).

]]> By: Daniel Spiewak http://www.codecommit.com/blog/java/in-search-of-a-better-build-system/comment-page-1#comment-2542 Daniel Spiewak Thu, 29 Nov 2007 16:46:17 +0000 http://www.codecommit.com/blog/java/in-search-of-a-better-build-system#comment-2542 @Dalibor A good point about the purpose for a build system. In this respect, I think automake does a much better job than many modern, java-specific build systems (showing its maturity). Unfortunately, most people (myself included) find automake fairly cryptic, not to mention inflexible in some areas such as build packaging and so on. apt-get build-deps is great for C/C++ apps, but it just doesn't cover everything with Java. There are so many third-party Java libraries, and a given application may use dozens of them. Obtaining them all in the correct version is a pain to say the least. To maven's credit, it does a good job in solving this problem...most of the time. The more obscure libraries are much harder to deal with in a Maven build. I'm sort-of looking forward to playing with Ivy/Ant to see how it holds up in this respect. @Dalibor

A good point about the purpose for a build system. In this respect, I think automake does a much better job than many modern, java-specific build systems (showing its maturity). Unfortunately, most people (myself included) find automake fairly cryptic, not to mention inflexible in some areas such as build packaging and so on.

apt-get build-deps is great for C/C++ apps, but it just doesn’t cover everything with Java. There are so many third-party Java libraries, and a given application may use dozens of them. Obtaining them all in the correct version is a pain to say the least. To maven’s credit, it does a good job in solving this problem…most of the time. The more obscure libraries are much harder to deal with in a Maven build. I’m sort-of looking forward to playing with Ivy/Ant to see how it holds up in this respect.

]]> By: Dalibor Topic http://www.codecommit.com/blog/java/in-search-of-a-better-build-system/comment-page-1#comment-2541 Dalibor Topic Thu, 29 Nov 2007 13:25:36 +0000 http://www.codecommit.com/blog/java/in-search-of-a-better-build-system#comment-2541 FWIW, I happily use Automake for my Java applications. It does the job, while getting out the way, and letting me concentrate on the code, rather than figuring out the build system. It's as primitive as make is, but it does the one job well that I care about from a build system: let me build/rebuild the code as I need it, while making it easy for others to repeat what I've done, and making it easy for me to ship source code tarballs letting them do that. It doesn't have dependency management, but that's what apt-get build-deps is for, without having to hack it into the build tool. It doesn't have explicit JUnit support, but since automake files are very similar to regular makefiles, just a lot simpler, it's trivial to make it run junit, or anything else without having to hack the build tool first. It does not have CI support, but there is no lack of CI tools like buildbot that take care of all that, without me having to hack the build tool to support it. I guess my point is that a good build system should do one thing well. That's entirely sufficient. FWIW, I happily use Automake for my Java applications. It does the job, while getting out the way, and letting me concentrate on the code, rather than figuring out the build system. It’s as primitive as make is, but it does the one job well that I care about from a build system: let me build/rebuild the code as I need it, while making it easy for others to repeat what I’ve done, and making it easy for me to ship source code tarballs letting them do that.

It doesn’t have dependency management, but that’s what apt-get build-deps is for, without having to hack it into the build tool. It doesn’t have explicit JUnit support, but since automake files are very similar to regular makefiles, just a lot simpler, it’s trivial to make it run junit, or anything else without having to hack the build tool first. It does not have CI support, but there is no lack of CI tools like buildbot that take care of all that, without me having to hack the build tool to support it.

I guess my point is that a good build system should do one thing well. That’s entirely sufficient.

]]> By: James Law http://www.codecommit.com/blog/java/in-search-of-a-better-build-system/comment-page-1#comment-2539 James Law Wed, 28 Nov 2007 22:10:30 +0000 http://www.codecommit.com/blog/java/in-search-of-a-better-build-system#comment-2539 Thanks. I've settled on 1. using ant for build/running tests 2. use maven for dependency management only, by using ant tasks that can pull out the maven dependencies- beyond that, maven never feels like I get the time I put into it back out. 3. use atlassian's cruise control : bamboo Looking forward to what the ant/ivy partnership may bring... Thanks.
I’ve settled on
1. using ant for build/running tests
2. use maven for dependency management only, by using ant tasks that can pull out the maven dependencies- beyond that, maven never feels like I get the time I put into it back out.
3. use atlassian’s cruise control : bamboo

Looking forward to what the ant/ivy partnership may bring…

]]> By: Ben Scherrey http://www.codecommit.com/blog/java/in-search-of-a-better-build-system/comment-page-1#comment-2529 Ben Scherrey Mon, 26 Nov 2007 15:01:25 +0000 http://www.codecommit.com/blog/java/in-search-of-a-better-build-system#comment-2529 Build systems require a LOT more than dependency tracking that make provided, especially with the advent of continuous integration. I consider a build environment for any significantly large project to be a software project of its own and Make is its "assembly language". We need higher orders of abstractions and Ant's XML just didn't cut it. I've gone through several systems the last few years (Scons was a strong "almost got it") and have finally settled on Boost.Build v2 ( http://boost.org/boost-build2/ ) which has an extension of Perforce's Jam system and excellent environmental awareness & extensibility. Its being re-written in Python and has reportedly gotten even faster. The DSL for Boost's bjam tool supports the declarative syntax that is more appropriate for a build system's rules than regular programming languages. Needs better examples on extensibility in the documentation but its been adopted by some critical projects and organizations and improves on a weekly basis. I think this one's got traction... Build systems require a LOT more than dependency tracking that make provided, especially with the advent of continuous integration. I consider a build environment for any significantly large project to be a software project of its own and Make is its “assembly language”. We need higher orders of abstractions and Ant’s XML just didn’t cut it. I’ve gone through several systems the last few years (Scons was a strong “almost got it”) and have finally settled on Boost.Build v2 ( http://boost.org/boost-build2/ ) which has an extension of Perforce’s Jam system and excellent environmental awareness & extensibility. Its being re-written in Python and has reportedly gotten even faster. The DSL for Boost’s bjam tool supports the declarative syntax that is more appropriate for a build system’s rules than regular programming languages. Needs better examples on extensibility in the documentation but its been adopted by some critical projects and organizations and improves on a weekly basis. I think this one’s got traction…

]]> By: Nils http://www.codecommit.com/blog/java/in-search-of-a-better-build-system/comment-page-1#comment-2528 Nils Mon, 26 Nov 2007 10:55:44 +0000 http://www.codecommit.com/blog/java/in-search-of-a-better-build-system#comment-2528 Another very nice buildsystem is OMake ( http://omake.metaprl.org/ ). It keeps a lot of makes syntax and strenghts while beeing a clean functional and object oriented language. It can do cool tricks like clean beeng "delete all artefacts can be regenerated by omake". Another very nice buildsystem is OMake ( http://omake.metaprl.org/ ).

It keeps a lot of makes syntax and strenghts while beeing a clean functional and object oriented language. It can do cool tricks like clean beeng “delete all artefacts can be regenerated by omake”.

]]>