ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bram de Kruijff (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-217) Delete bundles and config files from the repository.
Date Mon, 29 Apr 2013 10:00:16 GMT

    [ 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

Mime
View raw message