What happen if you also use dependency A not just because of B ?
How do you determine "because of B" ?
And what to you think of xwiki-commons-test-component that is a deps of
xwiki-platform-core ?
Should we remove it ? What about deps for logging ?
And could we add xwiki-commons-stability (probably provided scope) to a
high level pom to avoid adding/removing it all the time ? (or forget it,
since it come with xwiki-commons-component-api currently) ?
WDYT ?
On Thu, Jun 5, 2014 at 11:42 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
  For me the rule to apply is simple: when you require
dependency A
 because of another dependency B (B expose A in it's API, you implement
 an interface of A to be found by B, etc.) you should not explicitly
 depend on A.
 On Thu, Jun 5, 2014 at 11:32 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
  Hi devs,
 I am reviving this proposal since we never came to a conclusion, and I 
 have
  the feeling that our deps become more and more
convoluted.
 To resume what I get from past history with my own vision:
 1) Since our modules are getting really modular, it should never silently
 depends on transitive dependency of another module (with IMO some
 exception, see 3). So any undeclared deps found by dependency:analyse
 should be explicitly declare in the effective pom (Vincent POV as well)
 2) Apply maven principle, we should reuse and apply
 convention-over-configuration
 over configuration, so common dependency like slf4j, 
 xwiki-commons-stability
  ? ... should be in a high level parent pom
 3) We may rely on some very tight transitive dependency, for exemple, it
 would be really curious that xwiki-commons-component-api stop providing
 javax.inject, or that xwki-commons-test-components stop providing junit,
 mockito, and al.
 It would be nice to add those rules in our best practice and to always
 check our pom upon finishing changes in a module. The best would be to
 enforce those rules, but this is not easy since static analysis is 
 limited
  and could create false positive.
 WDYT ?
 On Mon, Aug 15, 2011 at 10:31 PM, Thomas Mortagne < 
 thomas.mortagne(a)xwiki.com
   wrote:
> On Mon, Aug 15, 2011 at 9:25 PM, Vincent Massol <vincent(a)massol.net>
  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-dependen…
 > >>
> >> 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
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
 
 --
 Thomas Mortagne
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
  
 --
 Denis Gervalle
 SOFTEC sa - CEO
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs  
 --
 Thomas Mortagne
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs