You're not missing anything. The integration we've written essentially replaces much of the internal resolution mechanism with support on the repository side. We currently do not use SNAPSHOTs and we do use ranges for a team of 1500+ developers. It will all be open source but we're not ready to open it yet. We have made all sorts of assumptions in general but some have been shaped by the requirements of the organization we're working for. We're not exactly sure what the POMs should look like but we're moving toward having no versions anywhere in the POMs and using tooling to generated the required POMs on deployment.
At some point, likely in January, I'll try to have a little meetup in the Bay Area to try and shape some of the final requirements. Our target is making it work for our customer but our hope is that this will be a generally applicable model for continuous delivery. I'm also testing this with Facebook's Presto project which is interesting because we basically have the requirement to work with a graph of related projects and release the graph of projects at the same time. We have the additional requirement that ultimately it needs to be consumable by users from Maven Central. We certainly haven't figured everything out but we're getting there and it's been working in production for 6 months. On Dec 15, 2014, at 7:06 AM, Robert Patrick <robert.patr...@oracle.com> wrote: > Sorry for the noise and maybe I am just being stupid but... > > This is a constant source of pain for us as Maven users when we do not use > snapshots. The real problem is that once you go down his path, Maven seems > to really only have two choices when you set your dependency version to 2.5.3: > > 1.) it only matches exactly with version 2.5.3 > 2.) it matches with any version that starts with 2.5.3 and picks "the newest". > > Currently, #2 isn't possible without the use of version ranges, which are > particularly painful with a large development team where I end up downloading > the POM for every version of the artifact listed in maven-metadata.xml (in > our case, hundreds per artifact) that is not currently cached in my > .m2/repository directory. It seems like the current state of the art is to > use the versions plugin to constant update your POM's dependency versions, > which works ok but requires extra effort/discipline. Moving Maven core to > use #2 seems like it removes the ability (or at least makes it much more > difficult) to get repeatable builds. > > What am I missing? > > Robert Patrick <robert.patr...@oracle.com> > VP, FMW Platform Engineering > Oracle > Mobile: +1 469 556 9450 > Sent from my iPad > >> On Dec 15, 2014, at 12:49 AM, Kristian Rosenvold >> <kristian.rosenv...@gmail.com> wrote: >> >> I somehow think we need to decide if we want to change anything :) >> >> Without changing anything there seem to be only "so" many approaches >> out there, this is well known territory. While initially confusing, >> jetty's 9.2.3.v20140905 approach is quite good. I assume they might >> have had a failing " 9.2.3.v20140902" a few days before that we never >> got to see. It still gives the silly suffix on the name, and I think >> we might do one better. >> >> We change something in maven core, introduce a clearer separation of >> dependency-version (as-referenced version ) and artifact version: >> (Using the currently staged assembly-plugin 2.5.3 at >> https://repository.apache.org/content/repositories/maven-1103 as en >> example) >> >> The artifact is *always* called 2.5.3 in the pom version (what we all >> know as artifact-version). It's even deployed to these GAV coordinates >> in staging nexus. The signature signs a 2.5.3. version. In the vote >> mail we refer to the version as 2.5.3.v2014-12-13. >> >> Seeing this version number, maven 3.3+ writes download the artifacts >> to the folder >> >> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13 >> >> The tester tests a version named 2.5.3.v2014-12-13. If I re-roll the >> version will be 2.5.3.v2014-12-15. The payload is always version >> 2.5.3. >> >> If the 2.5.3.v2014-12-13 is broken, the stage at >> https://repository.apache.org/content/repositories/maven-1103 is >> dropped and all the testers/integrators are left with a broken >> ~/.m2/repository/org/apache/maven/plugins/maven-assembly-plugin/2.5.3.v2014-12-13 >> artifact, waiting for a replacement. >> >> Testers with pervious maven versions would have to follow the "old" rules. >> >> Does this blend ? >> >> (I have not entirely sorted out how this differs from fixing problems >> with snapshots and using numbered snapshots instead. ) >> >> Kristian >> >> >> >> Sat Dec 13 08:35:33 >> >> 2014-12-15 2:29 GMT+01:00 Jason van Zyl <ja...@takari.io>: >>> Hi, >>> >>> The discussion keeps resurfacing about how we deal with failed releases so >>> I'll summarize how I think it should ultimately be done as a starting point. >>> >>> I'll go over the cases we've encountered thus far: >>> >>> 1) The user case prefers non-disjunct sets of releases, or from our PoV >>> re-used versions. I believe people are confused by missing versions and >>> will always result in questions like "What happened to version X?", where X >>> is a non-viable build. Not many people read release notes, will not >>> self-serve and it will just be a lot of questions and confusion. The >>> typical user doesn't care about the question of whether a particular build >>> is viable or not. I think they naturally expect contiguous, increasing >>> versions when they update to new versions of a product. >>> >>> 2) The tester case prefers new versions but has tolerated re-used versions. >>> Testers for core only really have to deal with the binary distribution and >>> if it gets thrown away there's not much chance of local repository >>> inconsistency because the typical tester, who is not an integrator, isn't >>> going to depend on the new core release for anything. Running 3.2.4 doesn't >>> put anything related to 3.2.4 in your local repository. >>> >>> 3) The integrator case prefers new versions. Different content with the >>> same version is a violation of our immutability philosophy and can cause >>> issues. Even though this is very much contained at the moment let's be >>> optimistic and believe we will have many integrators that will test >>> pre-released versions. Igor is right in that it's not fun to keep track of >>> this and why should the burden be placed on the integrator. The answer is >>> it shouldn't. >>> >>> 4) The release manager case prefers new versions. I have typically reused >>> versions because I believe 1) is true. It's a PITA to erase tags, shuffle >>> issues around in JIRA, and reset the POMs. I would prefer to just move >>> forward, but I have done it because the user confusion is not worth the >>> small effort it takes me to clean up a few resources. One hour for me >>> versus thousands of hours of confusion for all users. It's an easy >>> calculation. >>> >>> Taking all these cases into consideration so that all participants are >>> satisfied I think we ultimately want increasing and contiguous versions for >>> users, testers and integrators while the release manager does not have to >>> shuffle a bunch of resources around in the event of a non-viable build. >>> What we want is a form of continuous delivery where a version like 3.2.4 is >>> the version that we call it to the outside world (some refer to it as the >>> marketing version) and the qualifier changes from build to build so we have: >>> >>> 3.2.4-qualifier >>> >>> And for simplicity's sake let's just say the qualifier is a build number so >>> we end up with: >>> >>> 3.2.4-01 >>> 3.2.4-02 >>> ... >>> 3.2.4-NN >>> >>> Every build is a complete build that can be released, and in the stream of >>> builds that are produced we decide that one is good enough for public >>> consumption. Nothing in the issue tracking or documentation needs to change >>> as it's still referred to as 3.2.4. People who download the distribution >>> aren't going to care what the exact versions say on the JARs but some >>> education might be required to tell people that something like 3.2.4 is >>> actually 3.2.4-05 if they want to refer to an artifact from 3.2.4. I don't >>> think making aliases to the marketing versions are a good idea and wouldn't >>> want to duplicate artifacts so that they can be referred to by the >>> marketing version. People will just become accustom to knowing a qualifier >>> is necessary to find the actual version. >>> >>> This is more how things work at Eclipse where if you look at something from >>> Jetty: >>> >>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.eclipse.jetty%22%20AND%20a%3A%22jetty-servlet%22 >>> >>> You'll see that something like jetty-servlet 9.2.3 is actually referred to >>> as 9.2.3.v20140905. Jetty seems somewhat inconsistent with respect to >>> milestones but you get the idea. I think this works for all parties but >>> especially users where say we all happen to write blog entries about 3.2.4 >>> and it fails twice and we actually release 3.2.6. This is just so confusing >>> as anything that referred to 3.2.4 now really means 3.2.6 which is totally >>> inconsistent. I think skipping failed versions from the users perspective >>> like we are currently doing is just a recipe for a massive amount of >>> confusion and wasted time. Moving toward a stream based approach with a >>> marketing version and qualifiers for actual versions is really the only way >>> it can work for everyone. >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> http://twitter.com/takari_io >>> --------------------------------------------------------- >>> >>> To think is easy. To act is hard. But the hardest thing in the world is to >>> act in accordance with your thinking. >>> >>> -- Johann von Goethe >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
