archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deng Ching <och...@apache.org>
Subject Re: [Proposal] MRM-1362 - Add 'CRUD' pages for project-level metadata
Date Thu, 29 Apr 2010 10:10:21 GMT
On Fri, Apr 23, 2010 at 5:00 PM, Brett Porter <brett@apache.org> wrote:

>
> On 21/04/2010, at 7:46 PM, Deng Ching wrote:
>
> > This issue pertains specifically to the add, edit, view and delete of the
> > version-metadata.properties in the new content model through the webapp,
> as
> > discussed in
> > http://www.mail-archive.com/dev@archiva.apache.org/msg00977.html
> >
> > How It Would Work:
> >
> > 1. A new tab named "Project Metadata" in the Artifact browse page will be
> > added.
>
> +1 - though "Metadata" is probably long enough
>
> >
> > 2. If a version-metadata.properties for the artifact already exists, the
> > contents will be retrieved then displayed in the "Project Metadata" page.
>
> You shouldn't interact directly with the properties file - the repository
> API should handle it all (I'm still prototyping the JCR replacement here).
>
> > The user will have an option to edit and delete the metadata. The
> metadata
> > can be deleted whether it contains any information or not, since it can
> be
> > re-created during the repo scan.
>
> I'm not sure about deleting - things magically coming back through scan
> would make that confusing. Might be best to add a note about that when
> deleting.
>

Ok, noted :)


>
> >
> >   - Each property or set of properties will be displayed as fields that
> can
> > be modified.
>
> +1
>
> >   - To keep the info in the POM and the project version metadata
> > consistent, content that are directly taken from the POM cannot be edited
> > nor deleted. But additional data can be added.
> >
> >     For example, for the Description property.. the info obtained from
> the
> > POM (<description>) will be displayed as read only. But the user can add
> > additional description, which will be stored in a separate property in
> the
> > version-metadata.properties.
>
> +1, though they won't be able to use "Description". This is something we
> need to think through after the first implementation - do we double up the
> maven values (description and maven:description), or just keep the one, and
> if we allow editing how do we make it clear that doesn't reflect in the POM?
> For the moment, I think it's best just to make them read-only as you say.
>

Agreed


>
> > 3. Otherwise, if a version-metadata.properties for the artifact does not
> > exist, the user will have the option to create the metadata.
>
> This shouldn't be needed - the project will have metadata created just by
> reading it I think, and if not you can just assume it's empty and start
> adding / saving.
>
> >
> > Lastly, only users with Repository Manager roles will have add, update
> and
> > delete access to the project version metadata.
>
> +1 - though I'd make this a separate permission within the role so we can
> customise later.
>
> How is the implementation going? I have something similar I'd like to try
> that might build off your work.


I'm trying out JQuery for adding and modifying the contents. I'm thinking of
using pop-ups to add and modify data, especially the collections (e.g.
mailing lists, licenses, dependencies, etc.).

Thanks,
Deng

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message