> The reasons we gave are valid.
>> We could never figure out how to link them statically
...that's the valid reason? (meant as a serious question)
Could explain the problem a bit more in detail than in
> Your situation is easily solveable by
> building the jni bindings by hand instead of relying on the very
> slow-to-update debian package system. such is life on linux. Your
> world would have broken sooner or later, even if we were shipping the
> bindings for you (probably sooner).
With all due respect(!) but please re-read my posting.
...we did try to build them by hand. If this had worked
I would not moan about it.
>>...although still some things were missing (compared to
>>the eclipse cvs client) subclipse was already a nice
>>piece of software. ...*was* because since the remove
>>of the jni bindings renders the plugin useless (for us)!
>>We tried to create the jni bindings ourselves but for
>>some reason it's still not working. Besides you don't
>>wanna put this burden onto each an every user of the
>>plugin! ...at least it's not that easy as stated on
>>the web site.
>>Bugging the package maintainer does not help much
>>for Debian due to the fact that all the dependencies
>>have to be inside the same section:
>>>the packages in _main_
>>> * must not require a package outside of _main_ for compilation
>>> or execution (thus, the package must not declare a "Depends",
>>> "Recommends", or "Build-Depends" relationship on a non-_main_
>>Since subversion is in main all dependencies have
>>to be in main. (note: of course there is no sun jdk
>>nor the blackdown) The only one that is in main is
>>jikes ...is it possible to build the jni bindings
>>with jikes and gnu classpath?
>>Besides updating svn-javahl.jar with the self-build
>>one needs to be done for each and every eclipse
>>plugin update (through the manager)
>>We went back using the svn command line because of
>>the current situation. I hope this is heard...
Received on Thu Sep 30 04:24:29 2004