So... if I simply remove
org.tigris.subversion.clientadapter.javahl.feature from our installed
feature set, the user experience will be simpler as then the default
selected implementation will be SVNKit.
I suppose that *is* better, but there will be no mention of JavaHL,
leaving all JavaHL related activity as an exercise for the reader,
should they so desire it.
Nick
On Tue, Jun 11, 2013 at 12:26 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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/
--
Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc.
http://nick.divbyzero.com
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3057662
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2013-06-12 05:29:17 CEST