On 7 March 2013 11:57, Joachim Durchholz <j...@durchholz.org> wrote:
> 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.
>
Maven is *the* opinionated build tool.
Like any relationship, you must have give and take... both sides need
flexibility... but at some point there will be a deal breaker...
I like to let the dishes soak in the burn your hands hot soapy water for 5
minutes to let the surfactants do their stuff... she likes to start washing
them straight away... meh! I can compromise and put up with slightly less
clean dishes... so what if I have a PhD in physical chemistry and *know*
that my way is the correct way to wash dishes... or maybe we buy a
dishwashing machine and let it do the dishes for us.
On the other hand, previously I didn't like kissing an ashtray, she didn't
want to give up smoking... that was something I tried to compromise on, but
you know what, turns out that smoking is a deal breaker, so that
relationship ended (lucky for me and my wife eh!)
This is not a "Maven" issue. This is a relationship issue.
To bring this back to Maven...
Maven wants the java source code in ${basedir}/src/main/java... you want it
somewhere else... you know what, Maven is OK with that
Maven wants to build the dependency tree before it finalizes a build plan
that will include plugin executions that require resolving the dependency
tree in order to ensure that the transitive dependency tree does not
reorder the build-plan... you don't want to use a maven repository manager
or run a separate script to install the 3rd party dependencies into the
local repository cache... that one is a deal breaker for Maven... the
question is I have for you is: can you live with Maven's restrictions? This
is something that Maven will not compromise on... the ball is in your court.
> 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.
I am trying to come up with a better user facing documentation for the core
of Maven itself... my aim being to let people know that Maven is
OPINIONATED, that it's ok to disagree on some of those opinions, but that
some things are core opinions and if you disagree with those core opinions,
please don't use Maven.
>
>
> 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.
>
You don't want Maven... if you are not prepared to compromise on the above,
then (and please don't take this the wrong way) stop using Maven.
>
> 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.)
Do you want a pony too? ;-)
>
>
> > 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
Based on your wants stated above, my view is Gradle is what you want...
might not be what anyone else working on your project wants, may not even
be what you need, but you have your core principals and they clash with
Maven's core principals, for the sake of the children (the source code)
perhaps you and Maven should get a divorce
-Stephen
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
