<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks David for the update. I tried rule version 1.3.1 on wildfly
by adding the configuration snippet to root pom.xml. After removing
~/.victims, and doing ./build.sh clean install, it took about 15
minutes 34 seconds to complete.<br>
<br>
The message "Checking for new vulnerabilities..." appeared 122
times. The first time it tries to initialize the victim database,
it took maybe 10-15 seconds, and the rest 121 times took 3-4 seconds
each. So roughly the time spent on checking for vulnerabilities
updates are about 5-6 minutes.<br>
<br>
Running build.sh clean installl a second time with the plugin took
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
9:52.217s.<br>
<br>
It would be nice if it only checks for vulnerabilities update once
per mvn run, or once during a certain time period (say 8 hours).<br>
<br>
Cheng<br>
<br>
<div class="moz-cite-prefix">On 6/12/13 9:24 PM, David Jorm wrote:<br>
</div>
<blockquote
cite="mid:1905904324.18677100.1371086676516.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">Hi All
Just following up on this. Has anyone had a chance to test a build of WildFly with enforce-victims-rule 1.3? From my perspective I think it should be ready to use.
Thanks
David
</pre>
<blockquote type="cite">
<pre wrap="">This bug is now fixed in enforce-victims-rule 1.3, which was released to
maven central today. This release also includes a range of performance
improvements, including caching, which significantly improves performance
after the first build of a given project. We have tested it with WildFly 8
on a system where build time without the plugin was 10 minutes. With the
plugin, the first build took 19 minutes, and all subsequent builds took 11
minutes.
Can you please rm -rf ~/.victims/ then update your POM to reference
enforce-victims-rule 1.3 and try again?
Thanks
David
</pre>
<blockquote type="cite">
<pre wrap="">Thanks for reporting this issue. We suspect it is actually a bug in the
victims library, as false negatives or artifacts that do not exist in the
DB
should simply pass inspection with no warning or failure. We've fixed the
suspected bug and we're currently working on an updated release, I will
respond to the list once that is complete so you can test.
Thanks
David
</pre>
<blockquote type="cite">
<pre wrap="">Yes, the build failed. This plugin can be configured to WARNING level
in the pom, but we then we won't catch the real problems. In the test
run, I just copied the pom snippet from
<a class="moz-txt-link-freetext" href="https://github.com/victims/victims-enforcer">https://github.com/victims/victims-enforcer</a>
In my case, the failed test project is
<a class="moz-txt-link-freetext" href="https://github.com/jberet/jsr352/blob/master/test-apps/postConstruct/pom.xml">https://github.com/jberet/jsr352/blob/master/test-apps/postConstruct/pom.xml</a>,
which has just 1 direct dependency: an internal peer sub-module, which I
guess is not known to the scanner database. Probably that's why it
failed? But other similarlly-structured sub-modules passed (e.g.,
<a class="moz-txt-link-freetext" href="https://github.com/jberet/jsr352/blob/master/test-apps/propertyInjection/pom.xml">https://github.com/jberet/jsr352/blob/master/test-apps/propertyInjection/pom.xml</a>)
Cheng
On 5/29/13 9:55 AM, Brian Stansberry wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 5/28/13 9:56 PM, Cheng Fang wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The possible false negatives (as David mentioned in his original
email)
can also complicate otherwise successful builds. The following error
message might have been caused by gaps in the database, though it's
not
clear which dependency it is complaining about.
[WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message:
Could not determine vulnerabilities for hash:
8edd1a0bf70467791ec883b7452c21333e829ab714c83090f8328d8205f159f2669772dd66db01af60debd40402e994be7b08527e8f90211425567b52e6b9472
</pre>
</blockquote>
<pre wrap="">Does that fail the build, or is the problem limited to noise in the
build log?
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
wildfly-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>