Sonatype books are the essential references for anyone working with Apache Maven, repository management, and integrating Maven with Eclipse.
Learn best practices, central concepts, and complete integration for Maven, Nexus Professional, and m2eclipse. Sonatype books offer the latest content for the software development tools you depend on.
The fourth book in our series of books available for downloading is Developing with Eclipse and Maven.
In this book you will learn how to fully integrate Maven with Eclipse, the world’s most widely used IDE for Java development.
Maven is a software build tool, but it is much more than that. Maven is also a project management tool. It is designed to be flexible, easy, and intuitive – to be a more efficient and comprehensive build tool.
Eclipse is the most widely used IDE for Java development today. Eclipse has a huge amount of plugins and an innumerable amount of organizations developing their own software on top of it. Quite simply, Eclipse is ubiquitous. The m2eclipse project provides full integration for Maven within the Eclipse IDE.
Asking the Maven issue tracker for all the changes or fixes that contribute to our freshly released Maven 3.0, one ends up with about 420 issues. While this is a rather large number, most of these issues deal with regressions we encountered and fixed during refactoring of the internals. But those issues are uninteresting to users that consider upgrading from Maven 2.x and want to know what’s the delta to 3.0.
The primary source of information for this delta are the compatibility notes and the plugin compatibility matrix. These documents focus on changes that could negatively affect existing builds due to stricter behavior of Maven 3.0, but we also managed to implement a few general improvements here and there.
As we continue to develop our commercial products and invest in core open source projects like Maven, Nexus, m2eclipse, and Maven Central, we’re very interested in learning about your experiences and current challenges. If you are a programmer, manager, or technology executive, we would appreciate it if you could take some time out of your busy schedule to fill out this short survey.
Take the Sonatype software development survey for a chance to win an iPad 3G.
Need another reason to participate? You can win an Apple iPad just for filling out our survey*. Completing this survey automatically enters you into a drawing to win a 16GB 3G/WiFi Apple iPad (currently valued at $499).
* Official Rules for the Sonatype Survey iPad Promotion can be found here.
I’ve had the opportunity to see many development environments: from the mature organization with tens of thousands of developers that can afford to spend millions on dedicated infrastructure teams, to the three person start-up lacking something as simple as source control. This series of posts discusses some of the common anti-patterns in development infrastructure that are relevant regardless of team size or approach. It also provides some hints for how to avoid these problems.
Problem/Anti-pattern: Too Many Logins
No matter how mature your process is, I’ve always found credentials to be especially difficult for a new hire. It takes days, and then, even when you think you’ve created all of the necessary passwords, there are those other systems that jump up from out of nowhere.
“Do you have a login for Subversion? No. Talk to Tom about that? How about JIRA? I’m not sure who setup JIRA, let me check on that. Ok, we have this VPN, and you are going to need to get those credentials in order to check your email which, unfortunately, is a whole different set of passwords.”
The first few days of employment are meeting people, downloading Gigabytes of software, and remembering an encyclopedia of passwords. Some of these password might be managed by HR, others are managed by your Technology department, but this post focuses on those credentials that affect development infrastructure. If your development infrastructure is mature, your organization might solve this by consolidating authorization and access control information on an LDAP server or Atlassian’s Crowd. If you don’t use one of these products, then you are dealing with an expanding constellation of moving parts: JIRA, Subversion, GitHub, Basecamp, Bugzilla, Confluence, Twiki, Matrix, CruiseControl, etc.
Maven Central contains over 260,000 artifacts and serves over 70 million downloads every week. It has become the principal resource for exchanging Java artifacts with demand doubling year over year. Getting artifacts into Central is the most effective way to get your software to developers since every build tool that can download Java libraries knows where to look for a world of libraries and dependencies, and that single, authoritative place is Maven Central.
Earlier this year, we announced the availability of official repositories in the UK to improve performance for the users in Europe. Today we are making the artifact download statistics available to the projects whose artifacts are served by Central. This has been one of the most frequently requested features by project teams. Since the raw Central logs are larger than seven gigabytes every day, processing this data is no small undertaking.
The statistics are available to all projects hosted using Nexus at http://oss.sonatype.org, http://repository.apache.org and http://nexus.codehaus.org. These three avenues represent the majority of projects actively contributing artifacts. Nexus’ security mechanism already in place on these instances provides a mapping of repository path to project which allowed us to easily roll up the counts for each team. Read more to find out how to access your project’s statistics.