maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Jar file not in maven
Date Wed, 30 Jan 2013 15:34:25 GMT
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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message