You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ro...@toyota.com.au on 2007/12/05 05:26:32 UTC
Buggy version range ?
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.
######################################################################
Re: Buggy version range ?
Posted by Michael McCallum <gh...@apache.org>.
On Thu, 06 Dec 2007 11:26:53 Ronn.Chinowutthichai@toyota.com.au wrote:
> That's interesting.
indeed
>
> Would this version range work [1.2,-!) i.e., to match 1.2 or anything
> later ?
don't know good guess though
>
> 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"
when you get complex depedencies it is quite often very difficult to get a
consistent set of know good artifacts in release assemblies... think
dependency depths > 7 with lots of common deps
by encasulating third party and even internal components in dependency
compositions you can easily manage links to external projects... consider
hibernate... we have a composite dependecy with version 1.X that any of our
projects using hibernate use, they have a range [1,2-)... in order to upgrade
hibernate i can release a new composite in the 1.x range and all projects
will pick it up
or i can increment the composite range to 2.x - e.g. for move from 3.1.X
hibernate to 3.2.X. - and only project where i update the range to [2,3-!)
will be affected... as a bonus its not possible to now aggregate components
that a depedent on different versions of hibernate... this leads into your
next question...
> and "makes parallel development
> possible" ?
so with composites its possible to have a portion of artifacts using a
particular version of a third party library upgraded in isolation...
for example... a new deliverable is being built but needs the latest and
greatest spring... however a bug stops it from being used for some other
deliverables
I can have two deliverables that use spring composite 1.x which is spring
2.0.7 and the new deliverable use composite 2.x which is spring 2.0.8
i only use spring and hibernate to illustrate the point as they tend to be
ubiquitous across my projects... both are very high quality ;-)
Obviously the same is true for artifacts reused across 'my own' projects. I
can have two teams working in the most recent example on different versions
of java... the 1.x versions of our libraries are java4 and the 2.x are
java6... the appropriate use of ranges will mean that no java4 aggregation
will ever accidentally pull in a java6 jar
I would recommend a little research into linux and package management... in
particular Gentoo's portage.
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Buggy version range ?
Posted by Ro...@toyota.com.au.
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 <gh...@apache.org>
12/05/2007 04:14 PM
Please respond to
"Maven Users List" <us...@maven.apache.org>
To
"Maven Users List" <us...@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 Ronn.Chinowutthichai@toyota.com.au 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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
######################################################################
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.
######################################################################
Re: Buggy version range ?
Posted by Michael McCallum <gh...@apache.org>.
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 Ronn.Chinowutthichai@toyota.com.au 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:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org