maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz>
Subject Re: Unpacking jars into target/classes
Date Thu, 07 Mar 2013 11:57:53 GMT
Warning: Just philosophy here.
I AM trying to restrict myself to things I haven't said before. Some 
amount of repetition is inevitable, and this kind of discussion is 
nearing the point of diminishing returns, so I'm trying to cut down on 
this kind of discussion.

Am 07.03.2013 10:57, schrieb Baptiste MATHUS:
> I'm having a hard time understanding why you keep being unwilling to use
> Maven conventions but keep using it at the same time.

Hello? Because it has been advertised to me as "THE build tool that will 
solve my problems"? And maybe because switching build tool in mid-flight 
is a daunting task?

I'm here because I'm locked in, not because I think Maven is great.

> Maven is the opinionated build tool. Using its conventions is almost
> compulsory. Maven is all about conventions and making build standard across
> projects.

Problem with Maven is that its conventions are too restrictive. Maven 
works well as long as you are 100% inside its mental model of how a 
build should be set up; the problem is that as soon as you (need to) 
work outside that box, Maven will break down, horribly.
Overly terse documentation makes it worse because that makes it hard to 
decide whether the reason for some problem is because some option wasn't 
properly set, or whether the plugin simply can't do what one wants. 
That's making for a lot of frustrating dead-end exploration.

> If you want full scripting features and design the build the exact way you
> want,

That's not really what I want.
I want a declarative specification so the tool can decide what build 
steps to run.
I want full scripting only for the individual build steps. This probably 
means an obligation to specify the declarative metadata so the tool can 
set up its build plan. Plus this probably also means that people will 
need a way to test whether their metadata are correct, since otherwise 
people will get subtle errors into the build plans.

I also want Eclipse integration, so build configuration doesn't need to 
be specified redundantly.
This is usually done via a plugin that configures Eclipse projects, 
restricting further what can and what cannot work as build script (or 
requires another layer of metadata so the plugin knows what to do; m2e's 
lifecycle mapping complications are a good example how complicated this 
problem is.)
(Substitute the IDE of your choice for Eclipse if you want.)

 > then have a look at gradle. Or ant+ivy might make you happy.

I'm not sure whether Gradle fits the bill. Given the complexities 
involved, there's a high risk that it won't.
There's also that advice for any tool is invariably biased, so I also 
risk acting on inappropriate advice. I've been bitten by this time after 
time, Maven is just the last

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message