Message-ID: <60100515.3635.1369396210987.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3634_1515265584.1369396210987" ------=_Part_3634_1515265584.1369396210987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This is a rough sketch of the API. For the first few reports, th= ey will all go in one JAR: maven-repository-reports-standard. No integratio= n with the discoverer is necessary at this point.
This interface is used by the single artifact processor.
The initial implementation of this will just need to be a mock implement=
src/test/java, used to track the failures and success=
es for checking assertions. Later, implementations will be made to present =
reports on the web interface, send them via mail, and so on.
This interface will be called by the main system for each artifact as it= is discovered. This is how each of the different types of reports are impl= emented, so there will be implementations such as: ChecksumArtifactReport = MRM-17 (see repoclean's digestor for some related code= ), and TransitiveClosureArtifactReport MRM-2.
This interface is called by the main system for each piece of metadata a= s it is discovered, similarly to above. ChecksumArtifactReport will also im= plement this (as metadata has checksums), and there will be a MetadataValid= ationReport MRM-16
The transitive and metadata validation reports will need to query the re= pository for artifacts. There is no implementation of this at present - ins= tead, a mock implementation should be created that acts as a repository of = test artifacts.------=_Part_3634_1515265584.1369396210987--