Brett Porter wrote: > Joakim - any thoughts on these 2 additional questions? I'd like to > finish tidying this section up soon. > > Cheers, > Brett
Not sure what constitutes the 2 additional questions. But here's the background on the decision. The database was always viewed as *the* source for all information that is pertinent to Archiva. The configuration pieces were viewed not as a model or datasource, but a bootstrap to take a configuration from disk, and populate the database. The reporting would use the database. The repositories in the database are intentionally kept neutral, so that the future consumer to auto-adjust embedded <repositories> sections within pom files to the Archiva repository itself. Yes, currently the database tracks more fields than are used. But that will change rapidly post Archiva 1.0, when the auto-repo-adjust consumer kicks in and has to start tracking *all* repo ids to the map-to id specified in a configuration screen somwhere (that's the primary reason it was postponed, the need for a configuration screen) Also, the field for the source of the entry in the database will start to take on a more important role, as it can identify if it was manual, from configuration, or from a pom file. (some examples) I am against removing of the repository information in the database, as this will needlessly complicate reporting in the future. I am for removing the need for a configuration model, and would prefer that the database persistence and the configuration pieces utilize the same model. - Joakim
