Hello all,
I am cancelling the rc2 vote as there were some needed changes for the
release candidate. Keep an eye out for rc3 release.
Thank you,
Shane Dell
In sbt you can run `show evicted` to print the dependencies and what has
been overridden, although usually the highest version is chosen by default,
so it is a bit confusing that a earlier version was chosen.
Then something like
https://stackoverflow.com/questions/63272822/can-sbt-override-a-trans
Seems reasonable to me. Note that with all the updates, it's important
to double check that non of the licenses or notice information changes
for any of the dependency (either direct or transitive). Note that I
know changes were made to the bin.NOTICE and bin.LICENSE files for
Daffodil from 3.2
I'm looking forward to RC3.
On Fri, Mar 25, 2022 at 11:06 AM Shane Dell wrote:
> Okay so here is what I was able to find last night:
>
> - Adding the dependencyOverrides for commons-lang fixes the CVE issue and
> causes no issue
> to build
> - Updating "logback-classic" from 1.2.3 to 1.2.11 fixe
Okay so here is what I was able to find last night:
- Adding the dependencyOverrides for commons-lang fixes the CVE issue and
causes no issue
to build
- Updating "logback-classic" from 1.2.3 to 1.2.11 fixes the CVE issues and
causes no issue to
build
- Updating to daffodil 3.3.0 causes no issue
I think the log4cats findings are false positives. The links that
dependencyCheck provides for the log4cats findings are here:
https://ossindex.sonatype.org/component/pkg:maven/org.typelevel/log4cats-core_2.12@2.1.0
https://ossindex.sonatype.org/component/pkg:maven/org.typelevel/log4cats-slf4
Ah okay that makes we will still want dependabot for the node/typescript
extension side. But
what do you think is best for log4cats stuff since the latest version still has
CVEs? The
overriding fixed the commons-lang3 issue. But the log4cats-slf4j is a direct
dependency that
adds log4cats-core a
I'd probably update deps first so we don't get a flood of new dependency
PRs to approve.
Also, now that I think about it, dependabot doesn't do sbt dependencies.
We need scala-steward for that. Daffodil uses enables dependabot for
github-actions and container updates, and scala steward for sbt
So with the PR I will need to make to get this fixes going, would you want me
to just add dependabot? I believe that is an issue but can't remember for sure
but I can get it hooked up for both scala/sbt and for node/ts/extension.
On 2022/03/25 01:13:07 Steve Lawrence wrote:
> I believe the sbt w
I believe the sbt way to override transitive dependencies is with the
dependencyOverrides setting:
https://www.scala-sbt.org/1.x/docs/Library-Management.html#Overriding+a+version
While we're at it, we may want to also update all dependencies so
everything is at the latest. Eventually we'll wan
So its an issue com.microsoft.java:com.microsoft.java.debug.core:0.31.1 but
updating to com.microsoft.java:com.microsoft.java.debug.core:0.35.0, which is
the latest, it still uses a commons-lang3:3.6. So what do I do for these items
since updating to the latest version don't fix them?
On 2022/
The sbt dependency graph plugin might help to show where transitive
dependencies are coming from:
https://github.com/sbt/sbt-dependency-graph
On 3/24/22 8:34 PM, Shane Dell wrote:
I would say it is correct as in the list of jars for log4j-api I am seeing
2.17.2 which is the version that fixe
I would say it is correct as in the list of jars for log4j-api I am seeing
2.17.2 which is the version that fixed that CVE issue right? If so we are good
on that from. I was able to fix the logback errors by updating logback-classic
from 1.2.3 to 1.2.11. Still trying to figure out log4cat-slf4j
I even added this plugin first, in case there was some interaction/failure
My plugins.sbt:
addSbtPlugin("net.vonbuchholtz" % "sbt-dependency-check" % "3.3.0")
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "5.2.4")
addSbtPlugin("com.timushev.sbt" % "sbt-updates" % "0.3.4")
addS
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.
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] T
Interesting. This might be a difference between 3.3.0 and 4.0.0 of the
plugin? I get your list with 4.0.0, and a different list with 3.3.0.
Note that vscode does include log4j-api-2.17.0.jar. The log4j CVE's were
fixed in 2.17.2, so it's a bit concerning that this is only 2.17.0. But
maybe the
I get the vulnerabilities for:
- commons-lang3-3.6.jar
- log4cats-core_2.12-2.2.0.jar
- log4cats-slf4j_2.12-2.2.0.jar
- logback-classic-1.2.3.jar
- logback-core-1.2.3.jar
I don't get anything about log4j-api. And the only onces with a HIGH Severity
value are the two log4cats items. So is yours p
So I think the log4j errors you are seeing are coming from a library dependency
the Scala debugger user, this being `log4cats-slf4j` which only goes to 2.2.0
put still has two high CVE's, Adam maybe you know if we can switch this
something else to avoid the vulnerabilities?
On 2022/03/24 14:02:
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 exp
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 wrote:
> is "Somez" a typo?
>
> Does it matter that this is in build.sbt vs. global.sbt or any other of
> the .sbt fi
Yeah, that's a typo. I think it can go in any .sbt file in ~/.sbt/1.0/
On 3/24/22 10:58 AM, Mike Beckerle 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
wrote:
Ag
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
wrote:
> Agreed, this is part of my check list, but it would be good to document
> it somewhere to ensure it always gets done.
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)
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
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 u
Fixing the CVEs and bumping up to Daffodil 3.3.0 make sense to me. Steve how
would I setup the dependency check you are doing so I make sure I use versions
that fix it? Figure it would be good to add that into build.sbt/source so it
can be ran in CI at some stage as well.
On 2022/03/24 13:42:36
Since we have to fix the CVE issues, we should also update to Daffodil 3.3.0
On Thu, Mar 24, 2022 at 9:04 AM Steve Lawrence wrote:
> I think I've sort of found the issue with the different .class files. If
> I disassemble the class files that don't match, they all have diffs that
> look like th
I think I've sort of found the issue with the different .class files. If
I disassemble the class files that don't match, they all have diffs that
look like this:
- 21: ldc #155// String Uninitialized
field: /home/user/daffodil-vscode/path/to/file.scala: 394
+
-1 (binding)
Main issues is inclusion of packages with open CVE's, I think that
should be fixed for this release.
I'm also concerned about differences I found between the released
daffodil-debugger jar and the same jar I built from source. Class
files inside that jar differ, and it's not clear w
Yes, we should probably keep things separate. I described an approach
here, which I think is probably the simplest way to add what ASF requires:
https://lists.apache.org/thread/z51r3jdtr6djvoyfr71dml4otw7cophw
With that, there would just be a single vscode.md file at this URL:
https://daff
Steve, in regard to updating daffodil site should I create a separate folder
under site like `_releases_vscode` so that we can keep the releases READMEs for
daffodil and daffodil-vscode separated to keep it more organized? Or how do you
think would be best to separate those from each other?
On
I am changing my vote to +1. It now seems to be working as designed, and
looks useful. Yay.
My challenges here have been related to installation, reinstallation, etc.
Clearing out the RC1 to get the RC2 to work was non-trivial, but can be
easily addressed in doc short term.
However, while I am in
I don't think we need an rc3 if this is just a matter of cruft lying
around that needs to be cleaned up. If it fixes things for Mike he can
always change his vote to a +1. I woudl also like to look closer at the
release if cruft was just the issue.
We might want to add some documentation somew
Oh yeah makes sense, I just wanted to make sure to note some additional steps
that will be needed when testing the VS Code extension. I sent Mike an email
about this but haven't heard anything. However, if it does fix his issue since
I technically ended this vote on Sunday, should I make an rc3
rcX suffixes are intentionally left out of build artifacts. This way
once a rc passes a vote the release process is just a rename of the
build artifact to remove the -rcX from the filename. If -rcX was
actually inside a build artifact then it requires a source change and a
rebuild to remove it,
I believe a lot of the issue that Mike has been having is because of the
artifacts both using 1.0.0 without the rc. Since Mike installed the rc1
extension which created a folder called something like
"daffodil-dap/daffodil-debugger-${DAFFODIL_VERSION}-${DAFFODIL_VSCODE_VERSION"
in this instance
If the version number is the identifier that summarizes the build artifact
then the reported version above would be inaccurate as the actual version
was 1.0.0-rc2. Probably an oversight on the Scala-side of the build of the
extension.
I would argue, however, that the commit hash is useful optional
The commit hash is intentional. The issue with including a githash is
you get a different build when building outside of git. For
reproducibility, we want to be able to have the exact same builds
regardless of git vs no git.
On 3/22/22 12:16 PM, Adam Rosien wrote:
I have successfully hit a br
I have successfully hit a breakpoint on an included file using the
1.0.0-rc2 candidate extension:
- Breakpoint at EDIFACT-SupplyChain-Segments-D.03B.xsd (a schema file
included from the -Messages file), line 380
- Data file INVOIC_D.03B_Interchange_with_UNA.txt
FYI the backend doesn't appear to l
Ah a necessary
> "daffodilDebugClasspath": ""
was missing from my launch config. Confirmed backend launches... debugging
continues
On Tue, Mar 22, 2022 at 8:58 AM Adam Rosien wrote:
> I installed the vsix file from
> https://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/1.0.0-rc2
I installed the vsix file from
https://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/1.0.0-rc2/bin/
and set up a launch configuration (included below) based on the EDIFACT
schema at https://github.com/DFDLSchemas/EDIFACT. When running the session
I get a popup with the following error, wh
Since this vote closes sunday, and I won't have further test time before
then, I have to vote now.
Voting -1
I couldn't get the convenience binary .vsix file to work to debug EDIFACT
with a breakpoint in the 2nd file of the schema.
I went so far as to uninstall the older extension, shut down vsco
There isn't a lot of documentation specific to the Daffodil website. But
it is built using Jekyll, which has decent documentation:
https://jekyllrb.com/docs/
Specifically for Daffodil releases, the releases.md file defines the
main page (https://daffodil.apache.org/releases/) which lists all
Is there somewhere that has documentation on how to do?
On 2022/03/18 12:06:16 Steve Lawrence wrote:
> I haven't reviewed the release yet, but ASF requires a page on
> daffodil.apache.org that has links to downloads/hashes/keys/etc. It
> doesn't have to be done the same way we do Daffodil releas
I haven't reviewed the release yet, but ASF requires a page on
daffodil.apache.org that has links to downloads/hashes/keys/etc. It
doesn't have to be done the same way we do Daffodil releases pages, but
that's mostly just a template with a .md page for each release so
copying that and making ad
Hello all,
Ignore the last vote as I did not change my email to the proper one
registered for apache.
I'd like to call a vote to release Apache Daffodil VS Code 1.0.0-rc2.
All distribution packages, including signatures, digests, etc. can be
found at:
https://dist.apache.org/repos/dist/dev/daffod
Hello all,
I'd like to call a vote to release Apache Daffodil VS Code 1.0.0-rc2.
All distribution packages, including signatures, digests, etc. can be
found at:
https://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/1.0.0-rc2/
This release has been signed with PGP key
86DDE7B41291E38023
48 matches
Mail list logo
