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 20:02:46 GMT
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 <billie@apache.org> wrote:

> On Tue, Jan 31, 2017 at 9: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.
> >
>
> There is an IP clearance process for bringing externally developed code
> into an ASF project: http://incubator.apache.org/ip-clearance/
> It says a software grant form is required. I am not sure what the options
> are in the case where a software grant can't be obtained and the code is
> ASLv2 licensed. This would probably have to be discussed on the incubator
> general list or on legal.
>
>
> >
> > 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.
> >
>
> You not should use Apache's groupId. I heard from Josh that Sonatype
> encourages com.github.<username>.
>
>
> >
> > 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