Category Archives: How-To

Maven Tips and Tricks: Describing Maven Plugins with help:describe


September 29, 2009 By Tim O'Brien

If you do any non-trivial customization of a Maven build, you’ll understand that you need to have a good understanding of Maven Plugin configuration. What configuration parameters are available for a particular plugin goal? Most users tend to Google for the particular Maven plugin and rely on the fact that most Maven-generate plugin sites contain a standard list of goals and configuration parameters. While this works, there is a better way: use the Maven Help plugin’s describe goal to list the available configuration parameters for a Maven plugin.

Continue reading

Access Logging in Nexus 1.3.6


September 23, 2009 By John Casey

Since I’ve done much of the work on developing custom jetty.xml files for Nexus, it’s probably natural that I was the one to research and answer the following question:

How can I turn on access logging for a Nexus instance?

It turns out this is a fairly easy thing to do. My solution below draws on the Jetty documentation for version 6.x, here.

First, copy the basic sample jetty.xml file from $basedir/conf/example/jetty.xml to $basedir/conf/jetty.xml. This file provides feature parity with the default configuration built into Nexus, so restarting Nexus with this file in place (and unchanged) should not produce any difference in behavior. This is the starting point for customizing the Jetty configuration within Nexus.

Now that we have our starting point, we need to modify the Jetty configuration to provide access logging, called request logging in Jetty. Find the XML section that begins:

<Set name="handler">

In place of this section, paste the following modification:

<Set name="handler">
    <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection">
      <Set name="handlers">
        <Array type="org.mortbay.jetty.Handler">
          <Item>
            <New id="Contexts"
                    class="org.mortbay.jetty.handler.ContextHandlerCollection">
              <Call name="addLifeCycleListener">
                <Arg>
                  <New class="org.sonatype.plexus.jetty.custom. >>
                            InjectExistingPlexusListener"/>
                </Arg>
              </Call>
              <Call name="addLifeCycleListener">
                <Arg>
                  <New class="org.sonatype.plexus.jetty.custom. >>
                            DisableTagLibsListener"/>
                </Arg>
              </Call>
            </New>
          </Item>
          <Item>
            <New id="DefaultHandler"
                    class="org.mortbay.jetty.handler.DefaultHandler"/>
          </Item>
          <Item>
            <New id="RequestLog"
                    class="org.mortbay.jetty.handler.RequestLogHandler"/>
          </Item>
        </Array>
      </Set>
    </New>
  </Set>
  <Ref id="RequestLog">
    <Set name="requestLog">
      <New id="RequestLogImpl" class="org.mortbay.jetty.NCSARequestLog">
        <Arg>${nexus-work}/logs/yyyy_mm_dd.access.log</Arg>
        <Set name="retainDays">90</Set>
        <Set name="append">true</Set>
        <Set name="extended">false</Set>
        <Set name="LogTimeZone">GMT</Set>
      </New>
    </Set>
  </Ref>

This replaces the single Handler instance created in the original jetty.xml example with one that uses a chain of Handler instances, the last of which is the request logger. Notice how the contents that used to reside within the <Set name="handler"> section are now included in the embedded section that starts with:

<Set name="handlers">
    <Array type="org.mortbay.jetty.Handler">
      <Item>

Also notice, later in the modification we added, that the request log will be kept in $nexus-work/logs/ with a filename consisting of the current year, month, and day, with the suffix .access.log. (Remember, $nexus-work actually points to $basedir/../sonatype-work by default.) This places our access log in the directory already used by Nexus for other types of logging, for consistency and simplified maintenance.

Maven Tips and Tricks: Using GitHub


September 8, 2009 By Tim O'Brien

github-logo

Sonatype uses GitHub to host a number of projects including all of our books. It has been a very valuable tool for us, and we’ve already seen great benefits. The social, interactive nature of the tool allows people interested in the book to keep up with the development of the content, and we’ve already had a few contributors show up and help us write more content. Contributors can fork our books, add whole sections or correct typod and then make a simple pull request that notifies us of the changes. Because we find it so useful, I thought I’d take some time to detail the process of connecting a new Maven project to GitHub. The following post details the process of creating a new GitHub repository, importing a Maven project, and then configuring the SCM element in your project’s POM. Once you’ve done that, you can start using the Maven Release plugin to automate the SCM operations that accompany a release.

Continue reading

Profiling Maven Tests


September 7, 2009 By Marvin Froeder

A few days ago we changed nexus integration tests to use an embedded version of nexus instead of using a forked VM. Before every test Nexus is started and then stopped again after the test completes. This is done once for each test class (Junit: @BeforeClass=start nexus, @AfterClass=stop nexus).

During the first run we noticed some problems.Each time Nexus started, VM would use an additional 45Mb of memory. Soon we realized that our embedder was not working right. Stopping Nexus was not removing it from memory.

Setting all fields to null after stopping helped somewhat. But now instead of 45Mb of leak we were getting 40Mb, which was still too much when we had more then 200 tests to run. It was time to profile our tests.

At Sonatype we use yourkit for profiling, so I will demonstrate how to use yourkit to profile tests executed by maven. You should be able to use the same principle with any other profile tool. Continue reading

Create a Customized Build Process in Maven


August 5, 2009 By John Casey

Maven’s build process is driven by three key concepts: the build lifecycle, mojos, and the lifecycle mappings. If you’re not familiar with these concepts, you can read up on them in Maven, The Definitive Guide, especially Chapter 1 and Chapter 10.

Maven’s basic unit of work during the build is the Mojo (Maven POJO). Mojos are contained in plugins that group them together with similar functions. Additionally, Maven supplies a standard set of scaffolds – called build lifecycles – that provide an abstract, structured progression of the types of activities (lifecycle phases) typically found in a build. The standard build for a particular type of project is defined when the appropriate mojos are bound to the appropriate lifecycle phases using a lifecycle mapping.

Obviously, this is only a starting point; individual projects can further fine-tune their own builds by binding or reconfiguring mojos in their own POMs. However, the default build for a particular type of project – specified by the packaging element in the POM – is defined by its lifecycle mapping.

Maven provides mappings for many common project packagings out-of-the-box. But what if we have a custom project type? Maybe something that produces a particular type of artifact that only our internal systems know how to use? If we’re building a large number of these projects, it may make sense to teach Maven to support a custom project packaging. This is a relatively easy task, if you know a few tricks.

The Custom Lifecyle Mapping

In many cases, we’re interested in building a project artifact that is loosely based on the jar archive layout, with some critical details such as files added to META-INF/ that turn it into more than a run-of-the-mill classpath entry.

Continue reading