
Java Build Systems - a sad state of affairs - fogus
http://grok-code.com/538/java-build-systems-a-sad-state-of-affairs/
======
hdeshev
So, the Java build systems suck? You should see the .NET ones - those make me
cry.

I mean that the glass is half full. I wouldn't call a full dependency
resolution system like maven's "a sad state of affairs."

~~~
hello_moto
Amen sir. I made a switch to .NET and boy suddenly the Java ecosystem
(library, builds, IDE) looks a lot better!

------
pbrumm
There is buildr as well

<http://buildr.apache.org/>

It is built on ruby and follows the Convention over Configuration route. Which
keeps the build file quite small.

It has hooks into maven and can be run on jruby or ruby

~~~
csarva
buildr is actually an extension of rake. It essentially adds tasks for
building Java projects (classpaths, libraries, etc) and for packing standard
formats (jar, war, ear, etc). I've been using it for a while now and it's
great.

------
Adrock
The article makes no mention of the solutions implemented in the newer
languages on the JVM:

\- Groovy has Gant (<http://gant.codehaus.org/>)

\- Clojure has Lancet (<http://github.com/stuarthalloway/lancet>)

Both of these avoid the "XML tag soup" problem.

~~~
bitsai
I believe on the Clojure side, leiningen is the preferred tool of choice:

<http://github.com/technomancy/leiningen>

~~~
mike_organon
Leiningen leverages the maven repository underneath, but has a much simpler,
less scary API so it was adopted pretty quickly by clojure programmers.

------
karthikm
What's mentioned as drawbacks are powerful features Maven provides to handle
the project/plugin dependencies better. It takes a bit of understanding and
experience to appreciate these features and to use them effectively. I've used
Maven the right way in one of the biggest enterprise environments as well as a
couple of startups and the results have been nothing short of phenomenal. Am
still baffled by how most of the expert Java/JEE programmers have very little
knowledge about how Maven works.

~~~
gacba
_It takes a bit of understanding and experience to appreciate these features
and to use them effectively._

That would be the reason why most expert JEE folks aren't getting Maven. It's
not a short or easy learning curve. even on a good day with good folks to help
you wade through it.

That said, Maven's dependency management engine alone is worth the price of
admission. Bye-bye JAR hell. But the integrated build/release/tag/version
features are the real treat once you get that far...

~~~
karthikm
Yes. Thats why companies that can afford have separate build engineers. Maybe
one shouldn't be called an expert if they have a poor understanding of how
their build system works? My first couple of interview questions for Senior
JEE engineers always revolves around their understanding of build and I've
found it to be a useful parameter to validate their claims of being an expert.

------
brown9-2
Is there any build system that doesn't have it's problems?

edit: The discussion on Reddit points out many details about Maven that the
author has gotten wrong:
[http://www.reddit.com/r/programming/comments/dmu26/java_buil...](http://www.reddit.com/r/programming/comments/dmu26/java_build_systems_a_sad_state_of_affairs/)

~~~
zokier
Exactly. I'm mostly a C++ programmer and I have yet to find a build system
that I'd like enough to actually use even in my small hobby projects.

~~~
SAHChandler
If I might make a (self promoting) suggestion, I wrote one specifically for
small C/C++/ObjC projects. You can find the most recent release here[1]. Only
a few people have used it, but so far the response has been positive.

[1]:<http://github.com/sahchandler/bit/tree/CaressofSteel>

------
erickt
I also have my own build system, fbuild:

<http://felix-lang.org/tags/fbuild>

That has some basic support for Java. I'm using Python3 for my dsl. Here's a
dummy example of how to use it (from
<http://github.com/erickt/fbuild/tree/master/examples/java>):

    
    
        import fbuild.builders.java
        
        def build(ctx):
            java = fbuild.builders.java.Builder(ctx)
        
            lib = java.build_lib('lib.jar', ['World.java'])
            exe = java.build_lib('exe.jar', ['HelloWorld.java'], classpaths=[lib])
    
            ctx.logger.log(' * running %s:' % exe)
            java.run_class('HelloWorld', classpaths=[lib, exe])
    

I haven't had much demand for Java support, but it probably wouldn't be that
difficult to extend it to download from a maven repository.

------
lapusta
"But Maven uses XML too" - since Maven 3 you can use Groovy, JRuby & Scala
too.

~~~
enricopulatzo
I admit I'm entertained by your use of the word "since." Maven 3 is still
beta. When it gets released and adopted I fully believe it will be great. I
won't be depending on it until it is ready for prime time.

I do wonder if Maven 3's flexibility will hurt it or help it in the long run.
Yes pom.xml is XML, but at least there is only one dialect. If team A likes
XML and team B likes Groovy, development manager C will have a fun time
getting them to work together on project D.

------
srgseg
_Or maybe you want to loop through a set of files and perform a set of
operations on them._

If you did start putting clever code into Ant files, they'd get so huge they'd
be unmanageable. It's really really easy to just write your own Ant plugins in
Java.

Then your build files are very straightforward and readable, and just look
like a set of simple file operations and method calls.

Then Ant becomes really powerful - you can even write some plugins that take a
web server out of service using telnet to Cisco LocalDirector, SCP a
deployment build across and all sorts of other clever stuff.

Plugin example:

    
    
      public class MyTask extends Task {
    
        private String param1;
        private String param2;
    
        public void execute() throws BuildException {
          // do something
        }
      }
    

Then in the XML:

    
    
      <myTask param1="..." param2="..." />

~~~
extension
If you have to drop into raw Java to accomplish anything exceptional, it
largely defeats the purpose of build scripting.

------
jimbokun
Sometimes I suspect that the amount of time spent on build issues, IDE
configuration, continuous integration, version control, and dependency
management approaches half the total time spent on the project.

~~~
johnwatson11218
I think that one of big reasons people jump to new languages like Ruby is that
there isn't all this cruft. It may not be related to the build system but just
look at logging in java versus logging in Ruby. I know everybody likes to talk
about the advanced features of the Ruby language but I can't help but think
that much of the productivity boost comes from getting rid of this stuff.

~~~
papaf
_It may not be related to the build system but just look at logging in java
versus logging in Ruby._

I was in a meeting once where I was the lone "cowboy" Perl programmer amongst
amongst a group of Java dudes. One Java dude told another off for doing
logging wrong. He said "I have a book on this logging package if you want to
borrow it."

None of them knew why I laughed, but to me, logging was just a fancy print
statement. And somebody wrote a book about it.

~~~
hello_moto
The thing about Java developers is that some of them are probably seasoned
developers. They've been through many projects with scars everywhere. From
each project, they learned something new (not necessarily the best way, but
albeit something new). Combine that with the fact that there are people out
there who have been through these situations and wrote "best practices".

When they build the next system, they will try to use these best practices to
avoid their problems they've been through in the past. When this happened,
they are already experiencing the second-system syndrome (but they don't
realized it).

Of course each project differs right?

~~~
jsvaughan
yes nothing beats inexperience

------
lsd5you
Actually I have my own contribution to this space:

<http://ebuild.origo.ethz.ch/wiki/ebuild>

Although unfortunately the documentation is not ready yet, it is quite capable
and is designed to solve what I perceive to be critical short comings of
maven.

~~~
lsd5you
I've added some documentation. Far from complete, but it should shed some
light on the situation for the curious.

------
gaius
I still use Makefiles, and I like it!

~~~
frognibble
There's something to be said for relatively simple tool like make. It can be a
lot easier to understand what's going on with Make because it eliminates the
layers of stuff between the build script and the actual commands that are run.
That's not to say that it's possible to write inscrutable Makefiles.

~~~
jmount
Java presents a lot of problems for make (multiple classes from a single java
file, JNI produced files, circular class references, package to package
dependencies).

------
badmash69
The writer of this article either a troll or untalented hack.

Lets talk about the article : a) the so called XML tax : Agreed XML is not the
best representation of information but it does seem to be particularly suited
for build tasks. Ant's plug in tasks give you a lot of leeway -- a prudent
programmer would know how not to hang herself or himself. I hope for the
writer's sake that the example he chose is not from his actual project. If it
is, then the writer should probably find a different line of work.

b) Netbeans now supports Maven 'natively'. And before that, I have been
faithfully and successfully upgrading my Netbeans version while working on
enterprise scale applications. The problems that the writer mentions are
either exaggerations or a reflection of his ineptitude.

c) Maven : it took me a while to wrap my head around it and I hated learning
how to write plugins -- in xml. But it was worth the effort. I implemented a
Continuous Integration build system for my project that builds an EAR with
over 1.2 million line of code.

Maven just works -- once you have put in the effort to learn the platform. The
writer has not put in any effort towards that. In fact the maven problem he
talks about is actually a quote from a third party. This guy really does not
know what he is talking about.

Don't get me wrong -- ant and maven are far from perfect ; but this article
only betrays the writer's ignorance and lack of skill.

And then he goes on to recommend Rake . Would you take recommendation from a
guy who whines about stuff he knows nothing about ?

------
famousactress
It's true. They're all pretty sad. That said, the problems he lays out with
Maven are mitigated fairly well by using a local Maven proxy. I like to keep
all of my dependent bits in there, and I'm no longer at the mercy of changes
or differences in repos.

------
teyc
I loved the comment about the upgrade treadmill. Some build systems have
unintended consequences.

