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: [email protected]
For additional commands, e-mail: [email protected]
