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: Packaging up pre-existing jar and source jar
Date Fri, 18 Jan 2013 14:02:32 GMT
Stephen has laid out the case very well.
Had I remembered that I wrote this, I should have referred you to 
http://blog.artifact-software.com/tech/?p=177

We had pretty good success starting in Eclipse and once we moved to 
Eclipse/STS and got our Nexus repo in place, we were in Maven heaven.
We had a small team with never more that 5 people but we built and 
maintained an entire LMS with over 70 Maven projects producing over 60 
war files.
I spite of starting out in this business long before GUIs were available 
outside Xerox, I prefer to use a GUI when I can.

If you have a look at the articles tagged with Maven you will find some 
things that we learned that seemed to help in various aspects of 
development with Maven.

Ron


On 18/01/2013 5:07 AM, Stephen Connolly wrote:
> 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
>>
>>


-- 
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