mlxprs
mlxprs copied to clipboard
Debugger awareness of ml-gradle module mapping conventions
Local source modules are deployed in DHF using the logic described here:
https://github.com/marklogic-community/ml-gradle/wiki/How-modules-are-loaded
We should support multiple root directories in project source code corresponding to /
on MarkLogic (e.g. /ext
and /root
both deploying to /
).
I wouldn't bother supporting "/ext" - there's really no use case for it, "/root" is the way to go.
Would it be a common case in ml-gradle where we'd need multiple directories mapping to the same root? If you can always just pick one directory, this is pretty much covered. (q for @rjrudin)
For application modules, nearly all non-REST extensions will be / should be under src/main/ml-modules/root.
Where it gets tricky is for test modules and bundles.
Test modules are typically under src/test/ml-modules/root - e.g. marklogic-unit-test tests are likely under there (but a user could pick any directory; this is just a common path).
Bundles - https://github.com/marklogic-community/ml-gradle/wiki/Bundles - introduce additional module paths.
Thus, a project that is using marklogic-unit-test likely has 3 "root" directories:
- src/main/ml-modules/root
- src/test/ml-modules/root
- build/mlBundle/marklogic-unit-test-modules/ml-modules/root
A user may then wish to run a unit test via the debugger. Ideally, the debugger would be able to step through her test module, the application modules invoked by her test module, and possibly even the modules in marklogic-unit-test itself (though maybe not as likely, since most of those are XQuery).
Where does src/test/ml-modules/root
end up in the remote Modules database? That seems like an unnecessary abstraction to hoist it into a separate director in the Gradle config. Why not just have it under /root
?
A user may then wish to run a unit test via the debugger.
I’d expect this is a primary use case. This allows you to focus on your code and not the wrapping framework code. It’s also how you’d debug JavaScript that’s bootstrapped by an XQuery main module.
Users will configure mlModulePaths like this:
mlModulePaths=src/main/ml-modules,src/test/ml-modules
Then, in e.g. gradle-prod.properties, they'll just do this:
mlModulePaths=src/main/ml-modules
That provides a simple environment-based mechanism for determining whether to deploy test modules or not.
Users don't have to do that; they're free to put test modules under src/main/ml-modules/root, and then figure out how not to deploy them to a prod environment on their own.
That provides a simple environment-based mechanism for determining whether to deploy test modules or not.
That’s the rationale I didn’t understand. That makes sense. That does add an extra wrinkle to debugging, though, since the layout in the Modules database doesn’t align with what’s in the local file system. It’s almost like a source map use case.
Bundles will add the same complexity.
What do you think of a feature in ml-gradle that denotes which paths under src/main/ml-modules/root should be ignored in a particular environment?
That would easily work for marklogic-unit-test, as the convention is to have everything under "test".
An mlBundle ideally has a unique root directory in its path - e.g. "/acme.com/badMallocDetector".
A user could then add something like this to gradle-*.properties:
mlModuleRootPathsToIgnore=/test,/acme.com
This would require the user to also gitignore the /acme.com directory - bundles are unzipped to ./build/mlBundle by default right now as "build" is almost certain to be gitignored.
What do you think of a feature in ml-gradle that denotes which paths under src/main/ml-modules/root should be ignored in a particular environment?
That’s probably where I would have started rather than separate directories. (How do you even structure import
/require
paths in tests that look for things in /root
?)
What would the impact of your bundle proposal be on the mlxprs modules root configuration? We can add more smarts to align mlxprs and the debugger with how ml-gradle structures files, but that seems like a lot of work and ultimately very brittle.
Note that "/root" isn't part of the module URI. It's the directory in a module path that tells ml-gradle to load everything in it into the "root" directory - e.g. src/main/ml-modules/root/com/acme/test.sjs would be loaded as /com/acme/test.sjs.