metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Miklavcic <michael.miklav...@gmail.com>
Subject Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo
Date Tue, 31 Jan 2017 18:03:29 GMT
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 Maven Central, the artifacts are there forever. The
source code is also required to publish to Maven Central, so even though
it's not in a repo structure, it could still be referenced if absolutely
needed.
2. Bringing in the source code allows us to avoid a separate review process
with Sonatype/Maven for getting into Maven Central. Kraken pcap source
hasn't been modified in quite a while, so we wouldn't really be missing
much by forking the project internally. And we'd have the full source
building in case we need to address any bugs or security issues. Much
easier than the other option.

On Tue, Jan 31, 2017 at 10:53 AM, JJ Meyer <jjmeyer0@gmail.com> wrote:

> 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
> past. I will say sometimes it becomes a bit confusing as to what version of
> the submodule is being used. It could just be me though.
>
> http://alex.nederlof.com/blog/2013/07/08/using-git-submodules-for-maven-
> artifacts-not-in-central/
>
> Thanks,
>
> On Tue, Jan 31, 2017 at 11:41 AM, Michael Miklavcic <
> michael.miklavcic@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 Kraken code as part of Metron. So I could
> > literally pull down the full source, plop it in a new Maven submodule
> > within the Metron project structure and be good to go? Seems like this
> > might actually be easiest. Plus we'd have the source code.
> >
> > Alternatively, you mention publishing to Maven Central. It looks like
> Maven
> > Central has some requirements for publishing artifacts that might prove
> > hairy - http://central.sonatype.org/pages/requirements.html. Let's say I
> > fork the project (not via Metron) in my own github fork and modify the
> > Kraken poms to provide the necessary info. I'm supposed to provide the
> scm
> > location (my github repo), javadoc, signed jars, etc. I'd also need to
> > modify the groupId. Should that then be something personal (e.g.
> > com.michaelmiklavcic) or would it be ok to use org.apache.metron as a
> > groupId? I prefer to use Metron's groupId. I believe there is also a
> review
> > process involved with getting artifacts published to the central repo
> which
> > might take some time.
> >
> > I think the submodule sounds like the best approach, but want to be sure
> > I've understood the recommendations correctly. We need to resolve this as
> > part of our move out of incubation to TLP status.
> >
> > Thanks,
> > Mike
> >
> >
> > On Tue, Jan 17, 2017 at 2:49 PM, Billie Rinaldi <billie@apache.org>
> wrote:
> >
> > > On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley <mattf@apache.org> 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 that if it were a release artifact for an official
> > > release. There is some more information about releases here:
> > > http://www.apache.org/dev/release.html#what. Specifically, anything
> that
> > > is
> > > published is considered a release, and that would definitely include
> > > anything on dist.apache.org. We can only release source code and
> binary
> > > artifacts resulting from compiling that source code.
> > >
> > >
> > > >
> > > > We should not host anything with a license that isn’t compatible with
> > > > inclusion in an Apache project.  If we post only non-source
> artifacts,
> > > then
> > > > that would include packages with “Category B List” licenses (that
is,
> > > > ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses
> > (those
> > > > “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> > > > https://www.apache.org/legal/resolved .  For versioning, we could
> > simply
> > > > structure as a maven repo, and in fact that’s what I think we should
> > do.
> > > >
> > > > Hosting the source code is not, I think, something we are supposed to
> > do
> > > > for non-Apache projects: https://www.apache.org/legal/resolved
> again,
> > > > this time the very first question:
> > > >
> > > >     CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> > > >     No. See the Apache Software Foundation licenses page for more
> > > details,
> > > > and the Apache Software Foundation page for additional background.
> > > >
> > >
> > > Kraken does appear to be licensed under ASLv2. Based on that, it might
> be
> > > possible to use the kraken code as the basis of a submodule of the
> Metron
> > > project, so that the necessary kraken jars would be built as part of
> the
> > > Metron build.
> > >
> > > Alternatively, someone could just push the kraken jars to Maven central
> > > under a new group id. Here's an example of a personal GitHub repo
> project
> > > configured to publish to Maven central via Sonatype:
> > > https://github.com/joshelser/dropwizard-hadoop-metrics2/
> > > blob/master/pom.xml.
> > >
> > >
> > > >
> > > > On 1/13/17, 8:11 AM, "Billie Rinaldi" <billie@apache.org> wrote:
> > > >
> > > >     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 subject is changed as well.
> > > >
> > > >     On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
> > > >     michael.miklavcic@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 original reason for this was that these
> > jars
> > > > are not
> > > >     > hosted in Maven Central, and they were not reliably available
> in
> > > the
> > > > Kraken
> > > >     > repo. https://issues.apache.org/jira/browse/METRON-650 is
> > tracking
> > > > work
> > > >     > around copying these artifacts to the Metron repo.
> > > >     >
> > > >     > Kraken source on openSOC - https://github.com/OpenSOC/kraken
> > > >     > Krake maven repo on openSOC -
> > > >     > https://github.com/OpenSOC/kraken/tree/mvn-repo
> > > >     >
> > > >     > *Ask*
> > > >     > Create a new branch in incubator-metron to host any necessary
> > maven
> > > >     > artifacts. This branch would simply be
> incubator-metron/mvn-repo.
> > > > This is
> > > >     > similar to how we've hosted the asf-site.
> > > >     >
> > > >     > *Concerns/Questions*
> > > >     >
> > > >     >    1. Can we host these jars/artifacts in this manner?
> > > >     >    2. Concerns regarding licensing?
> > > >     >    3. Do we need to also grab and host the source code?
> > > >     >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message