On 8/28/2018 23:28, Michaël Michaud wrote:
>
> On 8/28/2018 22:00, Michaël Michaud wrote:
>>> HI Ede
>>>
>>>
>>>> right. what does it do by the way. i saw it lacks german translation which
>>>> i could do if i know what it does. it seems to be hidden in the Plugin
>>>> menu as well and should be placed properly via def-plugins.xml if we
>>>> decide to keep it.
>>> What should be placed by default-plugins.xml ? I think it is the role of
>>> the extension to place its own plugin isn't it ? default-plugins is not
>>> supposed to know anything about extension's plugin or did I miss something ?
>> well yes ;).. when i redesigned the plugin loading i made it possible for us
>> to finetune plugin installing as we want it, because we might know better
>> where to place it or simply want to force some order onto things.
>> another reason was to make it possible to influence plugin installing w/o
>> needing to patch the extension first. you might want to check eg. how
>> skyprinter is placed to a different location
>>
>> <plug-in initialize="false">
>> com.isa.jump.plugin.PrintPlugIn
>> <menus>
>> <main-menu name="I18N.ui.MenuNames.PRINT.SkyPrinter"
>> menupath="MenuNames.FILE/MenuNames.PRINT" />
>> </menus>
>> </plug-in>
>>
>> we can actually modify any aspect of the plugin installation here (icon,
>> name etc.)
> I know using default-plugins.xml gives a good control over plugin
> installation without changing the code, but in your example, this is a plugin
> that is included in OJ Core.
well no, it is shipped with CORE but actually is an extension in lib/ext/ and
installs itself. but ok, then take cadplan printer, which is shipped w/ PLUS
<plug-in initialize="false">
com.cadplan.jump.PrinterPlugIn
<menus>
<main-menu name="I18N.ui.MenuNames.PRINT.Cadplan"
menupath="MenuNames.FILE/MenuNames.PRINT" />
</menus>
</plug-in>
>What about real extension which we dont want in the core like the
>ViewManagerExtension ? Can we use default-plugins.xml to install plugins that
>do not exist in the CORE ?
yes. the plugin class simply needs to be within the scope of our classloader.
then
<plug-in initialize="true">
my.super.plugin
<menus>
<main-menu name="..." menupath="..." icon="..." />
...
</menus>
</plug-in>
installs it.
'initialize=false' though, does not prevent installing. it merely does not run
the install routine in plugin manager and the extension does have to do it
themselves. but when they do, they use featureinstaller, which in turn checks
for the values in default-plugins.xml, nifty no?
>
Should we maintain two default-plugins.xml ?
why? the idea is to have _one_ place, where we can sort menu entries or modify
them to our will. i would not know how to maintain sequence when two files are
used.
>And what abou third-party extensions that we want to include in PLUS ?
works already, doesn't it? some PLUS extensions are probably already sorted via
default-plugins.xml and if not they are simply added to the end of their
corresponding menu.
>>>> how about we remove it and if users complain we at least know it is in
>>>> actual use and think of a solution?
>> so Mike, rather removal or adaption? btw. the maven jar is merely 90kB big,
>> wouldn't javax.xml.bind suffice?
>> https://mvnrepository.com/artifact/javax.xml.bind/jaxb-api/2.1
> I think that we'll need several additional jars : jaxb-api, jaxb-core,
> jaxb-impl, activation
> That means 1.4M. But I did not test anything. It would be a good new if
> jaxb-api was sufficient ;-)
well, maven registries usually maintain dependency lists. the entry above does
state only a compile time dependency to one other jar. no runtime dependencies
at all. not saying it's correct, just stating what it says.
> I'd rather remove the extension than review its persistence mechanism because
> anyway, I generally package a specific distro to users I know. But before, I
> wish to hear from Jukka and Peppe, because if they sometimes use this
> extension, or know people using it, it maybe worthwhile letting it in PLUS
> distro, event at the price of +1.4Mb.
ok. let's wait for their opinion on the matter.. ede
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
