Return-Path: Delivered-To: apmail-tuscany-dev-archive@www.apache.org Received: (qmail 8741 invoked from network); 2 Jul 2008 16:06:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Jul 2008 16:06:25 -0000 Received: (qmail 23631 invoked by uid 500); 2 Jul 2008 16:06:26 -0000 Delivered-To: apmail-tuscany-dev-archive@tuscany.apache.org Received: (qmail 23350 invoked by uid 500); 2 Jul 2008 16:06:25 -0000 Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tuscany.apache.org Delivered-To: mailing list dev@tuscany.apache.org Received: (qmail 23341 invoked by uid 500); 2 Jul 2008 16:06:25 -0000 Delivered-To: apmail-ws-tuscany-dev@ws.apache.org Received: (qmail 23338 invoked by uid 99); 2 Jul 2008 16:06:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jul 2008 09:06:25 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ant.elder@gmail.com designates 64.233.182.191 as permitted sender) Received: from [64.233.182.191] (HELO nf-out-0910.google.com) (64.233.182.191) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jul 2008 16:05:35 +0000 Received: by nf-out-0910.google.com with SMTP id b11so122780nfh.28 for ; Wed, 02 Jul 2008 09:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :sender:to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=EkrWF3+NucIYxeaC73mwzif075eqJSS3IdHEA0DFhFw=; b=axFowgscNEKawYEHC5vCpsQI31rcMcOgxKTubgmglTg/nbaotNR8ZS9Ca69fkPwjdi oo934OUJXUzO1Sx3850NhIy7qb7I4nGAxdbHkn7aaMxQRWBwG3A9a/s5lQTy+3JH1WTr spAmg4mX2UH3duxVKwGSeCGoNob91FP/W9yf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:in-reply-to :mime-version:content-type:references:x-google-sender-auth; b=nZ+GAF1CAg4WZ/OL8yWLye4k+oZNhfYXiZcZDaEJBqRRFvg/JwXITwraJp348XWdtz CQmCmOr3koUPADiemjVZnmf9NeyuUIj1D7nBkjXUGlyGUKl8Wsp6InK26d0xfZLMe+PO mv27AiBV0STV6BWoHWrB9mRTM/wMC54nbwNdA= Received: by 10.210.68.17 with SMTP id q17mr6762094eba.53.1215014755341; Wed, 02 Jul 2008 09:05:55 -0700 (PDT) Received: by 10.210.52.3 with HTTP; Wed, 2 Jul 2008 09:05:55 -0700 (PDT) Message-ID: <71e1b5740807020905n4cdcfc60w9539a67a7be9117c@mail.gmail.com> Date: Wed, 2 Jul 2008 17:05:55 +0100 From: "ant elder" Reply-To: ant.elder@gmail.com Sender: ant.elder@gmail.com To: tuscany-dev Subject: Re: Grouping/Aggregating tuscany modules, was: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_999_3152169.1215014755354" References: <71e1b5740801071003maa5b07cnff914f38d3fc4280@mail.gmail.com> <71e1b5740806150052o1ef244f4q9aa42e79d474d43b@mail.gmail.com> <71e1b5740807010040s56f58a14w8ae88de34e96c674@mail.gmail.com> <486A1057.2070807@apache.org> <71e1b5740807010804i65634713waa226ef96ae7706b@mail.gmail.com> <71e1b5740807011651m1c56bd29hf830115df632647c@mail.gmail.com> <2A32A40F39B1471F80ABF4EE386045C7@rfengt60p> <71e1b5740807012358v28b33a37h1cb7afc50959ea0d@mail.gmail.com> X-Google-Sender-Auth: 5cc54f9b62fe649d X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_999_3152169.1215014755354 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This went to me not the dev list, comments in line ...ant On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng wrote: > Hi, > > Can you provide us some use cases for the aggregated jars? > > I think it's very important that we don't physically merge module jars into > a feature jar. > > Let's assume we have two features: f1 and f2. f1 contains modules m1 and > m2, f2 contains m1 and m3. > If that happens then likely we don't have the aggregation granularity correct. Could you provide an example of that using actual Tuscany modules and the aggregations suggested so far? > If we produce f1.jar and f2.jar, what's going to happen if my application > uses both f1 and f2? If we declare maven dependencies to f1 and f2, we end > up with a classpath containing f1.jar and f2.jar. All the classes/resources > from module m1 will be duplicate in these two jars. The jar aggregation also > prevents a feature to be depended by another feature for the same reason. > Even when we put maven on the side, do you expect the user to download both > f1.jar and f2.jar to support both features? If so, we still have the > duplicating artifacts issue. > > Also thinking about OSGi, adding feature jars will be problematic too. If > it's just a descriptor, then adding a feature just pulls into the contained > module bundles. > > I'm not seeing the problems you're hinting at, could you be more specific or give concrete examples? ...ant ------=_Part_999_3152169.1215014755354 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This went to me not the dev list, comments in line

   ...ant

On Wed, Jul 2, 2008 at 4:57 PM, Raymond Feng <enjoyjava@gmail.com> wrote:
Hi,
 
Can you provide us some use cases for the aggregated jars?
 
I think it's very important that we don't physically merge module jars into a feature jar.
 
Let's assume we have two features: f1 and f2. f1 contains modules m1 and m2, f2 contains m1 and m3.

If that happens then likely we don't have the aggregation granularity correct. Could you provide an example of that using actual Tuscany modules and the aggregations suggested so far?
 
If we produce f1.jar and f2.jar, what's going to happen if my application uses both f1 and f2? If we declare maven dependencies to f1 and f2, we end up with a classpath containing f1.jar and f2.jar. All the classes/resources from module m1 will be duplicate in these two jars. The jar aggregation also prevents a feature to be depended by another feature for the same reason. Even when we put maven on the side, do you expect the user to download both f1.jar and f2.jar to support both features? If so, we still have the duplicating artifacts issue.
 
Also thinking about OSGi, adding feature jars will be problematic too. If it's just a descriptor, then adding a feature just pulls into the contained module bundles.
 

I'm not seeing the problems you're hinting at, could you be more specific or give concrete examples?

   ...ant

------=_Part_999_3152169.1215014755354--