guacamole-client icon indicating copy to clipboard operation
guacamole-client copied to clipboard

add ability to reuse the classes from the `guacamole` module

Open cmosguy opened this issue 5 years ago • 4 comments

Hello Guacamole Team,

The purpose of this PR is to enable reuse of the classes from the guacamole module. What I found was it was not possible before because everything is deployed in a self-contained .war file. Now, with this PR, you can see a guacamole-1.2.0-classes.jar file in your .m2/repository directory tree that can be now used for development of other custom servlets.

cmosguy avatar May 09 '20 13:05 cmosguy

@cmosguy: Thank you for the contribution. Before we go further, though, please create a JIRA issue for this and tag both the pull request and the commit messages with the JIRA issue.

http://guacamole.apache.org/open-source/

necouchman avatar May 09 '20 14:05 necouchman

I'm not sure about this approach. There has to be some scope and design behind the creation of a library.

I agree it makes sense to extract a common core from the mainline Guacamole webapp to allow easier implementation of similar web applications, but I think the method for achieving that would have to be intentionally identifying, extracting, and committing to a public API. The mainline webapp would then pull in that library just as it currently leverages the more low-level guacamole-common and guacamole-common-js libraries.

mike-jumper avatar May 11 '20 01:05 mike-jumper

Hello @necouchman I just amended the commit message with GUACAMOLE-1071 is this all that is needed?

@mike-jumper -- I agree that the code would need to be refactored a bit to extract out the components low-level components that can be reused.

I think this is a starting point, and we need to think about how to make this modular. Do you or anyone on the team have ideas of how to more efficiently extract this out? Can we keep this in the mean time and let the community help?

cmosguy avatar May 14 '20 20:05 cmosguy

I think this is a starting point, and we need to think about how to make this modular. Do you or anyone on the team have ideas of how to more efficiently extract this out?

Can you perhaps describe what is driving you to make this change and what pieces you are looking to make use of? That may be a good starting point for discussion. I would also recommend bringing this onto the dev@ mailing list, to see how the wider development community feels about extracting a reusable core and what form that core might take.

Can we keep this in the mean time and let the community help?

I don't think we should release an API that we do not intend to support.

mike-jumper avatar May 14 '20 22:05 mike-jumper