On Nov 18, 2009, at 5:14 AM, Justin Erenkrantz wrote:
On Wed, Nov 18, 2009 at 5:57 AM, Christopher Brind bri...@brindy.org.uk
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
On Nov 18, 2009, at 10:22 AM, Leo Simons wrote:
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman nic...@hedhman.org
wrote:
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
jus...@erenkrantz.com wrote:
As Hyrum suggests, we can use org.apache.subversion.* if we want to
create a new
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
On Wed, Nov 18, 2009 at 5:57 AM, Christopher Brind bri...@brindy.org.uk 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
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman nic...@hedhman.org wrote:
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
jus...@erenkrantz.com 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
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 the
On Tue, Nov 17, 2009 at 5:11 PM, Branko Čibej br...@xbc.nu 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
Niclas Hedhman wrote:
On Tue, Nov 17, 2009 at 5:11 PM, Branko Čibej br...@xbc.nu 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
On Tue, Nov 17, 2009 at 5:54 PM, Branko Čibej br...@xbc.nu 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,
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 completely
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 am
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 will create
On Tue, Nov 17, 2009 at 2:57 PM, Ralph Goers ralph.go...@dslextreme.com 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
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
jus...@erenkrantz.com 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,
On 18/11/2009, at 3:40 PM, Niclas Hedhman wrote:
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
jus...@erenkrantz.com 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
On Nov 17, 2009, at 8:40 PM, Niclas Hedhman wrote:
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
jus...@erenkrantz.com 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
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 cmpil...@collab.net wrote:
What does the migration mean for
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
On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers ralph.go...@dslextreme.com 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
On Tue, Nov 17, 2009 at 10:39 AM, Niclas Hedhman nic...@hedhman.org wrote:
On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers ralph.go...@dslextreme.com
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
On Nov 16, 2009, at 6:39 PM, Niclas Hedhman wrote:
On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers ralph.go...@dslextreme.com
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
21 matches
Mail list logo
