Yep, that should be all that's needed.
I believe IntelliJ just uses the sbt server under the hood, so things
should "just work". We won't know for sure until we test it, but we use
plugins for other things (e.g. sbt-cc, native-packager) that I assume
work find with IntelliJ.
On 11/30/22 5:0
I recommend RC3. But I really didn't check anything else after getting
blocked on this one. So I can't say whether there are other issues yet.
On Wed, Nov 30, 2022 at 1:47 PM Shane Dell wrote:
> Mike, did you notice any other issues that should be fixed or was this the
> main one? As for t
If we make this an sbt plugin, then one would add a daffodil plugin to a
plugins.sbt in the project directory yes?
Along the lines of adding this line to each schema projects'
project/plugins.sbt
addSbtPlugin("org.apache.daffodil" % "daffodil-sbt-plugin" % "3.5.0")
This would need to be updat
+1, agreed this sounds better
On 11/30/22 12:19 PM, Christofer Dutz wrote:
+1 because I keep on reading it as competition … “Apache Daffodil versus Code
Extension” ;-)
Chris
From: Davin Shearer
Date: Wednesday, 30. November 2022 at 17:37
To: dev@daffodil.apache.org
Subject: Propose name cha
Mike, did you notice any other issues that should be fixed or was this the main
one? As for the Vote should it be left open or should I close it and do an rc3
since this bug you found is a pretty important item that should be working when
debugging?
On 2022/11/29 22:51:20 Mike Beckerle wrote:
>
Mike,
Good fine this was actually an issue in a file using the wrong variable name.
It was checking config.daffodilDebugClassPath instead of
config.daffodilDebugClasspath causing the classpath not to set. I will make an
issue for this on GitHub.
On 2022/11/29 22:51:20 Mike Beckerle wrote:
> V
+1 because I keep on reading it as competition … “Apache Daffodil versus Code
Extension” ;-)
Chris
From: Davin Shearer
Date: Wednesday, 30. November 2022 at 17:37
To: dev@daffodil.apache.org
Subject: Propose name change from "Apache Daffodil VS Code Extension" to
"Apache Daffodil™ Extension f
I'm working through getting our wiki documentation (
https://github.com/apache/daffodil-vscode/wiki) refreshed to coincide with
our upcoming 1.2.0 release of the extension, and in the course of updating
the material, I came across this guide (https://code.visualstudio.com/brand)
on proper ways to n
I really like this idea of centralizing a test framework for DFDL schemas
for all the reasons you mentioned. It would also serve to help structure
DFDL repositories, reduce burden on schema authors, and institute best
practices.
On Wed, Nov 30, 2022 at 9:48 AM Mike Beckerle wrote:
> I never got
> We might need to use a SBT plugin rather than a SBT module to achieve
such an effect.
I was thinking this exact thing. A "DFDL Schema" sbt plugin is probably
the best way to remove alot of this dependency duplication. Plugin
settings could also be used to enable/disable things like the flat
I believe both Maven and SBT handle transitive dependencies similarly? My own
build.sbt for schema projects has 4 dependencies, all of which are test-only
dependencies:
scalaVersion := "2.12.17"
libraryDependencies ++= Seq(
"com.github.sbt" % "junit-interface" % "0.13.3" % "test",
"junit"
I never got any feedback on this idea. Thoughts? Observations?
On Tue, Nov 1, 2022 at 11:17 AM Mike Beckerle wrote:
> I am having trouble regression testing schemas in bulk against the
> 3.4.0-RC1.
>
> The challenge is that there are 70+ such schemas. All of them have
> build.sbt which require u
12 matches
Mail list logo
