Dependency resolution in Java builds

[Lew]

You can set it up to use your own repository.

Of course, then it still reaches across the 'net every time something asks for
a more (or less) version that's not in the local repository. Without asking,
and barely telling.

You don't think we tried that? Thanks for the awesome advice, though!

It is my impression that Maven is a 90% tool. It make life easier for
the 90% easiest cases - cases where it is possible to have
the project follow the Maven philosophy. For the remaining
10% the same features that make it easier for the normal cases
make it real hard. So if the project is tricky, then you
are probably better of with Ant that is intended as
a custom build script tool.

Since real-world projects are nearly never simple, I challenge your "90%"
claim. I'd be surprised if the number were 10%. Do you have any evidence for
that statistic?

The project I'm on isn't even especially complicated, except for the Maven
builds. I wish it were based on Ant, but converting back once it's tangled up
in Maven is not straightforward. None of us, not even my management (!), is
happy with Maven.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Michal Kleczek]

Lew wrote:

On a recent project with Maven builds, we had a parent build ("foomain")
and several subsidiary modules ("foofrontend", "foologic",
"foopersistence", ...).
Historically different versions of the same frameworks were specified
for
the different modules. Yet when you pulled the dependencies into the
"foomain" pom.xml in common the build broke. Turns out some of the
dependencies transitively depend on the same libraries, but different
versions also, some of which are transitive dependencies for other
stuff, also different versions.

So it wasn't really Maven problem but dependency management problem.
From my experience Maven just makes dependency management issues explicit
and visible. I would argue it is a good thing.

 

[Jim Janney]

A process which, for most people, is pretty fast - seconds to
minutes. Much faster than in C, certainly. I suspect that the speed of
clean builds has meant that there isn't much demand for incremental
ones, and hence we don't have any ability to do them.

On the project I work on, every build is followed by a set of automated
tests (first unit, then integration). Compiling takes a few minutes,
and running the tests normally takes about an hour. So we do a clean
build every time.

When I'm working at my desk, I just save and Eclipse handles the rest,
usually in less than a second.

 

[Lew]

So it wasn't really Maven problem but dependency management problem.
From my experience Maven just makes dependency management issues explicit
and visible. I would argue it is a good thing.

My experience is that Maven quietly ignores your desire to keep things in the
local repository and messes up your dependencies. I would argue that
invisibly making changes is NOT a good thing.

Part of the problem I described is due to Maven's quiet retrieval of different
transitive dependencies. If it had instead crashed the build with a message
about an unresolved dependency, it would have been better. That certainly was
not a good thing, and it's laid right at Maven's feet.

Sometimes even a bad tool can be used effectively, if a person is aware of all
the kinks and quirks and is willing to take the effort to work around them.
Such tool's effectiveness under those conditions is not evidence of its goodness.

Maven sucks.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Joshua Maurice]

My experience is that Maven quietly ignores your desire to keep things in the
local repository and messes up your dependencies.  I would argue that
invisibly making changes is NOT a good thing.

Part of the problem I described is due to Maven's quiet retrieval of different
transitive dependencies.  If it had instead crashed the build with a message
about an unresolved dependency, it would have been better.  That certainly was
not a good thing, and it's laid right at Maven's feet.

Sometimes even a bad tool can be used effectively, if a person is aware of all
the kinks and quirks and is willing to take the effort to work around them.
Such tool's effectiveness under those conditions is not evidence of its goodness.

Maven sucks.

I've one of the resident build experts in my company for my product
team. I wrote half the stuff in use, including some home grown C++
Maven plugins which are working decently well when compared to the
Maven standard plugins.

One of my first pieces of advice is to do a full online (re)build up
front, then never ever do an online build ever again until your next
full clean rebuild. I've seen so many build failures that happened due
to Maven's curious and silent downloads of artifacts because the
developer accidentally forgot to specify the "-o" flag one time. I
tell them to use canned scripts where each script has "-o" hardcoded
in, but some don't listen.

Maven is a tolerable dependency management system, that is getting
various things online, automatically downloading them, version
mismatch resolution for different transitive dependencies, etc.,
especially for the toy example. However, it is a miserable failure
when it comes to a the /build/ part of a build system.

 

[Arne Vajhøj]

Since real-world projects are nearly never simple, I challenge your
"90%" claim. I'd be surprised if the number were 10%. Do you have any
evidence for that statistic?

The 90-10 were not statistical information but magnitude indication.
Like in 10% of the code use 90% of the time, 90% of the project takes
90% of the time and the 10% also takes 90% of the time.

Maven is pretty widely used.

And I know of several projects that are happy using it.

Real world projects can be relative simple in build. I would even
say that they should be relative simple in build. Complex builds
are usually a symptom of a bigger problem in the app.

Of course projects with problems, complex builds and Maven not
working properly is still common.

The project I'm on isn't even especially complicated, except for the
Maven builds. I wish it were based on Ant, but converting back once it's
tangled up in Maven is not straightforward. None of us, not even my
management (!), is happy with Maven.

Personally I prefer ant over Maven - I like the ability to code
my build. But from a project perspective coding the build
is just extra cost.

Arne

 

[Lew]

The 90-10 were not statistical information but magnitude indication.
Like in 10% of the code use 90% of the time, 90% of the project takes
90% of the time and the 10% also takes 90% of the time.

Maven is pretty widely used.

And I know of several projects that are happy using it.

Real world projects can be relative simple in build. I would even
say that they should be relative simple in build. Complex builds
are usually a symptom of a bigger problem in the app.

Of course projects with problems, complex builds and Maven not
working properly is still common.


Personally I prefer ant over Maven - I like the ability to code
my build. But from a project perspective coding the build
is just extra cost.

I'll take a fresh look.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|