mbeckerle commented on issue #54: URL: https://github.com/apache/daffodil-vscode/issues/54#issuecomment-977154874
There are a few different aspects to this problem. First, locally, schemas are preferably organized using the standard schema layout. This means the schema files will be spread out over src/main/resources and src/test/resources. E.g., the schema files under src/main/resources may not define any global elements at all, just types. The global elements may only be defined under src/test/resources. This means the schema is structurally assuming that both src/main/resources and src/test/resources are on the class path when testing. The second aspect is about one schema depending on another. The whole transitive closure of the chain of inter-schema dependencies is captured in the build.sbt file, and managed dependencies are used when running 'sbt test' to obtain all the schemas upon which this one depends (transitively). We need some way for the debugger to inherit this as well. For other IDEs, either they support parsing and processing the sbt file themselves, or they utilize sbt as a server of some sort so they can be fed the dependency information, OR, a command such as 'sbt eclipse' must be issued which writes out all the dependencies (transitively) to a file format suitable for the IDE (in this case Eclipse). However, we do it, we need some way to capture the inter-component dependencies without requiring users to do much work to set it up. Just setting this up for using the Daffodil CLI is pretty miserable. You have to edit these massive classpath entries, then log-out/login to get them to take effect, etc. Which is why I almost always invoke Daffodil via 'sbt test'. -- 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]
