Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support writing Guacamole commands in separate projects #424

Open
timodonnell opened this issue Apr 4, 2016 · 2 comments
Open

support writing Guacamole commands in separate projects #424

timodonnell opened this issue Apr 4, 2016 · 2 comments

Comments

@timodonnell
Copy link
Member

Not sure if this is already doable as-is, but I have a case now where I'd like to do this, so it'd be good to figure out what the best approach is and put together an example for others. @jstjohn is also interested in this.

I have a Guacamole command in a branch here that is an ad-hoc analysis I needed for a separate project.

Since it doesn't really belong in Guacamole master, I'd like that command to live in a separate repo (for hammerlab internal users: this one), while minimizing the amount of maven boilerplate. It'd be useful to put together some documentation showing the best way to do this.

@arahuja
Copy link
Contributor

arahuja commented Apr 5, 2016

@timodonnell What are thinking for this? Two things I could see are 1) having a github repo that has an example that is cloneable or 2) a maven archetype?

I think this should be possible as-is (we would need to publish an updated JAR to maven) but I have used guacamole in other projects previously. One issue is that we do mix a lot of command-line utilities, spark components, and general read-handling, and those would all need to be included since we have a single jar created. Splitting the project back to multiple modules as in #329 would allow for end-users to selectively take features for example pileupFlatMap and have their own command interface.

@timodonnell
Copy link
Member Author

@arahuja I somehow missed your comment before, sorry about that. I think having an example of such a command is a good idea. Maybe we could add a directory to the Guacamole repo with a minimal separate project that uses Guacamole to implement a new command? That way we can keep the example in sync with Guacamole without having to have a separate repo for it, and can also test in Guac travis that it builds. Then someone can just copy it over as a template if they want.

I'm not too concerned about pulling in unneeded components as I doubt it's much of a performance impact. I'm not against splitting up Guacamole though if you think it's worthwhile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants