maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 08:13:35 GMT
Joachim, a possible solution would be to front the external non-Maven repo
with a repo manager transforming it into a true Maven repo. As a Nexus (one
of the repo managers out there) user I know you can do that via
implementing a virtual repo plugin, but I would expect you can do similar
things with the other repo managers as well. Just keep in mind that it
can't do anything magical; if metadata is missing you have to provide it in
some way.

Other than that, I can only shim in with Stephen that many of us are tired
of arguing about what's the correct way of solving things "the Maven way".
You may not agree with us, but that's a different thing.

/Anders


On Tue, Jan 29, 2013 at 11:49 PM, Joachim Durchholz <jo@durchholz.org>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.
>
>
>  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).
>
>
>  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.
> See my lengthy rant on lwjgl in my answer to Stephen.
>
>
>  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.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message