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
