Stefan wrote: "For the external plugins they need to know only once
that they need to
drag and drop or remove jar files."
This is only true with simple plug-ins. If your plug-in has its own
folder structure and JAR dependencies, things can get a little more
complex.
Stefan wrote: "the problem with the external plugins would be that
they need to support
your interface - anything else wouldn't work."
I don't think this is exactly accurate. When I first mentioned the
tool I never planned on changing the current way of installing
plug-ins. My goal was only to make things a little easier for the
user. Also, as I mentioned to Larry, the tool could easily work with
plug-in that don't implement the interface by copying them to the
lib/ext directory.
I'll give this some more thought. Please rest assured that I won't
change anything in the core that affects how we currently install
plug-ins. I will also give consideration to Larry's concern about
confusing users on the plug-in installation.
Landon
On Sun, Nov 16, 2008 at 4:40 PM, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> mhm.. basically I agree with Larry right now. People can get confused.
>
> . For the external plugins they need to know only once that they need to
> drag and drop or remove jar files
> . For the internal plugins with have now the default-plugins.xml file
>
> the problem with the external plugins would be that they need to support
> your interface - anything else wouldn't work.
>
> btw. on the issue with the extension download tool: the problem was, so
> I believe, related to the use and unpacking of zip files???
>
> stefan
>
> Sunburned Surveyor schrieb:
>> Michael,
>>
>> You wrote: "...discovering new plugins in the project repository and
>> downloading/updating them seems more useful than a local installer,
>> that's why I misunderstood Landon's proposal when I read it."
>>
>> That was one of the ideas I had when I was thinking of the update
>> method in the PlugInHandler interface. The method could check a file
>> on a web server to see if new versions of a plug-in were available.
>> I'd imagine the same mechanism could be used to discover new plug-ins.
>> This would work similar to Eclipse.
>>
>> I always consider Larry's comments carefully, so I will think on what
>> he said. Perhaps there is a solution that won't confuse the users.
>>
>> Please remember I'm not talking about anything that would be forced on
>> OJ programmers. It would just be a tool that could be used if
>> programmers were interested.
>>
>> SS
>>
>> On Fri, Nov 14, 2008 at 2:49 PM, Michael Michaud
>> <[EMAIL PROTECTED]> wrote:
>>> Stefan Steiniger a écrit :
>>>> there has been an extension manager, but this one was rather for
>>>> downloading available plugins. the code is still there, but could be
>>>> that the plugin needs to be activated (in the xml file)
>>>>
>>> Yes, that's it.
>>> Larry says he had some problems with this plugin.
>>> but IMHO, discovering new plugins in the project repository and
>>> downloading/updating them seems more useful than a local installer,
>>> that's why I misunderstood Landon's proposal when I read it.
>>>
>>> Michaël
>>>> stefan
>>>>
>>>> Michael Michaud schrieb:
>>>>
>>>>> Hi,
>>>>>
>>>>> There used to be a plugin manager in the menu, but I cannot find it
>>>>> anymore.
>>>>> It was from lat/lon if I remember correctly, but I'm not sure it has
>>>>> ever been used the project's plugin.
>>>>> Anyone remember ?
>>>>>
>>>>> Michaël
>>>>>
>>>>> Sunburned Surveyor a écrit :
>>>>>
>>>>>> I've got about four plug-ins that I hope to release in January. This
>>>>>> includes my reader for GPX files, the latest edition of the Super
>>>>>> Select Tool, and a couple of Layer Utilities plug-ins.
>>>>>>
>>>>>> Some of these are simple plug-ins with a single Jar and no
>>>>>> dependencies. So you can just drop them into the /ext folder of
>>>>>> OpenJUMP. Other of my plug-ins, like the Super Select Tool and the GPX
>>>>>> Reader, depend on external libraries and have I18N and configuration
>>>>>> files. I had cooked up part of an installer for the Super Select Tool
>>>>>> when I got to thinking that it might be nice to have a tool that could
>>>>>> be used to install, uninstall, and update plug-ins for OJ. It wouldn't
>>>>>> have to be a part of OJ, it could even run as a separate executable.
>>>>>>
>>>>>> I was thinking of this simple interface:
>>>>>>
>>>>>> public interface PlugInHandler
>>>>>> {
>>>>>> public abstract void installPlugIn(File argOpenJumpFolder);
>>>>>>
>>>>>> public abstract void uninstallPlugIn(boolean
>>>>>> argRemoveSharedLibraries);
>>>>>>
>>>>>> public abstract void updatePlugIn();
>>>>>> }
>>>>>>
>>>>>> I was thinking of another interface that could be used by
>>>>>> PlugInHandler.installPlugIn method implementations to show a standard
>>>>>> GUI to the user during plug-in installation/update:
>>>>>>
>>>>>> public class PlugInInstallerGuiProvider
>>>>>> {
>>>>>> public abstract JPanel getLicensePanel();
>>>>>>
>>>>>> public abstract JPanel getInstallConfigurationPanel();
>>>>>>
>>>>>> public abstract JPanel getAboutPanel();
>>>>>> }
>>>>>>
>>>>>> I thought a library providing these interfaces and some default
>>>>>> implementations might help us standardize plug-in management and make
>>>>>> the process of installing and removing plug-ins a little easier on the
>>>>>> end user.
>>>>>>
>>>>>> Do you guys have any comments on this?
>>>>>>
>>>>>> The Sunburned Surveyor
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
