Maven Shared Components

Sample code is not working

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: file-management-1.2
  • Fix Version/s: file-management-1.2.2
  • Component/s: file-management
  • Labels:
    None
  • Environment:
    Windows XP Home SP2
    JDK 1.6.0_11
  • Number of attachments :
    0

Description

When running the code from this web site:

http://maven.apache.org/shared/file-management/examples/mojo.html

You will end up with the following problem:

Cause: Error loading class 'mypath.myplugin.Fileset'

The problem seems to be that the <fileset> child of the <configuration> pom.xml element is not translated to the corresponding "FileSet" (upper case S, package of the File Management API) class of Maven File Management API, but maven searches a "Fileset" (lower case S, different package) class in the custom plugin. So it seems the documentation on the web site is not complete, at least the part about "How to tell Maven how to map <fileset> to FileSet class?" is missing.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed doc in r748822.

The problem is that the proper type cannot be derived from the collection type of the field filesets. One either has to declare collection-like parameters as arrays (whose component type is available at runtime for DI) or provide a properly named class that extends the desired type in the same package as the mojo (cf. the sources of the Maven Clean Plugin). Using arrays has the additional benefit that the generated plugin documentation can better indicate the type to the user (i.e. FileSet[] vs. just List).

Show
Benjamin Bentmann added a comment - Fixed doc in r748822 . The problem is that the proper type cannot be derived from the collection type of the field filesets . One either has to declare collection-like parameters as arrays (whose component type is available at runtime for DI) or provide a properly named class that extends the desired type in the same package as the mojo (cf. the sources of the Maven Clean Plugin). Using arrays has the additional benefit that the generated plugin documentation can better indicate the type to the user (i.e. FileSet[] vs. just List ).
Benjamin Bentmann made changes -
Field Original Value New Value
Assignee Benjamin Bentmann [ bentmann ]
Fix Version/s fiile-managment 1.2.2 [ 14970 ]
Resolution Fixed [ 1 ]
Status Open [ 1 ] Closed [ 6 ]
Hide
Permalink
Markus KARG added a comment -

If your explanations enough are true then the generel plugin configuration guide is wrong too (see http://maven.apache.org/guides/plugin/guide-java-plugin-development.html) because it doesn't say that anything about the fact that the desired type must extend from List and be found in the same package as the mojo. So I would ask you to correct that general description, too, which only says:

Collections

This category covers any class which implements java.util.Collection such as ArrayList or HashSet. These parameters are configured by specifying the parameter multiple times just like an array. Example:

/**

  • My List.
    *
  • @parameter
    */
    private List myList;

<myList>
<param>value1</param>
<param>value2</param>
</myList>

Show
Markus KARG added a comment - If your explanations enough are true then the generel plugin configuration guide is wrong too (see http://maven.apache.org/guides/plugin/guide-java-plugin-development.html ) because it doesn't say that anything about the fact that the desired type must extend from List and be found in the same package as the mojo. So I would ask you to correct that general description, too, which only says: Collections This category covers any class which implements java.util.Collection such as ArrayList or HashSet. These parameters are configured by specifying the parameter multiple times just like an array. Example: /** My List. * @parameter */ private List myList; <myList> <param>value1</param> <param>value2</param> </myList>
Hide
Permalink
Benjamin Bentmann added a comment -

about the fact that the desired type must extend from List

Maybe you misunderstood me. In your example, the desired type is FileSet which need not extend List. The approach I meant was a custom type Fileset extends FileSet as already suggested in section "Parameter Types With Multiple Values", point 3.

Show
Benjamin Bentmann added a comment - about the fact that the desired type must extend from List Maybe you misunderstood me. In your example, the desired type is FileSet which need not extend List . The approach I meant was a custom type Fileset extends FileSet as already suggested in section "Parameter Types With Multiple Values", point 3.
Hide
Permalink
Markus KARG added a comment -

You are right, it is mentioned in point 3. The problem ist that nobody will remember about point 3 when reading the collections example. It would be great if you could add the note "This will inject two instance of the foo.bar.Param class into the List.". Also one wonders how the values "value1" and "value2" will get passed into the Param instances? What pattern will apply (i. e. what set* methods or constructors must exists to make this happen)?

Show
Markus KARG added a comment - You are right, it is mentioned in point 3. The problem ist that nobody will remember about point 3 when reading the collections example. It would be great if you could add the note "This will inject two instance of the foo.bar.Param class into the List.". Also one wonders how the values "value1" and "value2" will get passed into the Param instances? What pattern will apply (i. e. what set* methods or constructors must exists to make this happen)?

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Markus KARG
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: