Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/755
+1, just for the record
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/755
@ottobackwards and @nickwallen any issues?
---
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/755
I'm +1 with this (as a temporary measure to make things work), assuming
@ottobackwards and @nickwallen are as well.
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/755
So, I tested this on a kerberized multi-node cluster and full-dev. I
ensured that I tried with and without the management functions jar and
with/without kerberos as well.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/755
Whatever it takes in the meantime. When this is plugin based, this all
goes away.
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/755
Ok, I just want to be completely clear, we're actually choosing *one* of
our jars, the parsers jar, because it's an uber jar that has ALL of our stellar
functions in Metron in it. I'm also
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/755
ok, if and when we look at stellar archetypes and extensions we'll have to
keep this in mind
---
Github user cestella commented on the issue:
https://github.com/apache/metron/pull/755
@ottobackwards I'd argue that it SHOULD be a temporary thing. At the
moment things are broken as they are.
---
Github user ottobackwards commented on the issue:
https://github.com/apache/metron/pull/755
Is this just a temporary thing?
I think the longer term thing is to split the stellar out into their own
modules, an possibly have modules split further by special dependencies.
