Return-Path: 
 <jdo-dev-return-7881-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org>
Delivered-To: apmail-db-jdo-dev-archive@www.apache.org
Received: (qmail 337 invoked from network); 22 Dec 2008 18:15:28 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 22 Dec 2008 18:15:28 -0000
Received: (qmail 78822 invoked by uid 500); 22 Dec 2008 18:15:28 -0000
Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:jdo-dev-help@db.apache.org>
List-Unsubscribe: <mailto:jdo-dev-unsubscribe@db.apache.org>
List-Post: <mailto:jdo-dev@db.apache.org>
List-Id: <jdo-dev.db.apache.org>
Reply-To: jdo-dev@db.apache.org
Delivered-To: mailing list jdo-dev@db.apache.org
Delivered-To: moderator for jdo-dev@db.apache.org
Received: (qmail 37956 invoked by uid 99); 22 Dec 2008 17:45:34 -0000
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: 209.85.198.226 is neither permitted
 nor denied by domain of matthew@matthewadams.me)
Cc: JDO Expert Group <jdo-experts-ext@Sun.COM>
Message-Id: <F04F9188-C229-4280-867A-E32BE457AE7E@matthewadams.me>
From: Matthew Adams <matthew@matthewadams.me>
To: jdo-dev@db.apache.org
In-Reply-To: <04F61E29-96C4-4E8C-B130-34E559311202@SUN.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Enhancer specification text for discussion
Date: Mon, 22 Dec 2008 09:45:05 -0800
References: <04F61E29-96C4-4E8C-B130-34E559311202@SUN.com>
X-Mailer: Apple Mail (2.930.3)
X-Virus-Checked: Checked by ClamAV on apache.org

Looks pretty good to me.  One question, below, though.

On Dec 21, 2008, at 3:41 PM, Craig L Russell wrote:
> -<option>: If a parameter begins with a "-" is found, it is added to  
> the other options list via the addOptions method.

What is the format of the -<option> arguments for unary and non-unary  
arguments?  That is, some options may take no arguments, one argument,  
or more than one argument.  How does the standard enhancer analyze and  
pass these to the implementation?

For example, if I have three vendor-specific arguments foo, bar, and  
goo, used like this,

... -r -v -foo -bar bararg -goo gooarg1 gooarg2 acme-domain.jar

how does the standard enhancer know that gooarg1 and gooarg2 are  
arguments to not resource or directory names?  If the syntax is

<option>[<whitespace><option-value>[<whitespace><option-value>[...]]

I don't think it could.  This might require a different format of the  
form

<option>[:<option-value>[<whitespace><option-value>[...]]

and the use of platform-specific characters (quotes, double quotes,  
etc) to indicate that the option's arguments should be read together.   
To avoid this, the form could be instead

<option>[:<option-value>[<option-value-separator><option-value>[...]]

where <option-value-separator> could be in some list of specified  
values like comma, semicolon, colon, etc.

WDYT?

-matthew