search

hammerlab / guacamole

Spark-based variant calling, with experimental support for multi-sample somatic calling (including RNA) and local assembly
Apache License 2.0
84 stars 21 forks source link

support writing Guacamole commands in separate projects #424

Open timodonnell opened 8 years ago

timodonnell commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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.