John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 112 posts at DZone. You can read more from them at their website. View Full User Profile

Maven Mythbusters #2 - Maven Requires an Internet Connection to Delete a Directory

01.12.2010
| 3774 views |
  • submit to reddit

Maven seems to be one of those topics that brings out passion in many developers. In this series of articles, I want to take a look at some of the common myths and ideas that circulate about Maven, and see how they stand up to the light of scientific examination. Last time, we looked at the idea that Maven automatically updates for every build. This time we look at another myth quoted in this article: that Maven requires an internet connection to delete a directory.

Myth Number 2: Maven requires an internet connection to delete a directory

In this issue, I want to look at another quote from the same blog entry, which suggests that Maven requires internet access to perform a "mvn clean" (and by implication I presume, to perform any other core task):

"Maven is broken and wrong if it requires an internet connection to delete a directory"

 

Let's look at this one a little closer.

When you install Maven, you only install a small kernel - all of Maven's core functionalities are implemented by plugins. This is intentional (it's called modular design, actually). So the first time you use a particular lifecycle plugin (anything from "mvn clean" to "mvn deploy", and everything in between). And this will require network access - either to the central repository, or (preferably) to your local repository manager. This is normal behavior, but it can surprise new users, and certainly contributes to Maven's reputation of "downloading the internet".

So let's reproduce this in laboratory conditions. I've deleted my local repository (you never do this in a real environment, of course) and run "mvn clean":

 

$ rm -Rf ~/.m2/repository
$ mvn clean
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Tweeter
[INFO] Tweeter domain model
[INFO] Tweeter service layer
[INFO] Tweeter web application
[INFO] ------------------------------------------------------------------------
[INFO] Building Tweeter
[INFO] task-segment: [clean]
[INFO] ------------------------------------------------------------------------
Downloading: <a target="_blank" href="http://localhost:8081/nexus/content/groups/public/org/apache/maven/" title="http://localhost:8081/nexus/content/groups/public/org/apache/maven/">http://localhost:8081/nexus/content/groups/public/org/apache/maven/</a>
plugins/maven-clean-plugin/2.2/maven-clean-plugin-2.2.pom
3K downloaded (maven-clean-plugin-2.2.pom)
Downloading: <a target="_blank" href="http://localhost:8081/nexus/content/groups/public/org/apache/maven/" title="http://localhost:8081/nexus/content/groups/public/org/apache/maven/">http://localhost:8081/nexus/content/groups/public/org/apache/maven/</a>
plugins/maven-plugins/10/maven-plugins-10.pom
7K downloaded (maven-plugins-10.pom)
Downloading: <a target="_blank" href="http://localhost:8081/nexus/content/groups/public/org/apache/" title="http://localhost:8081/nexus/content/groups/public/org/apache/">http://localhost:8081/nexus/content/groups/public/org/apache/</a>
maven/maven-parent/7/maven-parent-7.pom
20K downloaded (maven-parent-7.pom)
Downloading: <a target="_blank" href="http://localhost:8081/nexus/content/groups/public/org/apache/" title="http://localhost:8081/nexus/content/groups/public/org/apache/">http://localhost:8081/nexus/content/groups/public/org/apache/</a>
apache/4/apache-4.pom
4K downloaded (apache-4.pom)
Downloading: <a target="_blank" href="http://localhost:8081/nexus/content/groups/public/org/apache/maven/" title="http://localhost:8081/nexus/content/groups/public/org/apache/maven/">http://localhost:8081/nexus/content/groups/public/org/apache/maven/</a>
plugins/maven-clean-plugin/2.2/maven-clean-plugin-2.2.jar
11K downloaded (maven-clean-plugin-2.2.jar)
...
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting directory /Users/johnsmart/Projects/wakaleo-training/tdd-training/
lab-solutions/tweeter/tweeter-web/target
[INFO]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Tweeter ............................................... SUCCESS [8.806s]
[INFO] Tweeter domain model .................................. SUCCESS [0.044s]
[INFO] Tweeter service layer ................................. SUCCESS [0.054s]
[INFO] Tweeter web application ............................... SUCCESS [2.518s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12 seconds
[INFO] Finished at: Wed Jan 06 20:59:41 NZDT 2010
[INFO] Final Memory: 10M/80M
[INFO] ------------------------------------------------------------------------

So this did indeed download stuff from the network, and did indeed require network access. But let's test this a little further. The quoted myth implies however that Maven needs network access every time it performs one of these core features. So let's see what happens when we run "mvn clean" again:

 

$ mvn clean
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Tweeter
[INFO] Tweeter domain model
[INFO] Tweeter service layer
[INFO] Tweeter web application
[INFO] ------------------------------------------------------------------------
[INFO] Building Tweeter
[INFO] task-segment: [clean]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO] ------------------------------------------------------------------------
[INFO] Building Tweeter domain model
[INFO] task-segment: [clean]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO] ------------------------------------------------------------------------
[INFO] Building Tweeter service layer
[INFO] task-segment: [clean]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO] ------------------------------------------------------------------------
[INFO] Building Tweeter web application
[INFO] task-segment: [clean]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean {execution: default-clean}]
[INFO]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Tweeter ............................................... SUCCESS [0.780s]
[INFO] Tweeter domain model .................................. SUCCESS [0.007s]
[INFO] Tweeter service layer ................................. SUCCESS [0.016s]
[INFO] Tweeter web application ............................... SUCCESS [0.408s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Jan 06 21:16:09 NZDT 2010
[INFO] Final Memory: 9M/80M
[INFO] ------------------------------------------------------------------------

This time, Maven required no network access, and downloaded no files. In fact, Maven will never require you to download anything related to these core plugins more than once. Maven's core plugins are bound to the version of Maven you are running - once you have downloaded them for one project, they will be available for all other Maven builds on your machine.

Now the blogger may have a point here - maybe Maven should download the core lifecycle plugins and install them into the local repository during the installation process. But Maven uses different plugins for different project types (JAR, WAR, EAR...), so that would make for a pretty big download, not all of which would necessarily be required for your particular projects. But if that's what it needs to keep the users happy, why not?

However the idea that Maven systematically needs network access for core functions such as "mvn clean" is clearly busted.

(The title and some of the images of this blog were of course shamelessly stolen from the great and highly scientific MythBusters TV series.)

From http://weblogs.java.net/blog/johnsmart

Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Adam Leggett replied on Tue, 2010/01/12 - 5:39am

Maybe an 'offline' installation tarball option for the upcoming Maven 3 is a good idea? I guess this would include the kernel plus all core lifecycle plugins and their dependencies. Would be interested to know what the download size would be.

Even with the default network-based bootstrapping of Maven, I think its also important to (yet again) reinforce the point that if you have an MRM installed in your shop this 'internet download' of core plugins would most likely happen within your LAN. We've been doing that since the days of Maven-Proxy and Proximity so its never really manifested itself as a problem for us as long as we locked down our core plugin versions, which as you point out, are now bound to a Maven release anyway. I think a lot of the FUD is due to developers' experience of using versions of Maven prior to 2.0.9 such that it has now become something of an urban myth - "Maven downloads the internet before doing anything!".

For more experienced dyed-in-the-wool SCM/Build Management types I think the fundamental worry is that this network interaction violates principles concerning governance and the repeatability (and predictability) of your builds. To assuage these worries in the past i've often had to design and configure a Maven eco-system to minimise its network interaction - plugin and dependency version lockdowns, no version ranges, no snapshots, no plugin updates etc. In these circumstances it would have made my life easier if this was the default behaviour of Maven, but i'd be interested know if the wider community wants this.

 

Michal Huniewicz replied on Thu, 2010/01/14 - 6:00am

I've deleted my local repository (you never do this in a real environment, of course)

Ha ha! Come on. It's the ultimate Maven problem solver.

Karl Peterbauer replied on Thu, 2010/01/14 - 9:01am in response to: Michal Huniewicz

Oh yeah! It's a good practice to configure your build server to dump it's local repository now and then, especially in times of heavy POM changes. "Works on my machine" is a proverbial excuse in teams working with Maven.

 Seriously: It's a gallant task to defend Maven against urban legends, and maybe Maven is a suitable tool in the hands of experienced, seasoned and cautious developers. But if you have some juniors, developers new to Maven, or a few cowards in your team, then expect all kinds of funny things, and  a broken or at least non-reproducible build every now and then ;-)

 

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.