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: [email protected]
For additional commands, e-mail: [email protected]
