I can see the confusion I am causing already! :]
I'm not worried about how OJ loads the plug-ins. Jon's code to
automatically initialize PlugIn implementations found in lib/ext or
any of its subdirectories works great. I was more concerned with
helping the user manage the installation process. This is only needed
if the plug-in doesn't contain just a single JAR.
Consider this folder structure example:
lib
ext
surveyos
super_select
i18n
The "super_select" folder contains the plug-in JAR and other files
needed for my Super Select Tool plug-in. This includes a configuration
file and I18N files stored in the "i18n" folder. I'd like to store
future plug-ins I create in there own sub-folder of "surveyos". I'll
put libraries that are depended on my more than one of my plug-ins in
the "surveyos" folder. That way I don't pollute the main "lib" folder
of OJ with libraries that are only used by my plug-ins.
In theory, installation of one of my plug-ins could involve the following steps:
- Copy the plug-in folder into the /lib/ext/surveyos folder.
- Copy any new libraries used by the plug-in into the /lib/ext/surveyos folder.
If the user has already installed plug-in 1 (that depends on "library
a") I don't want him to reinstall "library a" it when he installs
plug-in 2. What I really want is for the user to select from a list of
my available plug-ins, and have an installer do the rest, including
figure out the dependencies and copying folders to the correct OJ
sub-folder.
The Sunburned Surveyor
On Mon, Nov 17, 2008 at 7:51 AM, P.Rizzi Ag.Mobilità Ambiente
<[EMAIL PROTECTED]> wrote:
> I may be mistaken, but I believe the plugin classloader of OJ
> will load any .jar file it founds inside any ext subdirectory,
> not only inside the ext directory itself.
> So even if a plugin has a complex directory structure, what is
> only needed is that its JARs are under ext somehow.
> So:
> ext/pippo/pluto/paperino/pippo.jar
>
> will work as good as:
> ext/pippo.jar
>
> A different story may be for a plugin that needs DLLs or .so modules
> or that has a complex configuration system, but in that case it may
> have it's own installer...
>
> Something that may be useful for OJ would a simple system (via GUI
> and/or configuration files) to specify several different directories
> to look plugin for. This way one could put it's plugin JARs wherever
> he wants in the filesystem and then tell OJ to load them like they
> were inside the ext directory or to stop looking into that directory
> to "remove" them.
>
> My 2 (Euro)cents.
>
> Bye
> Paolo Rizzi
>
>
>> -----Messaggio originale-----
>> Da: Sunburned Surveyor [mailto:[EMAIL PROTECTED]
>> Inviato: lunedì 17 novembre 2008 16.42
>> A: OpenJump develop and use
>> Oggetto: Re: [JPP-Devel] Tool for installing,
>> uninstalling,and removing
>> OpenJUMP plug-ins.
>>
>>
>> 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
>>
>
> -------------------------------------------------------------------------
> 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
