Am 30.01.2013 16:14, schrieb Ron Wheeler:
You are arguing with the guys who wrote Maven and are responsible for
maintaining it.
Should I stand in awe from that?
I doubt it.
I have seen many holes punched into authority figures.
In one instance, I was the one who did the punching.
Besides, I have my own list of awesome projects. It's just that a lean,
mean, Chomsky-0-capable, assembly-optimized (three lines source to 20
lines assembly) natural language phrase generator never met a widespread
demand.
Maven did, and Maven was the first to deliver a "good enough" solution.
I don't want to belittle that, and I bet it has been the fruit of much
work and thinking, but so are many other projects. Maven's clout doesn't
entitle its makers to awe - or, put another way: Resting on your laurels
is the wrong way to wear them.
They are giving you good advice about how to use it properly.
Why not try it their way for a week and see if it solves your problems.
I have come here because the recommended way just replaces a problem
(binary jar import) with another one (repository management - I have no
public server to put one on, and I would need to).
That problem has remained unanswered, so I have no basis for trying
anything out.
Essentially, I've been asking for a fork, and you keep recommending I
try out a hammer, and that it will somehow, magically, enlighten me and
show me that all my problems are indeed nails.
Okay, it's a metaphor and can be wrong like any metaphor, but it's my
current state of knowledge, and I'd really like to see an argument that,
somehow, my current problem is indeed a nail. It won't work if what I
write is being ignored in favor of assumptions like "OMG he's still
trying to shoehorn an SVN repo into carrying Maven repos" or "OMG he's
ignoring stability issues" - no I'm neither, but somehow you guys let
yourself get triggered into these assumptions whenever somebody talks
about SCM, or downloads, or binary jars.
It's really annoying and tiring to argue against such assumptions.
Stephen has tried to give you concrete reasons why your way will lead to
a constant battle.
With emphasis on "tried".
Ultimately, he failed because he didn't really understand what I was
asking and argued based on assumptions that didn't hold.
I can only tell you that our team was once where you are - starting out,
learning "the Maven way" without a repo.
Once we got the repo, a lot of good things happened in terms of our
understanding of the Maven way, our ability to deal with third party
jars and our ability to manage projects in a sensible and efficient way.
I'll readily believe that. I'll also believe that it worked for your
sitation.
I don't see how it would work for me. I don't have a server that's (a)
visible to all project members and (b) can carry a Maven repo.
I'd do it on Maven Central, but somehow I doubt it's the right place for
experimenting with MRMs. Besides, Central does (rightfully) have some
strict rules in place, and struggling with strict rules and new
workflows and new tools at the same time is a few too many unknowns at
the same time to make success probably.
I have also seen a lot of new people come in and have trouble getting
adjusted.
It leads to a lot of traffic before they get rid of the ideas that once
drove their builds and conformed to the Maven way of doing things.
Frequently it is an Ant mindset that slows adoption and sometimes it is
a homemade build methodology.
No Ant mindset here.
My mindset is a "make" one: The first-class citizens are build rules and
artifacts, with the build rules creating the dependency graph between
artifacts. (Heck, I even wrote a make variant in Rexx, as a student.)
Unix make is inadequate for today's needs because it offers no way to
easily construct build rules as variants of existing rules, because it
has no good way to deal with dependency cycles, and because the makefile
syntax is a pile of suck (by modern standards).
However, the "build rules infer dependencies" mindset is still applicable.
Ant is anathema from that perspective. It's just a different way to
express build scripts, with no way to express dependencies. It was a
good stopgap measure while make wouldn't work and no better alternatives
were available.
Maven is more interesting, since it has quite some very strong points
(declarativiy, build stability, dependency management), but it also gets
some things thoroughly backwards (plugins that sometimes run just in one
phase and sometimes across phases, a badly documented set of conventions
combined with a convention-over-configuration approach, configuration
for a build step distributed over two, sometimes three plugins, pre-xxx
and post-xxx phases already hinting that the next version of Maven will
have pre-pre-xxx and post-post-xxx phases).
Just my unenlightened view.
And limited to GAV coordinates, dependencies, parent poms, and
configuration mechanics, so I'm missing anything beyond that - MRMs and
deployment, and maybe a few things more.
I'd really love to have an MRM for the repo that m2e runs inside the
Eclipse workspace. That would be useful; Eclipse's "Maven Repositories"
view is extremely limited (essentially it's just a display of all GAV
coordinates available, which is a start but just a start).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
