Return-Path: 
 <dev-return-109617-apmail-maven-dev-archive=maven.apache.org@maven.apache.org>
X-Original-To: apmail-maven-dev-archive@www.apache.org
Delivered-To: apmail-maven-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id DB4B3104DD
	for <apmail-maven-dev-archive@www.apache.org>;
 Mon,  7 Apr 2014 10:53:25 +0000 (UTC)
Received: (qmail 47991 invoked by uid 500); 7 Apr 2014 10:53:23 -0000
Delivered-To: apmail-maven-dev-archive@maven.apache.org
Received: (qmail 47256 invoked by uid 500); 7 Apr 2014 10:53:21 -0000
Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@maven.apache.org>
List-Help: <mailto:dev-help@maven.apache.org>
List-Post: <mailto:dev@maven.apache.org>
List-Id: "Maven Developers List" <dev.maven.apache.org>
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Delivered-To: mailing list dev@maven.apache.org
Received: (qmail 47244 invoked by uid 99); 7 Apr 2014 10:53:19 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 10:53:19 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of lennart.jorelid@gmail.com
 designates 209.85.216.171 as permitted sender)
Received: from [209.85.216.171] (HELO mail-qc0-f171.google.com)
 (209.85.216.171)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2014 10:53:14 +0000
Received: by mail-qc0-f171.google.com with SMTP id c9so6127483qcz.2
        for <dev@maven.apache.org>; Mon, 07 Apr 2014 03:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=3shgpItVZ2kqnxHHEB/2aRjLVkDkASv93xu+Z3u6A1E=;
        b=Km5F1xSnfBScvsorJjZOCyaeJgk1UzDeh67KUT0QqCVPsVwfXq9iTMYRn4EfAqWXsD
         MoRPE7o4IF8MvUA36w8tOwhfY7e8cxxovlCUsf5IBPyT7rSWcnZdfYq1ZgVdzXRsoi6K
         pU6dqEkj7PqCv/EgonN33l6bB8DTFICNlU2p6BkJqiO5gEBa6mjL0ECB8Cq8QzGH6hWN
         zKs9c6wuVsPsayWwCSO2jLXjSzGYcqTu9W6nA/HEiLVNfHrCZPkRTmhSGVwnxcndIgfe
         F4SvKa2NklmIK1WPEMXlpnvTRWZhBpzQIskWdb9MLWskTzlBvKthShFr16I5j6kry6GT
         zXKQ==
MIME-Version: 1.0
X-Received: by 10.224.112.6 with SMTP id u6mr7959115qap.78.1396867972345; Mon,
 07 Apr 2014 03:52:52 -0700 (PDT)
Received: by 10.140.109.181 with HTTP; Mon, 7 Apr 2014 03:52:52 -0700 (PDT)
In-Reply-To: 
 <CAKDUN1uVQ1PTzqnrTPzrO3S+7ECkU6XmOed2mXVHi1_syvDCoA@mail.gmail.com>
References: <DD5253C3-6655-4805-ACC9-536F9B92533F@takari.io>
	<op.xdwqqr2gkdkhrr@robertscholte>
	<52FBCC7C-BC87-4304-8D58-7AD3F8FA897C@talios.com>
	<CALhtWkd2SKACDZMokWupVLh6oA2WteoRoT9qs9ez=T0NR=SvcQ@mail.gmail.com>
	<A43E3BE5-7994-4D1C-A6C8-9308B990BB36@talios.com>
	<CAJ1fz82WJu+CdLQ-iRNnA7LdSxkoHNhPBkhNBv6+kVm7K1SPqA@mail.gmail.com>
	<CAKDUN1uVQ1PTzqnrTPzrO3S+7ECkU6XmOed2mXVHi1_syvDCoA@mail.gmail.com>
Date: Mon, 7 Apr 2014 12:52:52 +0200
Message-ID: 
 <CAJ1fz82bEEhZv12TP=b_DdkNCU4MMSeSEtJO1YdabcKU1+1Lxw@mail.gmail.com>
Subject: Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject
 dependencies
From: =?ISO-8859-1?Q?Lennart_J=F6relid?= <lennart.jorelid@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2e8484a329104f671abe4
X-Virus-Checked: Checked by ClamAV on apache.org

--001a11c2e8484a329104f671abe4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, I realize what Mark was referring to - but I still cannot see the
point in having to repeat oneself WRT importing an already imported
compile-scope dependency in all projects where it would be used. This would
imply loads of redundant imports in all dependent poms in a multi-module
reactor along the lines of:

        <dependency>
            <groupId>a.project.a.domain</groupId>
            <artifactId>mydomain-model</artifactId>
        </dependency>

I would claim the contrary position to Mark's - I would not want to litter
all poms in the reactor with the dependency above just because it is
imported in a project onto which several/most/all other projects in the
reactor depends. This approach violates the DontRepeatYourself principle
quite a lot. Moreover, since the dependency *is* required to get the
dependent projects to run properly I can see quite a few reasons why it
would break existing builds. Simply passing a type from the mydomain-model
as an argument to a method in a publicly available interface implies that
the mydomain-model project is required transitively.

Moreover - I find the dependency mechanism broken in the other direction
compared to Mark's view; presently we have to repeat all provided-scope
depedencies in the reactor since they are not transitively spread as
dependencies to importing projects. Loads of unnecessary POM repetition
follows, which is less than ideal since the POM can get quite bloated as
is. I would rather suggest that we need new transitive scope semantics for
provided-scope dependencies to prevent us from unnecessarily repeating
these several times in a multimodule reactor.

Thus ... I'm asking because I assume that Mark sees something I have missed
in the pom transitivity mechanism, and I want to know what that might be.


2014-04-07 9:42 GMT+02:00 Anders Hammar <anders@hammar.net>:

> I believe he's talking about what's mentioned here (see the asterix):
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-me=
chanism.html#Dependency_Scope
>
> /Anders
>
>
> On Mon, Apr 7, 2014 at 9:37 AM, Lennart J=F6relid
> <lennart.jorelid@gmail.com>wrote:
>
> > I don't understand the difference between what you suggest here, Mark,
> and
> > simply disabling transitive dependencies.
> > Could you elaborate somewhat?
> >
> >
> > 2014-04-07 3:41 GMT+02:00 Mark Derricutt <mark@talios.com>:
> >
> > > On 7 Apr 2014, at 12:32, Benson Margulies wrote:
> > >
> > >  We then have other logical classpaths. . Something like javadoc shou=
ld
> > >> be able to define another named classpath structure; combining the
> > >> dependencies of the plugin's implementation with dynamic code
> > >> (doclets, whatever) seems like a category confusion to me.
> > >>
> > >
> > > If we change/break this - can we PLEASE make the compilation path
> IGNORE
> > > transitive dependencies of 'compile' dependencies - if I -need- it to
> > > compile, -I- should depend on it up front.
> > >
> > >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> >
> > --
> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D+
> > | B=E4sta h=E4lsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart J=F6relid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | M=F6lnlycke - Kista
> > |
> > | Email: lj@jguru.se
> > | URL:   www.jguru.se
> > | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D+
> >
>



--=20

--
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D+
| B=E4sta h=E4lsningar,
| [sw. "Best regards"]
|
| Lennart J=F6relid
| EAI Architect & Integrator
|
| jGuru Europe AB
| M=F6lnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D+

--001a11c2e8484a329104f671abe4--