|
||||||||
|
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 |
||||||||
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
1) if you can be as generic as possible, I agree. But for certain things, you do not want to be as generic. For example, the CRUD on resources -> can be generic, but the registration of a target is too specific for a single resource to be made generic. Moving these "action"-like methods to the specific resource would clutter the abstract resources too much;
2) TargetState represents the state of a target (the only entity with state in Ace). Together with Target it forms a composite that cannot be treated separately. If you want, you can refactor TargetState to be an inner class of Target. As for AuditEvents, these are read-only entities. You could make them as generic as Artifact, Feature, etc. but for 75% of the CRUD operations you need to make exceptions for them.
As for the import/export of models, I have my questions about their use case: if you want to create an export/copy of an existing Ace-repository, you need more than only its metadata, which you cannot currently obtain through the REST API;
3) The updateResources is now implemented; it needed a fix in Ace to make the definition of a repository object accessible from the REST API.
I've added a more-or-less generic invokeResourceAction to the Java API; which is internally used as well. We need to discuss whether this is sufficient...