On 08/25/2011 07:34 AM, Benson Margulies wrote:
I discovered yesterday that one team had taken this idea to its local extreme, and were just using release versions, no -SNAPSHOTS at all.
Do you mean they were only using release versions in dependencies? This would make sense to me. If you want to test a multimodule change (such as API + usage), temporarily switch the dependency to a snapshot version, iteratively test the combined change, then commit and release the upstream module, update the dependency to the new release, and commit the downstream module. The rule then would be "no snapshot versions in dependencies may be committed except to experimental branches". (I assume using snapshot versions for plugins would be verboten as well, especially given MNG-1911; what about snapshot versions for parent links?)
Or do you mean they never used snapshot versions even for projects or even temporarily in dependencies? If so, how do you locally test a multimodule change without running the risk of clobbering a locally cached release with your own modified version just by running mvn install on upstream? I can imagine adding a (non-snapshot) qualifier to the affected module versions derived from a branch name or JIRA/Bugzilla identifier, e.g "1.3.FOO-114", which would then have little risk of accidental confusion with an unrelated patched version.
By the way it would seem safer if Maven refused to overwrite an artifact in the local repository that had been retrieved from a remote repository (as recorded by _maven.repositories), or conversely to download even an apparently newer remote update when there was already a locally built artifact. However this would prevent you from running e.g. 'svn co http://svn.apache.org/repos/asf/maven/maven-3/tags/maven-3.0.3 . && mvn install' if you already happened to have ~/.m2/repository/org/apache/maven/maven-plugin-api/3.0.3/maven-plugin-api-3.0.3.jar for unrelated reasons. Perhaps a nonfatal warning could be issued when it looks like locally built and remotely downloaded artifacts might be colliding.
Also, is there a standard way of creating a special product build for integration testing that uses the latest committed versions of all components, especially if snapshot versions are not being used at all? What about running unit tests against the latest committed versions of the transitive dependency graph even when declared dependencies are much older? versions:use-latest-versions could I guess be run as a preparatory step for both, but it modifies the versionable pom.xml, which is unpleasant; nicer would be a special Maven flag (or -lib something?) which would replace the standard artifact resolver for the duration of a build.
A published "best practices" document on this topic would be very much appreciated, since the existing references leave this to your imagination. It would also be good if IDEs could assist developers with a standardized workflow, e.g.: https://netbeans.org/bugzilla/show_bug.cgi?id=198781
SNAPSHOTs are useful when there's a directed graph of usage: one entity is publishing, and some other entities are consuming, and they never switch places.
I think you mean that for a given artifact, SNAPSHOTs are only ever published by at most one entity, which additionally ensures that their versions are totally ordered? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
