JP Fiset <firstname.lastname@example.org> wrote on 09/20/2005 09:49:22 AM:
> Would there be possible design changes to javahl that would alleviate
> to change the libraries on every minor revisions? I am thinking of
> like passing XML docs, or something equivalent, between the JAR and the
> library. That would mean that the list of parameters would stabilize,
> providing better binary compatibility between revisions.
You are misunderstanding. I am saying that the JAR could be from 1.2.0
and the library from 1.2.3 (or vice versa) and they would work fine. You
just cannot take a JAR from 1.1.x and use it with a 1.2.x library and vice
JavaHL uses JNI so the interface contract is fairly tight.
Finally, we are driving JavaHL pretty hard and constantly demanding new
features so we generally demand the very latest version in Subclipse. I
do not see that changing for a while.
> Ideally, the native library should get shipped with Subversion itself,
> the end user's need to fetch them. Are there technicalities that I am
> why this can not be done? Memory management issues? Compiler selection?
There are no technical issues with this approach, it is simply that in the
case of Linux this is entirely under the control of the distribution
provider. There are no Subversion "binaries" for any platform other than
Windows. A company named Metissian has been providing them for OS X, but
in the Linux world it is up to the distro. Historically many
distributions will not include any software that requires Java because of
the licensing issues. This is getting better and there are more and more
options for JavaHL being made available in the distros.
> Yes, I agree that the XML flavours of the commands will make for more
> parsing of the results. Would you mind enlightening me on the
> advance commands where dodginess is expected even if XML results are
No, the issue is that right now most of the commands do not have an --xml
option. Once they all do, I would expect this issue to get a lot better.
This adapter will always be the slowest but it should be possible for it
to become a lot more reliable.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Wed Sep 21 00:00:27 2005