On Tue, Jun 11, 2013 at 11:38 AM, Nick Boldt <nickboldt_at_gmail.com> wrote:
> On Tue, Jun 11, 2013 at 10:24 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Mon, Jun 10, 2013 at 3:18 PM, Nick Boldt <nboldt_at_redhat.com> wrote:
>>> So I have two suggestions which could improve the user experience:
>>> a) default to SVNKit when JavaHL is unavailable, or
>> We already do this. However, if JavaHL is the chosen default we do
>> not so it silently. We will first give you notification that the
>> library is not available. This is intentional. We want you to use
>> JavaHL and if it is installed and the chosen default, then we are
>> going to notify you that it is not setup.
>
> When I install the features here [1] into Eclipse or JBDS, Subclipse
> and SVNKit are installed, but SVNKit isNOT selected as the default -
> rather, even though it's unavailable, JavaHL is set as the default SVN
> implementation, and the warning message re: JavaHL is thrown.
>
> [1] http://download.jboss.org/jbosstools/updates/requirements/subclipse/1.8.20_1.7.9.1/features/
>
> So, yes, JavaHL is selected as default but as you say, it's not done
> silently. My point is that OOTB, that means a user can't simply use
> Subclipse w/o having to then go install something else.
Take a step back for a second. The available client adapters are
separate from Subclipse. It only needs one of them to be installed to
work. If only one is installed, then that will be the default
automatically. If you have more than one installed, and you have not
selected your default in the preference, then we choose JavaHL as the
default.
At the time of using it, all the JavaHL adapter knows is that it was
asked to be used and failed to load the native library. So it reports
this, once per Eclipse session, upon first attempt to use it.
Once Subclipse sees that JavaHL does not work (but this is after the
message has been displayed) it will fallback to the next available
adapter. So the experience I see when I take an action that requires
the API is that I first get this message but once I click OK on the
dialog the action then proceeds and works properly (because I also
have SVNKit installed). After that, throughout the life of that
Eclipse session, SVNKit will be used first and everything works.
This is the user experience we want. If you want it to be more
seamless, then I recommend that you do not install the JavaHL plugin.
Then the user will only have one adapter available, SVNKit, so that is
what will be used. JavaHL is not a required plugin. If you are
creating a p2 type installer like the Eclipse Marketplace Client, it
ought to be possible to just not tell it about that plugin.
> I suppose the ideal setup would be to be able to install JavaHL
> directly from within a Subclipse plugin (eg., a wizard linked from the
> warning dialog), with platform detection and license agreement
> confirmation, but I realize that's a lot more work. It would of course
> improve the ease of use and it easier for users to adopt JavaHL
> instead of SVNKit.
It will never be possible for us to install the native libraries on
Linux or Mac. We can easily make the JavaHL library itself available,
but based on how SVN works that library requires countless other
libraries that have to be installed in your distro. That is why we
link to documentation with pointers on how to install the right
packages and make Eclipse aware of them.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3057832
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2013-06-12 16:57:33 CEST