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/21 11:46:26 UTC
[Proposal] MRM-1362 - Add 'CRUD' pages for project-level metadata
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.
2. If a version-metadata.properties for the artifact already exists, the
contents will be retrieved then displayed in the "Project Metadata" page.
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.
- Each property or set of properties will be displayed as fields that can
be modified.
- 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.
Another example is the Licenses property.. the licenses specified in
the POM will only be readable. But the user can add another license, which
will again be stored in a separate property. Duplicates will not be
accepted.
3. Otherwise, if a version-metadata.properties for the artifact does not
exist, the user will have the option to create the metadata.
Lastly, only users with Repository Manager roles will have add, update and
delete access to the project version metadata.
Thoughts or comments are welcome :)
Thanks,
Deng
Re: [Proposal] MRM-1362 - Add 'CRUD' pages for project-level metadata
Posted by Deng Ching <oc...@apache.org>.
On Fri, Apr 23, 2010 at 5:00 PM, Brett Porter <br...@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
Re: [Proposal] MRM-1362 - Add 'CRUD' pages for project-level metadata
Posted by Brett Porter <br...@apache.org>.
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.
>
> - 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.
> 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.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/