On Sep 29, 2012, at 12:31 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> 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 septembre 2012 08:07:21 David Hoffer a écrit : >>>>> I find this topic interesting for a couple of reasons. I was one of >> the >>>>> original posters of this topic and created some of the relevant JIRA >>>>> issues >>>>> regarding it. >>>>> >>>>> However one of the problems is that since this issue was never >>>>> fixed...and >>>>> sadly seems never will be...we had to abandon the use of version >>>>> ranges. I >>>>> do not agree they are a bad idea. I think they could have been a >> very >>>>> useful feature if implemented as originally proposed. >>>>> >>>>> (The fundamental problem was that they did not exclude SNAPSHOTS as >>>>> >>>>> originally intended/stated.) >>>>> >>>>> Effectively we had to work around the lack of version ranges by just >>>>> building against SNAPSHOTS instead (I'm talking about internal code >>>> >>>> here). >>>> >>>>> So effectively the SNAPSHOT became our version range. One of the >>>>> problems>> >>>>> of this approach is now I have to toggle between going >> offline/online if >>>>> I >>>>> don't want to accept new updates since it will be changing on a >> regular >>>>> basis. Using version ranges would have been a more elegant solution >> as >>>>> it >>>>> would give me more control over what versions I depend on during >>>>> development. >>>>> >>>>> Because it wasn't fixed and we had to do the workaround I have not >> been >>>>> close to this issue anymore...its been like 5 years or more. But the >>>>> short >>>>> answer is it should be fixed and it can/could be useful as some have >>>>> indicated in this discussion. >>>>> >>>>> -Dave >>>>> >>>>> On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler >>>> >>>> <rwhee...@artifact-software.com >>>> >>>>>> wrote: >>>>>> >>>>>> On 28/09/2012 3:17 AM, Jesse Long wrote: >>>>>>> Without version ranges, how do I write a library that works with >>>> >>>> SLF4J >>>> >>>>>>> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
