issue#178 refactor subplugins calls

[tuanngocnguyen]

Hi @NinaHerrmann

Regards #178, I have made changes for the external trigger/step plugins.
All existing builtin plugins should still works as they are.
This patch allow developers to define additional lifecycle trigger/step plugins outside their pre-defined subplugins folders.
That is, a tool_sampletrigger can be defined as a lifecycle trigger if it define a trigger class (subclass of \tool_lifecycle\trigger\base) under "tool_sampletrigger\lifecycle" name space.

Please let me know your opinion on this.
Thanks

[jwcatau]

Hallo @NinaHerrmann!

Just touching base with you regarding @tuanngocnguyen's subplugin refactor PR.

We're building this for a client who are happy to contribute this and additional sub-plugins which depend on this architecture, which poses a (small) risk in the event that your plugin needs to be forked.

If you'd like, I'd be keen to touch base with you on this to discuss the adjusted plugin approach, with a view to confirming the changes we're proposing to your plugin are satisfactory, and likely to be accepted.

This will greatly assist with version management and open up your plugin for more plugins (some of which are under development by us) can be published using the same architecture.

Kind regards,
James.

[jwcatau]

Hi @NinaHerrmann,

Following up on this PR.

It would be great to discuss getting this change merged, to encourage community development of plugins and greater adoption by more users without the need to fork your plugin.

Appreciate your feedback and any opportunity to discuss any concerns or questions.

Thanks!

[dmitriim]

Linking a new PR #293