On Thu, Jan 28, 2010 at 12:20 PM, Mark Phippard <markp...@gmail.com> wrote: > On Wed, Jan 27, 2010 at 5:18 PM, Hyrum K. Wright > <hyrum_wri...@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. > 2) Clean up deprecated methods/classes. It looks like you are already > doing this. I saw a few more (BlameCallback3 springs to mind). Yay! > 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. > 4) Looks like you plan to dump the Synchronized client. No real > comment or objection from me. Die! > 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.
