I would think that we want individual plugins for each variant. This does lead me back to an earlier discussion about gremlin-variant packaging. We didn't want to do
gremlin-variant +-- gremlin-variant-python +-- gremlin-variant-js, +-- .... +-- gremlin-variant-XXXXX so with gremlin-variant users are going to just get everything when they depend on it. To my knowledge, we are only kinda viewing this from a python perspective atm and haven't really researched all the languages we support, but I sense that ultimately as we add more GLVs we're going to end up with a really messy pom.xml for gremlin-variant with the potential for conflict as we try to make maven deal with packaging issues for all those disparate languages. Again, hard to say how much trouble this will eventually be, but might be worth noodling on again in case anyone has any new thoughts on the matter. On Thu, Jun 16, 2016 at 12:10 PM, Daniel Kuppitz <[email protected]> wrote: > The last few days I've been working on a Gremlin Python code executor for > the TinkerPop docs. What I noticed was that we can't simply execute Gremlin > Python code in our Gremlin Groovy console, simply because the console has > no dependency to the gremlin-variants projects. > > That was unfortunate for the docs pre-processor, but what about the normal > user? Do we need to have those language variants always available or would > it be sufficient to have a Gremlin-Xyz plugin (where Xyz could be Python, > Ruby, etc.)? > > I've added the "missing" dependency for now to get the docs pre-processor > extension done, but I think we should remove that dependency again and > create a plugin instead, before the branch gets merged into master. > > Cheers, > Daniel >
