Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3F12F200B5B for ; Fri, 5 Aug 2016 14:51:44 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 3D88E160A8E; Fri, 5 Aug 2016 12:51:44 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3A6F4160A6D for ; Fri, 5 Aug 2016 14:51:43 +0200 (CEST) Received: (qmail 57173 invoked by uid 500); 5 Aug 2016 12:51:42 -0000 Mailing-List: contact user-help@karaf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@karaf.apache.org Delivered-To: mailing list user@karaf.apache.org Received: (qmail 57163 invoked by uid 99); 5 Aug 2016 12:51:42 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Aug 2016 12:51:42 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id E22611863C5 for ; Fri, 5 Aug 2016 12:51:41 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.179 X-Spam-Level: * X-Spam-Status: No, score=1.179 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=basistech.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id GTsBSjnmrrFo for ; Fri, 5 Aug 2016 12:51:38 +0000 (UTC) Received: from mail-ua0-f173.google.com (mail-ua0-f173.google.com [209.85.217.173]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id 121515F238 for ; Fri, 5 Aug 2016 12:51:37 +0000 (UTC) Received: by mail-ua0-f173.google.com with SMTP id 74so11863267uau.0 for ; Fri, 05 Aug 2016 05:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basistech.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8m1+pVrgqqfxm//hFksJTGXlNGQ+M3Os4kq3N2Se7X8=; b=WaajdCJ6rfJ+up6pQ+1dp3qL4e922yHotUufXBzxM+ehnd20h84AFHFcDefhuDX/7t 8ew3AbzUwJuwDsHZHZA0IGCkl+iITarnvUsLsGbUfYoXJDtcNNtfp+Jn/PTXRgrFTb+9 FtmnbTeuprVlByAGownjYmoEuvJbczr46GB8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=8m1+pVrgqqfxm//hFksJTGXlNGQ+M3Os4kq3N2Se7X8=; b=MrsYractSoR76WDkQ8xW4k0sYsHsrjV+hFwcp02M7QNS+IkzaYejHjOhK0r/iVLkRe Szsp84z6ejKAHmS4/lYFxwqOD/CYKTz+B698crKd7aQ8T6BunsASN9HCbFDo3ua2Z+Rf f9sC9Q5eKEq7m2D2splp/XBULOEBV/qi/l6UwAc/qQdR4kW3n502vKzIJrIbQ2FY6bzR GqXXWtnRVHCFSVXpD28b0OKtfOXuYcD9H+eMyzafmJHU4KX2ibqz5wQfWJdP4EznNMj8 8SigCvv/+0+RMejWhSx7AHaL1mL3X3tVsTFFjsy8JBsPSidhYaJf6fsrufW69dJVKIEL /4Zg== X-Gm-Message-State: AEkoout4eGFGuJlBVSLzqRJDQYTQEtuCdCO/87bAYa5m2I3hc0Dwc8RM4EI8XnvPNGOkY002kM82jPwH+N93I6+G X-Received: by 10.159.40.74 with SMTP id c68mr39871627uac.9.1470401490663; Fri, 05 Aug 2016 05:51:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.90.199 with HTTP; Fri, 5 Aug 2016 05:51:30 -0700 (PDT) In-Reply-To: <597D6CEB-B4CC-459B-AB0E-3E23ACFDBE5B@gmail.com> References: <597D6CEB-B4CC-459B-AB0E-3E23ACFDBE5B@gmail.com> From: Benson Margulies Date: Fri, 5 Aug 2016 08:51:30 -0400 Message-ID: Subject: Re: transitive dependencies of feature descriptors To: user@karaf.apache.org Content-Type: multipart/alternative; boundary=94eb2c04486a878ad5053952864d archived-at: Fri, 05 Aug 2016 12:51:44 -0000 --94eb2c04486a878ad5053952864d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 5, 2016 at 8:41 AM, Daniel McGreal wrote: > Hi, > I tend to prefer setting scope of the dependencies to =E2=80=98provided= =E2=80=99, either > in the 'aggregator=E2=80=99 or by using dependencyManagement in features.= This > means you can stack the features files without having to re-exclude the > transitives you=E2=80=99re not interested in. > Best, Dan. > I'm experimenting with this. it can get a little messy when someone else has done a bad job on the same task. If some OSGi bundle has a mixture of OSGi and non-OSGi dependencies (and I've seen this in servicemix), and I mark it provided, I have to then redeclare the OSGi dependences at scope compile. It may be the least messy solution. thanks. > > On 5 Aug 2016, at 13:33, Benson Margulies wrote: > > > > On Fri, Aug 5, 2016 at 8:32 AM, Jean-Baptiste Onofr=C3=A9 > wrote: > >> You mean that you use the karaf-maven-plugin to generate the features.xm= l >> ? >> > > JB, > > Yes, I always use the plugin. > Regards, benson > > > >> >> Regards >> JB >> >> On 08/05/2016 02:28 PM, Benson Margulies wrote: >> >>> JB, >>> >>> The jar files incorporated in the uber jar show up in the dependency >>> graph and thus reappear in as 'wrap:' bundles in features. >>> >>> If project X declares a dependency on feature F, then the dependencies >>> of feature F are considered as bundles in project X's feature, because >>> they are part of project X's overall dependency graph. the >>> karaf-maven-plugin does not filter them out, even though F is accounted >>> for as an aggregated feature. >>> >>> Regards, >>> benson >>> >>> >>> On Fri, Aug 5, 2016 at 8:09 AM, Jean-Baptiste Onofr=C3=A9 >> > wrote: >>> >>> Hi Benson, >>> >>> honestly, I don't understand your point ;) >>> >>> You have an "uber" bundle containing packages, and this bundle is i= n >>> a feature. >>> >>> This feature can be used as an inner feature. >>> >>> So what's the point ? >>> >>> Regards >>> JB >>> >>> >>> On 08/05/2016 02:03 PM, Benson Margulies wrote: >>> >>> Folks, I wonder if someone else has found a way out of this. >>> >>> Consider a project that builds an OSGi bundle by aggregating so= me >>> non-OSGi jar Maven dependencies. Those dependencies are in the >>> dependency tree of the resulting bundle. >>> >>> Now, consider what happens if you generate a feature to contain >>> that >>> bundle. You can carefully exclude artifactIds to ensure that >>> these >>> embedded jars do not show up in the feature.xml as 'wrap' >>> bundles. >>> >>> However, there are still in the dependency graph of the feature >>> itself. >>> >>> So, when you write a dependency _on the feature_ to incorporate >>> that >>> feature in a larger system, now the non-OSGi bundles are back i= n >>> the >>> picture. You then have to write Maven for them all >>> over again. >>> >>> If I wrote a patch to the karaf-maven-plugin to exclude >>> non-feature >>> dependencies of features, would some committer commit it? >>> >>> >>> -- >>> Jean-Baptiste Onofr=C3=A9 >>> jbonofre@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >>> >> -- >> Jean-Baptiste Onofr=C3=A9 >> jbonofre@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > --94eb2c04486a878ad5053952864d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 5, 2016 at 8:41 AM, Daniel McGreal <d.j.mcgreal@gmail.= com> wrote:
Hi,
I tend to prefer setting scope of the dependen= cies to =E2=80=98provided=E2=80=99, either in the 'aggregator=E2=80=99 = or by using dependencyManagement in features. This means you can stack the = features files without having to re-exclude the transitives you=E2=80=99re = not interested in.
Best, Dan.

I'm experimenting with this. it can get a little messy when so= meone else has done a bad job on the same task.

If= some OSGi bundle has a mixture of OSGi and non-OSGi dependencies (and I= 9;ve seen this in servicemix), and I mark it provided, I have to then redec= lare the OSGi dependences at scope compile. It may be the least messy solut= ion.

thanks.


=C2=A0

On 5 Aug 2016= , at 13:33, Benson Margulies <benson@basistech.com> wrote:



On F= ri, Aug 5, 2016 at 8:32 AM, Jean-Baptiste Onofr=C3=A9 <= ;jb@nanthrax.net&g= t; wrote:
You mean that you use th= e karaf-maven-plugin to generate the features.xml ?
JB,

Yes, I always use the plugin.=C2= =A0
Regards, benson

=C2=A0

Regards
JB

On 08/05/2016 02:28 PM, Benson Margulies wrote:
JB,

The jar files incorporated in the uber jar show up in the dependency
graph and thus reappear in as 'wrap:' bundles in features.

If project X declares a dependency on feature F, then the dependencies
of feature F are considered as bundles in project X's feature, because<= br> they are part of project X's overall dependency graph. the
karaf-maven-plugin does not filter them out, even though F is accounted
for as an aggregated feature.

Regards,
benson


On Fri, Aug 5, 2016 at 8:09 AM, Jean-Baptiste Onofr=C3=A9 <jb@nanthrax.net
=
<mailto:jb@nanthrax= .net>> wrote:

=C2=A0 =C2=A0 Hi Benson,

=C2=A0 =C2=A0 honestly, I don't understand your point ;)

=C2=A0 =C2=A0 You have an "uber" bundle containing packages, and = this bundle is in
=C2=A0 =C2=A0 a feature.

=C2=A0 =C2=A0 This feature can be used as an inner feature.

=C2=A0 =C2=A0 So what's the point ?

=C2=A0 =C2=A0 Regards
=C2=A0 =C2=A0 JB


=C2=A0 =C2=A0 On 08/05/2016 02:03 PM, Benson Margulies wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Folks, I wonder if someone else has found a way= out of this.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Consider a project that builds an OSGi bundle b= y aggregating some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 non-OSGi jar Maven dependencies. Those dependen= cies are in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dependency tree of the resulting bundle.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Now, consider what happens if you generate a fe= ature to contain that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bundle. You can carefully exclude artifactIds t= o ensure that these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 embedded jars do not show up in the feature.xml= as 'wrap' bundles.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, there are still in the dependency grap= h of the feature
=C2=A0 =C2=A0 =C2=A0 =C2=A0 itself.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 So, when you write a dependency _on the feature= _ to incorporate that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 feature in a larger system, now the non-OSGi bu= ndles are back in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 picture. You then have to write Maven <exclu= sions> for them all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 over again.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If I wrote a patch to the karaf-maven-plugin to= exclude non-feature
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dependencies of features, would some committer = commit it?


=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Jean-Baptiste Onofr=C3=A9
=C2=A0 =C2=A0 jbon= ofre@apache.org <mailto:jbonofre@apache.org>
=C2=A0 =C2=A0 http://blog.nanthrax.net
=C2=A0 =C2=A0 Talend - http://www.talend.com




--94eb2c04486a878ad5053952864d--