[
https://issues.apache.org/jira/browse/ACE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644391#comment-13644391
]
Bram de Kruijff commented on ACE-217:
-------------------------------------
2) The artifacts column shows all artifacts in the current artifact-repository
and you can remove them at will using the 'X'. I can see how tree-views and
filters may help, but there is a separate issue for that at ACE-319
1) The 'Repository view' in the "Add bundles" dialog is filtered against the
current state of the artifact-repository. An initial approach is to allow
deletion of these resources. There are some considerations though;
* The fact that a resource is not referenced from the current
artifact-repository doe NOT mean it is not referenced from older revision in
the deployment-repository. Thus deleting a resource could break deployment
packages for target at old/rollback versions. I see two ways to address this
(at some point); First we could check all deployment revisions and state of
targets and disallow deleting resources within some reasonable limit. However,
this is probably pretty complex, expensive and hard to communicate to the user.
The second approach is to introduce resource caching on the server so that it
is no dependent on the user-managed / upstream repository when constructing a
deployment package. I discussed this with Marcel before and IMHO that would be
a far more robust approach that will also prepare us for multiple (upstream)
repositories.
* OBR management is somewhat scatted around the code base. In this case the OBR
upload is encapsulated by the ArtifactRepositoryImpl and it does ot support
delete. As proposed in ACE-341 the repository should become a first-class
service allowing us to decouple repository management. Again something that
will prepare is for multiple (upstream) OBRs where some will be manageable and
some wont. This also relates to the R5 discussion at ACE-314.
In the scope of this issues I propose to;
* Allow deletes of resource in the OBR view because, as Paul argues, the OBR is
private and are assumed to know what your are doing.
* For the time being implement the delete functionality in the webui code,
pending a OBR solution that covers the broader issues.
WDYT?
> Delete bundles and config files from the repository.
> -----------------------------------------------------
>
> Key: ACE-217
> URL: https://issues.apache.org/jira/browse/ACE-217
> Project: ACE
> Issue Type: New Feature
> Components: OBR
> Reporter: Paul Bakker
> Assignee: Bram de Kruijff
>
> If an ACE server is often updated with new versions of bundles you will end
> up with lots of obsolete bundles, which makes it hard to work with the UI.
> The UI should provide a way to completely remove bundles from the repository.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
