5 Jun
2014
5 Jun
'14
3:23 p.m.
> Ok, I rephrase my question.
> Could you define what you consider a usage of dependency A because of B and the
opposite?
I'll dare explaining
Indirect dependency (no dependency on A should be defined in C):
C ----> B ----> A
* C uses classes from B
* B uses classes from A
* C does NOT use classes from A
Direct dependency (explicit dependency on A should be defined in C)
C ----> B ----> A
\_ _ _ _ _ _ _^
* C uses classes from B
* B uses classes from A
* C uses classes from A
-----Original Message-----
From: devs [mailto:devs-bounces@xwiki.org] On Behalf Of Denis Gervalle
Sent: Thursday, June 05, 2014 16:10 PM
To: XWiki Developers
Subject: Re: [xwiki-devs] [Proposal] Cleaning our POM deps by explicitly listing used
dependencies?
On Thu, Jun 5, 2014 at 2:27 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
On Thu, Jun 5, 2014 at 2:14 PM, Denis Gervalle
<dgl(a)softec.lu> wrote:
But you may not see that so easily when you change a few line in an existing module.
Nothing will complains until you remove your deps to B.
What happen if you also use dependency A not just
because of B ?
You put a dependency on A.
How do you determine "because of B" ?
By thinking.
And what to you think of xwiki-commons-test-component that is a deps
of xwiki-platform-core ?
It's wrong IMO. Any forced dependency is wrong IMO.
Should we remove it ?
Yes we should remove it.
What about deps for logging ?
Depends how you use it, the logger used with @Inject is an official
feature of our component framework so xwiki-commons-component-api
should be enough.
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) ?
It's far from being used everywhere and there is no rule forcing to
use it, you set @Unstable when an API is unstable, it's not forbidden
to not go through @Unstable. Plus you are supposed to remove that
annotation after some time.
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-dep
endency-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,
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> >> 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