The first time Maven resolves a dependency it caches it in the ~/.m2/repostory/<groupId>/<atrifactId>/<version>/ directory. From this point on, assuming you don't add or change dependencies, you can build completely offline without any special flags.
If your project includes dependencies on snapshots it's a little different; by default Maven will check if new snapshot versions of dependencies are available every build. You can override this behavior by either building in offline mode (-o) or by updating the snapshot policy. The snapshot policy defines the frequency at which these checks are performed and can be controlled per project and/or per developer. An individual developer on the project can also override the project wide settings. Another very handy feature is the ability to include javadoc and source for project dependencies when generating Idea/Eclipse projects. For example, to generate an Idea project with the ability to click through to dependency code and view dependency javadoc I use (same offline/online rules apply): mvn -DdownloadSources -DdownloadJavadocs idea:idea Admittedly the black box nature of Maven means when things go wrong they REALLY go wrong. However, I've been drinking the Maven Kool-Aid for a few years now and I still seem to be breathing. Drink the Kool-Aid... ;-P Cheers, Dan On 14 February 2010 04:34, Andrew Purtell <apurt...@apache.org> wrote: > I suspect the problems I'd like to avoid we've already mostly taken on > with Ivy. Primarily: The need to be connected to build and test. That is > a real problem on a 15 hour flight. Domestic flights have options, but > not the international ones. At least with Ivy I can edit out the resolve > steps from the Ant buildfile as long as I ran 'ant test' before boarding. > Edit, then rm -rf build/classes/* instead of 'ant clean', etc. > > Don't tell me I need to spend hours to figure out how to set up a local > mirror of the public repo and then keep it up to date thereafter. There > seem to be 5 large repositories referenced in ivysettings.xml. I doubt I > have or can spare enough disk on the laptop and don't have the bandwidth > to prune to just the packages that HBase needs and then update by hand > whenever that changes or they change. If you tell me this, I have an > impolite response for you. > > Clearly I'm unhappy with the definition of "progress" of some. Will > Maven make me more or less unhappy? If Maven can support some totally > disconnected operation from cache -- which Ivy cannot apparently -- then > that would be awesome. If it makes the situation for me worse, I'll just > do something else on those flights. > > - Andy > > > > ----- Original Message ---- > > From: Ryan Rawson <ryano...@gmail.com> > > To: hbase-dev@hadoop.apache.org > > Sent: Sat, February 13, 2010 12:10:36 AM > > Subject: Re: Moving to Maven (HBASE-2099) > > > > Would you mind elaborating more? At the moment, most people do not > > build hbase, and the POM/jar/publishing thing is orthogonal - those > > who wish to build their own projects with ivy and/or ant are free to > > do so and not be impacted by our use of maven. > > > > We have ivy, but it doesnt integrate with our IDEs and is rather slow > > to build and rebuild. > > > > On Sat, Feb 13, 2010 at 12:03 AM, Mathias Herberts > > wrote: > > > -1 > > > > > > I think Maven is too complex and will lower the adoption of HBase by > > > people today willing to build it. > > > > > > I would suggest using Ivy for dependency management as was done in > Thrift. > > > > > > Mathias. > > > > > > > > >
