Re: Version ranges not working

[Paul French]

It is clear version ranges are used by some people and they do find them 
useful including me. You cannot predict how and in what circumstances 
specific features of maven will be used by the many people out there, 
good or bad in your opinion.


I still would prefer making version range calculations pluggable where a 
default is supplied (the current). I can then create my own plugin which 
overrides the default and specify it my POM. For example I would 
probably use semantic versioning on artifacts in specific groups which I 
specify and use specific versions for others. Who knows? The fact of the 
matter is I can do what I like and the build will be repeatable (in 
terms of the version range calculation).


Currently when we release an artifact or product we have created a 
release plugin which creates an effective POM listing all versions used, 
including the transistive ones. Hence our release builds are repeatable. 
We can go back in time, branch and fix.


The biggest pain we have is the speed of the dependency calculation when 
developing. I'm sure this can be optimized.



On 01/10/2012 07:22, Hervé BOUTEMY wrote:

Le lundi 1 octobre 2012 02:31:44 Jesse Long a écrit :

I have created a ticket - http://jira.codehaus.org/browse/MNG-5353

thank you
I changed it from "Bug" to "Wish": no, nobody ever asked for such a behaviour,
it's really a new idea AFAIK
which BTW seems a good enhancement IMHO

now we need to check with people using ranges that it is ok for them: if
anybody can think of a problem, please share

Regards,

Hervé

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version ranges not working

[Paul French]

yes and no, depends

We have a lot of developers and a lot of OSGi bundles. The public API of 
each bundle is specified in the manifest. We use API analysis to compare 
the latest code of the artifact with the last released version of that 
artifact. So the version of the updated bundle is specified by api 
analysis. As long as we have not broken backwards compatibility the 
version goes up just a micro version. If the bundle's api is tested and 
passes all its unit tests then it is released. All developers will get 
the updated bundle without doing anything. If we have to break backwards 
compatibilty then we go up a major version. No one will get this change 
unless they want it by updating their version range in their POM. This 
is good since the developer knows there is API changes and it is very 
likely they will need to make changes in their code in how they use the 
new API.


We do this in our sprint phases i.e. lots of developer activity working 
on many different areas of many different products, no one needs to 
touch their POM unless we agree to a major change (we avoid major 
changes if possible)


When we create a release candidate of a particular product we generate 
an effective POM where all exact versions of all artifacts are 
specified. So yes we now use exact versions. We branch this single 
effective POM to do release fixes and are happy to manually update the 
POM since we expect the changes to be small.


Hence we can re-produce our releases anytime later.

I agree in general version ranges can cause problems. But in some 
circumstances they can be useful.


On 28/09/2012 00:20, Baptiste MATHUS wrote:

+1.
Version ranges are basically just a bad practice in my experience. I mostly
don't see any interest apart from being able to see a normally passing
build suddenly going rogue because you somehow had a dependency update
somewhere in the dependency tree. (I wrote something similar in that
comment
http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
)

So, please, Maven users, don't use them. It's like having scripts inside
your pom.xml, it might seem sexy and powerful, but it's dangerous.
Nail down a version, and upgrade explicitly when you need to and/or are
ready to. You'll be very happy that way and your build'll stay green.

Cheers

2012/9/28 Stephen Connolly 


Well that is a recipe for disaster. rules only make sense within the scope
of the artifacts they apply to.

This is kind of why version ranges are next to useless from a practical PoV
anyway

On 27 September 2012 23:05, Paul French  wrote:


I would only want the same version rules applied to all artifacts, not on
a per artifact basis, that would be a nightmare! I understand that people
who produce artifacts have their own versioning rules. However we can

take

that into account in our version ranging.

Usually for 3rd party artifacts we have a very narrow version range since
we cannot trust the producer of that artifact not to break their current
API in later versions unless they support semantic versioning.


On 27/09/2012 22:29, Stephen Connolly wrote:


when is that class applied?

each dependency would have its own comparator, as each dependency has

its

own versioning rules.

and then don't start on epoch's (i.e. where the versioning rules change
from under your feet mid sequence

It's tempting... but dangerous... the closest I have come up with is the
rulesets hack from versions-maven-plugin @ mojo... but even that has
issues... hence why I haven't pushed it further.

-Stephen

On 27 September 2012 22:19, Paul French  wrote:

  Okay I see the problem.

How about allowing a user to plugin a Version class that implements
Comparator

class MavenVersion implements Comparable
{
  public int compareTo(MavenVersion o)
  {
// your implementation
  }
}

Then we can all do whatever we need.


On 27/09/2012 21:40, Hervé BOUTEMY wrote:

  I understand that many people get caught

But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?

The actual semantic is pure mathematical range, including or excluding
an
extreme

since 1.8-alpha<1.8-beta-<1.8-rc<1.8-SNAPSHOT<1.8, it's pure math

IMHO, anything that doesn't conform mathematical range will have some
unexpected behaviour sometime

Yes, people need to learn that they usually want
[1.7,1.8-alpha-SNAPSHOT)
if
they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
Or we need to create another notation and define its semantics

precisely

Regards,

Hervé

Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :

  +1

I agree with Jesse.

A version range like [1.7,1.8) should exclude any artifact that

starts

with 1.8

Then maven (or aether) would respect semantic versioning rules.

We use version ranges/semantic versioning and API analysis to ensure
our
artifacts are versioned correctly. Sometimes we

Re: Version ranges not working

[Paul French]

I have to disagree. Version ranges are very useful to us especially with 
artifacts we control where we use semantic versioning and api analysis 
to enforce this.


Artifacts we don't control the versioning of e.g SLF4J we nail down the 
version we use.


Our product POM's can have 100's of version ranged artifacts

If we could plugin a version range class into maven (maven would ship 
with a version range class with the rules it uses now), at least I would 
then have a choice to replace it with an implementation I'm happier with.


Anyway it works for us as it is now, so I'm not going to lose any sleep 
over it.


Cheers

On 27/09/2012 23:36, Stephen Connolly wrote:

Well that is a recipe for disaster. rules only make sense within the scope
of the artifacts they apply to.

This is kind of why version ranges are next to useless from a practical PoV
anyway

On 27 September 2012 23:05, Paul French  wrote:


I would only want the same version rules applied to all artifacts, not on
a per artifact basis, that would be a nightmare! I understand that people
who produce artifacts have their own versioning rules. However we can take
that into account in our version ranging.

Usually for 3rd party artifacts we have a very narrow version range since
we cannot trust the producer of that artifact not to break their current
API in later versions unless they support semantic versioning.


On 27/09/2012 22:29, Stephen Connolly wrote:


when is that class applied?

each dependency would have its own comparator, as each dependency has its
own versioning rules.

and then don't start on epoch's (i.e. where the versioning rules change
from under your feet mid sequence

It's tempting... but dangerous... the closest I have come up with is the
rulesets hack from versions-maven-plugin @ mojo... but even that has
issues... hence why I haven't pushed it further.

-Stephen

On 27 September 2012 22:19, Paul French  wrote:

  Okay I see the problem.

How about allowing a user to plugin a Version class that implements
Comparator

class MavenVersion implements Comparable
{
  public int compareTo(MavenVersion o)
  {
// your implementation
  }
}

Then we can all do whatever we need.


On 27/09/2012 21:40, Hervé BOUTEMY wrote:

  I understand that many people get caught

But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?

The actual semantic is pure mathematical range, including or excluding
an
extreme

since 1.8-alpha<1.8-beta-<1.8-rc<1.8-SNAPSHOT<1.8, it's pure math

IMHO, anything that doesn't conform mathematical range will have some
unexpected behaviour sometime

Yes, people need to learn that they usually want
[1.7,1.8-alpha-SNAPSHOT)
if
they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
Or we need to create another notation and define its semantics precisely

Regards,

Hervé

Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :

  +1

I agree with Jesse.

A version range like [1.7,1.8) should exclude any artifact that starts
with 1.8

Then maven (or aether) would respect semantic versioning rules.

We use version ranges/semantic versioning and API analysis to ensure
our
artifacts are versioned correctly. Sometimes we get caught out by what
Jesse outlined below.

On 27/09/2012 15:51, Stephen Connolly wrote:

  On 27 September 2012 14:41, Jesse Long  wrote:

  Dear Maven Community,

I am writing to beg you to fix the problems with the version ranges
in
Maven 3.0.5, specifically regarding the defining compatible version
ranges.

I am using Maven 3.0.4. I have a simple project that depends on
org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
[1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I
define
the
version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then
slf4j-api
version 1.6.0-alpha2 is linked in.

Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then
the
correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
released it would probably break again.

This is all too counter-intuitive. The current version of SLF4J is
1.7.1.
If my project was to be built against it, knowing that there is a
likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
does
not adhere to SemVer), I would like to define my version range for
slf4j-api as [1.7.0,1.8.0). I

  I think you do [1.7.0,1.8.0-!)

but that might just include 1.8.0-SNAPSHOT

   have no way of knowing before the time what type of -RC0, -alpha2


qualified releases will be made for 1.8.0, so I can only exclude
1.8.0.

However, when 1.8.0-alpha2 is released with incompatible changes, my
build
will immediately be broken.

I could depend on version 1.5.11 directly, without using a version
range,
but Maven considers this a soft version dependency and will ignore it
as
needed.

It is apparent that there is no reli

Re: Version ranges not working

[Paul French]

I would only want the same version rules applied to all artifacts, not 
on a per artifact basis, that would be a nightmare! I understand that 
people who produce artifacts have their own versioning rules. However we 
can take that into account in our version ranging.


Usually for 3rd party artifacts we have a very narrow version range 
since we cannot trust the producer of that artifact not to break their 
current API in later versions unless they support semantic versioning.


On 27/09/2012 22:29, Stephen Connolly wrote:

when is that class applied?

each dependency would have its own comparator, as each dependency has its
own versioning rules.

and then don't start on epoch's (i.e. where the versioning rules change
from under your feet mid sequence

It's tempting... but dangerous... the closest I have come up with is the
rulesets hack from versions-maven-plugin @ mojo... but even that has
issues... hence why I haven't pushed it further.

-Stephen

On 27 September 2012 22:19, Paul French  wrote:


Okay I see the problem.

How about allowing a user to plugin a Version class that implements
Comparator

   class MavenVersion implements Comparable
   {
 public int compareTo(MavenVersion o)
 {
   // your implementation
 }
   }

Then we can all do whatever we need.


On 27/09/2012 21:40, Hervé BOUTEMY wrote:


I understand that many people get caught

But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?

The actual semantic is pure mathematical range, including or excluding an
extreme

since 1.8-alpha<1.8-beta-<1.8-rc<1.**8-SNAPSHOT<1.8, it's pure math
IMHO, anything that doesn't conform mathematical range will have some
unexpected behaviour sometime

Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT)
if
they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
Or we need to create another notation and define its semantics precisely

Regards,

Hervé

Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :


+1

I agree with Jesse.

A version range like [1.7,1.8) should exclude any artifact that starts
with 1.8

Then maven (or aether) would respect semantic versioning rules.

We use version ranges/semantic versioning and API analysis to ensure our
artifacts are versioned correctly. Sometimes we get caught out by what
Jesse outlined below.

On 27/09/2012 15:51, Stephen Connolly wrote:


On 27 September 2012 14:41, Jesse Long  wrote:


Dear Maven Community,

I am writing to beg you to fix the problems with the version ranges in
Maven 3.0.5, specifically regarding the defining compatible version
ranges.

I am using Maven 3.0.4. I have a simple project that depends on
org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
[1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
the
version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
version 1.6.0-alpha2 is linked in.

Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
released it would probably break again.

This is all too counter-intuitive. The current version of SLF4J is
1.7.1.
If my project was to be built against it, knowing that there is a
likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
does
not adhere to SemVer), I would like to define my version range for
slf4j-api as [1.7.0,1.8.0). I


I think you do [1.7.0,1.8.0-!)

but that might just include 1.8.0-SNAPSHOT

  have no way of knowing before the time what type of -RC0, -alpha2

qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.

However, when 1.8.0-alpha2 is released with incompatible changes, my
build
will immediately be broken.

I could depend on version 1.5.11 directly, without using a version
range,
but Maven considers this a soft version dependency and will ignore it
as
needed.

It is apparent that there is no reliable way to define a compatibility
range in Maven. I feel that this should be a major concern to all Maven
users and developers.

It would be a shame for all the effort made by the Maven community to
make
software builds stable and reproducible to be undermined by consistent,
predictable breakage described above.

I have read in mailing list archives that the suggested way of
excluding
all 1.8.0 pre-release version is to define an exclusive upper bound as
1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above
with
1.6.0-RC0, this does not work. Also, it makes no sense at all for a
user
to
wish to include 1.8.0-SNAPSHOT and not 1.8.0.

My proposal is that the qualifier is ignored when comparing a version
to
the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
considered to fall outside of the version range. Importantly, it should
only be for th

Re: Version ranges not working

[Paul French]

Okay I see the problem.

How about allowing a user to plugin a Version class that implements 
Comparator


  class MavenVersion implements Comparable
  {
public int compareTo(MavenVersion o)
{
  // your implementation
}
  }

Then we can all do whatever we need.

On 27/09/2012 21:40, Hervé BOUTEMY wrote:

I understand that many people get caught

But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?

The actual semantic is pure mathematical range, including or excluding an
extreme

since 1.8-alpha<1.8-beta-<1.8-rc<1.8-SNAPSHOT<1.8, it's pure math
IMHO, anything that doesn't conform mathematical range will have some
unexpected behaviour sometime

Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT) if
they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999]
Or we need to create another notation and define its semantics precisely

Regards,

Hervé

Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit :

+1

I agree with Jesse.

A version range like [1.7,1.8) should exclude any artifact that starts
with 1.8

Then maven (or aether) would respect semantic versioning rules.

We use version ranges/semantic versioning and API analysis to ensure our
artifacts are versioned correctly. Sometimes we get caught out by what
Jesse outlined below.

On 27/09/2012 15:51, Stephen Connolly wrote:

On 27 September 2012 14:41, Jesse Long  wrote:

Dear Maven Community,

I am writing to beg you to fix the problems with the version ranges in
Maven 3.0.5, specifically regarding the defining compatible version
ranges.

I am using Maven 3.0.4. I have a simple project that depends on
org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
[1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define
the
version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
version 1.6.0-alpha2 is linked in.

Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
released it would probably break again.

This is all too counter-intuitive. The current version of SLF4J is 1.7.1.
If my project was to be built against it, knowing that there is a
likelihood of an incompatible change being introduced in 1.8.0 (SLF4J
does
not adhere to SemVer), I would like to define my version range for
slf4j-api as [1.7.0,1.8.0). I

I think you do [1.7.0,1.8.0-!)

but that might just include 1.8.0-SNAPSHOT


have no way of knowing before the time what type of -RC0, -alpha2
qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.

However, when 1.8.0-alpha2 is released with incompatible changes, my
build
will immediately be broken.

I could depend on version 1.5.11 directly, without using a version range,
but Maven considers this a soft version dependency and will ignore it as
needed.

It is apparent that there is no reliable way to define a compatibility
range in Maven. I feel that this should be a major concern to all Maven
users and developers.

It would be a shame for all the effort made by the Maven community to
make
software builds stable and reproducible to be undermined by consistent,
predictable breakage described above.

I have read in mailing list archives that the suggested way of excluding
all 1.8.0 pre-release version is to define an exclusive upper bound as
1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
1.6.0-RC0, this does not work. Also, it makes no sense at all for a user
to
wish to include 1.8.0-SNAPSHOT and not 1.8.0.

My proposal is that the qualifier is ignored when comparing a version to
the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
considered to fall outside of the version range. Importantly, it should
only be for the special case of comparing to the version number in an
exclusive upper bound.

If the powers that be see fit, an exception could be made for service
pack
qualifiers, which according to one web page on Maven version ordering I
read, should be sorted after the release, although I would prefer to see
Maven more closely aligned to SemVer, where all qualified version numbers
are considered pre-release versions. I consider 1.7.2 a better version
number than 1.7.1-sp1.

Ultimately, I would like to be able to make things as easy as possible
for
users depending on a library that adheres to SemVer, to define a
compatibility range like: [1.4.0,2.0.0). I see no reason why it should
not
be as easy as that.

Please consider fixing this soon.

I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
signup link on this page displays an error:
http://maven.apache.org/users/
**getting-help.html <http://maven.apache.org/users/getting-help.html>

Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
but the ini

Re: Version ranges not working

[Paul French]

+1

I agree with Jesse.

A version range like [1.7,1.8) should exclude any artifact that starts 
with 1.8


Then maven (or aether) would respect semantic versioning rules.

We use version ranges/semantic versioning and API analysis to ensure our 
artifacts are versioned correctly. Sometimes we get caught out by what 
Jesse outlined below.



On 27/09/2012 15:51, Stephen Connolly wrote:

On 27 September 2012 14:41, Jesse Long  wrote:


Dear Maven Community,

I am writing to beg you to fix the problems with the version ranges in
Maven 3.0.5, specifically regarding the defining compatible version ranges.

I am using Maven 3.0.4. I have a simple project that depends on
org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as
[1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define the
version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version
1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api
version 1.6.0-alpha2 is linked in.

Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the
correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was
released it would probably break again.

This is all too counter-intuitive. The current version of SLF4J is 1.7.1.
If my project was to be built against it, knowing that there is a
likelihood of an incompatible change being introduced in 1.8.0 (SLF4J does
not adhere to SemVer), I would like to define my version range for
slf4j-api as [1.7.0,1.8.0). I


I think you do [1.7.0,1.8.0-!)

but that might just include 1.8.0-SNAPSHOT



have no way of knowing before the time what type of -RC0, -alpha2
qualified releases will be made for 1.8.0, so I can only exclude 1.8.0.

However, when 1.8.0-alpha2 is released with incompatible changes, my build
will immediately be broken.

I could depend on version 1.5.11 directly, without using a version range,
but Maven considers this a soft version dependency and will ignore it as
needed.

It is apparent that there is no reliable way to define a compatibility
range in Maven. I feel that this should be a major concern to all Maven
users and developers.

It would be a shame for all the effort made by the Maven community to make
software builds stable and reproducible to be undermined by consistent,
predictable breakage described above.

I have read in mailing list archives that the suggested way of excluding
all 1.8.0 pre-release version is to define an exclusive upper bound as
1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with
1.6.0-RC0, this does not work. Also, it makes no sense at all for a user to
wish to include 1.8.0-SNAPSHOT and not 1.8.0.

My proposal is that the qualifier is ignored when comparing a version to
the version number declared in an exclusive upper bound. ie. 1.6.0-xyz
should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore
considered to fall outside of the version range. Importantly, it should
only be for the special case of comparing to the version number in an
exclusive upper bound.

If the powers that be see fit, an exception could be made for service pack
qualifiers, which according to one web page on Maven version ordering I
read, should be sorted after the release, although I would prefer to see
Maven more closely aligned to SemVer, where all qualified version numbers
are considered pre-release versions. I consider 1.7.2 a better version
number than 1.7.1-sp1.

Ultimately, I would like to be able to make things as easy as possible for
users depending on a library that adheres to SemVer, to define a
compatibility range like: [1.4.0,2.0.0). I see no reason why it should not
be as easy as that.

Please consider fixing this soon.

I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The
signup link on this page displays an error: http://maven.apache.org/users/
**getting-help.html 

Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
but the initial report is for a similar issue, not this issue. The issue I
describe above is reported and discussed in the comments for MNG-3092
though.

Thanks,
Jesse

--**--**-
To unsubscribe, e-mail: 
users-unsubscribe@maven.**apache.org
For additional commands, e-mail: users-h...@maven.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Error in deploying war file

[Paul French]

Yes go to Spring forums. But I thought Spring MVC  3 requires Spring 
core 3  and there was artifact name change from spring 2 to 3


You could try removing the maven reference to spring core and see what 
gets pulled in by spring mvc 3


*Paul French
Technical Lead/Research & Development
* Kirona Solutions Ltd
Tel: 01625 585511
E-Mail: paul.fre...@kirona.com
Web: www.kirona.com <http://www.kirona.com>

This email and any attachments are confidential and should only be read 
by those to whom they are addressed. If you are not the intended 
recipient, please contact us on 01625 585511, delete the email 
(including any attachment) from your computer and destroy any copies. 
Any distribution or copying without our prior permission is prohibited. 
Internet communications are not always secure and may be subject to 
delays, non-delivery and unauthorised alterations. Therefore, 
information expressed in this message is not given or endorsed by Kirona 
Solutions Limited ("Kirona") unless otherwise notified by our duly 
authorised representative independent of this message. No warranty is 
given that this email (including any attachment) is virus free. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those of Kirona.


Registered addresses: Kirona Solutions Limited, Barrington House, Heyes 
Lane, Alderley Edge, Cheshire. SK9 7LA Registered in England and Wales 
No: 04678711


On 01/08/2012 13:38, Wayne Fay wrote:

Aug 1, 2012 11:42:06 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring FrameworkServlet 'dispatch'
Aug 1, 2012 11:42:06 AM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NoSuchFieldError: APPLICATION_CONTEXT_ID_PREFIX
 at
org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:430)

Ignore everything else. This is your problem. Take this problem to the
Spring people and ask them to help you solve it.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Offline is broken - _maven.repositories

[Paul French]

Any idea what version of the aether libraries (1.12 or 1.13) will be 
used in 3.0.4 and a guess on when 3.0.4 will be released?


We are using 3.0.3 with aether 1.13 libraries. It works really well 
except maven crashes out when there is version conflicts in your POM.


Depending on your answer I would to test the latest 3.0.4 snapshot and 
see if this issue goes away.


On 14/10/2011 12:15, Mark Derricutt wrote:

This can be "fixed" by upgrading the aether libraries inside your maven release.

Hopefully the 3.0.4 release will be out soon that includes these.  The updated 
aether version has significant fixes, among which are fixes that solve the 
problems around artifacts not being found in the local repo.

Mark

On 14/10/2011, at 11:50 AM, Paul Grove wrote:


Can I have the hour of my life I just wasted trying to get Maven 3 working
offline? Even with -o Maven kept complaining about dependency not in local
repository we basically it was. After an hour of wasted time I discovered my
local repository full of files named _maven.repositories after deleting all
these files Maven then worked offline just fine. theirs me thinking offline
means offline, I missed my kids bedtime because of this. Another reason
gradle will be getting a closer look from me.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [m2e-users] maven 3.0.3 - performance with version ranges

[Paul French]

wow!

Dropped in aether 1.13 into apache maven lib/ext (so patched applied 
external to eclipse) and also updated the m2e embedded runtime plugin 
org.eclipse.m2e.maven.runtime_1.0.1.201106291304  (as a quick test) and 
now as an example a build that took 1 minute 43 secs now only takes 5 
seconds.


Will build our own embedded runtime as instructed below now.

Thanks for everyone's help.

Any ideas when an official maven 3.0.4 release will happen as well as an 
official maven 3.0.4 embedded runtime m2e connector ?


Paul French
Kirona Solutions Ltd
Tel: 07803 122 058
E-Mail: paul.fre...@kirona.com
Web: www.kirona.com <http://www.kirona.com>

This email and any attachments are confidential and should only be read 
by those to whom they are addressed. If you are not the intended 
recipient, please contact us on 01625 585511, delete the email 
(including any attachment) from your computer and destroy any copies. 
Any distribution or copying without our prior permission is prohibited. 
Internet communications are not always secure and may be subject to 
delays, non-delivery and unauthorised alterations. Therefore, 
information expressed in this message is not given or endorsed by Kirona 
Solutions Limited ("Kirona") unless otherwise notified by our duly 
authorised representative independent of this message. No warranty is 
given that this email (including any attachment) is virus free. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those of Kirona.


Registered addresses: Kirona Solutions Limited, Barrington House, Heyes 
Lane, Alderley Edge, Cheshire. SK9 7LA Registered in England and Wales 
No: 04678711



On 30/09/2011 12:28, Igor Fedorenko wrote:

I do not know if the underlying problem has been solved with aether
and/or maven. You need to talk to aether and/or maven developers to find
out.

As far updating m2e embedded maven runtime, it is relatively easy now --
setup development environment as explain in [1], then change
m2e-maven-runtime/org.eclipse.m2e.maven.runtime/pom.xml to use whatever
version of dependencies you want to try.

[1] http://wiki.eclipse.org/M2E_Development_Environment

--
Regards,
Igor

On 11-09-30 6:22 AM, Paul French wrote:

maven 3.0.3 has terrible performance and memory usage when using version
ranges. This has a knock on effect using m2e

It takes maven ages to update the maven dependencies.

I have a main project with a some version ranged dependencies which in
turn have versioned ranged dependencies. Outside of eclipse it takes
many minutes and considerable memory to get a successful build. Most
time is spent resolving the dependencies.

I have also run maven offline when I know I have all dependencies in my
local repo and it is still very, very slow.

In m2e (and workspace resolution on), you can check out a dependency
that is very simple and this triggers a re-build of the main project.
The same happens when you delete the dependent project or make pom
version changes to it. So in eclipse this becomes really tedious
especially if you have 4 or 5 related projects checked out. You end up
sitting and waiting for your workspace to be re-built all the time.

I understand what maven is doing but I do believe it could be done a lot
better when resolving version ranges.

I also know maven 3.0.3 uses aether 1.11 to so its dependency 
management.


I'm really keen to try and find a solution. aether 1.12 has been
released. Is there anyway I can hook this into maven 3.0.3

Does aether 1.12 solve

Is there a pre-release of maven 3.0.4 out there yet that I can try and
does it use aether 1.12 ?

Thanks
Paul

___
m2e-users mailing list
m2e-us...@eclipse.org
https://dev.eclipse.org/mailman/listinfo/m2e-users

___
m2e-users mailing list
m2e-us...@eclipse.org
https://dev.eclipse.org/mailman/listinfo/m2e-users

maven 3.0.3 - performance with version ranges

[Paul French]

maven 3.0.3 has terrible performance and memory usage when using version 
ranges. This has a knock on effect using m2e


It takes maven ages to update the maven dependencies.

I have a main project with a some version ranged dependencies which in 
turn have versioned ranged dependencies. Outside of eclipse it takes 
many minutes and considerable memory to get a successful build. Most 
time is spent resolving the dependencies.


I have also run maven offline when I know I have all dependencies in my 
local repo and it is still very, very slow.


In m2e (and workspace resolution on), you can check out a dependency 
that is very simple and this triggers a re-build of the main project. 
The same happens when you delete the dependent project or make pom 
version changes to it. So in eclipse this becomes really tedious 
especially if you have 4 or 5 related projects checked out. You end up 
sitting and waiting for your workspace to be re-built all the time.


I understand what maven is doing but I do believe it could be done a lot 
better when resolving version ranges.


I also know maven 3.0.3 uses aether 1.11 to so its dependency management.

I'm really keen to try and find a solution. aether 1.12 has been 
released. Is there anyway I can hook this into maven 3.0.3


Does aether 1.12 solve

Is there a pre-release of maven 3.0.4 out there yet that I can try and 
does it use aether 1.12 ?


Thanks
Paul


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven metadata files downloaded over and over again (3.0.3)

[Paul French]

Thanks Mark for the reply. I will take a look when my boss is not looking.

Do you know if I can I get my current maven install 3.0.3 to use the 
later version of aether 1.12 instead of 1.11 ?


I've googled and cannot find an approximate release date for 3.0.4, any 
ideas? Plus I've seen some posts, which you have also contributed where 
it is not clear if 3.0.4 will or want include 1.12


Again can you clear this one up for me?

Thanks again.
P
On 28/09/2011 10:49, Mark Derricutt wrote:

I've not looked at the dependency resolution code ( which I believe is mostly, 
if not all now contained in the eclipse aether project ), but I've heard its 
one of the darker, more mysterious and complex parts of the codebase, that not 
enough many people understand - I could be wrong here tho.

I recent release of Aether which should be included in maven 3.0.4 when it gets 
release improves and fixes some recent issues that I'e been seeing with 
resolutions so that might be a good place to look at.

Mark



On 28/09/2011, at 10:10 PM, Paul French wrote:


Is the dependency management code easy to understand? I'm happy to get my hands 
dirty.




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven metadata files downloaded over and over again (3.0.3)

[Paul French]

Yes we use version ranges in our poms.

The only problem we have is speed and memory.

Everytime a build of a project is kicked off from the command line or 
within eclipse maven downloads the meta data files for each dependent 
and transitive dependencies. You can understand this since maven needs 
to check for later versions within the ranges specified. You can stop 
the downloads by running in offline mode which can help a bit.


However we've noticed maven downloads the same meta data file 39 times 
in one maven build. It seems that maven does not cache these during a 
build and if a pom specifies 10 artifacts and each of these artifacts 
depends on artifact X then the meta data file for artifact X is 
downloaded 10 times instead of just once. In offline mode the build 
still takes a long time and we need memory settings of at least 
-Xmx1000m to get a successful build so I suspect the local repo meta 
data files are also being loaded over and over again as well.


We tried to use snapshots originally but had to abandon them since maven 
3.0.3 does not support maintaining a single snaphot, it creates a new 
snapshot each time, meaning you end up with many snaphot versions which 
played havoc when using version ranges. Builds would fall over with out 
of memory even when given as much as memory as possible on our dev 
machines. So we maintained versioned artifacts ourselves. However as the 
number of versions increases for a specific artifact the builds seem to 
be getting exponentially slower.


This makes building in eclipse very painful (using m2e), you could 
change one dependency and then have to wait many minutes before eclipse 
manages to re-build specific projects.


Any ideas or suggestions?

Is the dependency management code easy to understand? I'm happy to get 
my hands dirty.


--
Paul French
Kirona Solutions Ltd
Tel: 07803 122 058
E-Mail: paul.fre...@kirona.com
Web: www.kirona.com <http://www.kirona.com>

This email and any attachments are confidential and should only be read 
by those to whom they are addressed. If you are not the intended 
recipient, please contact us on 01625 585511, delete the email 
(including any attachment) from your computer and destroy any copies. 
Any distribution or copying without our prior permission is prohibited. 
Internet communications are not always secure and may be subject to 
delays, non-delivery and unauthorised alterations. Therefore, 
information expressed in this message is not given or endorsed by Kirona 
Solutions Limited ("Kirona") unless otherwise notified by our duly 
authorised representative independent of this message. No warranty is 
given that this email (including any attachment) is virus free. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those of Kirona.


Registered addresses: Kirona Solutions Limited, Barrington House, Heyes 
Lane, Alderley Edge, Cheshire. SK9 7LA Registered in England and Wales 
No: 04678711

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

Added the snapshot repo back in and it now has major problems. A build 
that was fine before now fails with out of memory. - all version ranges 
set to [8.0.0,9.0.0)


On 22/06/2011 09:39, Mark Struberg wrote:

humm, maybe the resolution mechanism sniffs _all_ snapshot timeshot versions 
and not only the last one?

Could you please re-add the snapshot repo and set the version ranges to 
[8.0.0,9.0.0)?

The question is if this is related to the fact that the snapshot repo just has 
lots of artifacts (due to the timestamping) or if it's related to the -SNAPSHOT 
in the version range.

txs and LieGrue,
strub

--- On Wed, 6/22/11, Paul French  wrote:


From: Paul French
Subject: Re: maven 3.0.3 out of memory error, version ranges, lots of maven 
meta downloads
To: users@maven.apache.org
Cc: "Ian Jones"
Date: Wednesday, June 22, 2011, 8:26 AM
Thanks for that.

Out of interest if I remove the snapshot repository and
change my version ranges to [8.0.0,9.0.0) instead of
[8.0.0.SNAPSHOT,9.0.0.SNAPSHOT) all works fine again even in
eclipse.

For now we will live without snapshots.


On 22/06/2011 06:21, Kristian Rosenvold wrote:

 From what I can understand this issue is almost

certainly some kind of combinatorial explosion caused in the
calculation of the dependencies. Sample project/and or heap
dumps will be required here as far as I can understand.

As for the embedded building, you might want to take

note that plexus-utils 2.1 fixes a memory leak wrt
embedding.  This has been released in surefire 2.9.
maven-scm and the xAR plugins also have the same problem and
can be fixed by upgrading the plexus-utils dependency to 2.1
in these plugins.

Kristian









-

To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

Thanks for that.

Out of interest if I remove the snapshot repository and change my 
version ranges to [8.0.0,9.0.0) instead of 
[8.0.0.SNAPSHOT,9.0.0.SNAPSHOT) all works fine again even in eclipse.


For now we will live without snapshots.


On 22/06/2011 06:21, Kristian Rosenvold wrote:
From what I can understand this issue is almost certainly some kind of 
combinatorial explosion caused in the calculation of the dependencies. 
Sample project/and or heap dumps will be required here as far as I can 
understand.


As for the embedded building, you might want to take note that 
plexus-utils 2.1 fixes a memory leak wrt embedding.  This has been 
released in surefire 2.9. maven-scm and the xAR plugins also have the 
same problem and can be fixed by upgrading the plexus-utils dependency 
to 2.1 in these plugins.


Kristian







-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

Hello Ron,

thanks for your comments. See inline comments.

Cheers

On 21/06/2011 15:38, Ron Wheeler wrote:

On 21/06/2011 9:45 AM, Paul French wrote:

On 21/06/2011 14:25, Ron Wheeler wrote:

500Mb is not a lot of memory for a Java program.


It is when all I can give eclipse is 900MB. Beyond that the JVM fails 
to start. M2E as far as I know does not start a new JVM when building.

Perhaps someone else can settle this.
http://maven.40175.n5.nabble.com/setting-java-memory-options-for-m2-plugin-td138828.html  
seems to indicate that Maven runs in its own JVM with its own memory 
configuration.


I hope you are right. But that particular post is for launching maven 
externally to eclipse. The m2e plugin itself uses an embedded maven for 
dependency management. It is the dependency management that is failing 
with out of memory.




We have noticed that some libraries such as Apache's CXF webservices 
will require additional memory to be added to Maven if you are 
building applications that include it.
Since virtual memory is virtually free, you might as well just 
accept reality and increase the VM.


I can not imagine anyone doing software development with a modern 
IDE that would have trouble finding 1Gb of VM.


On my 2GB laptop all I can give eclipse is 900MB

You are mixing real and virtual.
You can give it as much virtual as you need and it will find the real 
memory (usually a lot less) that it can use.
You should have your Windows VM set to at least 4Gb on a 2Gb RAM 
laptop doing software development.


I'm not mixing real and virtual.  I was just indicating the maximum 
amount of memory I could give eclipse on my laptop. I don't care whether 
it is real or virtual I let windows handle that.


If someone can tell me how I can give eclipse more then a 1G of memory 
(windows XP) then that would be great. At the moment I use a shortcut:


eclipse.exe -vmargs -Xmx900M

If I set to 1000M then the JVM fails to start.



All our guys have 2Gb laptops and can set virtual memory to 1 Gb for 
Eclipse and 1 Gb for the JVMs that it spawns.


It is only for a short time anyway and what else are you trying to do 
while it builds?

You want it to use every bit of real RAM that it needs to finish quickly.

Anyway, there is nothing that you can do to make it use less memory 
unless you want to break your builds down and even then, you may need 
libraries like CXF that just take a lot VM to build.



Ron





We build under Eclipse STS but I don't think that it makes any 
difference since Maven is running in its own VM.


I would not use version ranges since I like to know what I am 
putting into production.
Once you initially set the versions of what you are supporting, it 
is not difficult to maintain that list as you work your way through 
new versions of third party code.

We do it at the start of each of our release cycles.
We usually stick with the existing set from the last release unless 
there is a reason to move.
The version configuration for a new release is setup and managed by 
the entire team (small part of the release startup) and unless 
something catches fire, we stick with our set throughout the life of 
our release.


We have 100's of bundles and usually most in flux. Someone put's a 
bug fix in a bundle, I do not want to have to *know*, as long as it 
is compatible with what I require which we automatically enforce via 
PDE API analysis tooling. At release time we know what is delivered 
and can re-produce the build since an exact version POM is built for 
us and packaged in the artifact with the version range one backed up.


I can understand people being resistant to version ranges but with 
OSGi more and more jars are broken down into smaller components (and 
so projects) and version ranging really helps if you enforce semantic 
versioning between bundles.


Nevertheless there is a problem with maven 3.0.3 when using version 
ranges.





Ron

On 21/06/2011 8:59 AM, Benson Margulies wrote:

Yes this came to the list.

*someone* is going to have to run yourkit or jprofiler on a real
version of your problem.

Of course, the person best positioned to do that would be, ahem, you.
Unless you could give access to, well, me.


It would be a giant public service for there to be a sufficiently
complex example of this sort of thing available for development and
testing,  and it would pay your organization off in the long run
in terms of maven working better for you.

On Tue, Jun 21, 2011 at 6:42 AM, Paul 
French  wrote:

Thanks for reply - see inline

On 21/06/2011 11:27, B Smith-Mannschott wrote:
On Mon, Jun 20, 2011 at 19:54, Paul 
Frenchwrote:
Below is some filtered output from a maven build (showing maven 
meta data

being downloaded for one artifact). All my dependencies use version
ranges
of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)

In general the build fails with out of memory. I can increase 
the heap

size
and the build is successful, but a relatively

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

I forgot to mention that maven 3.0.3 is using more then 1024MB of heap 
before it even gets to the compile stage. We will look into profiling it 
later today.



On 21/06/2011 14:45, Paul French wrote:

On 21/06/2011 14:25, Ron Wheeler wrote:

500Mb is not a lot of memory for a Java program.


It is when all I can give eclipse is 900MB. Beyond that the JVM fails 
to start. M2E as far as I know does not start a new JVM when building.


We have noticed that some libraries such as Apache's CXF webservices 
will require additional memory to be added to Maven if you are 
building applications that include it.
Since virtual memory is virtually free, you might as well just accept 
reality and increase the VM.


I can not imagine anyone doing software development with a modern IDE 
that would have trouble finding 1Gb of VM.


On my 2GB laptop all I can give eclipse is 900MB



We build under Eclipse STS but I don't think that it makes any 
difference since Maven is running in its own VM.


I would not use version ranges since I like to know what I am putting 
into production.
Once you initially set the versions of what you are supporting, it is 
not difficult to maintain that list as you work your way through new 
versions of third party code.

We do it at the start of each of our release cycles.
We usually stick with the existing set from the last release unless 
there is a reason to move.
The version configuration for a new release is setup and managed by 
the entire team (small part of the release startup) and unless 
something catches fire, we stick with our set throughout the life of 
our release.


We have 100's of bundles and usually most in flux. Someone put's a bug 
fix in a bundle, I do not want to have to *know*, as long as it is 
compatible with what I require which we automatically enforce via PDE 
API analysis tooling. At release time we know what is delivered and 
can re-produce the build since an exact version POM is built for us 
and packaged in the artifact with the version range one backed up.


I can understand people being resistant to version ranges but with 
OSGi more and more jars are broken down into smaller components (and 
so projects) and version ranging really helps if you enforce semantic 
versioning between bundles.


Nevertheless there is a problem with maven 3.0.3 when using version 
ranges.





Ron

On 21/06/2011 8:59 AM, Benson Margulies wrote:

Yes this came to the list.

*someone* is going to have to run yourkit or jprofiler on a real
version of your problem.

Of course, the person best positioned to do that would be, ahem, you.
Unless you could give access to, well, me.


It would be a giant public service for there to be a sufficiently
complex example of this sort of thing available for development and
testing,  and it would pay your organization off in the long run
in terms of maven working better for you.

On Tue, Jun 21, 2011 at 6:42 AM, Paul 
French  wrote:

Thanks for reply - see inline

On 21/06/2011 11:27, B Smith-Mannschott wrote:
On Mon, Jun 20, 2011 at 19:54, Paul 
Frenchwrote:
Below is some filtered output from a maven build (showing maven 
meta data

being downloaded for one artifact). All my dependencies use version
ranges
of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)

In general the build fails with out of memory. I can increase the 
heap

size
and the build is successful, but a relatively simple build is now
requiring
500MB heap size.

First question is why is maven re-checking and downloading the 
same meta

data over and over again?

If I add additional version ranged dependencies to my pom then the
problem
seems to get exponentially worse. For a larger build so many 
requests are
made so quickly to the nexus remote repository that I start to 
see "Error

transferring file: Address already in use: connect".

Any ideas how to reduce the memory usage? Do not say "do not use 
version
ranges". We use semantic versioning enforced by API analysis 
tools for

each
of our modules (OSGi bundles) so we require version ranges.

If I change all version range dependencies to an exact dependency (a
serious
amount of pom editing) then all is fine. As you can tell below we 
have 3

main internal remote repos setup (kirona, kirona-snapshot and
third.party.libraries). We do not specify version ranges on 
libraries

that
are not in our control e.g. log4j etc etc

Downloading:

http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml 


Downloading:

http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 


Downloaded:

http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml 


(354 B at 21.6 KB/sec)
Downloaded:

http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 


(318 B at 6.6 KB/sec)
Down

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

On 21/06/2011 14:25, Ron Wheeler wrote:

500Mb is not a lot of memory for a Java program.


It is when all I can give eclipse is 900MB. Beyond that the JVM fails to 
start. M2E as far as I know does not start a new JVM when building.


We have noticed that some libraries such as Apache's CXF webservices 
will require additional memory to be added to Maven if you are 
building applications that include it.
Since virtual memory is virtually free, you might as well just accept 
reality and increase the VM.


I can not imagine anyone doing software development with a modern IDE 
that would have trouble finding 1Gb of VM.


On my 2GB laptop all I can give eclipse is 900MB



We build under Eclipse STS but I don't think that it makes any 
difference since Maven is running in its own VM.


I would not use version ranges since I like to know what I am putting 
into production.
Once you initially set the versions of what you are supporting, it is 
not difficult to maintain that list as you work your way through new 
versions of third party code.

We do it at the start of each of our release cycles.
We usually stick with the existing set from the last release unless 
there is a reason to move.
The version configuration for a new release is setup and managed by 
the entire team (small part of the release startup) and unless 
something catches fire, we stick with our set throughout the life of 
our release.


We have 100's of bundles and usually most in flux. Someone put's a bug 
fix in a bundle, I do not want to have to *know*, as long as it is 
compatible with what I require which we automatically enforce via PDE 
API analysis tooling. At release time we know what is delivered and can 
re-produce the build since an exact version POM is built for us and 
packaged in the artifact with the version range one backed up.


I can understand people being resistant to version ranges but with OSGi 
more and more jars are broken down into smaller components (and so 
projects) and version ranging really helps if you enforce semantic 
versioning between bundles.


Nevertheless there is a problem with maven 3.0.3 when using version ranges.




Ron

On 21/06/2011 8:59 AM, Benson Margulies wrote:

Yes this came to the list.

*someone* is going to have to run yourkit or jprofiler on a real
version of your problem.

Of course, the person best positioned to do that would be, ahem, you.
Unless you could give access to, well, me.


It would be a giant public service for there to be a sufficiently
complex example of this sort of thing available for development and
testing,  and it would pay your organization off in the long run
in terms of maven working better for you.

On Tue, Jun 21, 2011 at 6:42 AM, Paul French  
wrote:

Thanks for reply - see inline

On 21/06/2011 11:27, B Smith-Mannschott wrote:
On Mon, Jun 20, 2011 at 19:54, Paul 
Frenchwrote:
Below is some filtered output from a maven build (showing maven 
meta data

being downloaded for one artifact). All my dependencies use version
ranges
of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)

In general the build fails with out of memory. I can increase the 
heap

size
and the build is successful, but a relatively simple build is now
requiring
500MB heap size.

First question is why is maven re-checking and downloading the 
same meta

data over and over again?

If I add additional version ranged dependencies to my pom then the
problem
seems to get exponentially worse. For a larger build so many 
requests are
made so quickly to the nexus remote repository that I start to see 
"Error

transferring file: Address already in use: connect".

Any ideas how to reduce the memory usage? Do not say "do not use 
version
ranges". We use semantic versioning enforced by API analysis tools 
for

each
of our modules (OSGi bundles) so we require version ranges.

If I change all version range dependencies to an exact dependency (a
serious
amount of pom editing) then all is fine. As you can tell below we 
have 3

main internal remote repos setup (kirona, kirona-snapshot and
third.party.libraries). We do not specify version ranges on libraries
that
are not in our control e.g. log4j etc etc

Downloading:

http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml 


Downloading:

http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 


Downloaded:

http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml 


(354 B at 21.6 KB/sec)
Downloaded:

http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 


(318 B at 6.6 KB/sec)
Downloading:

http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 


Downloading:

http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/k

Re: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

Thanks for reply - see inline

On 21/06/2011 11:27, B Smith-Mannschott wrote:

On Mon, Jun 20, 2011 at 19:54, Paul French  wrote:

Below is some filtered output from a maven build (showing maven meta data
being downloaded for one artifact). All my dependencies use version ranges
of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)

In general the build fails with out of memory. I can increase the heap size
and the build is successful, but a relatively simple build is now requiring
500MB heap size.

First question is why is maven re-checking and downloading the same meta
data over and over again?

If I add additional version ranged dependencies to my pom then the problem
seems to get exponentially worse. For a larger build so many requests are
made so quickly to the nexus remote repository that I start to see "Error
transferring file: Address already in use: connect".

Any ideas how to reduce the memory usage? Do not say "do not use version
ranges". We use semantic versioning enforced by API analysis tools for each
of our modules (OSGi bundles) so we require version ranges.

If I change all version range dependencies to an exact dependency (a serious
amount of pom editing) then all is fine. As you can tell below we have 3
main internal remote repos setup (kirona, kirona-snapshot and
third.party.libraries). We do not specify version ranges on libraries that
are not in our control e.g. log4j etc etc

Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 21.6 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 6.6 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 10.0 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 11.2 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 9.7 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 10.8 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve...

The above problems renders eclipse useless with m2e, it causes eclipse to
hang on start up (build automatically set to true) and eventually die!!

I'm starting to come to the conclusion that between maven and m2e version
ranges just do not work very well. I hope I am wrong!!

Thanks
Paul

In my a case I found Maven slurping metadata on every build was
related to how I had configuredalways  in
repositories profile defined in my settings.xml (It had been a
"temporary" change which got forgotten...)

I did circumvent the problem as you suggest by setting my repos to have an 
updatePolicy
of interval:10 so during a build, maven does not re-download the same
maven meta data file. However not very complicated builds are still failing
with out of memory even with 1024M of heap space. So this workaround just
speeds up the inevitable out of memory error appearing.


I got burned twice by version ranges. (It's at least a few years ago,
so I don't remember the specifics.) I haven't touched them since.
Also, their meaning hinges on how Maven chooses to sort versions, and
I've not yet seen a sufficiently unambiguous definition of that.
Consider that Maven will accept aNyOld3.2Crap-X1r as a version number.
  Even if you stick to the 'pa

Re: Fwd: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

To be clear the problem is in maven. I am running maven from the command 
line.


Thanks
P


On 21/06/2011 11:16, Paul French wrote:
Can someone confirm on the maven users list that they have received 
this email?


I did not but it does appear in the mail archive

Thanks
P

 Original Message 
Subject: 	maven 3.0.3 out of memory error, version ranges, lots of 
maven meta downloads

Date:   Mon, 20 Jun 2011 18:54:41 +0100
From:   Paul French 
Organisation:   Kirona
To: users@maven.apache.org
CC: Ian Jones 



Below is some filtered output from a maven build (showing maven meta
data being downloaded for one artifact). All my dependencies use version
ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)

In general the build fails with out of memory. I can increase the heap
size and the build is successful, but a relatively simple build is now
requiring 500MB heap size.

First question is why is maven re-checking and downloading the same meta
data over and over again?

If I add additional version ranged dependencies to my pom then the
problem seems to get exponentially worse. For a larger build so many
requests are made so quickly to the nexus remote repository that I start
to see "Error transferring file: Address already in use: connect".

I can circumvent this problem by setting my repos to have an updatePolicy
of interval:10 so during a build maven does not re-download the same
maven meta data file. However not very complicated builds are still failing
with out of memory even with 1024M of heap space. So this workaround just
speeds up the inevitable out of memory error appearing.

Any ideas how to reduce the memory usage? Do not say "do not use version
ranges". We use semantic versioning enforced by API analysis tools for
each of our modules (OSGi bundles) so we require version ranges.

If I change all version range dependencies to an exact dependency (a
serious amount of pom editing) then all is fine. As you can tell below
we have 3 main internal remote repos setup (kirona, kirona-snapshot and
third.party.libraries). We do not specify version ranges on libraries
that are not in our control e.g. log4j etc etc

Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 21.6 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 6.6 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 10.0 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 11.2 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 9.7 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 10.8 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve...

The above problems renders eclipse useless with m2e, it causes eclipse
to hang on start up (build automatically set to true) and eventually die!!

I'm starting to come to the conclusion that between maven and m2e
version ranges just do not work very well. I hope I am wrong!!

Thanks
Ian

Fwd: maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

Can someone confirm on the maven users list that they have received this 
email?


I did not but it does appear in the mail archive

Thanks
P

 Original Message 
Subject: 	maven 3.0.3 out of memory error, version ranges, lots of maven 
meta downloads

Date:   Mon, 20 Jun 2011 18:54:41 +0100
From:   Paul French 
Organisation:   Kirona
To: users@maven.apache.org
CC: Ian Jones 



Below is some filtered output from a maven build (showing maven meta
data being downloaded for one artifact). All my dependencies use version
ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)

In general the build fails with out of memory. I can increase the heap
size and the build is successful, but a relatively simple build is now
requiring 500MB heap size.

First question is why is maven re-checking and downloading the same meta
data over and over again?

If I add additional version ranged dependencies to my pom then the
problem seems to get exponentially worse. For a larger build so many
requests are made so quickly to the nexus remote repository that I start
to see "Error transferring file: Address already in use: connect".

I can circumvent this problem by setting my repos to have an updatePolicy
of interval:10 so during a build maven does not re-download the same
maven meta data file. However not very complicated builds are still failing
with out of memory even with 1024M of heap space. So this workaround just
speeds up the inevitable out of memory error appearing.

Any ideas how to reduce the memory usage? Do not say "do not use version
ranges". We use semantic versioning enforced by API analysis tools for
each of our modules (OSGi bundles) so we require version ranges.

If I change all version range dependencies to an exact dependency (a
serious amount of pom editing) then all is fine. As you can tell below
we have 3 main internal remote repos setup (kirona, kirona-snapshot and
third.party.libraries). We do not specify version ranges on libraries
that are not in our control e.g. log4j etc etc

Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 21.6 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 6.6 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 10.0 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 11.2 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading:
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
(318 B at 9.7 KB/sec)
Downloaded:
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
(354 B at 10.8 KB/sec)
Downloading:
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve...

The above problems renders eclipse useless with m2e, it causes eclipse
to hang on start up (build automatically set to true) and eventually die!!

I'm starting to come to the conclusion that between maven and m2e
version ranges just do not work very well. I hope I am wrong!!

Thanks
Ian

maven 3.0.3 out of memory error, version ranges, lots of maven meta downloads

[Paul French]

Below is some filtered output from a maven build (showing maven meta 
data being downloaded for one artifact). All my dependencies use version 
ranges of the form [1.0.0.SNAPSHOT,2.0.0.SNAPSHOT)


In general the build fails with out of memory. I can increase the heap 
size and the build is successful, but a relatively simple build is now 
requiring 500MB heap size.


First question is why is maven re-checking and downloading the same meta 
data over and over again?


If I add additional version ranged dependencies to my pom then the 
problem seems to get exponentially worse. For a larger build so many 
requests are made so quickly to the nexus remote repository that I start 
to see "Error transferring file: Address already in use: connect".


Any ideas how to reduce the memory usage? Do not say "do not use version 
ranges". We use semantic versioning enforced by API analysis tools for 
each of our modules (OSGi bundles) so we require version ranges.


If I change all version range dependencies to an exact dependency (a 
serious amount of pom editing) then all is fine. As you can tell below 
we have 3 main internal remote repos setup (kirona, kirona-snapshot and 
third.party.libraries). We do not specify version ranges on libraries 
that are not in our control e.g. log4j etc etc


Downloading: 
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded: 
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml 
(354 B at 21.6 KB/sec)
Downloaded: 
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 
(318 B at 6.6 KB/sec)
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading: 
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded: 
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 
(318 B at 10.0 KB/sec)
Downloaded: 
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml 
(354 B at 11.2 KB/sec)
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading: 
http://fuji:8081/nexus/content/repositories/third-party/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona-knopflerfish/com/kirona/server/third.party.libraries/maven-metadata.xml
Downloaded: 
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/server/third.party.libraries/maven-metadata.xml 
(318 B at 9.7 KB/sec)
Downloaded: 
http://fuji:8081/nexus/content/repositories/kirona-snapshots/com/kirona/server/third.party.libraries/maven-metadata.xml 
(354 B at 10.8 KB/sec)
Downloading: 
http://fuji:8081/nexus/content/repositories/kirona/com/kirona/serve...


The above problems renders eclipse useless with m2e, it causes eclipse 
to hang on start up (build automatically set to true) and eventually die!!


I'm starting to come to the conclusion that between maven and m2e 
version ranges just do not work very well. I hope I am wrong!!


Thanks
Paul


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven 3 version ranges with snapshots

[Paul French]

  
  
I've added the below to the discussion at...

http://jira.codehaus.org/browse/MNG-3092

...but include here in case anyone else has some ideas.


If you consider semantic versioning http://semver.org/
where by using carefully chosen version numbers (enforced by an api
analysis tool) and version ranges to specify your dependencies
between your components then version ranges need to support some
basic ideas.

  I have component A [1.0.0] and
component B [1.1.0] and component A
depends on component B with version range [1.0.0,1.2.0)
   A [1.0.0] depends on B
[1.0.0,1.2.0)
  We start additional development on B so it will initially be B
[1.1.1-SNAPSHOT] So A will pull this
in as it's current dependency i.e. B [1.1.1-SNAPSHOT]
as a dependency (the current behaviour of maven 3.0.3)
  Work continues on B and someone adds a method to an interface
which is used by A, component B's version is increased to [1.2.0-SNAPSHOT] to signal the possible
incompatible change since version B [1.1.0]
  If you think about it, this snapshot of B could be incompatible
to A so we need to exclude it in our version range i.e. we
modify component A's dependency version range on B to exclude
the 1.2.0-SNAPSHOT
   A [1.0.0] depends on B
[1.0.0,1.2.0-SNAPSHOT)
  So already I'm not liking this since I have to specify I don't
want the 1.2 SNAPSHOT but I can live with it.
  However the dependency pulled in for A will now always be B [1.1.1-SNAPSHOT], there will never be a
release of B[1.1.1] made by us, our
baseline is B[1.1.0] and we have not
made a new baseline release yet for component B but it will at
best be [1.2.0] or a later version.
  
  I've concluded but I could be wrong that you need to be able to
say whether you want to include or exclude SNAPSHOT in your
version ranges. We develop OSGi bundles. Using the PDE analysis
API tooling we compare on going development of bundles with a
baseline release and update the POM/Bundle-Manifest version as
appropriate depending on code changes. So we require to use
version ranges with snapshots included when doing continuous
integration but do not include SNAPSHOT when doing releases.
  I actually would prefer A [1.0.0]
depends on B [1.0.0,1.2.0) to actually mean...
   "A depends on B from 1.0.0 up to but NOT including 1.2.0 or
1.2.0-SNAPSHOT"
  From our point of view, if you do not want 1.2.0 since it will
be incompatible then you do not want 1.2.0-SNAPSHOT either since
it will also be incompatible.
  To be clear B [1.1.1-SNAPHOT] is
valid in the range above by default.
  However when building a release we would like to set a property
or something equivalent (not in the POM, you do not want to have
to go through all the POMS) and exclude SNAPSHOT in version
ranges.
  I suspect other people may require other scenarios so I see
some form of pluggable version range strategy being the answer.
You plugin the functionality you require. The default behaviour
will be what I have outlined 
      My 10 pence 


-- 
  Paul French
Kirona Solutions Ltd
Tel: 07803 122 058
E-Mail: paul.fre...@kirona.com
Web: www.kirona.com
  
  
This email and any attachments are confidential and should only
be read by those to whom they are addressed. If you are not the
intended recipient, please contact us on 01625 585511, delete
the email (including any attachment) from your computer and
destroy any copies. Any distribution or copying without our
prior permission is prohibited.
Internet communications are not always secure and may be subject
to delays, non-delivery and unauthorised alterations. Therefore,
information expressed in this message is not given or endorsed
by Kirona Solutions Limited ("Kirona") unless otherwise notified
by our duly authorised representative independent of this
message. No warranty is given that this email (including any
attachment) is virus free. Any views or opinions presented are
solely those of the author and do not necessarily represent
those of Kirona.


Registered addresses: Kirona Solutions Limited, Barrington
House, Heyes Lane, Alderley Edge, Cheshire. SK9 7LA Registered
in England and Wales No: 04678711