Brett Porter wrote: > Hi, > > I put these together the other day - any thoughts? > > Topic > - [ ] Recent changes > - [ ] archiva-common > - [ ] PathUtil > - [ ] doesn't this already exist in plexus-utils/commons-io? Oddly enough, no. And I plan on removing that utility anyway. It's use is diminishing in favor of BaseFile. > - [ ] BaseFile > - [ ] is this a case of premature optimisation? Not sure I understand. The usage of 'relative path' is immensely important within Archiva. This is "the one true file" object that will ultimately win. > - [ ] Consumer > - [ ] why init? why not just in the constructor? Seems like > a half component... > - [ ] I found it to be a confusing inheritence structure > - [ ] Better to move all consumers to a -consumers artifact > rather than split over commons and core? It is spread out due to 2 reasons, api -vs- usage, and to limit tight dependencies across modules. The consumer API is going to be split out. ( see http://docs.codehaus.org/display/MAVENUSER/The+Design+of+Archiva )
I am documenting the usage of it too. Archiva has memory problems, remember? I found that constructing a new consumer for each and every file is *BAD* (tm). Also, the consumers that are used are passed into the scanner by the calling function. This list is different depending on the event/action. Converter, Data Refresh Task, and On Upload Event are 3 different places that utilize consumers. > - [ ] ConsumerFactory > - [ ] unnecessary plexus use. 'name' is never used. I'm being brow-beaten by trygvis and jvanzyl in #plexus about this. I'm getting educated about proper plexus usage ATM. > - [ ] GenericModelConsumer > - [ ] only used in mocks? This isn't wired up properly yet. It's a place holder for effective pom. > - [ ] GenericArtifactConsumer > - [ ] should use plexus requirements to get the builders as > a map Just learned about plexus Map requirement mapping. I could make the change, but (see next) ... > - [ ] since this probably shouldn't be a component, pass > in the > builder to processFile (or wrap the artifact > repository in a container that has the builder and > artifact repo - this is more practical since > eventually it will be part of the layout anyway) I'm reworking the whole bidirectional layout mechanism into a single component. I think this is what you are hinting at? > - [ ] ManagedArtifactTypes > - [ ] this should be able to be achieved with the > existing metadata from the ArtifactTypeHandler in > maven-artifact, rather than duplicating the types of > attachments (with the addition of the javadoc and > sources attachments which could be managed in Archiva) Agreed. I'll look into it. > - [ ] archiva-core > - [ ] RepositoryTask > - [ ] put policies into plexus-taskqueue? > - [ ] DataRefreshExecutor > - [ ] consumers should be a list requirement directly from > plexus, no need for wrapper class The wrapper class is there to limit the amount of copy/paste <component> garbage between archiva-core and archiva-webapp's application.xml > - [ ] archiva-reports-standard > - [ ] better to use string representation for key than > [Artifact|Metadata]ResultsKey? > - [ ] ReportingDatabase should be an interface, proper > components > - [ ] why is getting the number of failures, etc resource > intensive? Because not all loaded at once? > - [ ] ArtifactResultsDatabase has strange component declaration > vs inheritence. > - [ ] ARD is JDO specific. (this may have been fixed in > archiva-database, haven't looked yet) > - [ ] split into database, database-jdo and reports-standard, > reports-other, etc. > - [ ] is there an interface trigger for re-generating the > reports in case the data gets out of sync? This whole module is undergoing a gutting. The work being done in archiva-database invalidates huge portions of this module. > - [ ] General > - [ ] Some design notes needed / existing ones updated, and > more javadoc particularly > for the reusable classes There are 3 areas of documentation that are being worked on. 1) Architectural Design in general. 2) Database Design. 3) Javadoc on public / reusable classes. > - [ ] Old Stuff > - [ ] archiva-converter > - [ ] FileTransaction seems duplicated with various > transaction events (though both are used) > - [ ] legacy converter is in separate package, but default > repository converter is not. > - [ ] check for code duplication between legacy and default > converters 90% of this code has been recently moved to maven-artifact-converter and maven-transaction. https://svn.apache.org/repos/asf/maven/shared/trunk/maven-artifact-converter/ https://svn.apache.org/repos/asf/maven/shared/trunk/maven-transaction/ That module will be gutted shortly.
