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?
You didn't mention what you were using, and all other mentions of
install-file have consistently been a "mvn xxx" command line, so I was
just assuming that that's the standard way.
Telling them to upload to their repos isn't exactly what I'd consider a
"repeatable build". Imagine a project pulling in a gazillion of
binaries, all at different versions; shouldn't instaling them be part of
an automated process?
I never use a command line for Maven or to upload to my Maven Repo.
What else?
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.
Well, from a non-maven-user's perspective, insisting on manually
installing external (non-maven) dependencies is quite bizarre, too.
Dunno who's on the more bizarre point of view here. Don't think anybody
here is impartial enough to decide.
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.
Except that the artifact loses all metadata that link it to its origin.
Which means people lose information about what they're actually dealing
with, it's just a binary blob with unknown content, not even a version
number survives.
You need to manually supply that information. Manual = there's no
guarantee that it's even correct.
If the collaborators don't share a common repo, the problem gets worse
since everybody needs to correctly supply that information. If anybody
has problems, you can't properly diagnose them because you don't really
know whether they got the download right, so suddenly you're now
burdened with maintaining a maven repo.
(Bitbucket doesn't offer maven repos. I'm not aware of any service that
allows setting up closed-group maven repos unless you pay $. This is a
small project with a budget of zero, so $ is not really an option.)
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.
???
I was talking about what people do. Lots of workarounds; Stephen just
facepalmed about a proposed workaround, with the words of "not this
one!" IIRC.
So... yes, there are plenty of them.
> This is the way Maven and Maven repos work with un-Mavenized projects.
Yeah, and I have taken extraordinary pains to explain how that flies in
the face of Maven's claims of automating a repeatable and dependable
build process, and I have yet to hear an argument that falsifies that.
Can't say I'm impressed with the concepts as presented.
If you do something different, people will think that you don't know how
to use maven properly.
I fail to understand how manually installing artifacts is a good idea if
they are available from a stable, unchanging source. Yet the only way
you've been offering is exactly that, and you have consistently failed
to argue how that's still a good idea (in fact from my current
understanding, it's a horrible, bizarre idea).
As long as this is the situation, the workflow itself must be considered
dubious, and I couldn't care less about what others think about the use
of such a workflow.
Yes, yes, yes, I may be wrong.
Just explain yourself. Explain how manual installation to a maven repo
is preferrable to an automated one, I dare you.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
