"Alexander Kitaev" <alex@tmate.org> wrote on 07/20/2005 10:13:02 AM:
> > I think the point was to avoid the namespace clash. We do
> > not want to ship a version of Subclipse that does not include
> > JavaHL. Unless we completely redesigned clientAdapter so
> > that each adapter was its own plugin, there would be
> > classloader problems in getting the right JavaHL implementation.
> Yes, I see your point, but I think that making adapter implementations
> pluggable through extension point is more natural then current approach
and
> still easier then writing new implementation of svnClientAdapter for
> JavaSVN. I will do that modification as soon as I will have time, unless
> someone else will do it earlier :)
I have already thought the same thing as I would ideally like the version
of JavaHL or JavaSVN to be separate from Subclipse. So you could install
a new version of JavaHL/JavaSVN by installing a new plugin, independent of
Subclipse. An enormous problem that I see is that svnClientAdapter is not
an Eclipse plugin. We cannot just hack it up as there are other projects
(at least svnAnt) that need it outside an Eclipse environment.
I am not sure how we can solve that problem.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Jul 21 00:21:11 2005