Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of stephen.alan.connolly@gmail.com
 designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <510996B3.70905@durchholz.org>
References: 
 <CAKGS6FbEo7nLnurLU48q=zK720PeU2ckcWvKBnTfUEZV-dTmYw@mail.gmail.com>
	<CAKAumBE_i4e-VWrTe6pctTo6naNaz9jQdkSbQzBoVqoa8LZmGA@mail.gmail.com>
	<CA+nPnMzP4PLanFm5NmMRCSN3eBENW3sG23oyBkx9=1w5eez-yQ@mail.gmail.com>
	<CAKDUN1u+79KWC0nruz7qafoJeh3AxPmGYmMKr9TLf_9xVG1cSg@mail.gmail.com>
	<5108273D.3000806@durchholz.org>
	<CA+nPnMy=HEmfha1LeywvdMhiSTCVRLbR0HL0U5Huy98FBCYKaQ@mail.gmail.com>
	<51084BBF.4080508@durchholz.org>
	<CA+nPnMx9re1xW5NgPdDGF-jKRVamVZoW-fF+JHY5HvuK9seu5g@mail.gmail.com>
	<5108DA1E.4030106@durchholz.org>
	<510938E5.5030302@artifact-software.com>
	<510996B3.70905@durchholz.org>
Date: Wed, 30 Jan 2013 22:39:00 +0000
Message-ID: 
 <CA+nPnMxrMoFEkhducSJzU-J6Zs_WwfHxER9sqX63NOtJZrHsEQ@mail.gmail.com>
Subject: Re: Jar file not in maven
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=e89a8f3bae492a2c0504d4892dfd

--e89a8f3bae492a2c0504d4892dfd
Content-Type: text/plain; charset=ISO-8859-1

There are two ways to look at this:

1. Maven is what it is, how do I achieve my end goal as close as is
practicable to the maven best practices

2. Maven sucks, and here is how it should do things differently.

We appreciate both types of viewpoint, but keep in mind that it has taken
*over a year* to even get close to releasing a new version of Maven (for a
whole host of problems I don't want to confuse this thread with)

The 2nd line is probably better suited to discussion on the developer
list... This is the users list, where discussion is more of the 1st type.

On Wednesday, 30 January 2013, Joachim Durchholz wrote:

> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

--e89a8f3bae492a2c0504d4892dfd--