On Mon, Aug 15, 2011 at 9:25 PM, Vincent Massol <[email protected]> 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…
I'm -0 and near -1 to list this kind of dependencies, using slf4j or javax.inject are what you HAVE TO use when you write an XWiki component so it's redundant from my POV. > > WDYT? > > 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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
