I'm on 1.6.2. Can you confirm you added the plugin to
~/.sbt/1.0/plugins/plugins.sbt
That error sounds like something you'd get if the plugin wasn't enabled.
On 3/24/22 12:28 PM, Mike Beckerle wrote:
So I backed out the version of plugin to 3.3.0.
I still get
$ sbt
[info] welcome to sbt 1.6.2 (Oracle Corporation Java 17)
/home/mbeckerle/.sbt/1.0/plugins/build.sbt:1: error: not found: value
dependencyCheckAssemblyAnalyzerEnabled
dependencyCheckAssemblyAnalyzerEnabled := Some(false)
^
[error] Type error in expression
[warn] Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore?
(default: r)
What version of sbt are you using? I am on 1.6.2 as you see.
On Thu, Mar 24, 2022 at 11:03 AM Steve Lawrence <slawre...@apache.org>
wrote:
Looks like the plugin version I'm using is 3.3.0, I'd guess they changed
something about this option in the newer 4.0.0 version?
On 3/24/22 11:00 AM, Mike Beckerle wrote:
Either way build.sbt or other, I just get
dependencyCheckAssemblyAnalyzerEnabled := Some(false)
^
[error] Type error in expression
On Thu, Mar 24, 2022 at 10:58 AM Mike Beckerle <mbecke...@apache.org>
wrote:
is "Somez" a typo?
Does it matter that this is in build.sbt vs. global.sbt or any other of
the .sbt files under plugins?
On Thu, Mar 24, 2022 at 10:52 AM Steve Lawrence <slawre...@apache.org>
wrote:
Agreed, this is part of my check list, but it would be good to document
it somewhere to ensure it always gets done.
As to the error, I don't remember doing this, but also added this to
~/.sbt/1.0/build.sbt to disable the .NET analyzer:
dependencyCheckAssemblyAnalyzerEnabled := Somez(false)
On 3/24/22 10:45 AM, Mike Beckerle wrote:
We should add this sbt dependency check instruction to the release
workflow
- which actually needs a section with a checklist of things to
check/verify
like this. Or maybe it's a separate page,
release-testing/verification.
However, I tried it (using version 4.0.0 of the plugin) on daffodil
and
it
failed per below. Do you have a configuration or environment settings
you
use with this plugin? It has many many options, and presumably one of
them
will turn off this problem.
sbt:daffodil> dependencyCheckAggregate
... list of zillion jars here ....
10:37:55.213 [pool-263-thread-8] ERROR
org.owasp.dependencycheck.analyzer.AssemblyAnalyzer -
----------------------------------------------------
10:37:55.213 [pool-263-thread-8] ERROR
org.owasp.dependencycheck.analyzer.AssemblyAnalyzer - .NET Assembly
Analyzer could not be initialized and at least one 'exe' or 'dll' was
scanned. The 'dotnet' executable could not be found on the path;
either
disable the Assembly Analyzer or add the path to dotnet core in the
configuration.
10:37:55.213 [pool-263-thread-8] ERROR
org.owasp.dependencycheck.analyzer.AssemblyAnalyzer -
----------------------------------------------------
[success] Total time: 2 s, completed Mar 24, 2022, 10:37:56 AM
sbt:daffodil>
CVE checking can perhaps be avoided via dependabot, but I like the
notion
that a join between our dependencies and the CVE database gets done
somehow, and sbt-dependency-check seems to do this.
On Thu, Mar 24, 2022 at 10:02 AM Steve Lawrence <slawre...@apache.org
wrote:
I just used this for the dependency check, that has all the
instructions
that are needed:
https://github.com/albuch/sbt-dependency-check
They say to put that in project/plugins.sbt, but I recommend putting
it
in ~/.sbt/1.0/plugins/plugins.sbt, then it's available for any
project
you might use (e.g. both daffodil and vscode).
Then just run "sbt dependencyCheckAggregate", and the resulting
report
is put in target/scala-2.12/dependency-check-report.html.
I'm not sure I would recommend adding CVE checking to CI because
downloading the CVE database takes a long time, especially the first
time. I might recommend instead just enabling dependabot, that's been
good about keeping Daffodil dependencies up to date.
