[m2] best practices on defining dependencies: i.e. how to avoid the kitchen sink

[Barrie Treloar <ba...@gmail.com>]

I just added a dependency on EasyConf
      <dependency>
        <groupId>easyconf</groupId>
        <artifactId>easyconf</artifactId>
        <version>0.9.5</version>
      </dependency>

and now I have a lot of dependencies which I don't need.

I think this is because the dependencies listed in EasyConf pom needs
to be more strictly defined. For example there are api dependencies
and implementation dependencies, and some dependencies are runtime
optional (but not marked as such)

So is there a recommended best practice for defining dependencies?

Looking at EasyConf as an example I think:

APIs should be compile (the default)
Implementations should be runtime, and if they are extra features
should also be defined optional.

What happens when you are not using an optional feature? Because the
API is needed to compile the artifact itself then it will also be
included when I depend on that artifact even though I am not using
that feature.  Should the API also be marked as optional then?

I'm sure there are probably other pom's out there that do not
correctly define the dependencies. So in these cases what is the
suggested way of overriding them so they are not included?  Including
the dependency again and using optional doesn't fix the problem,
nor does changing the scope to provided, but this might be because
EasyConf depends on xdoclet:xdoclet:jar:1.2.1 which is not available
at ibiblio.

Cheers
Bae

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] best practices on defining dependencies: i.e. how to avoid the kitchen sink

[Denis Cabasson <de...@insee.fr>]

Two things can be done on this matter:

Short term solution: add an extra excludes/exclude element to your
dependency which allows for transitive dependencies filtering. (You can
include it in your dependencyManagement section of your parent pom if your
project is multi-module).

Long term solution: If you are confident pom is wrong and dependency
scope/optionnal shoudl be corrected, you can submit an issue to
http://jira.codehaus.org/browse/MEV after having read
http://maven.apache.org/guides/mini/guide-maven-evangelism.html

Denis


baerrach wrote:
> 
> I'm sure there are probably other pom's out there that do not
> correctly define the dependencies. So in these cases what is the
> suggested way of overriding them so they are not included?  Including
> the dependency again and using optional doesn't fix the problem,
> nor does changing the scope to provided, but this might be because
> EasyConf depends on xdoclet:xdoclet:jar:1.2.1 which is not available
> at ibiblio.
> 
> Cheers
> Bae
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-m2--best-practices-on-defining-dependencies%3A-i.e.-how-to-avoid-the-kitchen-sink-tf2070286.html#a5701865
Sent from the Maven - Users forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] best practices on defining dependencies: i.e. how to avoid the kitchen sink

[Barrie Treloar <ba...@gmail.com>]

> I'm sure there are probably other pom's out there that do not
> correctly define the dependencies. So in these cases what is the
> suggested way of overriding them so they are not included?  Including
> the dependency again and using optional doesn't fix the problem,
> nor does changing the scope to provided, but this might be because
> EasyConf depends on xdoclet:xdoclet:jar:1.2.1 which is not available
> at ibiblio.

Maybe you can use the hacks I described above, it would have helped
had I not done the n00b thing and forget to install the parent pom
which has the dependency management section in it...

However the correct way is to add an exclusions section to the dependency:
Something like:

      <dependency>
        <groupId>easyconf</groupId>
        <artifactId>easyconf</artifactId>
        <version>0.9.5</version>
      <!-- EasyConf workaround for poor dependency definitions
      i.e. bringing in the kitchen sink -->
        <exclusions>
          <exclusion>
            <groupId>struts</groupId>
            <artifactId>struts</artifactId>
          </exclusion>
          ...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org