You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Greg Stein <gs...@gmail.com> on 2009/11/16 20:00:28 UTC
Re: JavaHL package namespace / migration / compatability
Dunno. Lots of java packages have had to deal with the issue as they
migrate to the ASF. I'm sure that general@incubator (cc'd) has some
prior knowledge and precedent.
Cheers,
-g
On Mon, Nov 16, 2009 at 11:47, C. Michael Pilato <cm...@collab.net> wrote:
> What does the migration mean for JavaHL's package namespace and our version
> compatibility?
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Nov 17, 2009 at 10:39 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers <ra...@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
> and the Jini spec comes to mind.
>
> And as Ralph mentioned, a compatibility jar would IMHO be an
> acceptable compromise.
I am even willing to do the work (it ain't hard) ...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Craig L Russell <Cr...@Sun.COM>.
On Nov 16, 2009, at 6:39 PM, Niclas Hedhman wrote:
> On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers <ralph.goers@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
> and the Jini spec comes to mind.
Right. Generally the specification classes *must* reside in the java
name space. But implementation classes would have an
org.apache.whatever name space.
Craig
>
> And as Ralph mentioned, a compatibility jar would IMHO be an
> acceptable compromise.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: JavaHL package namespace / migration / compatability
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Nov 17, 2009 at 8:58 AM, Ralph Goers <ra...@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
and the Jini spec comes to mind.
And as Ralph mentioned, a compatibility jar would IMHO be an
acceptable compromise.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Niclas Hedhman <ni...@hedhman.org>.
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, typically major digit increment.
> But could anyone who was involved with any of these
> adopted projects share their experience with changing the package names?
> How did that affect their users? Did they write compatibility wrappers
> with the old package names, too? Did they have an equivalent version
> compatibility policy?
Wicket must have been one of the major ones in a similar position.
Also, Wicket didn't follow the "domain name" approach that is the
norm, making a change perhaps even less "needed" compared to people
seeing a jar full of "org.tigris" stuff.
Martijn, do you feel like digging into your buried feelings on the subject?
What I remember of Wicket incubation (as a User) was that they had
less stringent versioning constraints, so that it continued to live in
1.x version space, even though incompatibilities were introduced.
> I'm not steadfastly against completely changing the JavaHL API and
> writing compatibility layers, but I really would like to understand the
> reasons; other than Java coding standards which you can't reasonably
> expect to apply, since the compatibility wrapper breaks them in the very
> same way that the current API does.
The "benefit" of the "wrapper breakage" is that they are immediately
deprecated and can be dropped in a future release.
> (And of course that owned-domain rule isn't really broken as long as we
> can make sure that no-one else "steals" subversion.tigris.org.)
Well, I don't know who/what tigris.org really is, so I have no comment
other than if you don't pay for the registration there are very little
'assurances', since it may disappear.
> I don't know what you're used to, but I'd find it very strange indeed if
> I had to make massive changes to my code just because some company
> bought my library vendor. Not /quite/ the same situation, but for
> example, we didn't have to change one line of code in Subversion to
> support new versions of BDB after Oracle bought Sleepycat
(I have not done C/C++ programming since 1995, and back then libraries
were few and far apart.)
The underlying issue is "naming conflicts", which Sun tried to address
in Java with a simple scheme, but one that only works if people
co-operate. Some people choose to co-operate (I, Apache and others)
and some choose to ignore it. So it boils down to Apache policy more
than anything, in the same way that we *choose* to not make or even
re-distribute LGPL'd code, even though we have the right to do so.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Branko Čibej <br...@xbc.nu>.
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 words, we
>> *must* keep the same package names in the JavaHL public API.
>>
>
> "Must" is a strong word, and a compatible path forward is suggested.
>
"Must" is just a result of what our API versioning policy promises to
our users. Any number of compatibility layers won't change that.
>> Is there a
>> specific reason for doing a bunch of extra work that does not add any
>> value to JavaHL but only adds a layer of indirection for /all/ users of
>> the library?
>>
>
> 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 somewhat confident that some of
> these projects have more dependent developers than Subversion.
>
I'm sure they do. But could anyone who was involved with any of these
adopted projects share their experience with changing the package names?
How did that affect their users? Did they write compatibility wrappers
with the old package names, too? Did they have an equivalent version
compatibility policy?
I'm not steadfastly against completely changing the JavaHL API and
writing compatibility layers, but I really would like to understand the
reasons; other than Java coding standards which you can't reasonably
expect to apply, since the compatibility wrapper breaks them in the very
same way that the current API does.
(And of course that owned-domain rule isn't really broken as long as we
can make sure that no-one else "steals" subversion.tigris.org.)
> The indirection overhead would be "optional". Do a
> "s/org.tigris/org.apache/g" replace and you are good to go without the
> overhead.
>
I don't know what you're used to, but I'd find it very strange indeed if
I had to make massive changes to my code just because some company
bought my library vendor. Not /quite/ the same situation, but for
example, we didn't have to change one line of code in Subversion to
support new versions of BDB after Oracle bought Sleepycat
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Nov 18, 2009, at 5:14 AM, Justin Erenkrantz wrote:
> On Wed, Nov 18, 2009 at 5:57 AM, Christopher Brind <brindy@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
>> should
>> change its namespace.
>>
>> It sends the wrong message not to change given the importance of
>> the Apache
>> namespace, imho.
>
> If Subversion were a Java project, maybe I would consider it more
> important that it change.
>
> However, the Java bindings are a very small (and largely
> insignificant, IMO) part of Subversion. Holding a C-based project up
> for graduation because their Java bindings aren't in the org.apache.*
> namespace starts to sound petty. -- justin
I have a different opinion. Java package spaces have always carried
significant importance in the java community in terms of who is
providing stewardship of the code.
Having users change the packages when they move to a *new* version
requires no significant burden. It happens all the time in the Java
world and we are not treading on new ground here.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Nov 18, 2009 at 5:57 AM, Christopher Brind <br...@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 should
> change its namespace.
>
> It sends the wrong message not to change given the importance of the Apache
> namespace, imho.
If Subversion were a Java project, maybe I would consider it more
important that it change.
However, the Java bindings are a very small (and largely
insignificant, IMO) part of Subversion. Holding a C-based project up
for graduation because their Java bindings aren't in the org.apache.*
namespace starts to sound petty. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Christopher Brind <br...@brindy.org.uk>.
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 importance of the Apache
namespace, imho.
Regards,
Chris
On 18 Nov 2009 05:18, "Brett Porter" <br...@apache.org> wrote:
On 18/11/2009, at 3:40 PM, Niclas Hedhman wrote: > On Wed, Nov 18, 2009 at
12:06 AM, Justin Erenkr...
Handling case by case is valuable.
If it were com.somecompany.foo.* then there might be cause for concern in
that it might not appear independent.
I'm fine with Subversion keeping the current namespace, under the
understanding that migrating in the future in a way that makes sense for
their users is a good thing to do. This is similar to when a subproject goes
TLP too - for example, I work on Archiva, which came from Maven, which is
partially org.apache.maven.archiva.* and partially org.apache.archiva.*.
- Brett
--------------------------------------------------------------------- To
unsubscribe, e-mail: genera...
Re: JavaHL package namespace / migration / compatability
Posted by Brett Porter <br...@apache.org>.
On 18/11/2009, at 3:40 PM, Niclas Hedhman wrote:
> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
> <ju...@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, either Subversion address this issue pre-graduation, OR we
> remove the package name change requirement for ALL incubating
> projects, leaving it up to the project post-graduation to address it.
> It has been a contentious issue in the past, and will be so in the
> future, and I am not going to defend ASF's position if it doesn't
> apply to everyone.
>
Handling case by case is valuable.
If it were com.somecompany.foo.* then there might be cause for concern in that it might not appear independent.
I'm fine with Subversion keeping the current namespace, under the understanding that migrating in the future in a way that makes sense for their users is a good thing to do. This is similar to when a subproject goes TLP too - for example, I work on Archiva, which came from Maven, which is partially org.apache.maven.archiva.* and partially org.apache.archiva.*.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Ralph Goers <ra...@dslextreme.com>.
On Nov 17, 2009, at 8:40 PM, Niclas Hedhman wrote:
> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
> <ju...@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, either Subversion address this issue pre-graduation, OR we
> remove the package name change requirement for ALL incubating
> projects, leaving it up to the project post-graduation to address it.
> It has been a contentious issue in the past, and will be so in the
> future, and I am not going to defend ASF's position if it doesn't
> apply to everyone.
>
> I would actually like to hear from more Java-centric developers of
> Board and IPMC what they think about this...
I've already weighed in, but here is my answer again. I have mixed feelings, as I suspect the folks who asked this question in the first place do. Our package naming requirements aren't really out of the norm. But to expect the subversion project to break backward compatibility just to graduate is a bit much. That would be like redhat insisting that all the JBoss packages be renamed from org.jboss to org.redhat. There has to be a middle ground that is acceptable and won't cause chaos with the project's customers.
One solution that was mentioned was to do the rename but allow a compatibility jar with the old names.
Another solution was to create a jar with the new names that refers to the existing jar. Presumably all new functionality would go there.
I'm even OK with leaving as it is and creating a new jar with correct package names for new functionality and just having a concrete plan on how to do it.
To me, any of these is acceptable. What I'm personally not OK with is leaving it as it is for years unless tigris.org is owned by Apache, which I'm pretty sure isn't going to happen.
Ralph
Re: JavaHL package namespace / migration / compatability
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Nov 18, 2009, at 10:22 AM, Leo Simons wrote:
> On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
>> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
>> <ju...@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, either Subversion address this issue pre-graduation, OR we
>> remove the package name change requirement for ALL incubating
>> projects, leaving it up to the project post-graduation to address it.
>
> Any reference to this being a requirement? I looked for it the other
> day but didn't find anything.
>
> "If its not documented rule it is not a rule".
Then it's time to document this in our rules.
Java package spaces have always carried significant importance in the
Java community in terms of who is providing stewardship of the code.
This convention is so taken for granted in the Java community that I
am not surprised that it has not been written down.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
> <ju...@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, either Subversion address this issue pre-graduation, OR we
> remove the package name change requirement for ALL incubating
> projects, leaving it up to the project post-graduation to address it.
Any reference to this being a requirement? I looked for it the other
day but didn't find anything.
"If its not documented rule it is not a rule".
> It has been a contentious issue in the past, and will be so in the
> future, and I am not going to defend ASF's position if it doesn't
> apply to everyone.
>
> I would actually like to hear from more Java-centric developers of
> Board and IPMC what they think about this...
I wouldn't say I'm java-centric but I do a lot of it :)
I think package renaming is in many cases required for branding or
trademark reasons (which goes both ways -- org.apache.java.framework
was an issue once, com.google.httpd would be today, but on the upside
"import org.apache" may make people feel nice and cosy, too).
I think sf.net.<foo> or org.tigris.<foo> is not that big an issue to
keep (for a while), if there's good enough reasons (like api
compatibility for an established codebase).
Beyond that, I personally think the java standards for package naming
are really a mixed blessing, and if a project wanted to break them
(say subversion decided to go with subversion.<stuff> instead of
org.apache.subversion.<stuff>), fine, good luck to them. Regardless of
the stupidity of the rules (or the stupidity of breaking the rules),
we as incubator should really not even try to enforce these kinds of
standards; projects should make their own decisions about that.
ciao,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
<ju...@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, either Subversion address this issue pre-graduation, OR we
remove the package name change requirement for ALL incubating
projects, leaving it up to the project post-graduation to address it.
It has been a contentious issue in the past, and will be so in the
future, and I am not going to defend ASF's position if it doesn't
apply to everyone.
I would actually like to hear from more Java-centric developers of
Board and IPMC what they think about this...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Nov 17, 2009 at 2:57 PM, Ralph Goers <ra...@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 confused.
>
> IMO, whether the package names are changed in 1.7 or in some future release is up to the project to decide. But they should change sooner or later.
>
> You asked for our input and this is it.
It's noted, but, as others have mentioned, binary/source compatibility
is a very strong concern for Subversion.
Since subversion.tigris.org is still going to be up (at least as a
pointer, if not in some stronger form), I think we're fine for folks
who want documentation or references well after Subversion is an
official ASF project.
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.
Thanks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Ralph Goers <ra...@dslextreme.com>.
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 somewhat confident that some of
> these projects have more dependent developers than Subversion.
> The indirection overhead would be "optional". Do a
> "s/org.tigris/org.apache/g" replace and you are good to go without the
> overhead.
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, whether the package names are changed in 1.7 or in some future release is up to the project to decide. But they should change sooner or later.
You asked for our input and this is it.
Ralph
Re: JavaHL package namespace / migration / compatability
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 same package names in the JavaHL public API.
"Must" is a strong word, and a compatible path forward is suggested.
> Is there a
> specific reason for doing a bunch of extra work that does not add any
> value to JavaHL but only adds a layer of indirection for /all/ users of
> the library?
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 somewhat confident that some of
these projects have more dependent developers than Subversion.
The indirection overhead would be "optional". Do a
"s/org.tigris/org.apache/g" replace and you are good to go without the
overhead.
I am not qualified to answer your sarcasm about C libraries and header
files. No idea how naming conflicts are avoided in reality.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Ralph Goers <ra...@dslextreme.com>.
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 compatibility problems. I don't know if it is completely possible to create a separate jar containing the necessary glue code to map the org.tigris classes to org.apache - or if is even worth the effort.
>>>
>>
>> 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 package names in the JavaHL public API. Is there a
>> specific reason for doing a bunch of extra work that does not add any
>> value to JavaHL but only adds a layer of indirection for /all/ users of
>> the library?
>
> Subversion's versioning guidelines say that the old APIs (and implicitly the package names) need to stay stable in future 1.x releases.
>
> That does not, however, preclude us from creating an up-to-date interface in the org.apache namespace, and only adding new and future features to that interface, effectively deprecating the old one.
>
Makes sense to me.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
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 possible to create a separate jar containing the necessary glue code to map the org.tigris classes to org.apache - or if is even worth the effort.
>>
>
> 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 package names in the JavaHL public API. Is there a
> specific reason for doing a bunch of extra work that does not add any
> value to JavaHL but only adds a layer of indirection for /all/ users of
> the library?
Subversion's versioning guidelines say that the old APIs (and implicitly the package names) need to stay stable in future 1.x releases.
That does not, however, preclude us from creating an up-to-date interface in the org.apache namespace, and only adding new and future features to that interface, effectively deprecating the old one.
-Hyrum
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Branko Čibej <br...@xbc.nu>.
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 necessary glue code to map the org.tigris classes to org.apache - or if is even worth the effort.
>
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 package names in the JavaHL public API. Is there a
specific reason for doing a bunch of extra work that does not add any
value to JavaHL but only adds a layer of indirection for /all/ users of
the library?
This suggestion is equivalent to requiring that all C APIs that come
from this community be prefixed with ap_ ... so "it's completely
possible to create a separate set of headers with the necessary glue
that map svn_ to ap_svn_."
Sorry about being a bit sarcastic there.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
Posted by Ralph Goers <ra...@dslextreme.com>.
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 map the org.tigris classes to org.apache - or if is even worth the effort.
Ralph
On Nov 16, 2009, at 11:00 AM, Greg Stein wrote:
> Dunno. Lots of java packages have had to deal with the issue as they
> migrate to the ASF. I'm sure that general@incubator (cc'd) has some
> prior knowledge and precedent.
>
> Cheers,
> -g
>
> On Mon, Nov 16, 2009 at 11:47, C. Michael Pilato <cm...@collab.net> wrote:
>> What does the migration mean for JavaHL's package namespace and our version
>> compatibility?
>>
>> --
>> C. Michael Pilato <cm...@collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org