Return-Path: 
 <felix-dev-return-4322-apmail-incubator-felix-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-felix-dev-archive@www.apache.org
Received: (qmail 35149 invoked from network); 26 Jan 2007 14:47:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 26 Jan 2007 14:47:57 -0000
Received: (qmail 69393 invoked by uid 500); 26 Jan 2007 14:47:57 -0000
Delivered-To: apmail-incubator-felix-dev-archive@incubator.apache.org
Received: (qmail 69352 invoked by uid 500); 26 Jan 2007 14:47:57 -0000
Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:felix-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:felix-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:felix-dev@incubator.apache.org>
List-Id: <felix-dev.incubator.apache.org>
Reply-To: felix-dev@incubator.apache.org
Delivered-To: mailing list felix-dev@incubator.apache.org
Received: (qmail 69314 invoked by uid 99); 26 Jan 2007 14:47:57 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Jan 2007 06:47:57 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [217.160.230.40] (HELO mout.perfora.net) (217.160.230.40)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Jan 2007 06:47:48 -0800
Received: from [24.180.252.202] (helo=[192.168.1.85])
	by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis),
	id 0MKp2t-1HASMQ0LEj-0007Fd; Fri, 26 Jan 2007 09:47:27 -0500
Message-ID: <45BA147E.6050904@ungoverned.org>
Date: Fri, 26 Jan 2007 09:47:26 -0500
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: maven-bundle-plugin proposal
References: <45B9147F.6010504@ungoverned.org>
In-Reply-To: <45B9147F.6010504@ungoverned.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: perfora.net abuse@perfora.net
 login:b399c17105f59dfa36985f08f30e623d
X-Provags-ID2: 
 V01U2FsdGVkX1/jZLEQ2XF1ElJv9Knp/Mq1J14Pywm8iIx6YCbHFnql0JgKuEWdZypqw169m8z4St1X8U/MIv02Q1bzbMx2IfrV4pWJCJT5p6AtRqncAylf/A==
X-Virus-Checked: Checked by ClamAV on apache.org

One other issue that I think we need to follow up on, how should the 
plugin handle transitive dependencies of the bundle's dependencies?

I see three options:

   1. Ignore them and require the bundle developer to list them as
      explicit dependencies if they want to embed them.
   2. Embed all transitive dependencies of any embedded bundle dependency.
   3. Use the matching rules from <embed-dependency> to determine if any
      of the transitive dependencies should also be embedded.

Personally, I think (3) makes the most sense and is the most flexible; 
this approach assumes that we can get groupId/artifactId/version/scope 
of transitive dependencies.

Thoughts?

-> richard

Richard S. Hall wrote:
> Hello,
>
> Back in early December we had a discussion with Emil Eifr�m, Aaron 
> Siri, et al about how the new bundle plugin should deal with embedding 
> (as opposed to inlining) dependent JAR files. Peter and I have finally 
> had some time to discuss this and have come up with a simple proposal 
> that we can now submit for some feedback.
>
> The general approach is a slightly modified version of Peter's first 
> proposal. The idea is to add a mechanism to deal with embedding JARs 
> that is very similar to how the old maven plugin worked, but doing it 
> in a slightly more generic way than the old plugin by adding the 
> following instruction:
>
>    embed-dependency        ::= clause ( ',' clause ) *
>    clause                  ::= MATCH ( ';' attr '=' MATCH )
>    attr                    ::= 'groupId' | 'artifactId' | 'version' | 
> 'scope'
>    MATCH                   ::= <globbed regular expressions>
>
> This instruction would be used to match the specified Maven 
> dependencies for embedding. Any matching dependency would have its JAR 
> file embedded onto the resulting bundle JAR file and it would be 
> appended to the Bundle-ClassPath header after ".".
>
> This would allow people to easily achieve the same behavior as the old 
> plugin by simply doing:
>
>    <embed-dependency>*;scope=compile,*;scope=runtime</embed-dependency>
>
> Thus, this instruction would automatically embed any maven 
> dependencies that were of scope "compile" or "runtime" and append them 
> to the bundle class path.
>
> What do you think?
>
> -> richard
>