I think I forgot an "in theory"... But anyway, yes that is my point. The needs of the build are different from the needs of the runtime and the needs of the test.
Maven is about specifying the needs of the build (it is a build tool after all) and because it does testing and because it has handy plugin goals such as jetty:run it acquires some of the other needs... But in reality the Pom format is ill suited for expressing those needs. Some of the missing concepts are: 1. Identifying equivalence of artifacts. Eg javax.sevlet:servlet-api:2.5 is equivalent to org.apache.geronimo.specs:geronimo_servlet-api_2.5:1.0.0 (not actual GAV but you know the one I mean.) both of these provide the same set if class definitions, one should be able to declare in your Pom that you want to use a specific one so that the graph can be substituted. (be nice if the dependent projects could identify what they provide for you, but that is less necessary). This is like <excludes> only it effectively applies to all other dependencies rather than the one it is applied to. 2. Separation of version specification scopes (this is easier because the absence of specified scopes implies equivalence of all scopes... IOW if you only say one version then that is the version for all scopes). The idea the IVY people had some ideas in this line, but the issue i see us when you give people freedom to have as many scopes as they want and to give those scopes whatever names they want, those scopes become meaningless to consumers of your artifacts. What is one person's "runtime" is another's "test" or "run-time" or "container" or "run" or .... How do I specify that I want foo:bar's "compiling" scope transitive dependencies to be my "compile" scope and it's "mock-container-integration-test" transitive as my "test" scope? It sounds nice in theory to allow everyone infinite scopes... In practice it makes life harder for everyone... But any list of basic scopes is not going to meet everyone's needs... I think we currently need a few more... But opening the flood gates would be a retrograde step for the 95% I have other thoughts but my 2.75 yr old son now is demanding to play racing cars on my phone, so I need to hit send on this mail now ;-) On Saturday, 29 September 2012, Jason van Zyl wrote: > > On Sep 29, 2012, at 12:31 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com <javascript:;>> wrote: > > > The issue I see is that there is a difference with ranges between build > > time and run time. > > > > Bingo. And this is what confuses a lot of people especially if they come > from OSGi where the target platform against which they compile is really a > runtime notion. But I believe this is a completely flawed approach. Igor > and I have had so many conversations about this. > > > In general at build time you want the lowest version in the range > (assuming > > the api is versions correctly) to ensure you are compatible with the > > smallest set of api method signatures. > > At build time you build against _one_ version. You may want it to be the > lowest, or some other criterion, but you build against a very specific > version. No in their right might is going to let the system just resolve > any implementation from any source. Never, ever going to happen and the > conflation of these things specifically in Maven was just an oversight in > what we actually allow. I think Ralph got it mostly right in how > dependencyManagement works because in practice most of the time you want to > severely limit what gets chosen. Where the current system breaks down is > the combination of many subsystems but that's another story and if you're > dealing with one application all the time it works great. You compile > against something very specific. At runtime however you may let the system > roam somewhat in order to update without rebuilding the whole system for > performance problems, security fixes or what have you. > > Allowing ranges in the POM for compilation I believe is a mistake for the > most part. Maven conflates the compile time and runtime where compile time > is king, and OSGi conflates compile time and runtime where runtime is king. > Both have problems. A QA person cannot validate a range in practice, they > can however validate a concrete set of components and given proper > retention policies on repositories, proper management of configurations of > the various systems the result is reproducible. This things was built, I > tested this thing and it runs as expected so I'm shipping this thing which > consists of a known set of artifacts. On top of that you can reason about > what might be acceptable changes. But again in practice who is going to let > a runtime system just go grab some shit and update itself. Probably no one. > Really you find you need to make a change, you introduce a new artifact and > test it again. I really don't think anyone really allows a runtime to > update itself without strict constraints. > > There are distinct cases as well. If you're a SaaS you likely don't give a > crap and you just rebuild everything and deploy it again, or you take a > diff of the artifacts of one build to the next and send instructions to a > node and change it to mirror the new version, or use a git repo and just > update it. The case of Eclipse is different in that you want people to be > able to update to newer versions. But we build m2e with very specific > versions of bundles and then use ranges so that people with existing > installations and use new things. But the Eclipse repository for a release > is extremely constrained from version to version. Everyone builds against > the same thing building up to a release and we put ranges in manifests so > people can update, but compile time is for the most part very specific. > > At any rate, I believe the specification of what you compile with versus > what you may potentially want to run with should be separated. Maven and > OSGi get this wrong from my perspective. And it seems to me in the wild > more people do OSGi with Maven so this muddies the water even further (the > maven-bundle-plugin is the most used plugin outside of the core maven > plugins). > > > > > At run time you want the highest as it has the most big fixes in theory. > > Right, in theory you would like to leave the runtime intact for as long as > possible absorbing changes without rebuilding if possible. But I'm not sure > this is really done. At the most advanced development shops I've been in > there are radical simplifications like just rebuild and redeploy the whole > thing because Maven, along with everything else can result in problems > primarily from configuration differences, retention policies on > repositories but it's enough to cause problems that prevent predictable > re-deploys. So they rebuild and redeploy the whole thing. > > > > > At test time you ideally want every version. But that matrixes out to an > > impossible combinatorial. > > I think you create them when necessary and they are specific and you test > that and validate it. No one in practice tests all combinations as it's > likely many of them are not used so why expend the resources to try them. > > > > > On Saturday, 29 September 2012, Hervé BOUTEMY wrote: > > > >> Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : > >>> I thought about mathematical ranges as well, and the outcome for me > >>> personally that a strict mathematical time vector interpretation makes > no > >>> sense for maven. > >>> > >>> > >>> You have a library in version 1.7.0 which fits your project. > >>> > >>> Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary > >>> incompatible change. > >>> > >>> But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. > >>> > >>> Also: for most dependencies you only like to get released versions via > >> your > >>> version range. But as I read here some use this internally as well and > >> like > >>> to get SNAPSHOTS resolved. > >> a range tells about a constraint > >> then choosing a precise version between the multiple choices that match > >> constraints is not about the range but about what is usually called > >> "conflict > >> resolution" > >> This term is ok when it's about changing preferred version (ie when > >> versions > >> are not defined as range but as simple version, which means preferred > >> version) > >> but that term doesn't show that when it's about ranges, it's not about > >> conflict > >> but about choosing one version between the multiple valid choices: do > you > >> prefer the most recent? even if it is a snapshot or an alpha? or if the > >> most > >> recent is an alpha, you prefer to stick with stable version? > >> IMHO, during development, you can want to test latest alpha SNAPSHOT, > but > >> when > >> doing a release, you'll prefer stable versions > >> > >>> > >>> What about simply writing up what people like to have and then > implement > >> a > >>> new mechanism? I could even think about regexp based versioning... > >> sure, there is something to create here, but IMHO not into version > ranges: > >> into conflict resolution specification and switch (with CLI or IDE) > >> > >>> > >>> LieGrue, > >>> strub > >>> > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> > >>>> From: Hervé BOUTEMY <herve.bout...@free.fr> > >>>> To: Maven Users List <users@maven.apache.org> > >>>> Cc: > >>>> Sent: Saturday, September 29, 2012 5:06 AM > >>>> Subject: Re: Version ranges not working > >>>> > >>>> yes, https://jira.codehaus.org/browse/MNG-3092 is still here > >>>> > >>>> I'm not comfortable with the idea of excluding SNAPSHOT from ranges: > >> if we > >>>> do > >>>> so, it's not a *range* any more but a range + a filter > >>>> (1.7.1-SNAPSHOT is in [1.7,1.8] range,"in plain english") > >>>> > >>>> and actual discussion helps me dig into other ideas that could be > >> useful: > >>>> IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but > >> alphas > >>>> and beta too, no? > >>>> But I'm not sure about the use case (and "Guide to using version > >>>> ranges" still > >>>> needs to be written: https://jira.codehaus.org/browse/MNG-1368) > >>>> I understand that when a library is at 1.9 and someone needs old 1.8-, > >> he > >>>> implictely wants releases, not alpha nor SNAPSHOTS > >>>> But if 1.8 is still not out, and there is still work on 1.7.x, we need > >> to > >>>> accept *latest* 1.7.x whatever its maturity level is > >>>> > >>>> > >>>> Really , excluding version from a mathematical range is another > >> operation > >>>> that needs some specification and probably something more expressive > >> than > >>>> [min,max] > >>>> > >>>> Regards, > >>>> > >>>> Hervé > >>>> > >>>> Le vendredi 28 septeThanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > > > > > >
