Overriding plugin classloader via Annotations?

[Evgeny Minkevich]

Hi,

is there a way to enforce overriding classloader for a plugin through annotations?

Or the plugin.xml is the only way to go?

[Matt Casters]

Hi Evgeny,

I don't know what exactly you were asking for but we had a requirement to allow multiple plugins to use the same class loader.

So we added http://jira.pentaho.com/browse/PDI-11612

If there are other tweaks you need, this might be a great time to bring them forward.

Happy hacking,

Matt

[Evgeny Minkevich]

Had a look at the patch - good option to have indeed, thank you.

Would you have a minute to check the Drools library mess (http://jira.pentaho.com/browse/PDI-10657) ?

As the in-place upgrade did not work I converted the Rules Executor/Accumulator steps into a plugin. This way the DROOLS dependencies will be isolated from the downstream projects. Yes they will need to be explicitly defined in the downstream projects. But that will allow us to untangle them (i.e. modeller) from the PDI implementation and allow me to upgrade the DROOLS version to the recent release.

Would much appreciate some help in that regard.

Thanks.

 

--
You received this message because you are subscribed to the Google Groups "kettle-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kettle-develop...@googlegroups.com.
To post to this group, send email to kettle-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/kettle-developers.

For more options, visit https://groups.google.com/d/optout.

[Matthew Burgess]

This is a good idea as a plugin, thanks very much for your contribution! However we are encouraging contributors to add their plugins to the PDI Marketplace (hosting their own code and distribution, rather than in the pentaho-kettle GitHub project) to keep the size of the core product to a minimum and put the power back in the hands of the user as to which plugins are installed and so forth.

I meant to respond earlier to this and for that I apologize; I offer my help in getting you set up to deliver the plugin to the PDI Marketplace so we can all benefit from your contribution!

Cheers,

Matt(B)

[Evgeny Minkevich]

Sure - that's the plan. I would like to do a proper implementation (including variables, globals, flexible editing) for the latest version version of drools - 6.0.

The problem is that while the existing version (5.0) is part of the core PDI - it is not possible  - drools intialises itseld in a way that conflicts with plug in classloaders). That's why I suggested to move the _existing_ version (5.0) to be a plug in  as well - https://github.com/pentaho/pentaho-kettle/pull/272 - just to preserve backward compatibility for those who might be using it.

If the pull request is accepted I'll start on drools 6 as a plug in which will be distributed through a market place.

Two versions can coexist if they are both plugins.

Any help in promoting the abovementioned pull request is appreciated.

 

[Matthew Burgess]

Ah, I see what you mean, we've done something similar for logging in 5.0.  Matt C, can you review and comment on the inclusion of a new Kettle core plugin?

Thanks,

Matt

[Evgeny Minkevich]

Bear in mind that if you accept this pull, modeller project will most likely fail - as it depends on PDI for its libraries (that's why the in place fix - pull 205 - has been reverted).

To fix this failure one would need to add the following libraries as the modeller dependencies :

    <dependency org="org.mvel"                         name="mvel2"                rev="2.0.10"          transitive="false"/>

    <dependency org="org.eclipse.jdt"                  name="core"                 rev="3.4.2.v_883_R34x" transitive="false"/>

and potentially the drools if the two above will not be enough:

    <dependency org="org.drools"                       name="drools-api"           rev="5.0.1"           transitive="false"/>

    <dependency org="org.drools"                       name="drools-core"          rev="5.0.1"           transitive="false"/>

    <dependency org="org.drools"                       name="drools-compiler"      rev="5.0.1"           transitive="false"/>

These are the libraries that have been moved into plugin.

[Matt Burgess]

Indeed, that's been the concern thus far, the JDT dependency on Drools and the potential conflicts. For a releasable product, this implies quite a bit of regression testing by our engineers.

That's not to say your request won't be accepted, it just has to go through the engineering workflow including prioritization and risk assessment.

Cheers,

Matt

Sent from my iPhone