-
Notifications
You must be signed in to change notification settings - Fork 66
Create a package manager for REST API extensions and transforms #133
Comments
The advantage of doing this in conjunction with Roxy (instead of as a stand-alone project) is the simple path to deployment for extensions/transforms and any dependent libraries. |
Packages should probably support a |
Look at how bower does this for JavaScript libs. Each library has a bower.json file at the root of its github repo. Run bower with no params for all available commands. |
Also see http://getcomposer.org for PHP - also uses json for config. |
Talked to eedeebee earlier, who suggested that this could be used for more than extensions & transforms. As I'm picturing it, the registry would need to include XQuery lib modules anyway (for extensions/transforms that need supporting libraries). Not much of a leap to allow for lib modules that don't have extensions or transforms associated with them. Paxton, maybe this is a way to handle the different approaches to unit testing we've discussed. We could have different packages for unit testing. Install the one you want (current, or the annotation-based approach that requires ML6) and test away. If modules would get installed under src/lib (or src/pm-modules, or whatever), the rewriter would need to know where to find the tester. Maybe that level of integration is a version 2+ feature. |
Analogous to npm.
Motivation: make it easy to share REST API service extensions and transformations.
$ ml pm install tagger
$ ml pm remove tagger
$ ml pm publish tagger.xml
registry.marklogic.com would provide services to the "ml pm" command and allow for package browsing, like https://npmjs.org/.
This ticket lists first-cut functionality.
The text was updated successfully, but these errors were encountered: