Author Archives: John Casey

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 2.2.1 Released


August 11, 2009 By John Casey

I’m proud to announce the release of Apache Maven 2.2.1.

This release aims to fix some critical regressions introduced in Maven 2.2.0, along with some long-standing issues related to custom lifecycle configurations.

Addressing Regressions in the HTTP Wagon

Beginning in Maven 2.2.0, the default implementation of the HTTP Wagon was switched from the old Sun- / HttpURLConnection-based wagon to one that wraps HttpClient. This seemed to have several advantages, not least of which was giving the user more access to fine-grained configuration options and moving to a better-documented core API for Maven’s most-used wagon. However, we soon realized that these improvements came with a hefty price tag.

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

Maven 2.2.0 Released!


June 30, 2009 By John Casey

I’m pleased to announce that we at the Apache Maven project have released Maven 2.2.0. You should definitely give it a spin! Maven 2.1.0 was probably the most stable release we’ve ever done, in terms of the number of reported regressions. Maven 2.2.0 improves on this stability by fixing the few critical bugs that did come up, along with adding some new functionality. You can grab the new version here.

This release includes some important bugfixes and other improvements, including:

Removed feature from 2.1.0 that resolved expressions in version elements within the POM on installation and deployment.

This code was causing inconsistencies between the POM that landed in the repository and artifacts that are derived from that POM. The most prominent example deals with the GPG plugin: since the POM was modified on deployment, the GPG signature generated during the build was useless. This by itself effectively made Maven 2.1.0 unusable for releases.

Switched to a HttpClient-based wagon implementation for reaching HTTP repositories.

This is crucial for people sending long passwords, since the HttpUrlConnection-driven wagon did not-nice things with BASIC authentication headers when the password was very long…it line-wrapped the Base-64 header value, rendering the HTTP request invalid. In addition, HttpClient offers a wide range of options for configuration over HttpUrlConnection.

New default execution IDs for goals bound from the default lifecycle mapping and those invoked from the command line.

Previously, the only way to configure plugins that were used from the command line was to put the configuration options into the plugin-level configuration. This meant that it was impossible to separate CLI-oriented configuration settings from those used in goals that were bound to the lifecycle. Now, you can simply use an execution block with an id of default-cli to compartmentalize CLI-specific options.

Likewise, Maven 2.1.0 forces users to add configuration at the plugin level for any goals bound to the build via default lifecycle mapping. This could be particularly troublesome when you had multiple goals from a single plugin bound in via lifecycle mapping, and needed to respecify the same configuration option differently for the different goals. For instance, using different includes or excludes between the compiler:compile and compiler:testCompile goal executions was basically impossible. In Maven 2.2.0, you can use executions with the new per-goal default execution-Ids. For the compiler example, you can use default-compile and default-testCompile, respectively, to separate configurations for these two default goal executions.

Java 1.5+ is now a requirement.

Maven 2.2.0 upgrades the Java requirement to 1.5 or later. This allows us to finally start making the migration onto the Java5 generics syntax, and other nice little perks that come with a less archaic version of Java.

…and more…

For the full list of updates, see the Release Notes.

Maven 2.1.0 Released


March 22, 2009 By John Casey

We’re pleased to announce the release of Maven 2.1.0. If you’ve been staring longingly at version 2.1.0-M1 for the last few months, but couldn’t quite get up the nerve to try a milestone release, here’s your chance! Version 2.1.0 builds on the unprecedented stability of 2.1.0-M1, fixing the one or two bugs that were found in that release and adding some exciting new features. Some of these features include:

  • Obfuscated server passwords in the settings.xml (MNG-553)

This feature allows you to encrypt the passwords in the <servers/> section of your settings.xml, to keep them safe from prying eyes. To get started, see the Maven Mini-Guide to Password Encryption.

Tips for using encrypted passwords can also be found in the command-line help for Maven, mvn -h:

Options:
   […]
  -emp,—encrypt-master-password    Encrypt master security password
  -ep,—encrypt-password            Encrypt server password
  • Improvements to the Ant-based mojo support that bring up to feature parity with the maven-antrun-plugin (MNG-3971)

FINALLY, we have support for mojos and plugins written in Ant that’s every bit as good as the Ant support from the maven-antrun-plugin. All of the implied classpaths and innate expression-evaluation capabilities are now available to plugin developers who choose to use Ant.

  • Parallel resolution of artifacts (MNG-3379)

For those of you whose projects download the entire Internet when they build, you’ll probably be interested in parallel artifact resolution. This new feature allows up to five different artifacts (from different groupIds, initially) to be resolved at the same time, thereby shortening total build time in many cases. For more information, see the section “Configuring Parallel Artifact Resolution” in the Mini-Guide to Configuring Maven.

  • New build mode that mimics Make (MNG-2576)

If you’ve ever worked on a large project that contained many interdependent modules and wished you could build only the subset you’re currently focused on fixing, you should take a look at Maven’s new Make-like build modes. Using these modes, you have the ability to build dependency modules contained within the same multi-module build as the current project; to resume a failed multi-module build; and to rebuild all of the projects that depend on the current project. In short, this feature integrates directly into Maven’s core the capabilities found in the maven-reactor-plugin.

Tips for using the new Make-like build modes can be found in the command-line help for Maven, mvn -h:

Options:
   […]
   -amd,—also-make-dependents       If project list is specified, also
                                     build projects that depend on projects on the list
   […]
   -rf,—resume-from                 Resume reactor from specified project
   […]
   -am,—also-make                   If project list is specified, also
                                     build projects required by the list
   […]
   -pl,—projects                    Build specified reactor projects
                                     instead of all projects

You can also find the design document for these build modes here.