Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Create a package manager for REST API extensions and transforms #133

Closed
dmcassel opened this issue Sep 11, 2013 · 6 comments
Closed

Create a package manager for REST API extensions and transforms #133

dmcassel opened this issue Sep 11, 2013 · 6 comments

Comments

@dmcassel
Copy link
Collaborator

Analogous to npm.

Motivation: make it easy to share REST API service extensions and transformations.

$ ml pm install tagger

  • downloads the tagger extension, puts it into the rest/ext directory of the current Roxy project.
  • downloads any dependent libraries, sets up the path under your src directory. Convention: src/lib/{extension-name}/{libraries}. enforced?
  • downloading happens by "git clone" to a tmp directory, then files are moved to the appropriate locations.
  • stores information about what was installed. where?

$ ml pm remove tagger

  • lists files to be removed from the current Roxy project, prompts to confirm

$ ml pm publish tagger.xml

  • sends tagger.xml to package registry (a public-facing web site hosted by MarkLogic registry.marklogic.com).
<package>
  <extension>
    <name>tagger</name>
    <location>http://github.com/dmcassel/tagger</location>
    <description>Takes parameters "uri", "tag", and "path". Inserts a &amp;lt;tag&amp;gt; element with the value of the tag parameter at the specified path.<description>
    <works-with-ml>6</works-with-ml>
    <license url="http://opensource.org/licenses/MIT">MIT</license>
  </extension>
</package>
<package>
  <transform>
    <name>flatten-meta</name>
    <location>http://github.com/dmcassel/flatten-meta</location>
    <description>Converts elements of the form &amp;amp;lt;meta name="foo" value="bar"/&amp;gt; to &amp;lt;foo&amp;gt;bar&amp;lt;/foo&amp;gt;</description>
    <works-with-ml>6</works-with-ml>
    <works-with-ml>7</works-with-ml>
    <license url="http://opensource.org/licenses/MIT">MIT</license>
  </transform>
</package>

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.

@dmcassel
Copy link
Collaborator Author

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.

@dmcassel
Copy link
Collaborator Author

Packages should probably support a <depends-on> element. That way you could have multiple extensions/transforms that use the same dependent library.

@paxtonhare
Copy link
Contributor

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.

@eedeebee
Copy link
Contributor

Also see http://getcomposer.org for PHP - also uses json for config.
And Florent George's attempt for XML at cxan.org - suspect ther'es some integration with namespaces and paths there that might be interesting.

@dmcassel
Copy link
Collaborator Author

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.

@grtjn
Copy link
Contributor

grtjn commented Jun 13, 2017

MLPM saw light in 2015, and covers the needs described here. It comes with it's own mechanism to deploy src, as well as extensions, but that can be integrated into Roxy without too much difficulty. However, that is covered in #357.

I think there is no need for another package manager..

@grtjn grtjn closed this as completed Jun 13, 2017
@grtjn grtjn self-assigned this Jun 13, 2017
@grtjn grtjn added this to the July 2017 milestone Jun 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants