maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Packaging up pre-existing jar and source jar
Date Fri, 18 Jan 2013 10:07:56 GMT
On 18 January 2013 09:35, Joachim Durchholz <jo@durchholz.org> wrote:

> Am 17.01.2013 23:17, schrieb Stephen Connolly:
>
>  First, when you are playing with install:install-file you will find that
>> you regularly need to blow away your local cache (which is the real name
>> of
>> the "local repository")...
>>
>
> Turned out I'm not really installing to .m2/repository, but to something
> that m2eclipse calls "Workspace Projects".
>
> This has been working well, so I hope I can stick with that.
>
> Seems like that "local repository" terminology had me confused.
> What about changing the docs so that they don't say "local repository" but
> "repository cache"? That would spare future maven newbies that confusions.
> The paragraph that introduces it can explain that it's technically just a
> normal repository, but that you shouldn't do anything with it but
> occasionally clean out old cruft (or whatever it is that's okay to do with
> the local repository cache).
>
>
>  Second, repository routing... the killer feature of MRMs. Not everything
>> is
>> in central. There's the world of crazyness that is the redhat repos, the
>> old java.net repos, the pile of people who have yet to get why you should
>> push your stuff to central, or who think pushing to central is hard... and
>> then you end up with a pom from one repo and an artifact from another...
>> and the transitive deps are wrong because the poms are different.
>>
>> An MRM allows you to specify exactly what artifacts can be sourced from
>> which repositories and also gives you a single flat repository for maven
>> to
>> pull from...
>>
>
> Okay, this hasn't been an issue yet but I'll keep that in mind.
>
>
> > Most of the MRMs are trivial to set up and give you a reliable store
> > to cache in front of you.
>
> The issue being, this is another potential point of failure that I'll have
> to check if something goes wrong. So I'll want to postpone this until I'm
> familiar with the rest of the toolchain, getting that all to work hasn't
> been easy and I probably haven't seen all failure modes yet.


Run the MRM on your own machine.

There is one MRM that claims to run in like JVM overhead + 64MB of RAM and
consumes very few CPU resources (hint the company that makes it rhymes with
Pony tripe and they have an OSS version, which is fine for your needs)

I actually used to do this myself at my previous employers for when I
needed to work from home. I would run all my builds through that. When I
was commuting to and from work I could still work away, and when at home I
didn't need to fire up the VPN to build.

It made my on-line/off-line experience seamless. The other MRMs can provide
the same experience, I just don't know how low you can push the memory
usage of them and still have a functioning MRM.

My point is, you think adding a MRM is adding a point of failure...
actually it's taking away about 3-4 points of failure, so NET GAIN in
reliability.


>
>
>  Third, performance. When you list multiple <repository> in your pom or
>> settings.xml you force artifact resolution to hit ALL of them. with an MRM
>> you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local
>> anyway,
>> it's flattened (because it's a virtual repo) and you have a fast reliable
>> build and you can scale it out to others.
>>
>
> I supposes the m2eclipse repository manager does that already. It is
> hitting Maven Central on Eclipse startup, once (and takes minutes to
> complete).


With an MRM this would be seconds not minutes


> I think it allows building right away, so I'm probably fine.
>
> I can see that building from the command line might suck, because that
> won't have the m2eclipse "Workspace Repositories"


That, and I don't use eclipse, is just building a reactor out of all the
projects in your workspace which is handy, but will cause issues for you.

... erm, what's an MRM? A Maven Repository Manager?


Yes

>
>
>  There's more reasons if you feel you still want some...
>>
>
> I'd love to, but only if they are relevant.
> I have yet to look up what exactly the m2eclipse "Workspace Projects"
> thing is. Eclipse lists it in the "Maven Repositories" tab.
>

If you are really trying to grok what maven is doing, forget eclipse, start
from the CLI. Eclipse does all sorts of magic to try and protect you from
people who don't grok Maven and set up insane builds. That's what an IDE
should do, but for an engineer trying to grok what Maven is doing, you got
to go back to vi and CLI... otherwise you are dealing with Magic and we
have to resort to chants of "Follow the Maven way" and "just because" if we
are dealing with somebody using Magic


>
> Thanks for taking the effort to respond after my rant.
>

Our issue is we see this *every day*, so our short cut is to tell people:
learn from us, this is the way to do it.


>
> Regards,
> Jo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message