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 (athena.apache.org: local policy)
Message-ID: <5108744F.20906@artifact-software.com>
Date: Tue, 29 Jan 2013 20:15:59 -0500
From: Ron Wheeler <rwheeler@artifact-software.com>
Reply-To: rwheeler@artifact-software.com
Organization: Artifact Software
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: users@maven.apache.org
Subject: Re: Jar file not in maven
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> <510839D6.3020409@artifact-software.com>
 <510851FA.7000403@durchholz.org>
In-Reply-To: <510851FA.7000403@durchholz.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 29/01/2013 5:49 PM, Joachim Durchholz wrote:
> Am 29.01.2013 22:06, schrieb Ron Wheeler:
>> On 29/01/2013 2:47 PM, Joachim Durchholz wrote:
>>> Am 29.01.2013 19:42, schrieb Anders Hammar:
>>>> The right/correct solution here is to setup an internal Maven 
>>>> repository
>>>> where you deploy those jars to.
>>>
>>> I still feel very uneasy about that, and I think I can pinpoint the
>>> reason a bit better now:
>>>
>>> One of the promises of Maven is that you can describe the entire build
>>> process in the poms.
>>> Manually installing to a repository is outside the poms; it just makes
>>> that jar "magically appear". It would be okay for those jars where no
>>> traceable origin is available anymore (the situation would be dubious
>>> for other reasons though); however, it is NOT okay for those
>>> situations where there's a perfectly valid traceable origin for the
>>> jar, such as a stable company website to download it from, an SVN repo
>>> with a fixed revision number to take it from, or something generated
>>> at the bytecode level from otherwise available sources.
>>>
>>
>> Your use case is that you will give them your sources and POMs but not
>> access to your repo?
>> Fair enough.
>
> Well, it's not my repo, it's the repo of some third party that 
> provides the binary jars.
> Not that it changes much for the users, just to clarify which hat I'm 
> wearing. If I were responsible for those jars, I'd simply set up a 
> public Maven repo and avoid the whole can of worms; I'm the integrator 
> who's trying to cover up for those third parties who're unwilling or 
> unable to set up a Maven repo.
>
>> In that case, you will simply have to tell them where to get the files
>> and tell them that they have to be uploaded into their Maven repo with
>> the same GAV that you used in your POM.
>>
>> No one would have trouble with these instructions.
>
> Uh... there are a lot of people who're comfortable with an IDE but not 
> with the command line.
> For these, command-line instructions would register as "bizarre". 
> Media mismatch and all that.
Who said anything about a command line?
I never use a command line for Maven or to upload to my Maven Repo.

>
>> Otherwise you are going to have to give them some pretty bizarre
>> instructions about loading stuff onto each developer's workstation and
>> reloading them anytime they blow away their local cache.
>
> Sure. Not a serious problem. At worst, the jar gets downloaded again.
> If upstream complains, you're having enough developers hitting their 
> site that setting up an organization-wide maven repo for caching 
> purposes is an option.
>
> I'm assuming the download site is stable and will always reproduce the 
> same jar given the same coordinates. If the download site does 
> in-place updates, the entire discussion is moot and I agree the best 
> strategy would be to manually download the stuff, manually slap on a 
> version number, and install-file to some repo set up just to ensure 
> build stability.
>
>> Maven users are going to scratch their heads at that set of instructions
>> and ask "Why not just download what I need once and put it with the rest
>> of my external jars like a normal Maven project?"
>
> Not sure what bizarre instructions you're envisioning here.
> I want the download to be running from a pom. I want the plugin that 
> does this to skip the download if the artifact is already in the local 
> cache repo - that's allowed since the basic assumption is that the 
> upstream download source is stable (as would be typical for any 
> SCM-based one, or for Sourceforge).
>


My point is that for someone who knows how to use Maven, they are going 
to wonder why you are working this rather odd way.


>> They will eventually figure out the right way to do it and probably send
>> you a nice note about how you should have used a Maven repo.
>> If they are really nice, they will fix your instructions for the next
>> person and post it on their blog.
>
> In practice, I'm seeing tons of people trying out the most hilarious 
> workarounds.
> Also, I'm not seeing any workable procedure. install-file doesn't cut 
> it, it requires manual intervention to keep information on the 
> download coordinate from which the jar originates - which means that 
> this manual intervention isn't done and you end up with jars with no 
> useful version information in the maven repo.
No the repo has a meaningful version number. The one that you gave it. 
This could be the SCM revision number if you want.
Since you are writing the POM, your dependency GAV matches the GAV that 
you gave it in the repo.

> See my lengthy rant on lwjgl in my answer to Stephen.
>
When you put the artifact in your repo, you give it a GAV and from then 
on anyone who wants to use your POM has to use the same GAV when they 
upload this un-maven artifact. No big deal.

>> There are a few projects that do not distribute POM files with their
>> jars and some that do but do not publish to Maven Central.
>> It is just a fact of life that you have to load some things manually
>> into your repo and some things have to be given a "fake" POM by the repo
>> so you can reference them in a repeatable way.
>
> That's exactly where Maven could do better.
> Give Maven a notion of "stable external download site", controllable 
> from poms, and people will stop looking for workarounds. Well, at 
> least those who care to ask here :-)
> Whichever plugin is responsible for that could even do some quick 
> checks whether the download site is really stable (WWW status, SCM tag 
> existence check, whatever), and ring an alarm bell if anything is off. 
> That would be far better than any kooky workarounds people are trying 
> right now.

There is no kookie workaround. This is the way Maven and Maven repos 
work with un-Mavenized projects.
If you do something different, people will think that you don't know how 
to use maven properly.


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


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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