“We will be moving data centers and want to setup another Maven2 repo that is managed with Nexus OSS. We want both repositories to be online and read\writeable until we migrate all our environments to the new site. I have a few questions:

1. What is the best method for copying the repo to the new location?
2. What is the best method for keeping the two repos in sync? We want to minimize network bandwidth usage.”

The video below answers these questions, and offers multiple solutions:

Improving Your Java development with Maven 3 and Hudson

Tuesday, June 7, 2011 @ 10:30AM – 11:00AM EDT (UTC/GMT – 0400)

Presenter: Jason van Zyl, Sonatype CTO & Founder

Attend this webinar to learn about the advantages of upgrading to Apache Maven 3, including improved speed, greater stability and increased compatibility. Jason will also talk about the greatly improved support for Maven 3 within Hudson that is easy to configure and supports complex build scenarios with ease. We will cover the Eclipse IDE integration for both Maven and Hudson that improves developer productivity.

Register now!

About the webinar:

Tycho is a set of Maven plugins and extensions for building Eclipse plugins and OSGI bundles with Maven. Eclipse plugins and OSGI bundles have their own metadata for expressing dependencies, source folder locations, etc. that are normally found in a Maven POM. Tycho uses native metadata for Eclipse plugins and OSGi bundles and uses the POM to configure and drive the build. Tycho supports bundles, fragments, features, update site projects and RCP applications. Tycho also knows how to run JUnit test plugins using OSGi runtime and there is also support for sharing build results using Maven artifact repositories.

Join this webinar to get an overview of the Tycho project and to learn what plans the project has for the future.

• Date: May 3, 2011
• Time: 9:00 am PST / 12:00 pm EST / 4:00 pm UTC / 6:00 pm CET
• Length: 60 minutes
• Enroll here!

Software developer Igor Fedorenko details the new features and changes to m2eclipse 1.0, including pom.xml editor enhancements and reworked build lifecycle mapping.

For more videos from the Sonatype team, visit our Resource Center, or go to our YouTube channel.

To view the replay, click here.

Our next webinar – Hudson Continuous Integration with Sonatype Professional – is taking place on March 29. If your development team is looking for best practices for integrating Maven, Hudson and Nexus Professional this webinar is for you.

Sonatype Professional is the only integrated suite created for Maven-centric builds. The suite includes Sonatype Certified & Integrated Distributions of: Maven, Hudson, Nexus Professional, Eclipse Integration, Developer Onboarding as well as support from the experts. Register to learn how Sonatype Professional empowers development teams to realize the promise of agile through continuous integration, while reducing project risk.

• Date: Tuesday, March 29, 2011
• Time: 9:00 am Eastern Daylight Time (New York, GMT-04:00)
• Duration: 30 mins
• Presenter: Blaine Mincey, Sonatype Senior Systems Engineer
• Register for this webinar

EclipseCon 2011 is being held in Santa Clara, California from March 21 – 24.

As a Strategic Member of the Eclipse Foundation and as a proud Gold Sponsor, Sonatype is looking forward to another year of great talks, tutorials and BOF’s at EclipseCon 2011. Sonatype technical leaders will host a number of sponsored talks on Tuesday, March 22 in the Cypress Room. Topics we will cover include: Next Generation Development Infrastructure, Hudson Continuous Integration, Tycho Build Conversion, Discovering p2 API’s, Maven 3 and many more.

Check out the full lineup of presentations here.

We hope to see you there! But if you can’t make it, get all of the conference updates from the Sonatype team on Twitter by following the hashtag #EclipseCon.

Event Details:

• Date: March 21-24, 2011
• Location: Hyatt Regency Santa Clara, CA
• Event Website: http://www.eclipsecon.org/2011/

In a recent survey, 80% of developers, managers and architects said lack of integration between their tools was a huge efficiency drain. As teams standardize on tools like Maven, Hudson, and Nexus integration headaches can be real productivity killers.

View this webinar to learn how Sonatype Professional can help your team spend less time chasing problems and more time delivering code.

First, a general tip for users interested in using these enhancements in POMs: use the requireMavenVersion rule from the Maven Enforcer Plugin and required Maven version 3.0.3.  This will save other team members from running into strange build failures due to plugin misconfiguration if they are still using previous Maven versions.   Likewise, plugin authors that take advantage of these enhancements should properly declare the Maven prerequisite in the plugin POM.

Generic collections

The plugin configurator can now employ the generic type argument of a collection parameter to determine the type of the elements. In practice this means plugins can use collections as input parameters more freely without having to worry about the user being forced to specify the proper element type in the POM.

For instance, the goal parameter:

/** @parameter */
java.util.List<java.io.File> files;

can be configured like this in the new Maven version:

<files>
  <!-- Maven 3.0.3 can take care of converting this to a java.io.File instance -->

  <file>pom.xml</file>

  <!-- The previously required implementation attribute is now superfluous but still works -->
  <file implementation="java.io.File">build.xml</file>
</files>

Instead of having to specify the type of each element, Maven 3.0.3 will now automatically convert the first element in the previous example to an object of type “java.io.File”.

In absence of the implementation attribute, Maven usually looks for a class named <goalPackage>.<xmlElement> to determine the element type. The recognition of generics now enables plugin authors to use bean classes for collection elements that reside in a different package than the plugin goals.   In summary, collections now provide the same ease of configuration as classical arrays.

Automatic conversion of arrays to collections, and vice versa

Continuing in the spirit of the previous improvement, the new plugin configurator will now automatically convert a collection obtained from a parameter expression to an array if that’s the type expected by the plugin parameter. Likewise, an array would be converted to a collection if needed. The bottom line is that plugin authors targeting recent Maven versions can freely decide to use an array or a collection for a plugin parameter regardless of whether its default value actually yields a collection or array:

/** @parameter default-value="${project.compileSourceRoots}" */
List<String> sourceRootsAsCollection;

/** @parameter default-value="${project.compileSourceRoots}" */
String[] sourceRootsAsArray;

Before this change was made to the configurator plugin developers and Maven users had to be very careful about passing an array to a method that expected a List or vice versa. While this might seem like a minor change, it is one of many that will make plugin development easier.

Configuration of collection/array via system property

For many plugin parameters it is occasionally convenient to specify their values from the command line via system properties. In the past, this was limited to parameters of simple types like String or Boolean. The latest Maven release finally allows plugin users to configure collections or arrays from the command line via comma-separated strings. Take for example a plugin parameter like this:

/** @parameter expression="${includes}" */
String[] includes;

This can be configured from the command line as follows:

mvn <goal> -Dincludes=*Foo,Bar*

Plugin authors that wish to enable CLI-based configuration of arrays/collections just need to add the expression tag to their parameter annotation. Note that if compatibility with older Maven versions is to be kept, the parameter type must not be an interface but a concrete collection class or an array to avoid another shortcoming in the old configurator.

Inlined collections

Many users complain that Maven POMs make heavy use of container elements for collections. Instead of just listing a series of dependency elements, you have to wrap all of your dependency elements in a dependencies element. The same is true for includes and excludes and other elements throughout the POM.  This extra redundancy often adds up to some very large POMs. In Maven 3.0.3, we’ve made a change to the plugin API that will support plugin configuration without requiring container elements for collections.  Here is an example:

<fileset>
  <directory>src/demo</directory>
  <include>Foo*</include>
  <include>Bar*</include>
  <exclude>*Bad</exclude>
</fileset>

Previously, Maven would only look for a field or setter when processing the <include> elements. Now it also looks for an adder. So to support the above configuration, a plugin author would need to implement the configured bean like this:

public class Fileset
{

    private List<String> includes = new ArrayList<String>();

    public void addInclude( String include )
    {
        includes.add( include );
    }

    ...
}

The adder needs to be named add<xmlElement>() and must be public, non-static and have a single argument; it may have a return value. In case where multiple such adders with the same name exists, it is undefined which one gets actually called so be sure to avoid overloading the adder.

Given that merging of plugin configuration during POM inheritance or profile injection is purely based on the XML structure and not guided by information about the actual data types, users that employ this compacted configuration are well-advised to not mix it with the usual collection-style configuration format for a given plugin parameter as the merged configuration likely doesn’t produce the intended result.

Bean default properties

We can take the idea of inlining configuration a little further. Have a look at this example configuration:

<resources>
  <resource>
    <directory>src/foo</directory>
    <filtering>true</filtering>
  </resource>
  <resource>src/bar</resource>
</resources>

Looks odd at first, doesn’t it? Obviously, the <resource> element describes some complex structure, but the second <resource> element in the example consists just of a mere string. It’s not hard to guess that<resource>src/bar</resource> could be a shorthand form of <resource><directory>src/bar</directory></resource> by assuming the <directory> element is the default/primary property of a <resource>. With the new plugin configurator, this is actually possible now.

To enable the feature, a plugin author would have to add a method called set() to the bean class in question:

public class Resource
{

    private File directory;

    public void set( File directory )
    {
        this.directory = directory;
    }

...
}

This set() method must be public, non-static and take a single argument; it may have a return value.

Besides saving users a few bits of XML, this feature can also be used to configure complex beans via system properties from the command line. Let’s say we have a plugin parameter like this:

/** @parameter expression="${artifact}" */
Artifact artifact;

Now further assuming the Artifact bean used here implements a nice set() method that is smart enough to parse a string into artifact coordinates, one could invoke the plugin directly via:

mvn <goal> -Dartifact=org.apache.maven:maven-core:3.0

Last but not least, the default property feature also enables a smooth upgrade path in case plugin parameters need to be changed from simple values to complex structures. Going back to the initial example with the <resource>elements, consider the plugin author originally didn’t anticipate the <filtering> element and designed the plugin parameter to be of type File[].

With previous Maven versions, the only way to extend the plugin to support the<filtering> element is to deprecate the existing <resources> parameter and introduce a new parameter using the complex type or alternatively just break compatibility with existing POMs that use the old plugin version. Using the default property support, a plugin can change the parameter type from File[] to Resource[] without affecting existing users.

Simpler configuration of properties parameter

While java.util.Properties is just a concrete implementation of a Map, the configuration required for parameters of type Properties is structurally different from the configuration format for Map parameters. For the sake of consistency and conciseness, plugin parameters of type Properties can now also be configured like a Map, that is:

<properties>
  <key1>value1</key1>
  <key2>value2</key2>
</properties>

User-specified implementation class for map parameters

Previous Maven versions always used a TreeMap to configure parameters of type Map. In other words, neither the user nor the plugin author had any control over the map implementation being used. Just like with the collections, the updated plugin configurator recognizes an optional implementation attribute:

<map implementation="java.util.LinkedHashMap">
  <key>value</key>
</map>

In absence of both the attribute and a concrete implementation class in the parameter declaration, TreeMap continues to get used.

Hexadecimal and octal numbers

In some contexts, it’s more convenient to specify a number in hexadecimal or octal notation. To support this, plugin authors previously had to declare the corresponding plugin parameters as strings and do the conversion themselves. Now, it’s natively supported, using the prefix “0x” to denote hex notation and the prefix “0″ to denote octal notation.

<rgb>0xFF00C0</rgb> <!-- hex number -->
<perms>0664</perms> <!-- octal number -->

EclipseCon is the conference for anyone involved in Eclipse. As a proud member of the Eclipse Foundation, Sonatype is looking forward to another year of great talks, tutorials and BOF’s. We will be hosting a number of extended workshops as well as talks in the Cypress Room all day on Tuesday, March 22, 2011.

Sonatype founder Jason van Zyl will be giving a presentation on Next Generation Development Infrastructure with Maven, m2eclipse, Nexus & Hudson.

Presentation details:

All development organizations eventually converge on a set of tools to reduce costs, lower onboarding time, and leverage knowledge in strong communities to create standard processes. To this end we see in many organizations the emergence of a standard development stack consisting of Maven, m2eclipse, Nexus & Hudson. In this talk, Jason van Zyl, Founder of the Apache Maven project, will discuss the future of Maven and specifically Maven 3.x, the rapidly approaching m2eclipse 1.0 release, the recent Nexus 1.9 release and roadmap, and emerging tools such as Maven Shell and Polyglot Maven. Sonatype itself leverages this stack on a daily basis and this discussion will focus not only on the tools individually, but how they can work together to create a best practices approach to building and delivering your software in your organization.

Event details:

• Date: March 21-24, 2011
• Location: Hyatt Regency Santa Clara, CA
• Event website: http://www.eclipsecon.org/2011/

Stay tuned to the Sonatype blog for updates on Sonatype’s talks and presentations at EclipseCon 2011. And for the latest news and updates from the Sonatype team, follow us on Twitter @SonatypeCM.

These changes are now in the core of Hudson. Even though JSR330 can now be used by plugin authors these changes should, in no way, affect plugin authors using the existing API. Since this question came up on the mailing list, I’ll give a short description of how it works here. The JSR330 integration allows you to take advantage of JSR330, if you wish, by using an alternative plugin strategy. Our new plugin strategy interoperates with the existing, classic plugin strategy. Sonatype’s Hudson Professional distribution actually ships with a mixture of JSR330 plugins and classic plugins and we find this works quite well. We tried to make it easier to use new strategies for wiring up plugin, and Stuart McCulloch has offered this strategy on the Jenkins development list and it appears to have been absorbed as part of JENKINS-8897. Now that the absorbtion of our first proposal is complete we will move on to our next proposals. These proposals are a mixture of project infrastructure proposals and core Hudson proposals.

New infrastructure for plugin developers. Winston Prakash and I have been working on setting up a new infrastructure for Hudson plugin Developers where it’s very easy for them to develop, stage to Nexus OSS, and synchronize their plugins to Maven Central. As part of this work Sonatype is also working on making Hudson plugin development dead-simple with m2eclipse. Winston and I have started testing this new infrastructure with a few plugin developers over the last couple of days and it’s working out quite well.

Plugins update site generation from Maven Central. Once Hudson plugin developers have synchronized their plugins to Maven Central we want them to be made immediately available to Hudson users. I have been working on a plugin for Nexus that will listen for incoming changes to Hudson plugins and dynamically modify the JSON metadata required by the Hudson update manager. The information about available Hudson plugins will be made available from Maven Central as a set of REST services. The integration possibilities here are very interesting.

JAXRS-based REST API. Jeanfrancois Arcand has been working on adding support for the dynamic addition of resources in Jersey and adding support for a JSR330-based component provider. We want to be able to use JSR330 and we want Hudson plugins using JSR330 to be able to dynamically register their own REST resources. Once this work is done on Jersey we will be making the proposal for its inclusion to the Hudson core.

Modularizing the Hudson core using JSR330. Stuart McCulloch has started analyzing the Hudson core and finding ways to help us reduce the complexity by breaking it apart into distinct JSR330 components. This will be an ongoing process, but one we believe will help us with all other work we intend to do with Hudson.

Hudson Core Testing. There is simply no way that we can aggressively refactor the core and know the changes are not harmful without drastically increasing the amount of testing done. This will be another ongoing process and I believe the most important contribution we will be making.

We are moving more carefully and probably slower then we might like, but we feel that, in order to aggressively add features in the future, the testing infrastructure, development infrastructure, and core features need to be in place. All this work I’m talking about will likely take a release or two to get in place but once that is done we will be moving at a radically different pace.