On 31/07/2010, at 8:22 AM, Wendy Smoak wrote: > I've seen a few cases where projects use a non-SNAPSHOT version > number, and end up deploying to the 'internal' repo without going > through the Maven release process. (So, no checking for snapshot > dependencies, no svn tag, etc.) > > Ideally I'd like to stop it from happening -- perhaps a rule to apply > to a staging repo before it is allowed to be merged?
Yes, I think maybe we want consistency, so we could attach the reporting checks to both deployment and to stage promotion. That would be better than some of the manual stuff that happens now in the deployment code. > > But to audit the ones already in the repository, is there a way I can > make this a 'report' or have it show up on the list of problems found > in the repo? Take a look in archiva-artifact-reports, particularly LocationArtifactsConsumer which is reading the model. You should be able to reproduce these in a separate JAR that is dropped into the webapp and have them available from the UI. If you want to just add it to a future release, I think I'd add a check in the LocationArtifactsConsumer to complain even if its a valid snapshot if it is in a repository that isn't meant to include snapshots (and vice versa). The other checks could be in a "POM validation" type of report / check. Note that this has changed significantly on trunk (hopefully for the better ;) If you are making modifications, I'd focus on that if you can. Cheers, Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/
