[
https://issues.apache.org/jira/browse/CLK-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883500#action_12883500
]
Md. Jahid Shohel commented on CLK-347:
--------------------------------------
I already read that post, and that's how I thought too, that's why I did not
mention them on my earlier post. The requirements I see, and the possibility of
solving those with existing system are mentioned below-
Requirements -
1) Click should have modularity support. Where developers can write their own
click modules and use the same module on different applications.
2) Each module should be self contained with all its resources.
3) Each module should have a way to mention its own configurations. If any
specific configuration is not specified, then it will use the application's
configuration. This will give the module to run with its configurations
isolated.
4) A module need to be self contained, so that it should be possible just to
plug in a module without require to modify it before plugging it in.
What we can/can't solve with existing technology (according to requirements
sequence)-
1) Current click release does not support modularity at all. So may be we have
to start it from scratch. As per the last solution, we can have a ModuleService
which is responsible for loading all modules. And main application
(ClickServlet or any config service) can trigger the ModuleService to load
modules. That way we can keep loading modules separate.
2) For resources, It should work exactly as bob mentioned on earlier post (see
above). The only thing I will suggest is, the module should have a scope to
mention its own configuration with it.
3) There are several way to let the module has its own configuration with it.
Right now we xml approach, and we can share a huge amount of code from
xmlconfigservice (will require refactor xmlconfigservice and separate common
logics to share). Using properties or annotations are other alternatives. In
the old solution, it was done by letting user implement/extend a
interface/class and return their own configurations. We can still use that, but
this might encourage some user to hard code their configurations inside the
class.
> Module support
> --------------
>
> Key: CLK-347
> URL: https://issues.apache.org/jira/browse/CLK-347
> Project: Click
> Issue Type: Improvement
> Components: core
> Reporter: Bob Schellink
>
> Add module support to Click core. Some code has been committed here:
> http://click.svn.sourceforge.net/viewvc/click/trunk/sandbox/sabob/plugin/
> Note that with the recent work done on CLK-343 the module code wont compile
> anymore.
> A related issue is: CLK-328
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
