It's optional. Here are the instructions for publishing maven artifacts: http://www.apache.org/dev/publishing-maven-artifacts.html
On Wed, Mar 30, 2016 at 8:52 AM, Casey Stella <[email protected]> wrote: > Taylor, I noticed that you have uploading to repository.apache.org in the > template for the release vote. First, is that strictly required? Second, > if so, are there instructions? I'm having some problems uploading the > bundle created by the mvn repository plugin to a staging repo due to a > missing release profile (and I can't figure out where I might be able to > create such a thing..perhaps I need different or more karma for that sort > of thing?) > > Casey > > On Tue, Mar 29, 2016 at 10:03 PM, P. Taylor Goetz <[email protected]> > wrote: > > > Okay, so you are using gitpubsub... > > > > To remove the website from the releas, the two easiest options I can > think > > of are: > > > > 1. Just exclude the site directory from the source release. > > 2. Create a new, bare branch (e.g. "metron-site"), move the site content > > there, and ask infra to point to that branch for website publishing. > > > > -Taylor > > > > > On Mar 29, 2016, at 7:57 PM, Casey Stella <[email protected]> wrote: > > > > > > We are currently generating the site with jekyll and infra has > something > > > setup that will pull the site from git. > > > > > > Casey > > > > > >> On Tue, Mar 29, 2016 at 7:55 PM, P. Taylor Goetz <[email protected]> > > wrote: > > >> > > >> Yeah, I think that should cover it. > > >> > > >> In terms of licensing issues with the website code, I would recommend > > >> excluding it from the release. If it's not vital to building the > metron > > >> runtime components, it doesn't need to be in a release. > > >> > > >> How are you currently generating and publishing the website? > Svnpubsub? > > >> > > >> -Taylor > > >> > > >>>> On Mar 29, 2016, at 5:36 PM, Billie Rinaldi <[email protected]> > > wrote: > > >>>> > > >>>> On Tue, Mar 29, 2016 at 12:46 PM, Casey Stella <[email protected]> > > >> wrote: > > >>>> > > >>>> Regarding the use of effective_tld_names.dat, it is in use currently > > in > > >> the > > >>>> Whois enrichment adapter (for stripping top level domains from > > domains), > > >>>> but that adapter is not turned on in the tech preview. That being > > said, > > >>>> it's likely we will want to use that file in the future. Since this > > is > > >> a > > >>>> reference file and the reason for the binary-only exclusion is "By > > >>>> including only the object/binary form, there is less exposed surface > > >> area > > >>>> of the third-party work from which a work might be derived; this > > >> addresses > > >>>> the second guiding principle of this policy.", it would seem that > its > > >>>> inclusion as a piece of reference data lessens the exposed surface > > area > > >>>> from which a work might be derived, no? > > >>> > > >>> I read that part as saying that it's only okay to include the binary > > >>> version; but since this is textual data there is no binary version of > > >> these > > >>> files that we could include. However, I missed this part on my first > > >> read: > > >>> "For small amounts of source that is directly consumed by the ASF > > product > > >>> at runtime in source form, and for which that source is unmodified > and > > >>> unlikely to be changed anyway (say, by virtue of being specified by a > > >>> standard), inclusion of appropriately labeled source is also > permitted. > > >> An > > >>> example of this is the web-facesconfig_1_0.dtd, whose inclusion is > > >> mandated > > >>> by the JSR 127: JavaServer Faces specification." > > >>> > > >>> So it sounds like we could argue that these 3 files (which are all > > >>> identical) are a small amount of source, and we will be allowed to > > >> include > > >>> them with an appropriate reference in our LICENSE **as long as we > never > > >>> modify the effective_tld_names.dat files**. > > >>> > > >>> > > >>>> > > >>>> Casey > > >>>> > > >>>>> On Tue, Mar 29, 2016 at 2:55 PM, Billie Rinaldi <[email protected] > > > > >> wrote: > > >>>>> > > >>>>> These files have Mozilla Public License, which has an unusual > policy > > >> that > > >>>>> says we should only include them in binary form (!) -- see > > >>>>> http://www.apache.org/legal/resolved.html#category-b. Can we get > > rid > > >> of > > >>>>> them? > > >> > > metron-streaming/Metron-Common/src/test/resources/effective_tld_names.dat > > >> > > > metron-streaming/Metron-MessageParsers/src/test/resources/effective_tld_names.dat > > >> > > > metron-streaming/Metron-Topologies/src/main/resources/effective_tld_names.dat > > >>>>> > > >>>>> The files at metron-ui/lib/public/font/* seem to have SIL Open Font > > >>>> License > > >>>>> (https://github.com/FortAwesome/Font-Awesome#license), which has > the > > >>>> same > > >>>>> restriction, but they're okay since they're binary. We need to add > > >> their > > >>>>> info to our LICENSE. > > >>>>> > > >>>>> - checksums and signature are valid -- next time include a md5 > > >> signature > > >>>>> - DISCLAIMER is correct -- file name should include "incubating" > but > > >>>>> "incubator" is close > > >>>>> - no binaries in source tarball > > >>>>> - build is successful > > >>>>> > > >>>>> Billie > > >>>>> > > >>>>> On Tue, Mar 22, 2016 at 3:56 PM, James Sirota < > > [email protected] > > >>> > > >>>>> wrote: > > >>>>> > > >>>>>> > > >>>>>> A tag has been created for Metron_0.1BETA_RC5 > > >>>>>> > > >>>>>> Github: > > >> > > > https://github.com/apache/incubator-metron/releases/tag/Metron_0.1BETA_rc5 > > >>>>>> Apache: > > >> > > > https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=shortlog;h=refs/tags/Metron_0.1BETA_rc5 > > >>>>>> > > >>>>>> With a Git hash: > > >>>>>> 443ad7baa2ce5c3127a9691c7d45b7a4a92e257b > > >>>>>> > > >>>>>> The code is staged at > > >>>>>> http://home.apache.org/~jsirota/metron/Metron_0.1BETA_RC/RC_5/ > > >>>>>> > > >>>>>> The following are instructions for verifying the build. > > >>>>>> > > >>>>>> Step 1 – Build Metron > > >>>>>> > > >>>>>> cd incubator-metron/metron-streaming/ > > >>>>>> mvn apache-rat:check && cd metron-streaming && mvn clean > > >>>> integration-test > > >>>>>> && cd .. > > >>>>>> > > >>>>>> Verify that all tests are passing > > >>>>>> > > >>>>>> Step 2 – Deploy metron as a single VM via vagrant and ansible > > >>>>>> > > >>>>>> cd deployment/vagrant/singlenode-vagrant > > >>>>>> vagrant plugin install vagrant-hostmanager > > >>>>>> vagrant up > > >>>>>> > > >>>>>> For a more complete set of instructions refer to: > > >>>>>> https://github.com/apache/incubator-metron/tree/master/deployment > > >>>>>> > > >>>>>> Verify metron is working: > > >>>>>> - Check Ambari to make sure all the services are up by going to > > ambari > > >>>> in > > >>>>>> a browser at http://node1:8080 > > >>>>>> - Check Storm to make sure all the topologies are up > > >>>>>> From Ambari navigate to Storm -> Quick Links -> Storm UI > > >>>>>> - Check that the enrichment topology has emitted some data (could > > take > > >>>> a > > >>>>>> few minutes to show up in the Storm UI) > > >>>>>> - Check indexes to make sure indexing is done correctly and data > is > > >>>>>> visualized in Kibana in a browser at http://node1:5000 > > >>>>>> - Check that some data is written into HDFS for at least one of > the > > >>>> data > > >>>>>> sources > > >>>>>> Look in HDFS under > > >>>>>> /apps/metron/enrichment/indexed/yaf_doc|bro_doc|snort_doc > > >>>>>> This can be done from the browser by going to > > >>>>>> http://node:50070/explorer.html#/apps/metron/enrichment/indexed > > >>>>>> > > >>>>>> Step 3 (optional) – Verify AWS Multi-Node Deploy with Ansible > > >>>>>> cd deployment/amazon-ec2 > > >>>>>> ansible-playbook -i ec2.py playbook.yml > > >>>>>> > > >>>>>> For a more complete set of instructions refer to: > > >>>>>> https://github.com/apache/incubator-metron/tree/master/deployment > > >>>>>> > > >>>>>> To verify the working build go through the same verifications as > in > > >>>>> Step2, > > >>>>>> but on AWS. Reference playbook.yml for location of the services. > > >>>>>> Ambari-master contains Ambari, web contains Kibana and sensors. > > >>>>>> > > >>>>>> Please vote +1 if you approve and –1 if you do not approve. Also, > > >>>> please > > >>>>>> indicate if your > > >>>>>> vote is binding > > >> > > >
