On Nov 18, 2009, at 10:22 AM, Leo Simons wrote:
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman
wrote:
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
wrote:
As Hyrum suggests, we can use org.apache.subversion.* if we want to
create a new (better) Java interface within our versioning
On Nov 18, 2009, at 5:14 AM, Justin Erenkrantz wrote:
On Wed, Nov 18, 2009 at 5:57 AM, Christopher Brind > wrote:
I can understand why Subversion should be made a top level project
quickly,
but I personally believe the namespace change is a reasonable
request in
order to graduate for all the
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman wrote:
> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
> wrote:
>
>> As Hyrum suggests, we can use org.apache.subversion.* if we want to
>> create a new (better) Java interface within our versioning rules - but
>> that isn't necessary nor shou
On Wed, Nov 18, 2009 at 5:57 AM, Christopher Brind wrote:
> I can understand why Subversion should be made a top level project quickly,
> but I personally believe the namespace change is a reasonable request in
> order to graduate for all the same reasons that convinced me Pivot should
> change it
I can understand why Subversion should be made a top level project quickly,
but I personally believe the namespace change is a reasonable request in
order to graduate for all the same reasons that convinced me Pivot should
change its namespace.
It sends the wrong message not to change given the im
On Nov 17, 2009, at 8:40 PM, Niclas Hedhman wrote:
> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
> wrote:
>
>> As Hyrum suggests, we can use org.apache.subversion.* if we want to
>> create a new (better) Java interface within our versioning rules - but
>> that isn't necessary nor should
On 18/11/2009, at 3:40 PM, Niclas Hedhman wrote:
> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
> wrote:
>
>> As Hyrum suggests, we can use org.apache.subversion.* if we want to
>> create a new (better) Java interface within our versioning rules - but
>> that isn't necessary nor should i
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
wrote:
> As Hyrum suggests, we can use org.apache.subversion.* if we want to
> create a new (better) Java interface within our versioning rules - but
> that isn't necessary nor should it be a pre-req for graduation.
IMNSHO, either Subversion ad
On Tue, Nov 17, 2009 at 2:57 PM, Ralph Goers wrote:
> There is a more practical reason for this. If I have a need to debug a
> package or get further documentation, the package name gives me a pointer as
> to where to look. If tigris.org disappeared users would get very confused.
>
> IMO, whethe
On Nov 17, 2009, at 6:27 AM, Hyrum K. Wright wrote:
>
> On Nov 17, 2009, at 3:11 AM, Branko Čibej wrote:
>
>> Ralph Goers wrote:
>>> In general, Java code at Apache should reside under a package of
>>> org.apache. In this case, I would expect org.apache.subversion.javahl. Of
>>> course, this
On Nov 17, 2009, at 1:25 AM, Niclas Hedhman wrote:
>
> Java coding standard(s) makes very strong assertions that package
> names should be 'owned' domain names, to ensure avoidance of name
> collisions. Apache has maintained such for practically all projects,
> incl all incoming projects, and I a
On Nov 17, 2009, at 3:11 AM, Branko Čibej wrote:
> Ralph Goers wrote:
>> In general, Java code at Apache should reside under a package of org.apache.
>> In this case, I would expect org.apache.subversion.javahl. Of course, this
>> will create compatibility problems. I don't know if it is compl
On Tue, Nov 17, 2009 at 5:54 PM, Branko Čibej wrote:
> "Must" is just a result of what our API versioning policy promises to
> our users. Any number of compatibility layers won't change that.
Yes, but your versioning policy for sure allows incompatible changes
thru some mechanism, typically majo
Niclas Hedhman wrote:
> On Tue, Nov 17, 2009 at 5:11 PM, Branko Čibej wrote:
>
>
>> I don't quite understand the point of this. Here we are with a Java
>> wrapper library for the Subversion APIs. The versioning rules that apply
>> to it are the same as for the rest of Subversion -- in other wor
On Tue, Nov 17, 2009 at 5:11 PM, Branko Čibej wrote:
> I don't quite understand the point of this. Here we are with a Java
> wrapper library for the Subversion APIs. The versioning rules that apply
> to it are the same as for the rest of Subversion -- in other words, we
> *must* keep the same pac
Ralph Goers wrote:
> In general, Java code at Apache should reside under a package of org.apache.
> In this case, I would expect org.apache.subversion.javahl. Of course, this
> will create compatibility problems. I don't know if it is completely possible
> to create a separate jar containing th
On Nov 16, 2009, at 6:39 PM, Niclas Hedhman wrote:
On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers > wrote:
In general, Java code at Apache should reside under a package of
org.apache.
Yes, I can only recall that the only exceptions has been where there
are some formal specification backing the
On Tue, Nov 17, 2009 at 10:39 AM, Niclas Hedhman wrote:
> On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers
> wrote:
>> In general, Java code at Apache should reside under a package of org.apache.
>
> Yes, I can only recall that the only exceptions has been where there
> are some formal specification
On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers wrote:
> In general, Java code at Apache should reside under a package of org.apache.
Yes, I can only recall that the only exceptions has been where there
are some formal specification backing the project, JSRs, the OSGi spec
and the Jini spec comes to
In general, Java code at Apache should reside under a package of org.apache. In
this case, I would expect org.apache.subversion.javahl. Of course, this will
create compatibility problems. I don't know if it is completely possible to
create a separate jar containing the necessary glue code to ma
Dunno. Lots of java packages have had to deal with the issue as they
migrate to the ASF. I'm sure that gene...@incubator (cc'd) has some
prior knowledge and precedent.
Cheers,
-g
On Mon, Nov 16, 2009 at 11:47, C. Michael Pilato wrote:
> What does the migration mean for JavaHL's package namespace
21 matches
Mail list logo
