Hi, Using Artifactory you can attach any number of named metadata to a deployed file (or folder). This metadata can be either XML or property-based. It is fully searchable and can be attached and retrieved using simple REST queries (as long as the end user has the "annotate permission"), so there is no need for much custom development. Basically, to add and consume custom metadata to/from a zip you only use to use simple REST commands to a URL in the form of http://host:port/path-to-artifact:metadata-name, which is very lightweight on the repository. You can find more info about this here: http://www.jfrog.org/confluence/x/CQCq. The list of named metadata is also available though REST API ( http://www.jfrog.org/confluence/x/C4K5) and since metadata is searchable you can even use it to manage your artifacts by manipulating search results found according to metadata queries (promote/move, copy etc.), but that's a different story :)
Hope that helps, Yoav http://www.jfrog.org/ On Sun, Jun 6, 2010 at 9:54 PM, Les Hazlewood <l...@katasoft.com> wrote: > Yep, Nexus would be fantastic for this - we're basically trying to > come up with the most efficient mechanism to do the following: > > 1. A Grails developer releases a plugin. This process first entails > (ideally) Grails uploading it to a Maven repo (i.e. Nexus). > 2. Grails (during its 'release-plugin' command) next 'pings' the > global Grails Plugin Portal (http://www.grails.org/plugin/home) with > the location of the released artifact(s). > 3. The Plugin Portal downloads the plugin metadata when it can based > on the location specified in #2 and updates its website pages to > ensure that any searches in the Portal reflect the new release. > > The key here is #3 - finding the best way for the Portal to > most-efficiently download and read in the plugin metadata without > having to download the entire plugin release.zip. The Portal has to > support this for hundreds of plugins every day - it has to be as lean > as possible. > > Best, > > Les > > On Sun, Jun 6, 2010 at 7:38 AM, Jason van Zyl <ja...@sonatype.com> wrote: > > Nexus can utilize anything contained in the repository. Whether a piece > of metadata exists alongside the artifact or within it, a Nexus plugin could > be created to process the information. So you don't need to change the way > Grails plugins are packaged in order to extract the metadata and make it > available. We know from experience that Nexus is perfect for plugin systems > :-) > > > > On Jun 4, 2010, at 4:28 PM, Les Hazlewood wrote: > > > >> Is this possible? So, in addition to stuff like <developers>, is it > >> possible to add additional metadata? > >> > >> I'm asking because the Grails development team is exploring the > >> possibility of using a Maven repository (e.g. Nexus) to host Grails > >> plugins. A Grails plugin is a .zip file, but the Grails environment > >> (and the global Grails Plugin Portal > >> http://www.grails.org/plugin/home) need to read Grails-specific > >> metadata about that .zip without having to download the .zip first. > >> I'm proposing that the POM could serve that purpose *if* POMs can hold > >> additional metadata somehow. > >> > >> Any ideas? > >> > >> Thanks, > >> > >> Les > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > --------------------------------------------------------- > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
