stevedlawrence commented on code in PR #1452:
URL: https://github.com/apache/daffodil-vscode/pull/1452#discussion_r2419432058
##########
package.json:
##########
@@ -3,7 +3,11 @@
"displayName": "Apache Daffodil™ Extension for Visual Studio Code",
"description": "Apache Daffodil™ Extension for Visual Studio Code providing
DFDL syntax highlighting, DFDL code completion, DFDL schema debugging, and data
editor",
"version": "1.4.2-SNAPSHOT",
- "daffodilVersion": "3.11.0",
+ "daffodilScalaVersions": {
+ "<=3.10.0": "2.12",
+ "=3.11.0": "2.13",
+ ">=4.0.0": "3"
+ },
Review Comment:
I'm wondering if this really provides much value? Having daffodilVersion in
the package.json made sense previously when there was a specific version that
the debugger supports and it wanted to be easy to update, but now this
extension isn't really specific to one daffodil version. Figuring out the scala
version based on the daffodil version is unlikely to change, so almost feels
like it would be cleaner to just hard code it itno the extension logic instead
of this semver key/values. For example, getScalaVersion just becomes:
```ts
export async function getScalaVersion(daffodilVersion: string):
Promise<string> {
if (semver.satisfies(daffodilVersion, ">=4.0.0") "3"
else if (semver.satisfies(daffodilVersion, ">=3.11.0") "2.13"
else "2.12"
}
```
This feels cleaner than having to parse something form a json file, iterate
over keys, etc. And this logic is unlikely to ever need to be updated. It also
support patch releases if we ever do patch releases (though I don't think we'll
ever do that so isn't really worth consideration. Should we just remove
daffodilScalaVersions?
##########
debugger/src/main/scala-2/org.apache.daffodil.debugger.dap/Support.scala:
##########
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/** This file contains support code for making a majority of Scala shareable
between different versions of Scala and
+ * Daffodil. The main difference comes in package names, converting certain
variables, etc. This file has all the
+ * helper code for that for Scala 2.13.
+ */
+
+package org.apache.daffodil.debugger.dap
+
+import java.io._
+import java.nio.file.Path
+import org.apache.daffodil.sapi._
+import org.apache.daffodil.sapi.io.InputSourceDataInputStream
+import org.apache.daffodil.sapi.infoset.{JsonInfosetOutputter,
XMLTextInfosetOutputter}
+
+object Support {
+ /* Daffodil DataProcessor wrapper methods */
+ def dataProcessorWithDebugger(
+ p: DataProcessor,
+ debugger: org.apache.daffodil.runtime1.debugger.Debugger,
+ variables: Map[String, String]
+ ): DataProcessor =
+ p.withDebugger(debugger)
+ .withDebugging(true)
+ .withExternalVariables(variables)
+ .withValidationMode(ValidationMode.Limited)
+
+ /* Daffodil infoset wrapper methods */
+ def getInfosetInputter(data: InputStream): InputSourceDataInputStream = new
InputSourceDataInputStream(data)
Review Comment:
This should be called `getInputSourceDataInputStream`. An "InfosetInputter"
is actually something different used for unparsing.
##########
src/daffodilDebugger/daffodilJars.ts:
##########
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+import * as path from 'path'
+import * as fs from 'fs'
+import * as vscode from 'vscode'
+import { outputChannel } from '../adapter/activateDaffodilDebug'
+import { downloadAndExtract } from '../utils'
+
+/**
+ * The daffodil debugger doesn't bundle any of daffodil jars because we want
to support
+ * many versions of daffodil and do not want to bundle them all. The CLI zip
is an official
+ * daffodil release that contains all the daffodil jars (and their transitive
dependencies)
+ * that the debugger needs for a particular Daffodil version. The debugger
doesn't need all
+ * the jars that it bundles (e.g. daffodil-cli.jar) but those will just be
ignored.
+ */
+export async function checkIfDaffodilJarsNeeded(
+ daffodilVersion: string
+): Promise<string> {
+ const context = (await vscode.commands.executeCommand(
+ 'getContext'
+ )) as vscode.ExtensionContext
+
+ /**
+ * Global storage paths:
+ * Mac: /Users/<username>/Library/Application
Support/Code/User/globalStorage/asf.apache-daffodil-vscode
+ * Windows: %APPDATA%\Code\User\globalStorage\asf.apache-daffodil-vscode
+ * Linux:
/home/<username>/.config/Code/User/globalStorage/asf.apache-daffodil-vscode
+ */
+
+ const destFolder = path.join(
+ context.globalStorageUri.fsPath,
+ '.cache',
+ 'daffodil-debugger'
Review Comment:
Should we remove the .cache directory from this path? The entire global
storage directory is already kindof a cache, so seems like it's redundant.
Also, it feels like "daffodil-debugger" wants to be something like
"daffodil-versions" or just "daffodil" something. I think of the
"daffodil-debugger" as something that is related to daffodil but is a distinct
thing. This directory won't contain anything about the vs code debugger, it
just contains "core" daffodil.
##########
vite/package.vite.config.mjs:
##########
@@ -43,35 +43,46 @@ const packageData = jsoncParse(
fs.readFileSync(path.resolve('package.json'), 'utf8')
)
const pkg_version = packageData['version']
-const daffodilVersion = packageData['daffodilVersion']
-const serverPackage = `daffodil-debugger-${daffodilVersion}-${pkg_version}`
-const zipFilePath = path.resolve(
- `debugger/target/universal/${serverPackage}.zip`
-)
+const daffodilScalaVersions = packageData['daffodilScalaVersions']
function unzipAfterBuild() {
return {
name: 'unzip-server-package',
apply: 'build',
async closeBundle() {
- const serverPackageFolder = path.join(
- path.resolve('dist/package'),
- serverPackage
+ Object.entries(daffodilScalaVersions).forEach(
+ async ([_, scalaVersion]) => {
+ const serverPackage =
`daffodil-debugger-${scalaVersion}-${pkg_version}`
Review Comment:
One last thought, related to packaging things: do we want to download the
daffodil CLI for the default version (e.g. 3.11.0) and include that zip in the
vsix bundle? And then have a little bit of logic that extracts that zip to to
global storage if the version is used?
My thinking is many DFDL schema developers might be on air-gapped systems
where the download capability won't work. It might be helpful to bundle one
version of Daffodil so at least the default version works. And if they user is
air-gapped any other versions will just fail to download.
Doesn't have to be done as part of this PR, could be a future addition.
##########
src/launchWizard/script.js:
##########
@@ -72,6 +72,12 @@ function getConfigValues() {
)
const dataEditorLogFile = document.getElementById('dataEditorLogFile').value
const dataEditorLogLevel =
document.getElementById('dataEditorLogLevel').value
+ const dfdlDaffodilVersion = document.getElementById(
+ 'dfdlDaffodilVersion'
Review Comment:
Thinking about developers, what's the right way to test a locally built
version of Daffodil that hasn't been released? For example, what if I wanted to
build and test the extension with 4.1.0-SNAPSHOT?
I think what I would have to do is create the Daffodil CLI (e.g. sbt
daffodil-cli/stage), copy the result to the correct directory in the vs code
global storage, and then create a launch config that sets `dfdlDaffodilVersion`
to "4.1.0-SNAPSHOT"?
Or could I manually run the daffodil-debugger bash script, setting
`--daffodilPath` to the CLI files I built, and then will the extension then be
able to find the running DAPodil instance?
It might be worth documenting this in a developer section somewhere on how
to do this. Especially since as part of the a daffodil vote we might want to
verify that the existing existing works with new versions of daffodil.
##########
package.json:
##########
@@ -926,8 +944,10 @@
},
"dfdlDebugger": {
"type": "object",
- "description": "Configuration for debugger. Settings are logging
(level and file)",
+ "description": "Configuration for debugger. Settings are are
daffodilVersion, timeout and logging (level and file)",
Review Comment:
Remove double "are"
##########
vite/dev.vite.config.mjs:
##########
@@ -43,35 +43,46 @@ const packageData = jsoncParse(
fs.readFileSync(path.resolve('package.json'), 'utf8')
)
const pkg_version = packageData['version']
-const daffodilVersion = packageData['daffodilVersion']
-const serverPackage = `daffodil-debugger-${daffodilVersion}-${pkg_version}`
-const zipFilePath = path.resolve(
- `debugger/target/universal/${serverPackage}.zip`
-)
+const daffodilScalaVersions = packageData['daffodilScalaVersions']
function unzipAfterBuild() {
return {
name: 'unzip-server-package',
apply: 'build',
async closeBundle() {
- const serverPackageFolder = path.join(
- path.resolve('dist/package'),
- serverPackage
- )
+ Object.entries(daffodilScalaVersions).forEach(
+ async ([_, scalaVersion]) => {
+ const serverPackage =
`daffodil-debugger-${scalaVersion}-${pkg_version}`
+ const jvmFolderName = `jvm-${scalaVersion}`
+ const zipFilePath = path.resolve(
+ `debugger/target/${jvmFolderName}/universal/${serverPackage}.zip`
+ )
+
+ const serverPackageFolder = path.join(
+ path.resolve('dist/package'),
+ serverPackage
+ )
- // remove debugger package folder if exists
- if (fs.existsSync(serverPackageFolder)) {
- fs.rmSync(serverPackageFolder, { recursive: true, force: true })
- }
-
- await new Promise((resolve, reject) => {
- const stream = fs
- .createReadStream(zipFilePath)
- // @ts-ignore types for unzip-stream
- .pipe(unzip.Extract({ path: '.' }))
- stream.on('close', () => resolve())
- stream.on('error', (err) => reject(err))
- })
+ // remove debugger package folder if exists
+ if (fs.existsSync(serverPackageFolder)) {
+ fs.rmSync(serverPackageFolder, { recursive: true, force: true })
+ }
+
+ // if the debugger package doesn't exist continue
+ if (!fs.existsSync(zipFilePath)) {
+ return
+ }
+
+ await new Promise((resolve, reject) => {
Review Comment:
I'm not sure where this is happening, but I noticed after running "yarn
package" there three `daffodil-debugger-<scalaVersion>-1.4.2-SNAPSHOT`
directories in the root of the repo. The directory contains a the lib/ and bin/
directories, so it seems it's related to pacakging the native-pacakger zips
into the vsix. I'm not sure exactly where that's happening, but we should fix
that.
##########
src/tests/suite/daffodil.test.ts:
##########
@@ -166,72 +175,76 @@ suite('Daffodfil', () => {
})
})
- suite('getDaffodilVersion', () => {
- test('getDaffodilVersion returns same version as file', () => {
- var daffodilVersion = daffodil.getDaffodilVersion(packageFile)
- assert.strictEqual(daffodilVersion, '0.0.0')
- })
- })
-
- suite('non-debug specific commands', () => {
- const nonDebugSpecificCmds = [
- 'extension.dfdl-debug.debugEditorContents',
- 'extension.dfdl-debug.runEditorContents',
- 'extension.dfdl-debug.debugLastEditorContents',
- 'extension.dfdl-debug.executeTDML',
- ]
-
- // This breaks when the omega-edit tests run for some reason
- // test('Available by default', () => {
- // nonDebugSpecificCmds.forEach(async (cmd) => {
- // assert.strictEqual(
- // (await vscode.commands.getCommands()).includes(cmd),
- // true
- // )
- // })
- // })
-
- test('Not available when inDebugMode', () => {
- vscode.commands.executeCommand('setContext', 'inDebugMode', true)
-
- nonDebugSpecificCmds.forEach(async (cmd) => {
- assert.strictEqual(
- (await vscode.commands.getCommands()).includes(cmd),
- false
- )
- })
+ suite('daffodilScalaVersions', () => {
+ test('daffodilScalaVersions returns the same versions as file', () => {
+ var daffodilScalaVersions =
daffodil.getDaffodilScalaVersions(packageFile)
+ assert.strictEqual(daffodilScalaVersions['<=3.10.0,<3.11.0'], '2.12')
+ assert.strictEqual(daffodilScalaVersions['>=3.11.0,<4.0.0'], '2.13')
+ assert.strictEqual(daffodilScalaVersions['>=4.0.0'], '3')
})
})
- suite('debug specific commands', () => {
- const debugSpecificCmds = [
- 'extension.dfdl-debug.toggleFormatting',
- 'infoset.display',
- 'infoset.diff',
- 'infoset.save',
- ]
-
- test('Not available by default', () => {
- debugSpecificCmds.forEach(async (cmd) => {
- assert.strictEqual(
- (await vscode.commands.getCommands()).includes(cmd),
- false
- )
- })
- })
-
- // This breaks when the omega-edit tests run for some reason
- // test('Available when inDebugMode', () => {
- // vscode.commands.executeCommand('setContext', 'inDebugMode', true)
-
- // debugSpecificCmds.forEach(async (cmd) => {
- // assert.strictEqual(
- // (await vscode.commands.getCommands()).includes(cmd),
- // true
- // )
- // })
- // })
- })
+ // This breaks when the omega-edit tests run for some reason
+ // suite('non-debug specific commands', () => {
+ // const nonDebugSpecificCmds = [
+ // 'extension.dfdl-debug.debugEditorContents',
+ // 'extension.dfdl-debug.runEditorContents',
+ // 'extension.dfdl-debug.debugLastEditorContents',
+ // 'extension.dfdl-debug.executeTDML',
+ // ]
+
+ // test('Available by default', () => {
+ // nonDebugSpecificCmds.forEach(async (cmd) => {
+ // assert.strictEqual(
+ // (await vscode.commands.getCommands()).includes(cmd),
+ // true
+ // )
+ // })
+ // })
+
+ // test('Not available when inDebugMode', () => {
+ // vscode.commands.executeCommand('setContext', 'inDebugMode', true)
+
+ // nonDebugSpecificCmds.forEach(async (cmd) => {
+ // assert.strictEqual(
+ // (await vscode.commands.getCommands()).includes(cmd),
+ // false
+ // )
+ // })
+ // })
+ // })
+
+ // This breaks when the omega-edit tests run for some reason
+ // suite('debug specific commands', () => {
+ // const debugSpecificCmds = [
+ // 'extension.dfdl-debug.toggleFormatting',
+ // 'infoset.display',
+ // 'infoset.diff',
+ // 'infoset.save',
+ // ]
+
+ // // This breaks when the omega-edit tests run for some reason
+ // test('Not available by default', () => {
+ // debugSpecificCmds.forEach(async (cmd) => {
+ // assert.strictEqual(
+ // (await vscode.commands.getCommands()).includes(cmd),
+ // false
+ // )
+ // })
+ // })
+
+ // // This breaks when the omega-edit tests run for some reason
+ // test('Available when inDebugMode', () => {
+ // vscode.commands.executeCommand('setContext', 'inDebugMode', true)
+
+ // debugSpecificCmds.forEach(async (cmd) => {
+ // assert.strictEqual(
+ // (await vscode.commands.getCommands()).includes(cmd),
+ // true
+ // )
+ // })
+ // })
+ // })
Review Comment:
I'm not sure I understand. Was this an existing issue that you've just fixed
as part of this PR? Or did this PR change something?
##########
package.json:
##########
@@ -926,8 +944,10 @@
},
"dfdlDebugger": {
"type": "object",
- "description": "Configuration for debugger. Settings are logging
(level and file)",
+ "description": "Configuration for debugger. Settings are are
daffodilVersion, timeout and logging (level and file)",
"default": {
+ "daffodilVersion": "3.11.0",
+ "timeout": "10s",
"logging": {
"level": "INFO",
"file": "${workspaceFolder}/daffodil-debugger.log"
Review Comment:
I tried to test PR in its current state. I created a lunch.json and added
`"daffodilVersion": "4.0.0",` to the `dfdlConfig` section. I tried to run and
got this error:
> Cannot read properties of undefined (reading 'endsWith')
I'm not sure if there's a way to show stack trace where this is error is
happening.
##########
build.sbt:
##########
@@ -27,33 +27,30 @@ import javax.xml.transform.stream.StreamSource
//Fixes build issues on java11+
run / fork := true
Global / lintUnusedKeysOnLoad := false
+
val packageJsonStr = scala.io.Source.fromFile("package.json").mkString
-val daffodilVer = {
- val daffodilVerRegex = raw""""daffodilVersion": "(.*)",""".r
- daffodilVerRegex.findFirstMatchIn(packageJsonStr) match {
- case Some(m) => m.toString.split(":")(1).trim.replaceAll("\"",
"").replaceAll(",", "")
- case None => sys.error("Missing daffodilVersion specifier in
package.json")
- }
+val daffodilVers = {
+ val daffodilVerRegex = raw""""([^"]+)"\s*:\s*"(2.12|2.13|3)"""".r
+ daffodilVerRegex
+ .findAllMatchIn(packageJsonStr)
+ .flatMap {
+ case daffodilVerRegex(key, value) => Some(key -> value)
+ case _ => None
+ }
+ .toMap
}
Review Comment:
This is another place where having to use `daffodilScalaVersions` gets a bit
messy. What if we just hard code dependencies in here since they don't every
really need to change. Maybe the 4.0.0 dependencies wants to update
(technically it shouldn't be necessary), but we can let scala-steward do that.
Also, I was rethinking the jvmPlatform stuff and thinking about a better way
to support optional 17.
Combining those two ideas, what if we do this:
```scala
val scalaVersions = Seq("2.12.20", "2.13.16") ++
if (Properties.isJavaAtLeast("17") Seq("3.3.6") else Seq())
val debuggers = (projectMatrix in file("."))
.settings(
...
libraryDependencies ++= Seq(
// non-scala version dependant dependencies
),
libraryDependendencies ++= scalaBianryVersion.value match {
case "2.12" => Seq(
// scala-steward:off
"org.apache.daffodil" %% "daffodil-sapi" % "3.10.0" %
"provided,test",
"org.apache.daffodil" %% "daffodil-runtime1" % "3.10.0" %
"provided,test",
"org.apache.daffodil" %% "daffodil-lib" % "3.10.0" % Test,
// scala-steward:on
"org.scala-lang.modules" %% "scala-collection-compat" % "2.14.0"
)
case "2.13" => Seq(
// scala-steward:off
"org.apache.daffodil" %% "daffodil-sapi" % "3.11.0" %
"provided,test",
"org.apache.daffodil" %% "daffodil-runtime1" % "3.11.0" %
"provided,test",
"org.apache.daffodil" %% "daffodil-lib" % "3.11.0" % Test
// scala-steward:on
)
case "3" => Seq(
"org.apache.daffodil" %% "daffodil-core" % "4.0.0" %
"provided,test"
)
}
)
.jvmPlatform(scalaVersions)
```
This feels like a cleaner way to handle the jvm 17 optionality, and it also
puts all the libraryDependencies in one spot, I think making it more clear
what's going on.
##########
package.json:
##########
@@ -760,6 +774,8 @@
}
},
"dfdlDebugger": {
+ "daffodilVersion": "3.11.0",
Review Comment:
I tried to create a lunch.json config and it didn't already have
`"daffodilVersion"` in it. Autocomplete knew about it so I could add it, but it
might be nice if it already existed to make it more clear users change a
version? Or maybe it is clear somehow else and I'm just not familiar with
vscode and I'm missing something.
##########
vite/dev.vite.config.mjs:
##########
@@ -43,35 +43,46 @@ const packageData = jsoncParse(
fs.readFileSync(path.resolve('package.json'), 'utf8')
)
const pkg_version = packageData['version']
-const daffodilVersion = packageData['daffodilVersion']
-const serverPackage = `daffodil-debugger-${daffodilVersion}-${pkg_version}`
-const zipFilePath = path.resolve(
- `debugger/target/universal/${serverPackage}.zip`
-)
+const daffodilScalaVersions = packageData['daffodilScalaVersions']
function unzipAfterBuild() {
return {
name: 'unzip-server-package',
apply: 'build',
async closeBundle() {
- const serverPackageFolder = path.join(
- path.resolve('dist/package'),
- serverPackage
- )
+ Object.entries(daffodilScalaVersions).forEach(
+ async ([_, scalaVersion]) => {
+ const serverPackage =
`daffodil-debugger-${scalaVersion}-${pkg_version}`
+ const jvmFolderName = `jvm-${scalaVersion}`
+ const zipFilePath = path.resolve(
+ `debugger/target/${jvmFolderName}/universal/${serverPackage}.zip`
+ )
Review Comment:
Future consideration for simplifying this logic. We currently use sbt to zip
up things using `Universal/packageBin` just to unzip it here. If instead you
run `sbt Universal/stage` it will create the same directory structure without
zipping, and then you can just recursively copy
`debugger/target/${jvmFolderName}/universal/stage/`. Functionally it's the same
result, but might simplify this code a bit and avoids having to zip and unzip
things. Recommend just creating an issue for this, doesn't have to be done in
this PR since it's unrelated.
##########
src/daffodilDebugger/utils.ts:
##########
@@ -58,34 +90,66 @@ export async function runDebugger(
serverPort: number,
dfdlDebugger: DFDLDebugger,
createTerminal: boolean = false
-): Promise<vscode.Terminal> {
- const dfdlVersion = daffodilVersion(filePath)
+): Promise<vscode.Terminal | undefined> {
+ const dfdlScalaVersions = daffodilScalaVersions(filePath)
+
+ if (
+ !dfdlDebugger.timeout.endsWith('s') &&
+ !dfdlDebugger.timeout.endsWith('m') &&
+ !dfdlDebugger.timeout.endsWith('s')
+ ) {
+ vscode.window.showErrorMessage(
+ `DFDL Debugger Timeout ${dfdlDebugger.timeout} does not end in either s
for seconds, m for minutes or h for hours.
+ Appending s to end of timeout string.`
+ )
+ dfdlDebugger.timeout = `${dfdlDebugger.timeout}s`
+ }
+
+ // Locates the $JAVA_HOME, or if not defined, the highest version available.
+ const javaHome: IJavaHomeInfo | undefined = await getJavaHome()
+
+ const isAtLeastJdk17: boolean = parseFloat(javaHome?.version ?? '0') >= 17
+ outputChannel.appendLine(
+ `[DEBUG] Choosing java home at ${javaHome?.path}, version
${javaHome?.version}, is at least JDK 17: ${isAtLeastJdk17}`
+ )
+
+ let dfdlVersion = dfdlDebugger.daffodilVersion
+ let scalaVersion = await getScalaVersion(
+ dfdlScalaVersions,
+ dfdlDebugger.daffodilVersion
+ )
+
+ if (scalaVersion == '') {
+ displayModalError(
+ `Daffodil Version ${dfdlDebugger.daffodilVersion} does not satisfy any
version requirements`
+ )
+ return undefined
+ }
+
+ outputChannel.appendLine(
+ `[INFO] Using Scala ${scalaVersion} + Daffodil ${dfdlVersion} debugger`
+ )
+
+ /**
+ * The Scala 3 with Daffodil >= 4.0.0 debugger can only be ran on JDK 17 or
greater. So if the java version
+ * being used is less than 17, fallback to the Scala 2.13 and Daffodil
3.11.0 debugger and notify the user.
+ */
+ if (semver.satisfies(dfdlVersion, '>=4.0.0') && !isAtLeastJdk17) {
+ displayModalError(
+ `Daffodil Version ${dfdlVersion} uses Scala 3 and required JDK >= 17`
Review Comment:
I think I would remove "uses Scala 3". It isn't Scala 3 that requires JDK
17, it's Daffodil 4.0.0+. Some future versions of Scala 3 will drop JDK 8/11
support, but that hasn't happened yet, so this is potentially confusing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
