Date: 02 DEC 2009
Time: 10am Pacific Time
Title: LDAP integration in Nexus Professional: Technology roadmap
Speaker: Brian Demers, Software Developer, Sonatype

Summary: Nexus Professional adds a Lightweight Directory Access Protocol (LDAP) Authentication realm which provides Nexus with the capability to authenticate users against an LDAP server. In addition to handling authentication, Nexus can be configured to map Nexus roles to LDAP groups. This webinar covers the existing LDAP support in Nexus Professional and includes a technology roadmap for the future development.

Learn more about Nexus Professional.

The webinar is free to attend, but a registration is required. Register now.

Maven 3.0

With Maven 3.x we have made our best attempt to listen to users, find out what they need and want, and make reasonable preparations and plans to fix the problems, implement useful features, and create the integration points for working properly with third-party systems like Nexus and Hudson. While there have been many new feature requests — and we have many new features done or in the works — the number one concern is backward compatibility. Maven 3.x makes an ardent attempt to be 100% backward-compatible with Maven 2.x. All your Maven 2.x builds should work out of the box using 3.x without change to your projects. We simply can’t cause pain to the existing user base. We are very cognizant that even small changes can have a huge impact and so we have tried achieve complete Maven 2.x fidelity with Maven 3.x.

In Maven 3.x we have reduced the number of modules, we have simplified and extracted the artifact resolution system, we have put a performance framework in place, and we have created an enormous set of integration tests for Maven’s core and for many of the core plugins. We are constantly trying to validate core features and core plugins are working properly. We hope with the simplifications that we have made that more people will get involved in the project. We have done some heavy overhauling of many of the internals to make way for future features and I believe Maven 3.x is really the only path forward for Maven. What’s the technique we used to decide on how to plan and work toward the completion of Maven 3.x? A very practical approach to determining an optimal path called desire lines.

Desire Lines

A desire line usually represents the shortest or most easily navigated route between an origin and destination. The width and amount of erosion of the line represents the amount of demand. The term was coined by Gaston Bachelard in his book The Poetics of Space. Desire lines can usually be found as shortcuts where constructed pathways take a circuitous route. A concrete example: the pathways around the Berkeley campus in California. During the early years of Berkeley no pathways were paved. Instead they let inhabitants walk in optimal paths between the buildings and location over a period time to form clear pathways over the grass. Once these pathways had been established they could be paved to make the pathway more permanent. This is very similar to what happened with Maven 2.x. Consider Maven 2.x the pathways marked in the grass. Consider Maven 3.x taking all that learning from Maven 2.x and adopting the optimal form of use and codifying those forms of use i.e. paving the desire lines.

Over the course of hundreds of thousands of people using Maven we have a very good idea of what these optimal pathways look like now. Here are a few examples of some of the things we’ve seen and the things we have to do in order to make these lasting improvements.

Responding to invitations for improvement

There are many things in Maven 2.x that work reasonably well but have some minor flaws which cause irritation:

• Dependency management. How to effectively manage what we will call a target platform (intentionally using the Eclipse nomenclature). It is easy to manage the versions of an applications runtime or its target platform. But what happens when you start pulling in multiple, separately developed target platforms.
• Version specifications and version ranges. Maven’s notion of this is workable, but when it comes to the version specification and ranges it’s time to just defer to OSGi in this regard. What OSGi specifies and what Maven specifies are not wildly different but different enough to cause some problems. We’ll be working on aligning Maven to the version specification of OSGi.
• The way plugins interact with embedded environments was just wrong. We allowed for no support for incremental changes. The result is that in M2Eclipse when you change an individual resource, that individual resource can be processed efficiently and not fire up all of Maven to run the whole build lifecycle. Sorry, but you won’t have time to get a coffee anymore.
• There are slew more, but we’ll save those for other blog entries.

Responding to … being completely wrong

There are some things in Maven 2.x we just didn’t get right and we have to make reparations:

• Composition versus inheritance in the POM. There are some great debugged toolchains like we have in the Apache Organization POM for releasing, but this toolchain is not easily consumable by outside projects because it makes no sense to inherit from the Apache Organization POM for your projects. So how can we make these chunks of debugged combinations of plugins and their associated configuration? We will introduce mixins to help with this. Essentially it will be a POM consisting of plugins and configurations that can be externally parameterized. These mixins will be deployed to a repository and be referenced with a standard coordinate. Basically it will be an intelligent import with validation which will allow composition in your POMs.
• Checking out the whole source tree versus an individual module and parent element versioning. We have always intentionally made projects specify versions in the parent elements. When you check out individual modules this is necessary. But for projects where the whole source tree is checked out, the version of the parent can be inferred and the requirement for specifying the version element in the parent can be removed.
• Clean separation of operations that need to happen at the beginning and end of the lifecycle versus in the lifecycle itself. To make the OSGi integration we created work we needed to get at the projects before the build lifecycle was executed so we added a clear hook before lifecycle execution. What we have done to make OSGi integration work in Maven 3.x is simply not possible in Maven 2.x. We also had a terrible problem with reporting and aggregation because there was no clear point at which the lifecycle was over. Now once the build lifecycle is complete there is a clear hook to get the projects in the reactor so they can be processed easily. Accurate aggregation is now possible.

• Again, there are slew more, but we’ll also save those for other blog entries.

Responding to under-utilization of what exists

Unfortunately there are still a lot of powerful features and plugins in Maven that a lot of people don’t know about. We have tried to remedy this situation with the four books that we constantly update stream, and a stream of blog posts, and the soon to be enterprise Maven users list which will focus on the holistic and systematic use of Maven, M2Eclipse, Nexus and Hudson. We need to do a better job explaining end-to-end best practices for developing, testing, and provisioning software. We also need to do a better job describing some of the incredibly useful plugins we have like the enforcer plugin and the dependency plugin.

But again, our best attempt to show people what is available through the four books that we have:

• Maven: The Definitive Guide
• Repository Management with Nexus
• Developing with Eclipse and Maven
• The Maven Handbook

Here is a picture I always use to illustrate the point that even though something may be sitting directly in front of you, it’s not always immediately obvious unless someone points it out to you. This is very much the case where we see users asking us for help with particular use cases and in frequently it’s very easy to answer the question by pointing to a URL. My example is the Fedex logo which was designed to have an arrow being formed between the last two letters of the logo. Quite ingenious but most people I point this out to haven’t notice it.

We are going to try a lot harder to make sure the value that exists is easier to find. I don’t enjoy reading blog posts from unhappy users at all, but I especially don’t like it when I know there is a solution which has been documented somewhere. Those painful situations can be reduced if not eliminated completely.

Backward Compatibility

I can’t stress enough how important backward compatibility is to us. We have done a non-trivial amount of work to pave the way for new capabilities in Maven 3.x while preserving 100% backward compatibility for:

• Maven itself and the behaviour that users expect from the CLI
• Artifact Resolution API
• Plugin API
• Plugin configuration
• Site generation (even though we’ve extracted site/reporting entirely into the maven-site-plugin)

We must ensure that plugins and reports written against the Maven 2.0.x APIs remain viable in 3.0. We don’t want people rewriting their plugins or having to change their projects at all or it will simply be chaos. We simply have too many users and requiring changes will have an enormous human cost so we’ve been slow in announcing Maven 3.x. The version of Maven 3.x you can pull from the Sonatype grid is probably the best version of Maven that has existed but we are still being careful about releasing it. If you want to try it you can find it here.

We must also ensure that POMs of version 4.0.0 are supported in 3.x along with the behavior currently experienced. We will need to make changes to the POM in order to introduce many of the new features so we’ve made the requisite preparation. We are relying heavily on our integrations tests right now but as we move forward the work that Benjamin is doing on the project/model-builder will help us to accommodate different versions of a POM, and different formats we decide to support. The model-builder code has no limitation with respect to formats. We can support XML, or any source that anyone can dream up. These implementations may find use outside of Maven. For example someone might build something with the Maven, JRuby, and Mercury to create a JRuby-based system. The same could be done for Groovy. We already have some examples of this with the Polyglot Maven project we’ve started which will be the topic of a subsequent post.

We have managed to keep almost everything backward compatible and we will go so far as to provide an isolated execution environment that can contain older versions of the plugin API so that everything from the past can continue to work in Maven 3.x. We will not truly be able to do this until we change the internal Maven runtime over to OSGi but we know what needs to be done.

Integration Testing

An enormous amount of time and energy has gone into improving the the integration tests for Maven. The integration tests are the gatekeeper and let us determine that we have a Maven 3.x that is compatible for Maven 2.x. We now have 506 integration tests that will help protect us as we move forward. We will likely approach 600 integration tests by the time we reach the Maven 3.0 GA.

All core Maven plugins now have ITs and we have started branching out into the Mojo project to create plugin ITs there as well. We have a good pattern so we are encouraging anyone writing a Maven plugin to create ITs so that we can help ensure we don’t break people in the future. We have really taken fixing the problems we see seriously. I couldn’t help but make a little spoof of the SNL skit and adapting it for the Maven perspective.

In the next post I will start talking about some of the technical changes we have made to Maven 3.x in order to achieve our goals. Those will include:

• Refactored model/project builder (the support Polyglot Maven uses)
• Queryable lifecycle
• Lifecycle Extension points
• Error and integrity reporting
• Mercury: Jetty Client & SAT4J
• Embedding
• Incremental build support (used heavily in M2Eclipse for performance improvements, these are changes to the plugin API)

I plan to try and write something about Maven 3.x frequently in preparation for the Maven 3.x talks in Stockholm, Dusseldorf, Cologne, and Devoxx.

Stay tuned!

Trapo blog: Maven + Hibernate + Spring + HSQLDB = your tests running fast and out-of-the-box “I want to keep trapo environment as simple as possible. I want that people just fire a command and all tests can run immediately: not setups, no database creating, no sql to run. Just one single command and trapo should do everything for you. Because of that, I start to isolate the test environment from the production one so that I can then use a different database instance (or even database vendor). To integrate the combo, I just call HSQLDB to the party.” By Trapo, on 02 November 2009

Andreas Höhmann’s Weblog: Toogle jrebel with a cygwin bash function and maven “I’m using java rebel for web development with maven. Sometimes I would run jetty with jrebel sometimes without. For that I’m using two simple bash functions:…” By Andreas Höhmann, on 02 November 2009

Wakaleo Consulting: More Groovy Magic with Maven pom files “Last time, I introduced some of the new Groovy support available in Maven 3, and looked at how you will be able to write your pom files in Groovy, or in other non-XML notations. In this article, we’ll take a further look at what you can do with a Maven pom file written in Groovy.” 30 October 2009

Atlassian Blog: Automated performance testing using JMeter and Maven “When I think of Agile, I tend to think of the awesomeness it can bring me as a performance engineer. I see short cycles where the code is usually always stable and features are delivered incrementally. I get to watch the performance of the system evolve over time. Unfortunately, this means I’m testing software all the time. Thats fine though - none of this is by hand - this kind of repetitive task is perfect for automation.” By George Barnett, on October 20, 2009

Read on for a list of changes in the latest Nexus Book release.

Dependency management is not conflated with builds in the framework as a whole, it is an essential part of a build sytem. While you intended to speak about subtracting dependency management from the build, you end up reinventing the wheel simply because you can’t be bothered to learn how to use Maven. Your entry is the rant of an angry five year-old. I can’t figure out Maven, so I’m going to propose using it for dependency management, grafting it to a custom Ant script, and then using Ruby to craft a classpath. You don’t have a single qualified statement in the whole entry and you go on to suggest things that work again the idea of creating sensible, easily understood standards for developers. I’ll pick two.

1) “Because the build system is so awful.” You always blather on and on about this but we have thousands of users (and Sonatype hundreds of clients) who would say otherwise. We can’t seem to get rid of you but maybe you should just use a completely non-Maven build system so we don’t have to continue to hear from someone who can’t be bothered to learn about something he didn’t invent.

I’m willing to bet my life you’ll still be the physical embodiment of a build system diatribe. Howard, if you weren’t so unconstructive and rude you might get a little more help. It’s called tact, sometimes it’s useful. It’s the combination of plugins that always present problems to users because we don’t validate every possible combination and interaction between plugins. It has taken us many years of listening to users and incorporating feedback from constructive participants to get to where we are. As far as your specific issue, that’s just a hard problem and inside Eclipse the problem is exacerbated. We’re working on it, if you would like to help us converge on a solution, you are more than welcome, but your sniping tells me you are less than interested in being constructive.

2) “Without using the often flakey and undependable M2Eclipse plugin.” No version specified, no discussion, no tests, no qualification. No emails to the m2eclipse development team, no bug reports, nothing. We have many organizations and users that we are working with to address specific issues on m2eclipse, and we’re making quick progress on the 1.0 release. If you had been participating, if you had been communicating, we probably could’ve either solved your problem immediately or pointed you in the right direction. Despite the fact that you frequently snipe us, maybe it would have been a good opportunity to get some constructive feedback from a critic.

You are likely using 0.9.8, which is, frankly, ancient and not supported at the moment. We’ve recommended people use the 0.9.9 dev builds for some time, and the two builds are a universe apart. If you’re using 0.9.9 dev builds we’re pretty quick at fixing problems because the Maven 3.x trunk is synced up with the M2E dev builds. See Howard, useful information. Some constructive feedback. You do know that with the 0.9.9 dev builds we have customizable lifecycle mappings which allow you to eliminate as much of the Maven lifecycle as you wish? Which in your case may be all of it which is perfectly valid. But your solution negates workspace resolution, automatic javadoc and source downloading which are vital for debugging, the POM editing capabilities, searching for dependencies and a slew of other conveniences and your Ruby script just really isn’t a decent substitute.

Eclipse is just hard to integrate with because it has its own world of resources, files, classpath and pretty much everything else. That’s not a cop out, it’s a challenge that we’re overcoming with real effort. That’s life and we can deal but that’s why the M2E plugin is not 1.0 yet. But in all seriousness try 0.9.9 dev builds if you haven’t. If it’s WTP problems you’re having then that isn’t entirely our fault. WTP is another world of integration … trying to find a nice euphimism … challenges.

Did you ever stop to consider that you basically can’t resuse anyone else’s software and that you just rewrite everything? The build system doesn’t seem to be any different. Why don’t you just write your own if you’re not happy with anything else? I volunteer to be the first to try Hive Build. Or, why don’t you just stop and actually spend all this energy trying to help fix some of these problems? You can’t just take what you like out of a system – in this case the dependency management – and then slag the rest with unqualified nonsense. If it didn’t work for you and you had a vitriolic, cathartic reaction like Assaf did. At least Assaf redirected his energy toward creating Buildr, and I can respect that. I don’t think Assaf is entirely accurate, but he said his peace and then made something he likes better. Good for him, and more power to him. You, on the other hand, take what pieces you like, continually bitch, and periodically drive by and shoot us in the back without lifting a finger to help or even communicate.

You know how many things I like about Tapestry? Zero. I’ve had to work with it in a few places I’ve been, and I certainly have my opinions.

How many blog entries do you see me taking pot shots at Tapestry. Zero. I’ve actually had to use Tapestry and I can’t say it was very enjoyable for me. I could whine and bitch, but I wasn’t prepared to do anything to fix the issues. So it serves no purpose to complain and I’m sure there are people who find Tapestry useful and are happy with it.

If you actually had qualified explanations of problems you might get help, but more often than not you lead in with rancor. Doesn’t exactly endear anyone to your plight. You suffer from “obnoxious user deficit”. Instead of showing up at the front door asking questions and providing quality feedback, you barge in shouting about how awful everything is. You start off by annoying the people who could help you the most. I’m certainly not compelled to do anything for you. You’re one of those users who thinks acrimony is more effective at delivering results then civil dialog. Don’t be a tactless open source sniper espousing rancor (TOSSER).

To illustrate this problem, consider a 1.0 build of your product that depends on foo-1.2.jar. It works great. Then you build 2.0 of your product which still depends on foo-1.2.jar.  Since then, foo-1.2.jar was patched and now breaks your application.  However the application still works for half of your developers because the original foo-1.2.jar is in their local repository and possibly proxied in another Nexus instance.

The solution is to release a new version foo-1.2.1.jar. (ie foo-1.2.2.jar or foo-1.2.1.1-jar), but that alone isn’t enough. You want to make sure that you are using a repository manager that prevents someone from updating a release artifact once it has been published.

It has always been possible to stop people from doing this in Nexus but the solution was difficult to explain.  In the Nexus 1.4 release, we have reworked and simplified the interface to encourage this best-practive.

To disable redeployment, edit your repository and set the ‘Deployment Policy’ field to ‘Disable Redeploy’ then click save.

Upgrading from a previous version of Nexus 1.4.0 will set this field to ‘Allow Redeploy’, so no existing repositories will be changed and the behavior matches previous releases. However the default value when creating a new repository is now ‘Disable Redeploy’.

When you use Nexus, you are not just using a capable repository manager, you are adopting the best-practice.

Flexmojos provides first-class support for Flex and AIR development within Apache Maven. It allows Maven to compile, optimize, and test Flex SWF, Flex SWC, Air SWF and Air SWC.

We are proud to announce that Flexmojos now supports Flexunit4 and Fluint, being the first maven plugin to support Flexunit 4.

You can see all the other changes in Jira.

• https://issues.sonatype.org/browse/FLEXMOJOS/fixforversion/10300
• https://issues.sonatype.org/browse/FLEXMOJOS/fixforversion/10539

This is likely the last release in the 3.x series (although any critical bug will force a new release). Flexmojos 4.x development is focusing Flex 4. It probably won’t be compatible with Flex 3, but Flex 3 is well served by Flexmojos 3.x. Maven version will be bumped too, to Maven 2.2.1 or Maven 3, which contain some bug fixes not available on Maven 2.x (Flexmojos 3.x still compatible with Maven 2.0.9).

DZone: Maven Repository Nexus Pro Upgrades to 1.4 “The newly announced 1.4 version of Nexus Professional, a Maven repository manager, introduces a full plugin model with improved capabilities.” October 28, 2009

Nexus Maven Repository Manager Users List: Nexus 1.4.0 Released “Nexus 1.4.0 has been released. This was a rather substantial release, and contains a lot of new functionality and bug fixes.” October 28, 2009

Mosabuam: Company Super POM – A Maven Practice “Soon after the initial install of Maven you will hopefully like it and use it on a bunch of projects. You will notice that there are a bunch of things in the POM that are the same from project to project. Normally that is where the concept of a company or organisation POM appears. On the other hand internally Maven always uses the Super POM as well. Once multiple projects are involved things quickly get confusing, so lets look at this a bit closer and then get to my hybrid approach of a Company Super POM.” By Manfred Moser, on 29 Oct 2009

Eric Hauser’s Blog: ant2maven: Easy migration from Ant to Maven with Nexus “In the scope of a much larger project I am working on, I needed to convert a large number of Ant builds to Maven. Having done this in the past, I know that it is certainly a tedious process – particularly regarding depending resolution. So, I decided to make an attempt at scripting that process and ant2maven was born…” By Eric Hauser, on October 26, 2009

Antonio Goncalves’ Blog: Because I always forget how to use maven-ear-plugin “Sometimes you write a blog to express an idea, to ask some feedback from the community, to share a very nice trick… or because you always forget something and want to write it down so you can remember later on. That’s the reason of this post. I never remember how to use the maven-ear-plugin, so I’m writing it down.” By Antonio Goncalves, on October 23, 2009

Java.net: Exploring Maven 3 with John Ferguson Smart “John Ferguson Smart’s new java.net article and his latest blog post both investigate aspects of the upcoming Version 3 of Apache Maven. Maven, in case you’re not familiar with it, is a “software project management and comprehension tool.” At the core of Maven’s application to a specific software project is the project object model (POM). The POM file provides information on the basic structure of the project, and enables Maven to manage a project’s build, reporting, and documentation. It’s all about automating tasks that once required a lot of repetitious keystrokes by developers, QA teams, and others.” By Java.net, on October 22, 2009

electric-monk: Faster Development with JRebel “I’m going to walk through the steps I took to get JRebel working with maven and Intellij 8 since I ran into a few snags along the way. But first, I should explain why bother install it all. JRebel is a great tool that promises to increase your productivity in Java by enabling all sorts of HotSwaps not normally allowed by the JVM.” By Pete, on October 16, 2009

• Proxy Repository Browsing - With Nexus 1.4, the local cache and logical index views have been separated into separate tabs. We found that the previous single tab with a combo box to select the source was confusing.
• Publishing Web Sites to Nexus Professional - Nexus Professional 1.4 provides you with a WebDAV endpoint for publishing a web site. You can configure a Site repository that can be used as a publishing destination for project documentation. This means you don’t have to worry about providing some alternate solution to host your reports. The full support of Nexus security applies to this new type of repository, so you can control access at a very fine grained level.
• Repository Configuration Changes
  • Fine-grained control of Redeployment for Hosted Repositories: Nexus 1.4 provides administrators a simplied way to control how a hosted repository deals with the redeployment of artifacts. You can configure a repository to allow for the redeployment of previously deployed artifacts, allow for one-time deployment, or to provide a read-only interface for clients.
• Improvements to the Staging Plugin - The staging plugin had numerous improvements in the 1.4 release to increase usability and provide new functions for staging artifact bundle and verifying that staging repositories follow user configurable rule sets.
  • Support for Staging Rulesets: Nexus Professional 1.4 provides administrators with the ability to define a set of rules to apply to staging repositories before they can be promoted. The 1.4 release can validate that staging repositories contain valid POMs, valid PGP signatures, javadocs, and sources for all artifacts. The rules are pluggable and we expect to add more rules in the near future to support the Apache repository and our OSS hosting repository
  • Support for Uploading Artifact Bundles: The staging plugin now accepts artifact bundle uploads. Artifact bundles are archives which contain one or more associated artifacts, they are used to publish artifacts to the Central Maven repository, and you can use Artifact bundles to validate artifacts uploaded to Nexus.
  • General Usability Improvements in the Staging Plugin: This release of the Staging plugin focused on usability, the Staging plugin is full of improvements that make the user interface more intuitive and easier to use.
• User Account Plugin - The User Account Plugin in Nexus Professional gives unauthenticated Nexus users the ability to sign-up for a Nexus account. When this feature is enabled, a new user would click a sign-up link, fill out a simple profile form, read a captcha, and then activate a new account via an email confirmation message. Nexus Administrators can configure the default roles and permissions that are granted to newly signed up users.
• Repository Summary Panel - The repository summary panel provides statistics and configuration information for a specific repository. Users can consult the repository summary panel to gather the necessary distribution management settings for Maven configuration.
• Security Improvements - Many improvements to the user security model. In general, it is now easier to configure custom role mappings for externally managed users, and Sonatype has paid close attention to the user interface for managing users and roles. It is easier than ever to configure and secure a Nexus repository.
  • New User Role Tree: Click on a user and then click on the user role tree to see how each role contributes to the permissions for a particular user.
  • New User Privilege Trace feature: this features allows Nexus administrators to pinpoint which roles contribute which permissions to a particular user. While the user role tree provides an intuitive interface that lists role in a hierarchy, the privilege trace panel under user administration provides an alternate view. Click on a particular permission to find the roles contribute that permission to a user.
  • New Role Tree: Since a Nexus role can consist of both roles and privileges, we’ve provided an intuitive tree browser that allows an administrator to browse the hierarchy of roles and privileges associated with a Nexus Role.
  • Fine-grained control of View Repository Privilege: Nexus added the ability to configure a role to prevent users from browsing particular repositories. This is used to provide a cleaner view to users, for example to show them only groups they use via Maven and not confuse them with all the repositories aggregated by that group.
• Integration with Atlassian Crowd - Atlassian Crowd is a capable user and directory management system that can consolidate authorization and authentication to a central server. Nexus Professional’s Atlassian Crowd plugin provides seamless integration between Nexus and Atlassian’s Crowd server.
• Automated Nexus Error Reporting - Nexus 1.4 ships with an automated error repository system which can be configured to report Nexus exceptions and errors to the Nexus Issue Tracker. If configured, the system will send data to Sonatype’s Jira instance. The information contained includes the configuration (all passwords are obfuscated) as well as a file list of the repositories and exception traces. All of this data is encrypted using public-key cryptography so only Sonatype can view the contents. We expect that this information will allow us to further refine the stability of Nexus.
• Upgrades to the Nexus Book
  • A new chapter on Nexus Best Practices.
  • A new chapter on publishing web sites to Nexus.
  • Over 100 corrections and clarifications.
  • Over 80 new figures and diagrams.
  • Addition of a New Nexus Book Cover with the Nexus Logo
  

A good rule of thumb in Maven is to always declare explicit dependencies for classes referenced in your code. If you are going to be importing Commons BeanUtils classes, you should also be declaring a direct dependency on Commons BeanUtils. Fortunately, via bytecode analysis, the Maven Dependency plugin is able to assist you in uncovering direct references to dependencies. Using the updated POMs we previously optimized, let’s look to see if any errors pop up:

$ mvn dependency:analyze
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Chapter 8 Simple Parent Project
[INFO]   Chapter 8 Simple Object Model
[INFO]   Chapter 8 Simple Weather API
[INFO]   Chapter 8 Simple Persistence API
[INFO]   Chapter 8 Simple Command Line Tool
[INFO]   Chapter 8 Simple Web Application
[INFO]   Chapter 8 Parent Project
[INFO] Searching repository for plugin with prefix: 'dependency'.


...

[INFO] ------------------------------------------------------------------------
[INFO] Building Chapter 8 Simple Object Model
[INFO]    task-segment: [dependency:analyze]
[INFO] ------------------------------------------------------------------------
[INFO] Preparing dependency:analyze
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [dependency:analyze]
[WARNING] Used undeclared dependencies found:
[WARNING]    javax.persistence:persistence-api:jar:1.0:compile
[WARNING] Unused declared dependencies found:
[WARNING]    org.hibernate:hibernate-annotations:jar:3.3.0.ga:compile
[WARNING]    org.hibernate:hibernate:jar:3.2.5.ga:compile
[WARNING]    junit:junit:jar:3.8.1:test

...

[INFO] ------------------------------------------------------------------------
[INFO] Building Chapter 8 Simple Web Application
[INFO]    task-segment: [dependency:analyze]
[INFO] ------------------------------------------------------------------------
[INFO] Preparing dependency:analyze
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [dependency:analyze]
[WARNING] Used undeclared dependencies found:
[WARNING]    org.sonatype.mavenbook.optimize:simple-model:jar:1.0:compile
[WARNING] Unused declared dependencies found:
[WARNING]    org.apache.velocity:velocity:jar:1.5:compile
[WARNING]    javax.servlet:jstl:jar:1.1.2:compile
[WARNING]    taglibs:standard:jar:1.1.2:compile
[WARNING]    junit:junit:jar:3.8.1:test

In the truncated output just shown, you can see the output of the dependency:analyze goal. This goal analyzes the project to see whether there are any indirect dependencies, or dependencies that are being referenced but are not directly declared. In the simple-model project, the Dependency plugin indicates a “used undeclared dependency” on javax.persistence:persistence-api. To investigate further, go to the simple-model directory and run the dependency:tree goal, which will list all of the project’s direct and transitive dependencies:

$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Chapter 8 Simple Object Model
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree]
[INFO] org.sonatype.mavenbook.optimize:simple-model:jar:1.0
[INFO] +- org.hibernate:hibernate-annotations:jar:3.3.0.ga:compile
[INFO] |  - javax.persistence:persistence-api:jar:1.0:compile
[INFO] +- org.hibernate:hibernate:jar:3.2.5.ga:compile
[INFO] |  +- net.sf.ehcache:ehcache:jar:1.2.3:compile
[INFO] |  +- commons-logging:commons-logging:jar:1.0.4:compile
[INFO] |  +- asm:asm-attrs:jar:1.5.3:compile
[INFO] |  +- dom4j:dom4j:jar:1.6.1:compile
[INFO] |  +- antlr:antlr:jar:2.7.6:compile
[INFO] |  +- cglib:cglib:jar:2.1_3:compile
[INFO] |  +- asm:asm:jar:1.5.3:compile
[INFO] |  - commons-collections:commons-collections:jar:2.1.1:compile
[INFO] - junit:junit:jar:3.8.1:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

From this output, we can see that the persistence-api dependency is coming from hibernate. A cursory scan of the source in this module will reveal many javax.persistence import statements confirming that we are, indeed, directly referencing this dependency. The simple fix is to add a direct reference to the dependency. In this example, we put the dependency version in simple-parent’s dependencyManagement section because the dependency is linked to Hibernate, and the Hibernate version is declared here. Eventually you are going to want to upgrade your project’s version of Hibernate. Listing the persistence-api dependency version near the Hibernate dependency version will make it more obvious later when your team modifies the parent POM to upgrade the Hibernate version.

If you look at the dependency:analyze output from the simple-web module, you will see that we also need to add a direct reference to the simple-model dependency. The code in simple-webapp directly references the model objects in simple-model, and the simple-model is exposed to simple-webapp as a transitive dependency via simple-persist. Since this is a sibling dependency that shares both the version and groupId, the dependency can be defined in simple-webapp’s pom.xml using the ${project.groupId} and ${project.version}.

How did the Maven Dependency plugin uncover these issues? How does dependency:analyze know which classes and dependencies are directly referenced by your project’s bytecode? The Dependency plugin uses the ObjectWeb ASM (http://asm.objectweb.org/) toolkit to analyze the raw bytecode. The Dependency plugin uses ASM to walk through all the classes in the current project, and it builds a list of every other class referenced. It then walks through all the dependencies, direct and transitive, and marks off the classes discovered in the direct dependencies. Any classes not located in the direct dependencies are discovered in the transitive dependencies, and the list of “used, undeclared dependencies” is produced.

In contrast, the list of unused, declared dependencies is a little trickier to validate, and less useful than the “used, undeclared dependencies.” For one, some dependencies are used only at runtime or for tests, and they won’t be found in the bytecode. These are pretty obvious when you see them in the output; for example, JUnit appears in this list, but this is expected because it is used only for unit tests. You’ll also notice that the Velocity and Servlet API dependencies are listed in this list for the simple-web module. This is also expected because, although the project doesn’t have any direct references to the classes of these artifacts, they are still essential during runtime.

Be careful when removing any unused, declared dependencies unless you have very good test coverage, or you might introduce a runtime error. A more sinister issue pops up with bytecode optimization. For example, it is legal for a compiler to substitute the value of a constant and optimize away the reference. Removing this dependency will cause the compile to fail, yet the tool shows it as unused. Future versions of the Maven Dependency plugin will provide better techniques for detecting and/or ignoring these types of issues.

You should use the dependency:analyze tool periodically to detect these common errors in your projects. It can be configured to fail the build if certain conditions are found, and it is also available as a report.