maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz ...@durchholz.org>
Subject Re: Unpacking jars into target/classes
Date Thu, 07 Mar 2013 12:54:57 GMT
Just some feedback...

Am 07.03.2013 13:22, schrieb Stephen Connolly:
> Maven wants the java source code in ${basedir}/src/main/java... you want it
> somewhere else... you know what, Maven is OK with that

I'm actually okay with that source structure, though I don't like the 
split between .../java/... and .../resources/..., it's ripping apart 
stuff that will live side-by-side in the jar.
But... meh, I can adapt and I can see the reasons why one would want to 
keep the directories apart, It's ultimately a judgement call.

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

Which is a good thing in my book (and why I'm aghast when I see people 
building plugins during normal build).

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

Well, I have to compromise on that if Maven won't budge, right?

Dropping Maven will ultimately be what I'm forced into, but I can't 
switch right now.

> I am trying to come up with a better user facing documentation for the core
> of Maven itself...

It's never a bad idea to improve the docs, but the real problem is the 
plugin docs. Many options are "documented" along the lines of "frob: 
frobs the build", which isn't very helpful. Few if any plugins clearly 
document the use cases they are built for, or (almost more importantly) 
the use cases that will not work. Of course, lifting the restrictions 
would be even more helpful than documenting them :-)

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

These opinions need to be spelled out if people are to make an informed 
decision whether Maven is for them. The problem is that it's hard to 
spell everything out since it's so easy to have implied assumptions even 
without being aware of them. Plus, it's hard to spell everything out 
without getting lost in detail.

Also, such opinions need to be presented in a fashion that shows where 
there's room for reasonable disagreement. If opinions are presented as 
"that's the only reasonable alternative", people will assume that all 
the doubts they might harbor will eventually dissolve.
Maven is less prone to that problem than, say, Hibernate. Gavin has been 
promoting a single transactional model as the only reasonable one, which 
is okay for those programs that happen to live well with it but simply 
can't be made to work for all situations. It's a nasty kind of 
misrepresentation because it's to easy to fall to it, both for the 
author and for the reader.
Just listing that as a point to consider when laying out the arguments.

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

Ah, I was just on a tangent how an ideal build system should be done, 
IMNSHO.
I'm very aware that Maven isn't it :-)

> then (and please don't take this the wrong way) stop using Maven.

No offense taken. I'm already on my way out, it's just that switching 
build tools in general is a high-effort high-risk endeavour.

> Do you want a pony too? ;-)

In pink, preferrably ;-)

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

Maybe. I'm not sure whether it's really managing build ordering 
constraints well enough to be worth it.

> 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

I hear ya.
As with every divorce, things are easier said than done.

Regards,
Jo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message