The PR only adds the victims plugin to the victims-scan profile. It will
have no impact on builds that are not explicitly using this profile. The
idea is to create a jenkins job which performs builds with this profile
to check for known vulnerable dependencies, while having no impact on
other builds. I am happy to write this up in an article if you still
think it is necessary, Darran.
On 08/19/2013 08:54 PM, Darran Lofthouse wrote:
Personally I think even before that an article / document should be
produced describing EXACTLY how it will impact the build.
The last time we had substantial build changes was around the testsuite,
nothing was necessarily wrong with the changes made but it had a big
impact on how developers actually used the build day to day.
On 19/08/13 07:13, Jaikiran Pai wrote:
> I think as a first step, someone familiar with this plugin should raise
> a PR against WildFly upstream with the suggested approach of using a
> Maven profile to trigger it. Depending on what the PR looks like, it
> might need further changes or might be reviewed and merged.
> On Monday 19 August 2013 11:27 AM, David Jorm wrote:
>>>> With this setting in place, do you think we're in a position to try
>>>> committing the plugin configuration to a dedicated maven profile in the
>>>> root pom.xml, and setting up a jenkins job to run builds using that
>>> That would make sense, as running this as part of every build would be too
>>> time consuming for most developers.
>> Sorry to be a broken record, but would it be possible to implement this?
We're starting to get contributions to the victims database from other parties, so
there is increasing value to its usage in wildfly.
>> wildfly-dev mailing list
> wildfly-dev mailing list
wildfly-dev mailing list