+1 Richard's ideas sound good to me. I like moving the actual tasks to under 'org.dspace.ctask.<something>'
Given the choice of Richard's three naming options, I'd probably lean very slightly towards "org.dspace.ctask.general" (but "misc" would be a close second). I don't have a strong opinion though, so feel free to go with whatever you prefer, and then move things around as appropriate.
The only thing that I do ask is that we create a JIRA issue to track this change, so that it makes it into the 1.8.0 "History" of changes. Beyond that, I'm +1 to this idea in general.
- Hide quoted text -
On Thursday, August 18, 2011 9:36:43 AM, Richard Rodgers wrote:
I completely agree we should move the examples + virus scan - i.e. all implemetations - out of org.dspace.curate.
My vote for a new home is org.dspace.ctask.<something>, which follows a convention we have already established
(e.g. the new replication tasks are 'org.dspace.ctask.replicate'). This accomplish
es both having a standard
naming convention for sets of tasks, but also does not put the tasks under org.dspace.curate, which is a part of dspace-api.
If we later get our add-on act together, we can move 'ctask' and subtrees out of dspace-api.
The question then becomes what the<something> is. I'm not wild about 'sample' or 'examples' (although that's how it started out), since the set now
includes usable, general tasks. So I'd consider packages like:
Any other ideas?
On Aug 17, 2011, at 11:44 PM, Kim Shepherd wrote:
I'm going to commit those curation tasks I'd mentioned shortly, but
before I do, just wanted to run this refactor proposal past you all..
How about we move all the "supplied/example" tasks (no abstract
classes like AbstractCurationTask though) into org.dspace.curate.tasks
If you're all OK with that, I'll move the classes, commit my own,
update the default curation configs to reflect the changes, and we'll
be ready for 1.8