[EMAIL PROTECTED] wrote:
> On Sun, Jun 22, 2008 at 5:08 PM, Rahul Akolkar
> <[EMAIL PROTECTED]> wrote:
>> Yup, a reserved package name makes sense ("internal" is fine, and
>> atleast a couple of Apache projects use it). If there aren't any
>> objections, we should document this and start using the
On Sun, Jun 22, 2008 at 5:08 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> Yup, a reserved package name makes sense ("internal" is fine, and
> atleast a couple of Apache projects use it). If there aren't any
> objections, we should document this and start using the convention.
I'm really good wit
Please stop removing the "headers" from the reply body (for example,
I've retained the "On 6/22/08, Torsten Curdt <[EMAIL PROTECTED]>
wrote:" text below). Removing those makes conversations quite hard to
follow, especially the longer ones.
On 6/22/08, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> >
>
On Sun, Jun 22, 2008 at 9:35 AM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> Underscore? *shudder*
> What about a package name called "internal"
I don't really care what the naming convention is. I was just making
a suggestion of how we could allow APIs to change as long as they're
marked as int
Added note that those classes are not part of the public API
I'm not sure how we'd consider breakage though (does that mean we'll
be lax with changes to these classes?).
I mention this because there are a couple of classes in [scxml] as
well that fit this bill and we could add similar warning
On Fri, Jun 20, 2008 at 4:47 PM, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 6/20/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Author: sgoeschl
>> Date: Fri Jun 20 06:21:04 2008
>> New Revision: 669887
>>
>> URL: http://svn.apache.org/viewvc?rev=669887&view=rev
>> Log:
>> Added note t
On 6/20/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: sgoeschl
> Date: Fri Jun 20 06:21:04 2008
> New Revision: 669887
>
> URL: http://svn.apache.org/viewvc?rev=669887&view=rev
> Log:
> Added note that those classes are not part of the public API
>
I'm not sure how we'd consider