jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2.x Remote Resources Plugin
  • MRRESOURCES-56

The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource Bundle if the outputDirectory configuration parameter is specified and does not explicitly contain ${project.build.outputDirectory}

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.2.1
  • Fix Version/s: None
  • Labels:
    None
  • Environment:
    Window XP, Java 1.6

Description

Issue:

The maven-remote-resources-plugin (1.2.1) fails to create a usable Resource Bundle if the outputDirectory configuration parameter is specified and does not explicitly contain ${project.build.outputDirectory} - this makes ${project.build.outputDirectory} the only viable configuration.

The documentation for the remote-resources:bundle goal: (see: http://maven.apache.org/plugins/maven-remote-resources-plugin/bundle-mojo.html#outputDirectory) states:

outputDirectory:

The directory where you want the resource bundle manifest written to.
•Type: java.io.File
•Required: No
•Expression: ${project.build.outputDirectory}

Reproduction the issue:

With this initial POM:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>org.gteley</groupId>
  <artifactId>test</artifactId>
  <version>0.0.1-SNAPSHOT</version>

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-remote-resources-plugin</artifactId>
        <version>1.2.1</version>
        <executions>
          <execution>
            <goals>
              <goal>bundle</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <includes>
            <include>**/database*</include>
          </includes>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>


With this project directory structure:

test/
  |
  +src/
    |
    + main/
      |
      + resources
        |
        `database.ddl
        `database.sql


Execute this command: mvn clean package to obtain this good result:

test/
  |
  +src/
  |
  +target/
    |
    +test-0.0.1-SNAPSHOT.jar/
      |
      `database.ddl
      `database.sql
      |
      + META-INF\
        |
        ` MANIFEST.MF
        |
        + maven
          |
          ` remote-resources.xml
          |
          + org.gteley/
            |
            `pom.properties
            `pom.xml
    |
    + classes/
      |
      `database.ddl
      `database.sql
      |
      + META-INF\
        |
        + maven
          |
          ` remote-resources.xml
    |
    + maven-archiver/
      |
      ` pom.properties
    |
    + maven-shared-archive-resources/
    + test-classes/


Everything is fine, the contents of the Resource Bundle (test-0.0.1-SNAPSHOT.jar) are as required and expected for subsequent consumption by the remote-resource:process goal..

Now, amend the POM to explicitly specify the default value for the outputDirectory parameter:

(...)
        <configuration>
          <includes>
            <include>**/database*</include>
          </includes>
          <outputDirectory>
            $\{project.build.outputDirectory}
          </outputDirectory>
        </configuration>
        (...)


Execute this command again: mvn clean package to obtain the same good result.

OK far, now amend the POM to explicitly specify an alternative value (${project.build.directory}) for the outputDirectory parameter:

<configuration>
          <includes>
            <include>**/database*</include>
          </includes>
          <outputDirectory>
            $\{project.build.directory}
          </outputDirectory>
        </configuration>


The result below now reveals the issue, the Resource Bundle (test-0.0.1-SNAPSHOT.jar) is created, but without the necessary META-INF/maven/remote-resources.xml file:

test/
  | 
  |
  + META-INF\
    | 
    ` MANIFEST.MF
    | 
    + maven
      |
      ` remote-resources.xml
      |
      + org.gteley/
        |
        `pom.properties
        `pom.xml
  | 
  +src/
  | 
  +target/
    |
    +test-0.0.1-SNAPSHOT.jar/
      |
      `database.ddl
      `database.sql
    |
    + classes/
      |
      `database.ddl
      `database.sql
    |
    + maven-archiver/
      |
      ` pom.properties
    |
    + maven-shared-archive-resources/
    + test-classes/


By specifying ${project.build.directory} the META-INF/maven/remote-resources.xml file lies at the same directory level as the src and target directories (as expected) - but the Resource Bundle (test-0.0.1-SNAPSHOT.jar) does not now contain the META-INF/maven/remote-resources.xml file rendering useless for subsequent processing by the remote-resource:process goal:

Another way to also render the Bundled Resource useless for processing by the remote-resource:process goal is to append a subdirectory to the valid ${project.build.outputDirectory} configuration.

Amend the POM again this time specify an additional subdirectory to the ${project.build.outputDirectory} configuration of the outputDirectory parameter like this:

(...)
        <configuration>
          <includes>
            <include>**/database*</include>
          </includes>
          <outputDirectory>
            $\{project.build.outputDirectory}/somedirectory
          </outputDirectory>
        </configuration>
        (...)

Execute this command: mvn clean package to obtain this bad result:

test/
  | 
  +src/
  | 
  +target/
    |
    +test-0.0.1-SNAPSHOT.jar/
      |
      `database.ddl
      `database.sql
      |
      + somedirectory
        |
        + META-INF\
          | 
          ` MANIFEST.MF
          |
          + maven
            |
            ` remote-resources.xml
            |
            + org.gteley/
              |
              `pom.properties
              `pom.xml
    |
    + classes/
      |
      `database.ddl
      `database.sql
      |
      + somedirectory
        |
        + META-INF\
          | 
          + maven
            |
            ` remote-resources.xml
    |
    + maven-archiver/
      |
      ` pom.properties
    |
    + maven-shared-archive-resources/
    + test-classes/

The META-INF/maven/remote-resources.xml file now stems from the somedirectory/ directory, and not from the Jar's root directory as so again the Resource Bundle cannot be consumed by the remote-resource:process goal

One other avenue I've found that prevents the META-INF/maven/remote-resources.xml file from appearing in the Resource Bundle (test-0.0.1-SNAPSHOT.jar) is to update the execution section of the POM to include a phase like this:

(...)
        <executions>
          <execution>
          <phase>package</phase>
            <goals>
              <goal>bundle</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <includes>
            <include>**/database*</include>
          </includes>
        </configuration>
       (...)

Execute this command: mvn clean package to obtain this bad result:

test/
  | 
  +src/
  | 
  +target/
    |
    +test-0.0.1-SNAPSHOT.jar/
      |
      `database.ddl
      `database.sql
      |
      + META-INF\
        | 
        ` MANIFEST.MF
        | 
        + maven
          |
          + org.gteley/
            |
            `pom.properties
            `pom.xml
    |
    + classes/
      |
      `database.ddl
      `database.sql
      |
      + META-INF\
        | 
        + maven
          |
          ` remote-resources.xml
    |
    + maven-archiver/
      |
      ` pom.properties
    |
    + maven-shared-archive-resources/
    + test-classes/

This time, the remote-resources.xml correctly appears in the classes directory under classes/META-INF/maven/remote-resources.xml - but it does not get included in the Resource Bundle (test-0.0.1-SNAPSHOT.jar).

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. Hide
    Zip Archive
    test.zip
    24/Jun/11 1:52 AM
    2 kB
    Gareth Tudor Eley
    1. XML File
      test/pom.xml 0.8 kB
    2. File
      test/src/main/resources/database.ddl 0.0 kB
    3. File
      test/src/main/resources/database.sql 0.0 kB
    Download Zip
    Show
    Zip Archive
    test.zip
    24/Jun/11 1:52 AM
    2 kB
    Gareth Tudor Eley

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Robert Scholte added a comment - 09/Jan/12 5:00 PM - edited

I've added some formatting, but there seems to be a bug:
Where you read

$\{project.build.outputDirectory}

you should actually read ${project.build.outputDirectory}

Show
Robert Scholte added a comment - 09/Jan/12 5:00 PM - edited I've added some formatting, but there seems to be a bug: Where you read
$\{project.build.outputDirectory}
you should actually read ${project.build.outputDirectory}
Hide
Permalink
Robert Scholte added a comment - 10/Jan/12 1:56 PM

Even after adding some formatting it's still not clear to me what the real problem is?
Are you asking to make outputDirectory read-only, otherwise the result could be useless?
Do you want the outputDirectory to be relative to the ${project.build.outputDirectory} (i.e. target/classes)?

Maybe it would be easier to understand if you did something like this:

outputDirectory Expected result Actual result
(default) target/classes target/classes
Show
Robert Scholte added a comment - 10/Jan/12 1:56 PM Even after adding some formatting it's still not clear to me what the real problem is? Are you asking to make outputDirectory read-only, otherwise the result could be useless? Do you want the outputDirectory to be relative to the ${project.build.outputDirectory} (i.e. target/classes)? Maybe it would be easier to understand if you did something like this:
outputDirectory Expected result Actual result
(default) target/classes target/classes

People

  • Assignee:
    Unassigned
    Reporter:
    Gareth Tudor Eley
Vote (0)
Watch (0)

Dates

  • Created:
    24/Jun/11 1:52 AM
    Updated:
    10/Jan/12 1:56 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.