maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 21:54:59 GMT
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 
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 
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:
For additional commands, e-mail:

View raw message