date:20120927


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 get caught out by

what

Jesse outlined below.

On 27/09/2012 15:51, Stephen

Re: Version ranges not working

2012-09-27 Thread Ron Wheeler

+1
On 27/09/2012 7:20 PM, 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 :

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

[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,

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

as
need

Re: Ability to use latest plugin snapshot from maven 3 command line

I was hoping  like 'mvn -another-flag myplugin:goal'

I am surely understand the long name, for those ppl dont know too much
about maven will resist to use. but that is another story

Thank you

-D

On Thu, Sep 27, 2012 at 3:31 PM, Jörg Schaible  wrote:
> Dan Tran wrote:
>
>> hi Jörg
>>
>> The problem here is I run my plugin from command line, no pom.
>
> Then all you can do is to follow Roy's example.
>
> - Jörg
>
>
> -
> 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: Exporting Individual Files with the SCM Plugin

2012-09-27 Thread Christopher Gardner

I am curious why scm export supports the includes and excludes tags.
On Sep 27, 2012 6:32 PM, "Olivier Lamy"  wrote:

> 2012/9/28 Olivier Lamy :
> > 2012/9/28 Christopher Gardner :
> >> I'd like to export a few jar files from an svn location.  These jar
> files
> >> are developed by other developers at my company and have no maven
> support,
> >> and probably never will.
> > sad :-)
> >> I have the following entry in my pom:
> >>
> >> 
> >>   org.apache.maven.plugins
> >>   maven-scm-plugin
> >>   1.8
> >>   
> >> myusername
> >> mypassword
> >> target/checkout
> >> connection
> >> scm:svn:http://machine/svn/project
> >> foo.jar,bar.jar
> >>   
> >>   
> >> export
> >>   
> >> 
> >
> > That won't work (in fact includes is in parent class so this parameter
> > is listed in this mojo).
> > Why because svn cli doesn't support that :-)
>
> Maybe we could do that tru svnkit with the svnjava implementation
> (http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/)
> Just an idea as I didn't check the svnkit api
>
> > Maybe you can use a http get to the svn path ? the plugin
> > http://mojo.codehaus.org/wagon-maven-plugin/ can help for that.
> >
> >
> >>
> >> It appears that the includes tag is ignored, as the entire "project"
> >> directory is being exported. Any ideas as to what I'm doing wrong?
> >>
> >> I'm using this version of maven: Apache Maven 3.0.4 (r1232337;
> 2012-01-17
> >> 03:44:56-0500)
> >>
> >> Thanks in advance.
> >
> >
> >
> > --
> > Olivier Lamy
> > Talend: http://coders.talend.com
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Version ranges not working

2012-09-27 Thread Baptiste MATHUS

+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 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.
> >>> I

Re: Version ranges not working

My experience with versions-maven-plugin would show different, but each to
their own

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

> 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. Bu

Re: Version ranges not working

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 reliable way to define a
compatibility
range in Maven. I feel that this sh

Re: Version ranges not working

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 reliable way to define a
>>> comp

Re: Ability to use latest plugin snapshot from maven 3 command line

2012-09-27 Thread Jörg Schaible

Dan Tran wrote:

> hi Jörg
> 
> The problem here is I run my plugin from command line, no pom.

Then all you can do is to follow Roy's example.

- Jörg


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

Re: Exporting Individual Files with the SCM Plugin

2012-09-27 Thread Olivier Lamy

2012/9/28 Olivier Lamy :
> 2012/9/28 Christopher Gardner :
>> I'd like to export a few jar files from an svn location.  These jar files
>> are developed by other developers at my company and have no maven support,
>> and probably never will.
> sad :-)
>> I have the following entry in my pom:
>>
>> 
>>   org.apache.maven.plugins
>>   maven-scm-plugin
>>   1.8
>>   
>> myusername
>> mypassword
>> target/checkout
>> connection
>> scm:svn:http://machine/svn/project
>> foo.jar,bar.jar
>>   
>>   
>> export
>>   
>> 
>
> That won't work (in fact includes is in parent class so this parameter
> is listed in this mojo).
> Why because svn cli doesn't support that :-)

Maybe we could do that tru svnkit with the svnjava implementation
(http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/)
Just an idea as I didn't check the svnkit api

> Maybe you can use a http get to the svn path ? the plugin
> http://mojo.codehaus.org/wagon-maven-plugin/ can help for that.
>
>
>>
>> It appears that the includes tag is ignored, as the entire "project"
>> directory is being exported. Any ideas as to what I'm doing wrong?
>>
>> I'm using this version of maven: Apache Maven 3.0.4 (r1232337; 2012-01-17
>> 03:44:56-0500)
>>
>> Thanks in advance.
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: Exporting Individual Files with the SCM Plugin

2012-09-27 Thread Olivier Lamy

2012/9/28 Christopher Gardner :
> I'd like to export a few jar files from an svn location.  These jar files
> are developed by other developers at my company and have no maven support,
> and probably never will.
sad :-)
> I have the following entry in my pom:
>
> 
>   org.apache.maven.plugins
>   maven-scm-plugin
>   1.8
>   
> myusername
> mypassword
> target/checkout
> connection
> scm:svn:http://machine/svn/project
> foo.jar,bar.jar
>   
>   
> export
>   
> 

That won't work (in fact includes is in parent class so this parameter
is listed in this mojo).
Why because svn cli doesn't support that :-)
Maybe you can use a http get to the svn path ? the plugin
http://mojo.codehaus.org/wagon-maven-plugin/ can help for that.


>
> It appears that the includes tag is ignored, as the entire "project"
> directory is being exported. Any ideas as to what I'm doing wrong?
>
> I'm using this version of maven: Apache Maven 3.0.4 (r1232337; 2012-01-17
> 03:44:56-0500)
>
> Thanks in advance.



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: Exporting Individual Files with the SCM Plugin

2012-09-27 Thread Christopher Gardner

Philosophically I agree with your suggestion, but I am curious why I'm
having trouble with the includes tag. Shouldn't it just work?
On Sep 27, 2012 6:25 PM, "Graham Leggett"  wrote:

> On 27 Sep 2012, at 23:14, Christopher Gardner 
> wrote:
>
> > I'd like to export a few jar files from an svn location.  These jar files
> > are developed by other developers at my company and have no maven
> support,
> > and probably never will.
>
> Import the jars into your own maven repository, keeping your own copy.
> Configure your build as you normally would.
>
> Trying to bend your maven pom into something ugly goes against maven,
> rather keep things as clean as possible.
>
> If they don't version their artifacts, version them for them, but make it
> crystal clear where the artifacts came from.
>
> You don't want to rely on someone else's system that may or may not be
> available at a future date, and suddenly you're panicking because your code
> no longer builds.
>
> Regards,
> Graham
> --
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Exporting Individual Files with the SCM Plugin

2012-09-27 Thread Graham Leggett

On 27 Sep 2012, at 23:14, Christopher Gardner  wrote:

> I'd like to export a few jar files from an svn location.  These jar files
> are developed by other developers at my company and have no maven support,
> and probably never will.

Import the jars into your own maven repository, keeping your own copy. 
Configure your build as you normally would.

Trying to bend your maven pom into something ugly goes against maven, rather 
keep things as clean as possible.

If they don't version their artifacts, version them for them, but make it 
crystal clear where the artifacts came from.

You don't want to rely on someone else's system that may or may not be 
available at a future date, and suddenly you're panicking because your code no 
longer builds.

Regards,
Graham
--

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

Re: Version ranges not working

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 the special case of comparing to the version numbe

Re: Version ranges not working

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 the special case of comparing to the version number

Re: Version ranges not working


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 

Jira issue MNG-3092, reported over 5 years ago, is related to this issue,
but the initial report is for a similar issue

Re: Version ranges not working

2012-09-27 Thread Hervé BOUTEMY

Le jeudi 27 septembre 2012 15:41:25 Jesse Long a écrit :
> 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

thanks for the report
I updated the link, should be visible in the page soon

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

Re: Versioning with release plugin - support for qualifier

2012-09-27 Thread Karl Heinz Marbaise


Hi,


With e.g. 2.1.1-RC.1-SNAPSHOT

I've never seen a version marker like this..


or 2.1.1-RC1-SNAPSHOT the release plugin


This works...after 2.1.1-RC1-SNAPSHOT it will become
2.1.1-RC2-SNAPSHOT, 2.1.1-RC3-SNAPSHOT and so on...

Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen   http://www.soebes.de

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

Re: Ability to use latest plugin snapshot from maven 3 command line

hi Jörg

The problem here is I run my plugin from command line, no pom.

-D

On Thu, Sep 27, 2012 at 9:53 AM, Jörg Schaible  wrote:
> Hi Dan,
>
> Dan Tran wrote:
>
>> Hello
>>
>> Back in Maven 2, when executing  a plugin goal from command line,
>> Maven always tries to look for latest version and its snapshot
>>
>> In Maven 3, this capability disappear, Maven only looks for latest
>> released version.
>>
>> Would it possible to turn it on from command line?
>>
>> I fully understand the benefit of predictability. However, it becomes
>> very inconvenient to cut the plugin release while still testing.
>> and we cannt use maven2 because the plugin itself uses maven 3 api ( ie
>> aether )
>>
>> Is there already a request for this?
>
> AFAICS this has nothing to do with M2/M3, but early M2 versions simply did
> not pin-point the versions of the plugins they used. For latest releases of
> M2 (and IIRC all releases of M3) this policy have changed, and you will have
> to declare the version of a plugin explicitly in your POMs, if you want to
> use a different version than the one that is declared internally.
>
> - Jörg
>
>
> -
> 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

2012-09-27 Thread Hervé BOUTEMY

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

Re: Version ranges not working

2012-09-27 Thread Joachim Van der Auwera


Why not use
[1.7.0,1.7.99]

Just remember this when the project reaches revision 100 :-)

On 27-09-12 15: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 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-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


+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: What does the "tag" parameter for release:branch do?

2012-09-27 Thread Laird Nelson

On Thu, Sep 27, 2012 at 9:48 AM, Laird Nelson  wrote:

> I can't figure out what the tag parameter is supposed to do for the
> maven-release-plugin branch goal.
>

I'm guessing that this is just a mistake; much of the branch goal seems to
bear a striking similarity to the perform goal; I smell cut-and-paste.  :-)
 Maybe this is a property that got copied over but isn't used?

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Ability to use latest plugin snapshot from maven 3 command line

2012-09-27 Thread Jörg Schaible

Hi Dan,

Dan Tran wrote:

> Hello
> 
> Back in Maven 2, when executing  a plugin goal from command line,
> Maven always tries to look for latest version and its snapshot
> 
> In Maven 3, this capability disappear, Maven only looks for latest
> released version.
> 
> Would it possible to turn it on from command line?
> 
> I fully understand the benefit of predictability. However, it becomes
> very inconvenient to cut the plugin release while still testing.
> and we cannt use maven2 because the plugin itself uses maven 3 api ( ie
> aether )
> 
> Is there already a request for this?

AFAICS this has nothing to do with M2/M3, but early M2 versions simply did 
not pin-point the versions of the plugins they used. For latest releases of 
M2 (and IIRC all releases of M3) this policy have changed, and you will have 
to declare the version of a plugin explicitly in your POMs, if you want to 
use a different version than the one that is declared internally.

- Jörg

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

What does the "tag" parameter for release:branch do?

2012-09-27 Thread Laird Nelson

I can't figure out what the tag parameter is supposed to do for the
maven-release-plugin branch goal.  Could someone point me at some alternate
source of documentation?

The maven-release-plugin branch goal simply says (
http://maven.apache.org/plugins/maven-release-plugin/branch-mojo.html#tag):

The SCM tag to use.


...Use to do...to do what?

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Ability to use latest plugin snapshot from maven 3 command line

Thanks for the pointer?  are you talking about plugin registry?  It
seems this feature is not recommended ( i have not dig deep into it
yet )

btw, specify full plugin is not desirable ( ie mvn
groupId:artifactId:version:goal )

more suggestion is greatly appreciated.

-D

On Thu, Sep 27, 2012 at 9:17 AM, Lyons, Roy  wrote:
> Extremely easy fix for that:
>
> http://maven.apache.org/guides/introduction/introduction-to-plugin-resoluti
> on.html
>
> -- snip --
>
> For clarity, the following are the three ways to reference a mojo
> from the command line. These will all result in the clean mojo of the
> maven-clean-plugin being invoked:
>   mvn org.apache.maven.plugins:maven-clean-plugin:2.0:clean
>   mvn org.apache.maven.plugins:maven-clean-plugin:clean
>   mvn clean:clean
>
>
>
>
> -- /snip --
>
> So just reference your snapshot plugin with:
>  mvn :::
>
> That's it.
>
>
>
>
> On 9/27/12 10:35 AM, "Dan Tran"  wrote:
>
>>Hello
>>
>>Back in Maven 2, when executing  a plugin goal from command line,
>>Maven always tries to look for latest version and its snapshot
>>
>>In Maven 3, this capability disappear, Maven only looks for latest
>>released version.
>>
>>Would it possible to turn it on from command line?
>>
>>I fully understand the benefit of predictability. However, it becomes
>>very inconvenient to cut the plugin release while still testing.
>>and we cannt use maven2 because the plugin itself uses maven 3 api ( ie
>>aether )
>>
>>Is there already a request for this?
>>
>>Big thanks
>>
>>-D
>>
>>-
>>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: Ability to use latest plugin snapshot from maven 3 command line

2012-09-27 Thread Lyons, Roy

Extremely easy fix for that:

http://maven.apache.org/guides/introduction/introduction-to-plugin-resoluti
on.html

-- snip --

For clarity, the following are the three ways to reference a mojo
from the command line. These will all result in the clean mojo of the
maven-clean-plugin being invoked:
  mvn org.apache.maven.plugins:maven-clean-plugin:2.0:clean
  mvn org.apache.maven.plugins:maven-clean-plugin:clean
  mvn clean:clean

-- /snip --

So just reference your snapshot plugin with:
 mvn :::

That's it.

On 9/27/12 10:35 AM, "Dan Tran"  wrote:

>Hello
>
>Back in Maven 2, when executing  a plugin goal from command line,
>Maven always tries to look for latest version and its snapshot
>
>In Maven 3, this capability disappear, Maven only looks for latest
>released version.
>
>Would it possible to turn it on from command line?
>
>I fully understand the benefit of predictability. However, it becomes
>very inconvenient to cut the plugin release while still testing.
>and we cannt use maven2 because the plugin itself uses maven 3 api ( ie
>aether )
>
>Is there already a request for this?
>
>Big thanks
>
>-D
>
>-
>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

Ability to use latest plugin snapshot from maven 3 command line

Hello

Back in Maven 2, when executing  a plugin goal from command line,
Maven always tries to look for latest version and its snapshot

In Maven 3, this capability disappear, Maven only looks for latest
released version.

Would it possible to turn it on from command line?

I fully understand the benefit of predictability. However, it becomes
very inconvenient to cut the plugin release while still testing.
and we cannt use maven2 because the plugin itself uses maven 3 api ( ie aether )

Is there already a request for this?

Big thanks

-D

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

Re: Version ranges not working