That's interesting.
Would this version range work [1.2,-!) i.e., to match 1.2 or anything
later ?
> don't put [X.X] ranges in things that will resolve transitively.. that
gives
> NPE have not figure out why yet... i suspect broken metadata
Not sure what you mean, but when we use version range we use it all the
way (from the most common denominator libraries that are reused every
where at several levels right to the bespoke end product applications).
Here's a scenario that we have.
Three reusable artifacts that depends on each other.
* projecta <- project b (version range) <-project c (version range)
Bespoke application that may imports the above reusable artifacts
* project d may explictly declare depenencies on project a (version
range), project b (version rage) and project c (version range)!
Version range is certainly very useful but I think one can always work
around it, especially if it is buggy. Can you elaborate on what you mean
by "make complex project possible" and "makes parallel development
possible" ?
Regards,
rOnn c.
Michael McCallum <[EMAIL PROTECTED]>
12/05/2007 04:14 PM
Please respond to
"Maven Users List" <users@maven.apache.org>
To
"Maven Users List" <users@maven.apache.org>
cc
Subject
Re: Buggy version range ?
I use version ranges... make complex projects possible... makes parallel
development possible too
there are a few gotchas...
* [3,4) will match 4.0-SNAPSHOT should use [3,4-!)
* [3,4) will not match 3.0-SNAPSHOT
* don't use - any in ranges just causes trouble
make regular use of releases and where you have a breaking change
increment
the major version
don't put [X.X] ranges in things that will resolve transitively.. that
gives
NPE have not figure out why yet... i suspect broken metadata
broken metadata for external projects can be very anoyying... i wrap them
in
local projects I call composites that give the power of ranges with decent
metadata and let me use ranges for projects with funny versions that don't
work with ranges
we use eclipse with the m2eclipse plugin which works very well with ranges
using 2.0.7 and 2.0.8
we don't use modules
have over 113 artifacts
have both java4 and java6 repositories
On Wed, 05 Dec 2007 17:26:32 [EMAIL PROTECTED] wrote:
> Hi All,
>
> I'd like to get an idea if there are many people using the version range
> feature in the community. For those users using/relying version range,
do
> you find any problems with it?
>
> In our organisation, some people advocate the usage of version range but
> personally, I don't think it is robust enough for real world usage.
>
> Following problems are my main gripes that often stop me from runing
maven
> on a day to day basis.
>
> * idea plugin errors (can't resolve artifacts with obscure errors).
> * dependencies resolution errors (various obscure NPE errors).
> * release plugin errors (can't release because we do clean install first
> and it will resolve to snapshot).
> * release plugin does not crystalise the actual version that has been
> resolved in the release pom that has been tagged.
> * version range depends on maven-metadata.xml the content of the file
> which can be errorneous.
>
> This is mainly based on Maven 2.0.6, because 2.0.7 gave us more NPE on
> resolving transitive dependencies. The problem also seems to happen
with
> some projects and not others. Generally, we have about three or more
> layers of inhouse artifacts that are imported as dependencies across
> several maven modules.
>
> Like to hear any success/failure stories about this.
>
> Cheers,
> rOnn c.
> ######################################################################
> DISCLAIMER:
> This email and any attachment may contain confidential information.
> If you are not the intended recipient you are not authorized to copy
> or disclose all or any part of it without the prior written consent
> of Toyota.
>
> Opinions expressed in this email and any attachments are those of the
> sender and not necessarily the opinions of Toyota.
> Please scan this email and any attachment(s) for viruses.
> Toyota does not accept any responsibility for problems caused by
> viruses, whether it is Toyota's fault or not.
> ######################################################################
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
######################################################################
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.
Opinions expressed in this email and any attachments are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment(s) for viruses.
Toyota does not accept any responsibility for problems caused by
viruses, whether it is Toyota's fault or not.
######################################################################
