Return-Path: 
 <felix-dev-return-4329-apmail-incubator-felix-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-felix-dev-archive@www.apache.org
Received: (qmail 94233 invoked from network); 26 Jan 2007 21:02:41 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 26 Jan 2007 21:02:41 -0000
Received: (qmail 3460 invoked by uid 500); 26 Jan 2007 21:02:47 -0000
Delivered-To: apmail-incubator-felix-dev-archive@incubator.apache.org
Received: (qmail 3235 invoked by uid 500); 26 Jan 2007 21:02:46 -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 3224 invoked by uid 99); 26 Jan 2007 21:02:46 -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 13:02:46 -0800
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 (herse.apache.org: domain of fmeschbe@gmail.com designates
 66.249.82.237 as permitted sender)
Received: from [66.249.82.237] (HELO wx-out-0506.google.com) (66.249.82.237)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Jan 2007 13:02:38 -0800
Received: by wx-out-0506.google.com with SMTP id i26so854325wxd
        for <felix-dev@incubator.apache.org>;
 Fri, 26 Jan 2007 13:02:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=X7vu+HoXxN1JuOg0HR6HwNnq3yYkjJh0w8vHcEzp22dZzAqHtHC3ZFpJw+TScXo39rvq3qWOQU1uH67FbBx0rwhcHmioUQ0HUzghLPWO8x38wfSrL9+3ZuJpaouJHeTSB/xcRK4Ju2wWAgkWZSGrLhzUX5j+mIk0zSJVNFF7bTM=
Received: by 10.90.55.19 with SMTP id d19mr4188197aga.1169845337746;
        Fri, 26 Jan 2007 13:02:17 -0800 (PST)
Received: by 10.90.94.15 with HTTP; Fri, 26 Jan 2007 13:02:17 -0800 (PST)
Message-ID: <ae03024e0701261302g68bdba83q1b3f1def7c14e5fa@mail.gmail.com>
Date: Fri, 26 Jan 2007 22:02:17 +0100
From: "Felix Meschberger" <Felix.Meschberger@day.com>
Sender: fmeschbe@gmail.com
To: felix-dev@incubator.apache.org
Subject: Re: maven-bundle-plugin proposal
In-Reply-To: <EDA30BFE-AC1A-409B-B414-7367FF28C8CF@toolazydogs.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_46618_30586625.1169845337626"
References: <45B9147F.6010504@ungoverned.org>
	 <47958228-A1C6-4A14-972B-934B3D31E7AD@toolazydogs.com>
	 <45BA026A.8030606@ungoverned.org>
	 <3250793A-A01D-4BF3-B82E-B4B7627F566C@toolazydogs.com>
	 <45BA61AF.7000305@ungoverned.org>
	 <EDA30BFE-AC1A-409B-B414-7367FF28C8CF@toolazydogs.com>
X-Google-Sender-Auth: ac8520d09ae0afd4
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_46618_30586625.1169845337626
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

I would like to second Richard in keeping the syntax. In contrast to many
other maven plugins out there in plugin land, this one is a very simple
frontend to a third party tool. The parameters inside the <instructions>
element are simply copied over to the parameter map for BND.

I think it is valid to stay with the syntax of BND, which comes from the
OSGi world and not the maven world after all, and keep the plugin simple.
Having to convert the syntax would probably only introduce more problems
than it solves ...

Just my $.02.

Regards
Felix

On 1/26/07, Alan D. Cabrera <list@toolazydogs.com> wrote:
>
>
> On Jan 26, 2007, at 12:16 PM, Richard S. Hall wrote:
>
> > Alan D. Cabrera wrote:
> >>
> >> On Jan 26, 2007, at 5:30 AM, Richard S. Hall wrote:
> >>
> >>>>> 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?
> >>>>
> >>>> I like that finer degree of control that this gives but think
> >>>> that we should stick to using XML elements.  I think that it's
> >>>> bad form to mix-in OSGi manifest like patterns in a Maven POM,
> >>>> especially when those patterns govern the behavior of a Maven
> >>>> plugin.
> >>>
> >>> Do you have a proposal? I think it would be quite ugly/verbose to
> >>> break such syntax out into XML elements.
> >>>
> >>> I am not sure I understand why there is a constraint on the form
> >>> of XML used by a plugin. It is almost as if you are saying that
> >>> BND's syntax isn't Maven-like enough.
> >>>
> >>> This is a plugin for creating OSGi bundles, so it seems to make
> >>> sense for it to be comfortable for OSGi developers. Don't you think?
> >>
> >>
> >> It's not the end of the world if the plugin uses this syntax.
> >> This could arguably be a bike shed issue but let me give what I
> >> think is a relevant analogy.
> >>
> >> Let's say that we are writing a unix command that submits jobs to
> >> a VAX/VMS system; gee I hope people remember DEC.  One could say
> >> that we should allow the VAX/VMS command flag syntax, e.g. "/OUT"
> >> to be used for this unix command instead of the standard "-o"
> >> because it makes sense for it to be comfortable for VAX/VMSers.
> >> We would allow other unix options like "-v" and "-h", etc., hence
> >> we would be mixing the two nomenclatures.
> >>
> >> Not very pretty, in my opinion, in spite of my prowess and love
> >> for VAX/VMS.  It also causes problems for projects that may want
> >> to automatically generate scripts that may include this command
> >> because not only do those projects need to know unix commands but
> >> they must remember that there was this one project that was
> >> nostalgic for VAX/VMS command syntax.
> >>
> >> Part of the power of POMs is not the terseness of its expressions
> >> but that there is a single lingua franca.  XML provides easy
> >> access for tooling.
> >
> > I agree that this is a reasonable argument, but this is only
> > relevant if we assume that at some point in time someone else might
> > want to parse the BND commands, which seems like an unlikely
> > possibility.
>
> I'm not so sure.  Lots of interesting stuff to configure for these
> bundle puppies.  Tooling can definitely help.  However, I also had
> the argument that it's just plain bad form; granted this definitely
> falls into the grey realm of bike sheds.
>
> > To me, this is akin to maven version numbers. Version numbers are
> > not broken out into their individual elements, instead it is just
> > accepted that there is internal syntax which can be parsed and
> > certain pieces mean certain things, like SNAPSHOT.
>
> I think that you would be hard pressed to find many more examples
> like this and I would be quick to point out that the lexicon applies
> across the board for *all* maven POMs.
>
>
> Regards,
> Alan
>
>
>
>

------=_Part_46618_30586625.1169845337626--