Live data from Hacker News

Java Build Systems - a sad state of affairs

grok-code.com

31–40 of 45 posts

Re: Java Build Systems - a sad state of affairs

#31
post #12

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."

When I was using C#, I liked MSBuild just fine - but maybe I wasn't doing anything horrifically complex.

Re: Java Build Systems - a sad state of affairs

#32
post #28

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…

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…

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.

Re: Java Build Systems - a sad state of affairs

#33
post #15
post #2

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.

I believe on the Clojure side, leiningen is the preferred tool of choice: http://github.com/technomancy/leiningen

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

Re: Java Build Systems - a sad state of affairs

#34
post #30
post #7

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...

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.

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

Re: Java Build Systems - a sad state of affairs

#35
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 ?

Re: Java Build Systems - a sad state of affairs

#36
post #16

I still use Makefiles, and I like it!

What seems like a lifetime ago, I was taking graduate CS classes at my local University. I had been writing software professionally for more than 20 years, so I was atypical in my class.

We were given some assignment to write a mail server in Java. At the time, I had never used Java, but had decades of experience with other dialects of C, so I taught myself Java over the weekend.

I put together the server, as well as several classes that could be shared by the client and presented it to the team on the following tuesday. When I showed them java code in emacs, with a Makefile to compile it all and jar it up, they were astonished. They didn't believe that:

1) I had learned the fundamentals of a language in a couple of days and was producing professional quality code in that language (actually professional quality design).

2) That I could do it outside of some java-specific IDE, using 20 year old tools.

I learned Java over a weekend; I wasn't about to tackle ANT at the same time.

After years of using ANT, I still think it is a pain in the ass.

Re: Java Build Systems - a sad state of affairs

#37

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.

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.

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.

Re: Java Build Systems - a sad state of affairs

#39

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…

I think there are two reasons Maven adoption is slower than it maybe ought to be:

1. It's actually pretty darned complicated to use 'correctly' for a non-trivial project. 2. It approaches impossible to integrate into an existing non-trivial project. Maven wants you to do thing it's way (that's the point).. but that makes moving to it on an existing project a challenge

Re: Java Build Systems - a sad state of affairs

#40
post #37

Earlier quoted context omitted.

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.

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 stateme…

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?

Post reply on HN