On 08/15/2011 03:25 PM, Vincent Massol wrote: > > On Aug 12, 2011, at 4:45 PM, Sergiu Dumitriu wrote: > >> On 08/12/2011 07:50 AM, Vincent Massol wrote: >>> Hi devs, >>> >>> Running mvn dependency:dependency-analyze produces interesting results. >>> >>> For example: >>> >>> [INFO] >>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> [INFO] Building XWiki Commons - Properties 3.2-SNAPSHOT >>> [INFO] >>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> … >>> [INFO] --- maven-dependency-plugin:2.3:analyze (default-cli) @ >>> xwiki-commons-properties --- >>> [WARNING] Used undeclared dependencies found: >>> [WARNING] org.slf4j:slf4j-api:jar:1.6.1:compile >>> [WARNING] javax.inject:javax.inject:jar:1:compile >>> [WARNING] Unused declared dependencies found: >>> [WARNING] >>> org.xwiki.commons:xwiki-commons-component-api:jar:3.2-SNAPSHOT:compile >>> [WARNING] org.xwiki.commons:xwiki-commons-test:jar:3.2-SNAPSHOT:test >>> [WARNING] org.hibernate:hibernate-validator:jar:4.2.0.Final:test >>> [WARNING] org.hamcrest:hamcrest-core:jar:1.1:test >>> [WARNING] org.jmock:jmock:jar:2.5.1:test >>> >>> The question is (for this module but more generally for all others): >>> * Should we add slf4j and javax.inject reps in the pom.xml for this module? >>> (for ex today slf4j and javax.inject are found in the component-api dep) >>> >>> I think we should, wdyt? >> >> +1 as well. > > hmm actually we need to decide about the following: > > * In order to simplify writing pom.xml for modules having components (i.e. > depending on xwiki-commons-component-api) I had added the following to > xwiki-commons-component-api/pom.xml: > > <!-- Make it easy for components that wish to log - They don't have to > explicitly import SLF4J --> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-api</artifactId> > </dependency> > > * In the same manner we have a dependency on javax.inject in > xwiki-commons-component-api/pom.xml: > > <!-- We add this dependency here so that users of the Component API just > need to depend on this artifact and > don't have to explicitly add a dependency on > javax.inject:java.inject. --> > <dependency> > <groupId>javax.inject</groupId> > <artifactId>javax.inject</artifactId> > <version>1</version> > </dependency> > > So the question is: do we want to force each module depending on > xwiki-commons-component-api to have to declare an explicit dep on > javax.inject and org.slf4j? > > I'm not so sure about that… > > WDYT?
Hm, personally I'm in favor of Yes, but not very strongly. These are utility dependencies, which don't add much value to the code; they're part of the "infrastructure". So it would make sense to list only "real" dependencies that influence the higher level code. On the other hand, it's simpler to have just one clear rule: list all used dependencies. This also makes it easier to hunt down and spot all users of a library in case we need to change it, like we recently did with log4j->slf4j. Another thing just came to my mind in favor of not listing them: Maven encourages reuse and convention-over-configuration, so it would be good to define common infrastructure in just one place instead of copy-pasting it everywhere. > Thanks > -Vincent > >>> Note that the "Unused declared dependencies found:" doesn't always generate >>> correct results as is the case here. This is mostly because it's a static >>> byte code check so any dep used at runtime will be considered unused. >>> See >>> http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependency-plugin.html >> >> Some of these dependencies are not used directly by us, but are needed >> transitively by another library. For example, slf4j needs logback, which >> we never use directly (although we don't really declare it in every >> module that does logging). Hibernate needs us to pick a cache, a >> connection pool, validator, and a bytecode manipulation utility. So yes, >> we can safely ignore most of these false negatives, but we should still >> try to remove those that are really wrongfully declared as dependencies. >> >>> Thanks >>> -Vincent -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
