Mojo
  1. Mojo
  2. MOJO-265

xdoclet plugin has wrong relative paths when used twice in multiproject environment

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: xdoclet
    • Labels:
      None
    • Environment:
      maven2.0.2, java 1.5, windows 2000
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      In a muliproject environment like so:
      --projectA
      ----ejb1
      ------pom1.xml
      ----ejb2
      ------pom2.xml

      Each pom.xml has an xdoclet-plugin defined which calls the ejbdoclet task to generate interfaces. The ejbdoclet tag takes a destination attribute, but it seems to be ignored the second time the plugin is run.

      For instance, if i change the destination dir="." in both, they will both get written to ejb1. If I make them "../ejb1" and "../ejb2" respectively, still both go to ejb1. etc...

      Other plugins used in each pom put items in the correct relative locations, so I'm pretty sure its not a config issue surrounding that.

        Activity

        Hide
        Mike Perham added a comment -

        I've noticed this behavior also in my hibernatedoclet invocations.

        Show
        Mike Perham added a comment - I've noticed this behavior also in my hibernatedoclet invocations.
        Hide
        kris helenek added a comment -

        I was able to work around it because each subtask of the ejbdoclet task also takes an optional destdir attribute, which it will recognize correctly. I guess it has something to do with inheriting the destdir from the encapsulating ejbdoclet task that is failing; probably by using the previously defined attribute from the earlier plugin call (ejb1.)

        So the workaround for now is to define all destdir's for all subtasks.

        Show
        kris helenek added a comment - I was able to work around it because each subtask of the ejbdoclet task also takes an optional destdir attribute, which it will recognize correctly. I guess it has something to do with inheriting the destdir from the encapsulating ejbdoclet task that is failing; probably by using the previously defined attribute from the earlier plugin call (ejb1.) So the workaround for now is to define all destdir's for all subtasks.
        Hide
        Mike Perham added a comment -

        Ant is obviously having problems resolving relative paths in multi-module scenarios. I think the lesson here is to never use relative paths and prefer the project-specific variables. Instead of using $

        {basedir}

        /src/main/java, use $

        {project.build.sourceDirectory}

        . Instead of using "target", use $

        {project.build.directory}

        .

        Show
        Mike Perham added a comment - Ant is obviously having problems resolving relative paths in multi-module scenarios. I think the lesson here is to never use relative paths and prefer the project-specific variables. Instead of using $ {basedir} /src/main/java, use $ {project.build.sourceDirectory} . Instead of using "target", use $ {project.build.directory} .
        Hide
        Mike Perham added a comment -

        Oops, it's not ant's fault. The root cause of this bug is an open issue in Xdoclet 1.2.3.

        http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1505

        Show
        Mike Perham added a comment - Oops, it's not ant's fault. The root cause of this bug is an open issue in Xdoclet 1.2.3. http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1505

          People

          • Assignee:
            Unassigned
            Reporter:
            kris helenek
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: