On 07.08.2021 20:33, Michaud Michael wrote:
> Hi Ede,
>
> I'm on the way of upgrading extensions to make them work with recent changes.
>
> It will probably take some time as every single plugin is impacted.
are you using '-extensions-dir', '-limit-ext-lookup' in your IDE that were just
introduced to facilitate extension development?
i'm still in the process of finalizing HelloWorldExtension . if that's done i
will start with extensions as well.
please take care to remove lib/plus/ jars and implemenent extensions as maven
build download as outlined with skyprinter when you are finished with fixed
upped extensions.
> As far as I can see, I18N can now be used from extensions, thank you for
> that. I'll close the ticket, but before that, I'd like to upgrade a whole
> extension, and at the moment, I'm still annoyed with some changes you did in
> AbstractPlugIn that I would like to fully understand (or change).
don't be :))
> A PlugInContext is now requested in AbstractPlugIn
>
> line 414 : if (context == null) throw new RuntimeException("Add
> super.initialize() to your AbstractPlugIn.initialize()
> implementation!\n"+this.getClass().getName());
>
> I have questions about the why and the how :
>
> why : AbstractPlugIn used to take a PlugInContext argument at execution time
> (method execute). Seems that adding it as an attribute is convenient but I'm
> not sure it is needed.
well it was. we were using references to the workbench in AbstractPlugIn via
JUMPWorkbench.getInstance() that needed to be replaced somehow.
> For example, I think ToolboxPlugIn does not use initialization, so inheriting
> getContext which needs this attribute is error prone. Note that I probably
> wouldn't have notice it if it didn't cause trouble during old plugins
> migration
isn't ToolboxPlugIn still using JUMPWorkbench.getInstance().getContext() all
over, which by design is always the same?
and yeah ToolboxPlugIn is a weird beast that is not cleanly implementing the
JUMP PlugIn contract (instantiate,initialize,execute,execute,...), so we will
have to clean that at some point
> how : if an old plugin does not use super.initialize(), nothing break at
> compile time. Application starts normally but the UI can definitely break
> down if you try to use the plugin (in my case, cursor tools won't work any
> more). The logged message is quite clear but for such a breaking error, a
> dialog box would be needed.
not sure it is worth the effort for a one time error which should appear during
development only. but go ahead and add it if you feel it's needed. was under
the impression that the error is shown by UI though.
> Let see
>
> - if a context is something really needed by all plugins
it probably is not needed by *all* currently. nevertheless if we want to
contextualize throughout we need to provide the context _all over_ as it is the
anchor point to JUMP API.
> - if it is needed (or definitely wanted) : how can we force the
> implementation in all children or avoid broken implementation in a safer way
i'd say it is, so we merely have a choice between a proper constructor
parameter 'new PlugIn(WorkbenchContext wbc)' or the workaround i chose to make
transition a little bit more easy.
you are very welcome to convince me of any better way of course ..sunny regards
ede
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
