As the project manager and the one responsible for dealing with the
phone calls from irate client managers when the SaaS crashes or does bad
things to a bunch of their busy users,
I want the developers to test with the version that they built with and
run with the version that they tested.
In an SaaS environment, you don't have time to evaluate which one of
your dozens of dependencies is crashing one or more of your modules.
You have customers who are down until you either fix the problem with
your new version or roll-back and explain to the customers how they are
going to fix or replace the transactions that are incorrect.
Haphazard selection of versions does not reduce risk.
Ron
On 29/09/2012 4:01 PM, Jason van Zyl wrote:
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
---------------------------------------------------------
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
