You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Deng Ching <oc...@apache.org> on 2010/04/20 11:26:15 UTC
Re: Facets (was: Re: svn commit: r921376)
Hi Brett,
I'm currently looking at MRM-1362 (Add simple 'CRUD' pages for project-level
metadata along with a "generic metadata" plugin), and I have a question
regarding this feature. As I understand it, the contents of the project
version metadata (version-metadata.properties) comes mostly from the POM. If
we're going to provide a CRUD functionality for it through the webapp, won't
it have an effect that the info in the POM may not be the same as the info
stored in the project version metadata?
Thanks,
Deng
On Thu, Mar 11, 2010 at 12:45 AM, Brett Porter <br...@apache.org> wrote:
>
> On 11/03/2010, at 3:12 AM, Wendy Smoak wrote:
>
> > On Wed, Mar 10, 2010 at 10:08 AM, Brett Porter <br...@apache.org> wrote:
> >
> >> http://archiva.apache.org/ref/1.4-SNAPSHOT/metadata-content-model.html
> >>
> >> It's a way of storing plugin / functionality-specific metadata
> extensions - so the Maven specific parts (type, classifier, snapshot info)
> that is not part of the canonical content model are put into there.
> >
> > Thanks! That's not getting indexed [1], I'll see about linking it
> > from somewhere so Google can find it.
>
> I think we just did :)
>
> Anyway, there was a thread earlier where we hadn't quite decided whether to
> push dev't docs into APT / Subversion, or into Confluence.
>
> >
> > 'Metadata extensions' sounds potentially useful for storing arbitrary
> > metadata, like ratings (5 stars!) or approval status (whether an
> > artifact is allowed to be used in production) in a corporate
> > environment. Or am I way off?
>
> Yes, that's exactly what it's for. It's all derived from the ideas that
> have been posted here over the last couple of years relating to extensible
> metadata, and making it a fundamental part of the system and APIs rather
> than something tacked on.
>
> The work I'm doing at the moment is refactoring so that the available
> artifact type mappings becomes extensible, essentially using the "Maven 2"
> facet for storing type and classifier of an artifact. With a little work
> tomorrow that will be done, and I'll add a plugin that illustrates it.
>
> It might be good to do a simple metadata 'CRUD' page as a new tab. Is
> anyone interested in working on that?
>
> Here's some pointers - the extent of the code (aside from the actions) is
> not much more than:
>
> 1) create a new facet type (look at MavenProjectFacet for an example, or we
> could create a generic one that is just a set of key-value pairs), put it in
> a new project in plugins/, and include that dependency in the webapp.
>
> 2) Look it up in an action:
>
> /** @plexus.requirement */
> private MetadataResolver resolver;
>
> ...
>
> ProjectVersionMetadata metadata = resolver.getProjectVersion( repoId,
> groupId, artifactId, version );
> MetadataFacet facet = metadata.getFacet( "unique-id-of-my-facet" );
>
> 3) use the values for the CRUD forms:
>
> facet.toProperties()
> facet.fromProperties()
>
> 4) Store it:
>
> /** @plexus.requirement */
> private MetadataRepository metadataRepository;
>
> ...
>
> metadataRepository.updateProjectVersion( repoId, groupId, artifactId,
> metadata );
>
>
> There's also facets at the artifact level, but there isn't a good place in
> the UI to show them right now. One step at a time :)
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
Re: Facets (was: Re: svn commit: r921376)
Posted by Deng Ching <oc...@apache.org>.
You're right :) Anyway, I'll just send out a proposal for this tomorrow.
Thanks,
Deng
On Tue, Apr 20, 2010 at 6:48 PM, Brett Porter <br...@apache.org> wrote:
>
> On 20/04/2010, at 8:21 PM, Deng Ching wrote:
>
> >
> > Would it pose a problem if we reflect the changes in the metadata to the
> POM
> > itself? Then put a warning that any changes (to specific fields) will get
> > reflected to the POM and at the same time, limit which properties
> associated
> > to certain POM info can be modified.
> >
>
>
> It's pretty rare that you actually want to change a POM in the repository -
> I think it's going to be likely that someone wants to edit it for
> presentational purposes but not the backing storage (or not allow it at
> all). This also keeps things simpler :)
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
Re: Facets (was: Re: svn commit: r921376)
Posted by Brett Porter <br...@apache.org>.
On 20/04/2010, at 8:21 PM, Deng Ching wrote:
>
> Would it pose a problem if we reflect the changes in the metadata to the POM
> itself? Then put a warning that any changes (to specific fields) will get
> reflected to the POM and at the same time, limit which properties associated
> to certain POM info can be modified.
>
It's pretty rare that you actually want to change a POM in the repository - I think it's going to be likely that someone wants to edit it for presentational purposes but not the backing storage (or not allow it at all). This also keeps things simpler :)
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
Re: Facets (was: Re: svn commit: r921376)
Posted by Deng Ching <oc...@apache.org>.
On Tue, Apr 20, 2010 at 5:56 PM, Brett Porter <br...@apache.org> wrote:
>
> On 20/04/2010, at 7:26 PM, Deng Ching wrote:
>
> > Hi Brett,
> >
> > I'm currently looking at MRM-1362 (Add simple 'CRUD' pages for
> project-level
> > metadata along with a "generic metadata" plugin), and I have a question
> > regarding this feature. As I understand it, the contents of the project
> > version metadata (version-metadata.properties) comes mostly from the POM.
> If
> > we're going to provide a CRUD functionality for it through the webapp,
> won't
> > it have an effect that the info in the POM may not be the same as the
> info
> > stored in the project version metadata?
>
> Yep, good point. I was really looking for a simple starting point, so I'm
> happy if this just gets defined and documented in one way of your choice,
> eg.
> - you can change it and it's not reflected back (so will be inconsistent).
> You may or may not add another metadata property to indicate this so the UI
> can indicate it, or record all the maven stuff in duplicate fields so that
> originals can be shown
>
Would it pose a problem if we reflect the changes in the metadata to the POM
itself? Then put a warning that any changes (to specific fields) will get
reflected to the POM and at the same time, limit which properties associated
to certain POM info can be modified.
> - don't allow editing a fixed set of fields that we don't think makes sense
>
> Versioning the metadata would be an interesting future change also that
> might help here.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>
Re: Facets (was: Re: svn commit: r921376)
Posted by Brett Porter <br...@apache.org>.
On 20/04/2010, at 7:26 PM, Deng Ching wrote:
> Hi Brett,
>
> I'm currently looking at MRM-1362 (Add simple 'CRUD' pages for project-level
> metadata along with a "generic metadata" plugin), and I have a question
> regarding this feature. As I understand it, the contents of the project
> version metadata (version-metadata.properties) comes mostly from the POM. If
> we're going to provide a CRUD functionality for it through the webapp, won't
> it have an effect that the info in the POM may not be the same as the info
> stored in the project version metadata?
Yep, good point. I was really looking for a simple starting point, so I'm happy if this just gets defined and documented in one way of your choice, eg.
- you can change it and it's not reflected back (so will be inconsistent). You may or may not add another metadata property to indicate this so the UI can indicate it, or record all the maven stuff in duplicate fields so that originals can be shown
- don't allow editing a fixed set of fields that we don't think makes sense
Versioning the metadata would be an interesting future change also that might help here.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/