I was able to build in travis, with my branch, after changing the command:
The command "time mvn -q -T 2C -DskipTests install && time mvn -q -T
2C org.jacoco:jacoco-maven-plugin:prepare-agent
surefire:test@unit-tests && mvn -q
org.jacoco:jacoco-maven-plugin:prepare-agent
Github user james-sirota commented on the issue:
https://github.com/apache/incubator-metron/pull/556
Thanks for fixing the cumulative report. The histogram looks great +1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
Github user james-sirota commented on the issue:
https://github.com/apache/incubator-metron/pull/561
+ 1 looks great
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and
Hi Guys,
I would like to put this up for a vote. We would modify the bylaws with the
following:
Significant, pervasive features are often developed in a speculative branch of
the repository. The PMC may grant commit rights on the branch to its consistent
contributors, while the initiative is
Ambari has to manage the global configuration at least once or we cannot
deploy. IIRC, last time this came up, we decided to expose it via Ambari
but see if we could turn off the restart. I think we could expose it via an
action.
I'm pretty happy with any solution that takes that initial
I can test this on a cluster, but I need a couple of days. Centos7 is such
a mess I’m going to
switch my cluster back to 6.
On May 3, 2017 at 16:46:09, Matt Foley (mfo...@hortonworks.com) wrote:
Please see https://github.com/apache/incubator-metron/pull/564
If several of you could grab a
I’m going to do some more testing here and see, and stop spamming the list.
I have seen off of master work, and a build off of my travis branch fail
locally.
it could be that the problem is repo AND my branch
On May 3, 2017 at 16:28:35, Michael Miklavcic (michael.miklav...@gmail.com)
wrote:
Hi List,
I'm following this guide:
https://cwiki.apache.org/confluence/display/METRON/Metron+with+HDP+2.5+bare-metal+install
and Maven seems to fail after this:
"cd metron-deployment/packaging/docker/rpm-docker"
"mvn clean install -DskipTests -PHDP-2.5.0.0"
Removing intermediate container
That's great news! I was beginning to think we had a Maven bogeyman. I
wonder if Maven is swallowing an exception and wrapping it with something
that is user friendly. So, if the cached pom or jars are corrupted, it
might simply be reporting this as a "not found" problem. I guess that's
user
The Australia/Pacific version of Dataworks Summit is in Sydney this year,
September 20-21. This is a great place to talk about work you are doing
in Apache Metron or how you are using Metron. Information on submitting an
abstract is at
And… I Do have it locally
~/.m2 ottofowler% tree | grep jacoco
│ ├── jacoco
│ │ ├── jacoco-maven-plugin
│ │ │ ├── jacoco-maven-plugin-0.7.9.jar
│ │ │ ├── jacoco-maven-plugin-0.7.9.jar.sha1
│ │ │ ├── jacoco-maven-plugin-0.7.9.pom
│ │
I'm on 3.5 and not having issues with it.
On Wed, May 3, 2017 at 2:19 PM, Otto Fowler wrote:
> Did we change the requirements for pre-commit testing to run the command
> that way?
> I did a commit this morning with the old command.
>
>
> On May 3, 2017 at 14:04:32, Otto
Did we change the requirements for pre-commit testing to run the command
that way?
I did a commit this morning with the old command.
On May 3, 2017 at 14:04:32, Otto Fowler (ottobackwa...@gmail.com) wrote:
> git checkout -b whyyounowork apache/master
same issue locally
On May 3, 2017 at
One more thing - can you see if this exists in your local maven repo?
ls -lh $HOME/.m2/repository/org/jacoco/jacoco-maven-plugin/0.7.9/
<<<
total 136
-rw-r--r--+ 1 211B Mar 7 08:21 _remote.repositories
-rw-r--r--+ 1 46K Mar 7
I like your approach, Matt. +1 from me.
On Wed, May 3, 2017 at 1:32 PM, Matt Foley wrote:
> Thanks everyone for your input. After sleeping on it, and reviewing Jon’s
> and Nick’s input, here is my proposal:
>
> 1. Keep the parameter network.host as a synonym of
Thanks everyone for your input. After sleeping on it, and reviewing Jon’s and
Nick’s input, here is my proposal:
1. Keep the parameter network.host as a synonym of network.bind_host. This is
backward-compatible with our past usage, and completely predictable in terms of
results.
2. Add the
Note: Some input files additionally use unchecked or unsafe operations.
100 warnings
[ERROR] No plugin found for prefix 'org.jacoco' in the current project and
in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo]
available from the repositories [local
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/507
> can you elaborate on this fix/config a bit? I think we should definitely
add this detail to the doc. It looks like you've created a yaf user and prin
In the text that I
Does it run locally with:
mvn -q -T 2C -DskipTests install &&
mvn -q -T 2C org.jacoco:prepare-agent surefire:test@unit-tests && mvn -q
org.jacoco:prepare-agent surefire:test@integration-tests && mvn -q
org.jacoco:prepare-agent test --projects metron-interface/metron-config &&
Github user mmiklavc commented on the issue:
https://github.com/apache/incubator-metron/pull/507
@nickwallen can you elaborate on this fix/config a bit? I think we should
definitely add this detail to the doc. It looks like you've created a yaf user
and principal here. Any additional
No I cannot build locally with that command:
[ERROR] No plugin found for prefix 'jacoco' in the current project and in
the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available
from the repositories [local (/Users/ottofowler/.m2/repository), central (
I am going to be honest,
I don’t usually build locally with : mvn -q -T 2C -DskipTests install &&
mvn -q -T 2C jacoco:prepare-agent surefire:test@unit-tests && mvn -q
jacoco:prepare-agent surefire:test@integration-tests && mvn -q
jacoco:prepare-agent test --projects
GitHub user dlyle65535 opened a pull request:
https://github.com/apache/incubator-metron/pull/563
METRON-840: All "ambari_*" hosts need to have a /localrepo folder
## Contributor Comments
Fixes broken EC2 deployment. With the default config, each host running
needs a yum repo
I agree with Nick about the PR template insofar as we should keep it
simple. And for any checklist items, we should seek to automate as much as
possible. We've already made some strides with Justin Leet's changes to
include site-book building in the main build, for instance. I'd prefer to
add this
Also Otto, are you able to build locally with that branch and same merge
with master?
On Wed, May 3, 2017 at 9:51 AM, Justin Leet wrote:
> I'm also curious if it works if you change the two 'jacoco:prepare-agent'
> to 'org.jacoco:prepare-agent'. Master has built off of
I am not sure I know how to do that in Travis. I will look when I get back
On May 3, 2017 at 11:35:34, Ryan Merriman (merrim...@gmail.com) wrote:
> You might want to try clearing the mvn cache. I've had travis get into a
> bad state before because of corrupt maven artifacts.
>
> On Wed, May 3,
You might want to try clearing the mvn cache. I've had travis get into a
bad state before because of corrupt maven artifacts.
On Wed, May 3, 2017 at 10:26 AM, Otto Fowler
wrote:
> https://travis-ci.org/ottobackwards/incubator-metron/builds/228364894?utm_
>
Who has the credentials to be able to update the images on Atlas?
On Fri, Apr 21, 2017 at 11:02 AM, Casey Stella wrote:
> I'm betting we need to regenerate the quickdev image after all the mpack
> changes.
>
> On Fri, Apr 21, 2017 at 10:45 AM, Otto Fowler
I think it would be very valuable to split out publish_host and bind_host,
but I think it would make sense to do that work as part of a separate JIRA.
I would like to see us in a position to ship 0.4.0 as quickly as possible. Is
there a quick solution that reasonable balances security and
We are using a mvn plugin that automatically installs the correct version of
node and npm locally, at least for the management UI.
Are there other parts of the project that depend on these tools? Is it
desirable to include this even if they aren't a prerequisite for building? I
don't
It only worked "good enough" on Ansible because it was mainly used for
deploying to a controlled environment where we know the interface names;
aka Vagrant/Single Node.
It did not work well at all on environments other than Vagrant/Single
Node. The work that was done with Elasticsearch and
I think we should have documented in the template and guidelines something
to the extent ( appropriate for the document ) of :
“Metron provides a platform_info.sh script in metron-deployment/scripts
that outputs information that may be important to troubleshooting build and
deployment issues. It
Github user nickwallen commented on the issue:
https://github.com/apache/incubator-metron/pull/562
+1 Thanks, Otto! Tested on OSX and CentOS. Worked as expected.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
GitHub user ottobackwards opened a pull request:
https://github.com/apache/incubator-metron/pull/562
METRON-915 add node and npm to platform_info.sh
## Contributor Comments
Now that we depend on node and npm, put them into the platform_info.sh for
troubleshooting build
> Clearly, a generic parser would be useful for the community not a type of
parser that is highly customised for our noisy environment.
Increasing the number of generic parsers for the community is definitely a
good goal. I agree with you there.
Could we achieve the same goal by making our
How is the ambari service install configuration different from prior
configuration through ansible?
This used to work better right?
On May 3, 2017 at 07:06:52, zeo...@gmail.com (zeo...@gmail.com) wrote:
Thanks for the good write up Matt. Here are my thoughts:
D1: I don't see a way to have a
Github user gspeter commented on the issue:
https://github.com/apache/incubator-metron/pull/220
ok. thank you.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
Thanks for the good write up Matt. Here are my thoughts:
D1: I don't see a way to have a default that works in every scenario.
Documenting this and setting a sane default that works most of the time is
probably the best path forward.
D2: If we use _local_ and _site_, shouldn't it prioritize
Github user ottobackwards commented on the issue:
https://github.com/apache/incubator-metron/pull/220
please open the new jira and attach this log to that. As
@simonellistonball has requested, then mention me in the jira
---
If your project is set up for it, you can reply to this
Github user gspeter commented on the issue:
https://github.com/apache/incubator-metron/pull/220
Hi @ottobackwards
I run "mvn clean package -DskipTests | tee build.log". I send my log file.
Can you help me.
40 matches
Mail list logo