On Thu, Aug 25, 2011 at 8:59 AM, Jesse Glick <jesse.gl...@oracle.com> wrote: > 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 is a very simple environment, but I think not too unusual. This body of code consists of a few closely-coupled modules. It does have 'upstream' dependencies, but there's no reason to use snapshots of those, since the goal is to develop against a release. So, each dev gets the tree and builds and tests, self-contained. The version convention is that X.Y.Z.100 is the first 'dev version' after X.Y.Z.P, and at release time it switches to X.Y.Z+1.0. If we want to do internal releases to test release process or for other people to consume, we'd increment 100 to 101, etc. The code is small enough that an integration test set in Jenkins could just build it locally and get it from the local repo. If it got a little bigger, and we really wanted one Jenkins job to build it and others to consume it, we could force maven to download releases. At the same time that this group has been using this scheme, I've been maintaining another group of projects using snapshots and the release plugin, and, honestly, it's a pain. I spend a lot of time running the versions plugin and the release plugin. Once again, there's no interesting 'upstream-downstream' relationship. Upstream are very stable things, and inside this group of projects, multiple people work on multiple pieces, so there's no natural flow of published snapshots. Rather than test upstream snapshots routinely, I'm happy to expect 'upstream' to make internal releases when they have something stable enough for us to test. Then we know exactly what we're using. The bottom line here is that I'm developing a suspicion that snapshots are applicable to a very specific set of use-cases, and the tendency for everyone to use them all the time is not always productive. I will now go away until I can write this up with bells on. 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
