Maven Ear Plugin
  1. Maven Ear Plugin
  2. MEAR-149

skinnyWars and SNAPSHOT unique dependencies

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.7
    • Fix Version/s: 2.9
    • Labels:
      None
    • Environment:
      All
    • Patch Submitted:
      Yes
    • Number of attachments :
      1

      Description

      When trying to create skinnyWars, any SNAPSHOTS dependencies are not extracted out of WARs that have SNAPSHOT dependencies with unique timestamps. The AbstractFileNameMapping class uses the baseVersion to generate the filename which doesn't take into account timestamp dependencies, therefore the plugin is unable to delete any dependency in the libDir folder. Using the Artifact.version property will produce the correct filename for deletion.

      The really only affects DEV-produced artifacts where EARs are built for deployment and testing. Additionally, bloated EARs can affect repository managers where excessive disk space may not be available.

        Activity

        Hide
        Paul Vonnahme added a comment -

        I'm also seeing this issue.

        I'll also point out that if the person who built the war was using <outputFileNameMapping> feature of the war plugin, the ear plugin may not match any of the file names. Maybe you will need to have a <skinnyWarOutputFileNameMapping> option? Or would it be possible to pull the mapping from the war's pom.xml? In any case, I see that as a smaller issue than the SNAPSHOT dependencies. Ideally for now this patch could be applied, and support for <outputFileNameMapping> could be deferred if it's more of a major undertaking.

        In any case, the <skinnyWars> option is a great feature to have and I'm excited to see it mature.

        Show
        Paul Vonnahme added a comment - I'm also seeing this issue. I'll also point out that if the person who built the war was using <outputFileNameMapping> feature of the war plugin, the ear plugin may not match any of the file names. Maybe you will need to have a <skinnyWarOutputFileNameMapping> option? Or would it be possible to pull the mapping from the war's pom.xml? In any case, I see that as a smaller issue than the SNAPSHOT dependencies. Ideally for now this patch could be applied, and support for <outputFileNameMapping> could be deferred if it's more of a major undertaking. In any case, the <skinnyWars> option is a great feature to have and I'm excited to see it mature.
        Hide
        Geert Schuring added a comment - - edited

        I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a patch available that solves it. Could you (any committer) release 2.8.1 that includes this patch?

        Some detail about our situation: Because some jar is present twice in the ear file (once in ear file, and once in embedded war file), Weld throws an exception because it finds 2 candidates for 1 injection point and our ears cannot be deployed on our application server (Glassfish 3).

        Show
        Geert Schuring added a comment - - edited I'm running into this problem, and I must say that I'm quite stunned that this kind of bug is still present in the 2.8 version of the maven ear plugin, especially when there's a patch available that solves it. Could you (any committer) release 2.8.1 that includes this patch? Some detail about our situation: Because some jar is present twice in the ear file (once in ear file, and once in embedded war file), Weld throws an exception because it finds 2 candidates for 1 injection point and our ears cannot be deployed on our application server (Glassfish 3).
        Hide
        Robert Scholte added a comment -

        I've added a parameter so users can still use the baseVersion if they want. By default the version is used. This is the same as for other plugins which have this option.
        Fixed in r1540373

        Show
        Robert Scholte added a comment - I've added a parameter so users can still use the baseVersion if they want. By default the version is used. This is the same as for other plugins which have this option. Fixed in r1540373

          People

          • Assignee:
            Robert Scholte
            Reporter:
            Seth Rife
          • Votes:
            7 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: