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

        Hide
        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 ).
        Hide
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: