[
http://jira.codehaus.org/browse/MRM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104051
]
Brett Porter commented on MRM-294:
----------------------------------
since you asked, here's my feedback :)
RepositoryPurgeConsumer:
- it looks like index and repositoryLayout can be local variables instead (and
repository field can be removed)
- I saw: // @todo handle better injection of RepositoryPurge -- the injection
seems fine to me, but if you want to switch it to a component that's good too.
RepositoryPurge:
- what about removing the setters on this interface, and passing them to the
process method instead. As a component, this will be a singleton by default, so
you can't use the setters (you can make the component not be a singleton, but
there isn't any reason they need to retain state so I wouldn't worry).
- since the process method always uses a specific repository configuration
maybe it'd be better to pass that in directly instead of the general
configuration object?
AbstractRepositoryPurge:
- looks like 'index' can be removed
- getFiles() calls System.out - looks like that should be an IOException?
- abstract process() can be removed - it comes from the interface
- need to create an issue for the commented out index purge (is it better to
just omit this and let the normal indexing consumer pick up the deletion?)
- need to create an issue for it still being on browse page (per comment above)
- maybe it's a DAO caching issue?
- the exceptions in updateDatabase() are getting swallowed!
DaysOldRepositoryPurge:
- don't do new GregorianCalendar - use Calendar.getInstance() instead
DefaultCleanupReleasedSnapshots:
- name is inconsistent with the others - should be
CleanupReleasedSnapshotsPurge?
- System.out in here, and exception is swallowed - is it intentional to log and
swallow the exception?
A general thought here too, for later: it might be worth reviewing the
exceptions that can occur in *Purge and see if we can recover better from each
rather than bubbling it
Tests:
- I think you can remove many of the components from the test XML files where
the default suffice (just keep the registry and jdo factory)
- the tests have a lot of bolierplate that can probably be turned into methods
that generate test data
Missing tests:
- no tests for the consumer or the Released Snapshots purge
- days old test is only testing by file age - it should also test the
metadata-driven snapshots
A general thought for Archiva in the long term, too... setting up the database
to test this was probably a pain. We should have stub implementations of the
indexer and dao's to avoid it.
> Repository purge feature for snapshots
> --------------------------------------
>
> Key: MRM-294
> URL: http://jira.codehaus.org/browse/MRM-294
> Project: Archiva
> Issue Type: New Feature
> Affects Versions: 1.0-alpha-1
> Reporter: Wendy Smoak
> Assignee: Maria Odea Ching
> Fix For: 1.0-beta-1
>
>
> We need a way to purge a repository of snapshots older than a certain date,
> (optionally retaining the most recent one) and fixing the metadata.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
