On Jan 28, 2010, at 12:26 PM, Daniel Rall wrote:
> On Thu, Jan 28, 2010 at 12:20 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Wed, Jan 27, 2010 at 5:18 PM, Hyrum K. Wright
>> <hyrum_wright_at_mail.utexas.edu> wrote:
>>
>>> I think this is the way to go. I was playing around last night with re-jiggering the java code into the new
>>> package(s), and got something reasonable put together. I'll commit it shortly, and I invite folks to
>>> comment / criticize.
>>>
>>> (I'm especially hoping Mark can take a look, as he probably has more knowledge about Java package
>>> organization than I do. And he's one of the primary consumers.)
>>
>> It looks good so far, but until all of the existing JavaHL code is
>> successfully modified to use the new packages I am still a little
>> leary. I wish I could be more specific, but I recall trying to do
>> something in the past from Subclipse where there were certain JavaHL
>> objects that could not be created from outside the JavaHL package.
>
> If we had package private classes that you wanted to use externally,
> this would be the case.
> I recall more that we had C++ classes that weren't exposed directly to
> Java that you wanted to use; I think I ended up exposing them via Java
> wrappers.
>
>> So
>> I am wondering how we will be able to wrapper these. It could turn
>> out to be nothing or maybe we will just have to modify the new Apache
>> versions.
>>
>> Some things I would like to do since we are renaming:
>>
>> 1) Make all interfaces start with "I". You already did this for
>> SVNClientInterface, I'd like to do it for all of them.
>
> Fine, but dump any "Interface" suffix in this case.
Done and done.
>> 2) Clean up deprecated methods/classes. It looks like you are already
>> doing this. I saw a few more (BlameCallback3 springs to mind).
>
> Yay!
Yes. This is a perfect opportunity for us to cheat and do a somewhat-incompatible namespace reorganization without saying 2.0.
>> 3) Looks like you renamed SVNClient to Client. I think I would prefer
>> the old name just because it can be a nuisance if someone has another
>> class named Client (which seems like a potentially common name).
>
> Ditto, keep the prefix.
I kinda don't see the point, since it's redundant with the package name, but if you (as a consumer) feel it'd be best, we can change it back.
>> 4) Looks like you plan to dump the Synchronized client. No real
>> comment or objection from me.
>
> Die!
Do I hear issue 2755 calling?
>> 5) If we have time, there might be improvements/modifications that can
>> be performed on existing classes. Nothing specific springs to mind at
>> the moment.
>>
>> Adding dlr to the to: list. He has so much experience in the history
>> of these classes it would be good to have his feedback.
>
> I haven't looked at the code and don't expect any time to do so until
> late next week at the earliest. Please do keep me in the loop, though.
No problem. I'm fine on the technical aspects, it's more the "what's the Java way of class and package layout?" questions that I may need some guidance on. I'd like to see use use sub-packages where possible, as well.
Either of you need to feel free to hop in and shuffle stuff around as you see fit. I'm working on the tests right now, and when I get that committed, I plan on making the apache packages just wrap the tigris packages. Then, we can switch individual underlying layers as we're able.
-Hyrum
Received on 2010-01-28 21:59:40 CET