maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 08:58:50 GMT
>>> 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:
For additional commands, e-mail:

View raw message