Maven 2.x Ear Plugin

Allow exclusion of artifacts when building the ear file.

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.3.1
  • Fix Version/s: 2.7
  • Labels:
    None
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    2

Description

What is included in the .ear file is determined by the module list and the dependency list and its transitive dependencies. We are often confronted with changing demands about what to include in our ear files. It is quite hard to change our dependency management (scopes) every time without side-effects on other distributable artifacts. So I created an exclude configuration option which allows to exclude artifacts from the ear file based on regular expressions (java.util.regex) matching artifactIds and groupIds.

Use it like this:

<configuration>
   <excludes>
      <exclude>
         <groupId>be.nondistributable.*</groupId>
      </exclude>
   </excludes>
</configuration>
  1. Text File
    maven-ear-plugin-excludes.patch
    29/Jun/08 3:26 AM
    12 kB
    Dieter Houthooft
  2. Text File
    maven-ear-plugin-excludes-fixed.patch
    30/Jun/08 4:24 AM
    12 kB
    Dieter Houthooft

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dieter Houthooft added a comment -

There was a bug in the previous patch. Fixed + updated unit test.

Show
Dieter Houthooft added a comment - There was a bug in the previous patch. Fixed + updated unit test.
Hide
Permalink
Stéphane Nicoll added a comment -

That's interesting but we start having so many configuration options to manage the dependencies that I am afraid it becomes too much complex. We already have the excludes on the modules so we need to define a first-win strategy (and who wins on what).

Show
Stéphane Nicoll added a comment - That's interesting but we start having so many configuration options to manage the dependencies that I am afraid it becomes too much complex. We already have the excludes on the modules so we need to define a first-win strategy (and who wins on what).
Hide
Permalink
Maarten Billemont added a comment -

The current method of excluding dependencies is OK for excluding two or three.

It is UNMANAGABLE for excluding large groups of dependencies. Moreover, excluding transitive dependencies this way is utterly rediculous, especially when you have lots of them. You end up with a POM file that repeats x% of all the dependencies in your project, creating massive dublicate code which is hell to maintain.

For example, we want to exclude all non-in-house artifacts from the EAR generated; so that the EAR file we distribute contains only our own artifacts. The other dependencies, we put in the default/lib directory of our JBoss AS; they do not belong in the EAR file - where they only serve to bloat; especially when we're trying to build or deploy 4 EAR files, each with all of those dependencies in them.

Show
Maarten Billemont added a comment - The current method of excluding dependencies is OK for excluding two or three. It is UNMANAGABLE for excluding large groups of dependencies. Moreover, excluding transitive dependencies this way is utterly rediculous, especially when you have lots of them. You end up with a POM file that repeats x% of all the dependencies in your project, creating massive dublicate code which is hell to maintain. For example, we want to exclude all non-in-house artifacts from the EAR generated; so that the EAR file we distribute contains only our own artifacts. The other dependencies, we put in the default/lib directory of our JBoss AS; they do not belong in the EAR file - where they only serve to bloat; especially when we're trying to build or deploy 4 EAR files, each with all of those dependencies in them.
Hide
Permalink
Dennis Lundberg added a comment -

This is an interesting approach that I am interested in getting into the EAR Plugin. Although somewhat related to MEAR-60, this fills another need. It looks similar in concept to the packagingExcludes feature in the WAR Plugin. This feature is useful if you have multiple EARs that use a common "shared library" of JARs, where MEAR-60 in contrast is used to share JARs within the modules of a single EAR.

I'm also looking at MWAR-81, which is an enhancement to packagingExcludes to allow different "selectors", like regexp. There might be an overlap between these two. Even if it turns out there is no overlap, we should still try to use a common terminology when it comes to naming the configuration parameters.

Show
Dennis Lundberg added a comment - This is an interesting approach that I am interested in getting into the EAR Plugin. Although somewhat related to MEAR-60 , this fills another need. It looks similar in concept to the packagingExcludes feature in the WAR Plugin. This feature is useful if you have multiple EARs that use a common "shared library" of JARs, where MEAR-60 in contrast is used to share JARs within the modules of a single EAR. I'm also looking at MWAR-81 , which is an enhancement to packagingExcludes to allow different "selectors", like regexp. There might be an overlap between these two. Even if it turns out there is no overlap, we should still try to use a common terminology when it comes to naming the configuration parameters.
Hide
Permalink
Dennis Lundberg added a comment -

I found another approach to solve this issue that I feel works better.

It uses the same method that Maven WAR Plugin has, with packagingExcludes and packagingIncludes. These each take a comma-separated String of file patterns.

This was added in r1211419.

A new 2.7-SNAPSHOT has been deployed. Please give it a try.

You can look at the ITs that were added in that check-in for examples of how to configure it. I'll write up some documentation and add it to the site later on.

Show
Dennis Lundberg added a comment - I found another approach to solve this issue that I feel works better. It uses the same method that Maven WAR Plugin has, with packagingExcludes and packagingIncludes. These each take a comma-separated String of file patterns. This was added in r1211419 . A new 2.7-SNAPSHOT has been deployed. Please give it a try. You can look at the ITs that were added in that check-in for examples of how to configure it. I'll write up some documentation and add it to the site later on.
Hide
Permalink
Dennis Lundberg added a comment -

Documentation was added in r1212327.

Show
Dennis Lundberg added a comment - Documentation was added in r1212327 .

People

  • Assignee:
    Dennis Lundberg
    Reporter:
    Dieter Houthooft
Vote (4)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: