All, unless there are any objections, for now it might be best to keep the
status quo and circle back around to modifying this dependency at a later
time. While not ideal, it does not appear to currently violate any
licensing rules.
Best,
Mike
On Tue, Jan 31, 2017 at 11:04 AM, Billie Rinaldi
On Tue, Jan 31, 2017 at 9:41 AM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> Hi Billie,
>
> Thanks for the feedback and info. I'm working on resolving this over the
> next couple of days and could use some additional guidance when you have a
> moment.
>
> You mention building the
My reservation with this approach is that we're still depending on an
unreleased version of files from a github repo that we do not control. So
if Kraken or OpenSOC pull their repos, then this no longer works. The 2
approaches outlined above mitigate this risk as follows:
1. Once published to
Mike,
You wouldn't need to necessarily download the code and host it in the
metron repo. Git sub-modules are sometimes used in cases like this. It is
more like a pointer to an external repo. Below is a short read on how we
could potentially do this with git sub-modules. I have used these in the
Hi Billie,
Thanks for the feedback and info. I'm working on resolving this over the
next couple of days and could use some additional guidance when you have a
moment.
You mention building the Kraken code as part of Metron. So I could
literally pull down the full source, plop it in a new Maven
On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley wrote:
> Perhaps it would be more appropriate to put it under
> https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps as
> https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?
>
No, we could only do
Has anyone used git's sub-modules before? My understanding is you just
point to an external repository. So *technically* I do not think the code
would be hosted in the main repo. Even if that was allowed, I have concerns
about how inactive the repo is. Could we fork this, make our changes, and
Perhaps it would be more appropriate to put it under
https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps as
https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?
We should not host anything with a license that isn’t compatible with inclusion
in an Apache
No, we can't host artifacts in a git repo, or on a website. It would be
like distributing a release that hasn't been voted upon.
Regarding message threading, in Gmail adding a [tag] to the subject does
not create a new thread. So the change is not visible in my mailbox unless
the rest of the
Ok, that was funny
On Wed, Jan 11, 2017 at 7:43 AM, Casey Stella <ceste...@gmail.com> wrote:
> I'd recommend restarting this discuss thread with the subject
> "[DISCUSS][MENTORS] Hosting Kraken maven artifacts in incubator-metron git
> repo". That's the Mentors bat
I'd recommend restarting this discuss thread with the subject
"[DISCUSS][MENTORS] Hosting Kraken maven artifacts in incubator-metron git
repo". That's the Mentors bat-symbol. The other option is to repeat
"mentors" 3 times and either the mentors will appear or you wil
Any comment from the mentors on this?
On Mon, Jan 9, 2017 at 2:00 PM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:
> This is a question primarily for the mentors.
>
> *Background*
> metron-common is currently depending on the openSOC github repo for
> hosting kraken artifacts. The
Just a heads up and hopefully not a distraction:
Per https://issues.apache.org/jira/browse/METRON-583, if we ever update to a
never version of GROK, many of our existing rules are going to break.
I have a pull request out for this issue (
https://github.com/thekrakken/java-grok/pull/60 ) with
This is a question primarily for the mentors.
*Background*
metron-common is currently depending on the openSOC github repo for hosting
kraken artifacts. The original reason for this was that these jars are not
hosted in Maven Central, and they were not reliably available in the Kraken
repo.
14 matches
Mail list logo