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

Property to disable transitive dependencies resolving

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Number of attachments :
      3

      Description

      We have ears with a lot of modules. So the transitive dependencies are very huge and to exclude all these with <excluded>true</excluded> is no option. Also to mark these dependencies with optional is no way. It is possible to create a new property for that?

      1. patch.txt
        3 kB
        Thomas Hart
      2. patch2.txt
        1 kB
        Thomas Hart
      1. ear.jpg
        12 kB

        Issue Links

          Activity

          Hide
          Stéphane Nicoll added a comment -

          Not sure it's EAR-plugin related. This sounds more like a maven-core functionnality to me.

          Show
          Stéphane Nicoll added a comment - Not sure it's EAR-plugin related. This sounds more like a maven-core functionnality to me.
          Hide
          Thomas Hart added a comment -

          Sorry i'm a maven newbie, i don't know where the right position is. But I think the following code block include the unwanted dependencies.

          org.apache.maven.plugin.ear.AbstractEarMojo
          ScopeArtifactFilter filter = new ScopeArtifactFilter( Artifact.SCOPE_RUNTIME );
          if ( !isArtifactRegistered( artifact, allModules ) && !artifact.isOptional() &&
            filter.include( artifact ) )
          {
              EarModule module = EarModuleFactory.newEarModule( artifact, defaultLibBundleDir );
              allModules.add( module );
          }
          

          I try to use the excludeTransitive parameter for the dependency:resolve-plugins mojo. Maybe that works for me.

          Show
          Thomas Hart added a comment - Sorry i'm a maven newbie, i don't know where the right position is. But I think the following code block include the unwanted dependencies. org.apache.maven.plugin.ear.AbstractEarMojo ScopeArtifactFilter filter = new ScopeArtifactFilter( Artifact.SCOPE_RUNTIME ); if ( !isArtifactRegistered( artifact, allModules ) && !artifact.isOptional() && filter.include( artifact ) ) { EarModule module = EarModuleFactory.newEarModule( artifact, defaultLibBundleDir ); allModules.add( module ); } I try to use the excludeTransitive parameter for the dependency:resolve-plugins mojo. Maybe that works for me.
          Hide
          Stéphane Nicoll added a comment -

          Mmmm, true.

          What you're asking is disabling transitive deps altogether or you want to disable them for a particular dependency?

          Show
          Stéphane Nicoll added a comment - Mmmm, true. What you're asking is disabling transitive deps altogether or you want to disable them for a particular dependency?
          Hide
          Thomas Hart added a comment -

          In my case altogether.

          Show
          Thomas Hart added a comment - In my case altogether.
          Hide
          Thomas Hart added a comment -

          I check the dependency plugin, it doesn't work. Can i submit a patch, that excludes the code block above?

          Show
          Thomas Hart added a comment - I check the dependency plugin, it doesn't work. Can i submit a patch, that excludes the code block above?
          Hide
          Stéphane Nicoll added a comment -

          no It won't do what you expect.

          Show
          Stéphane Nicoll added a comment - no It won't do what you expect.
          Hide
          Stéphane Nicoll added a comment -

          WDYM when you say "it doen't work"?

          Show
          Stéphane Nicoll added a comment - WDYM when you say "it doen't work"?
          Hide
          Thomas Hart added a comment -

          I mean that the dependency:resolve with the property excludeTransitive don't have any effects to the ear plugin.

          The patch works for me. The following pom.xml produces the right ear (see image). Only the dependencies are included not the transitive dependencies.

          ...
               <plugin>
                  <groupId>org.apache.maven.plugins</groupId>
                  <artifactId>maven-ear-plugin</artifactId>
                  <version>2.3.1-SNAPSHOT</version>
                  <configuration>
                    <excludeTransitive>true</excludeTransitive>
                    <version>5</version>
                    <defaultLibBundleDir>lib</defaultLibBundleDir>
                    <modules>
                      <ejbModule>
                        <groupId>suite4p.enabler.jb402</groupId>
                        <artifactId>suite4p.enabler.jb402.server</artifactId>
                      </ejbModule>
                    </modules>
                    <jboss>
                      <version>4</version>
                    </jboss>
                  </configuration>
                </plugin>
              </plugins>
            </build>
            
            <dependencies>
              <dependency>
                <groupId>suite4p.enabler.jb402</groupId>
                <artifactId>suite4p.enabler.jb402.server</artifactId>
                <type>ejb</type>
              </dependency>
            </dependencies>
          
          Show
          Thomas Hart added a comment - I mean that the dependency:resolve with the property excludeTransitive don't have any effects to the ear plugin. The patch works for me. The following pom.xml produces the right ear (see image). Only the dependencies are included not the transitive dependencies. ... <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-ear-plugin </artifactId> <version> 2.3.1-SNAPSHOT </version> <configuration> <excludeTransitive> true </excludeTransitive> <version> 5 </version> <defaultLibBundleDir> lib </defaultLibBundleDir> <modules> <ejbModule> <groupId> suite4p.enabler.jb402 </groupId> <artifactId> suite4p.enabler.jb402.server </artifactId> </ejbModule> </modules> <jboss> <version> 4 </version> </jboss> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupId> suite4p.enabler.jb402 </groupId> <artifactId> suite4p.enabler.jb402.server </artifactId> <type> ejb </type> </dependency> </dependencies>
          Hide
          Stéphane Nicoll added a comment -

          > I mean that the dependency:resolve with the property excludeTransitive don't have any effects to the ear plugin.

          Well I wonder how it could have any effect.

          And your patch is plain wrong anyway: it works as a side effect. since you have a single dependency and non scope dependencies. Trust me, your simple project does not reflect how this plugin is used at all.

          Show
          Stéphane Nicoll added a comment - > I mean that the dependency:resolve with the property excludeTransitive don't have any effects to the ear plugin. Well I wonder how it could have any effect. And your patch is plain wrong anyway: it works as a side effect. since you have a single dependency and non scope dependencies. Trust me, your simple project does not reflect how this plugin is used at all.
          Hide
          Stéphane Nicoll added a comment -

          also note that you don't need the ejbModule entry at all. It's only used if you want to customize module's parameters (bundle file name, uri, etc)

          Show
          Stéphane Nicoll added a comment - also note that you don't need the ejbModule entry at all. It's only used if you want to customize module's parameters (bundle file name, uri, etc)
          Hide
          Thomas Hart added a comment -

          Ok i see it. Your are right, the patch is wrong.

          Please give me a second try, i think project.getArtifacts() is the right place. To get the list with no transitive dependencies simply use project.getDependencyArtifacts().

          Show
          Thomas Hart added a comment - Ok i see it. Your are right, the patch is wrong. Please give me a second try, i think project.getArtifacts() is the right place. To get the list with no transitive dependencies simply use project.getDependencyArtifacts() .
          Hide
          Kaizer Sogiawala added a comment -

          Hi Stephane,

          Any chance of getting this in? Looks like the above change will not affect the normal flow. This allows folks to explicitly choose what gets EARed up and not worry about transitive dependencies.

          Show
          Kaizer Sogiawala added a comment - Hi Stephane, Any chance of getting this in? Looks like the above change will not affect the normal flow. This allows folks to explicitly choose what gets EARed up and not worry about transitive dependencies.
          Hide
          Stéphane Nicoll added a comment -

          It's missing test cases so I need to write them first. But that sounds reasonable indeed. It's just not complete as a patch for now.

          Show
          Stéphane Nicoll added a comment - It's missing test cases so I need to write them first. But that sounds reasonable indeed. It's just not complete as a patch for now.
          Hide
          Kannan Kesavan added a comment -

          Hi,

          We are also facing same issue in maven-ear-plugin. In our project, one of our transitive dependency using ".so" files. In that project, they didn't specify any scope for ".so" files. Also it is not possible for us to give scope (entirely different project, and it is not in our hands to change/give scope). Finally when we build our ear module, it is throwing unknown artifact types[so].

          Could you please let me know when it will be fixed?

          Thanks,
          Kannan

          Show
          Kannan Kesavan added a comment - Hi, We are also facing same issue in maven-ear-plugin. In our project, one of our transitive dependency using ".so" files. In that project, they didn't specify any scope for ".so" files. Also it is not possible for us to give scope (entirely different project, and it is not in our hands to change/give scope). Finally when we build our ear module, it is throwing unknown artifact types [so] . Could you please let me know when it will be fixed? Thanks, Kannan
          Hide
          Stéphane Nicoll added a comment -

          you can exclude the dependency. Defining the so dependency again with scope provided will most probably fix the issue

          Show
          Stéphane Nicoll added a comment - you can exclude the dependency. Defining the so dependency again with scope provided will most probably fix the issue
          Hide
          Robert Scholte added a comment -

          I think this should be closed as won't fix. This kind of information should be solved in the dependencies-section of the pom.xml by specifying the excludes. Otherwise Maven will still try to download these (transitive) dependencies, even though they are not added to the ear.

          Show
          Robert Scholte added a comment - I think this should be closed as won't fix . This kind of information should be solved in the dependencies-section of the pom.xml by specifying the excludes. Otherwise Maven will still try to download these (transitive) dependencies, even though they are not added to the ear.
          Hide
          Max Schaefer added a comment -

          This would really be an appreciated feature because it would save me to configure all my transitive dependency excludes in pom.xml i.e. would increase
          readability: less configuration and
          maintainability: no need to check for new transitive dependencies on update of a module

          Show
          Max Schaefer added a comment - This would really be an appreciated feature because it would save me to configure all my transitive dependency excludes in pom.xml i.e. would increase readability: less configuration and maintainability: no need to check for new transitive dependencies on update of a module
          Hide
          Robert Scholte added a comment -

          r1544305 is an integration test which confirm that the following construction works for Maven3:

              <dependency>
                <groupId>GROUPID</groupId>
                <artifactId>ARTIFACTID</artifactId>
                <version>VERSION</version>
                <exclusions>
                  <exclusion>
                    <groupId>*</groupId>
                    <artifactId>*</artifactId>
                  </exclusion>
                </exclusions>
              </dependency>
          

          So it seems like Aether has already implemented the wildcard expressions for exclusions. Since this is the correct way, I'm not going to provide a solution just for M2.

          Show
          Robert Scholte added a comment - r1544305 is an integration test which confirm that the following construction works for Maven3: <dependency> <groupId> GROUPID </groupId> <artifactId> ARTIFACTID </artifactId> <version> VERSION </version> <exclusions> <exclusion> <groupId> * </groupId> <artifactId> * </artifactId> </exclusion> </exclusions> </dependency> So it seems like Aether has already implemented the wildcard expressions for exclusions. Since this is the correct way, I'm not going to provide a solution just for M2.

            People

            • Assignee:
              Robert Scholte
              Reporter:
              Thomas Hart
            • Votes:
              11 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: