On 30/01/2013 3:58 AM, Joachim Durchholz wrote:
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.
Stephen and the other hardcore guys like to talk bare metal.
We use Eclipse/STS
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?
Once you have your Repo proxying the universe(or the parts that you
want), you only have to upload non-mavenized artifacts.
We have some but no where near a gazillion.
I never use a command line for Maven or to upload to my Maven Repo.
What else?
The Nexus repo has a web interface.
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.
It is odd from the point of view of a Maven user.
Maven gets it artifacts for builds from Maven repos.
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.
If you give it a sensible GAV, you have the essential - G- who made it;
A what they called it; V the version that you downloaded.
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.)
You can set one up on your PC for free $0.
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.
We try to stop them from happening but it is not always easy.
> 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.
Once I put com.paypal:paypal.base:5.1.1 in my repo, my team can refer to
it in a dependency and always get the same version of the paypal library.
I only do this once.
If paypal comesout with 5.1.2 and we want to use that, we upload it and
change the version in our parent pom and all the children will use 5.1.2.
If we change our mind, we just reverse the change to the parent and all
70 of our builds will now use 5.1.1
Very repeatable.
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).
No meta-data at the source unless you know what standards they follow
there for tagging, releasing, etc.
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.
I know exactly what the team is using and it is fixed until we change it.
I have maybe 10 manual uploads and they are pretty stable.
I proxy 8 Maven repos including Maven Central so we get a lot of stuff
automatically. We probably use well over 100 external libraries.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
