Details
Improvement
Description
For now, <jdk></jdk> provides only one operator '!' which means negation, but it would be great if i can use '+' and ~ operator:
<jdk>1.5+</jdk> <!-- this will be activated when the current JDK version is 1.5 or above (e.g. 1.6) -->
<jdk>1.1 ~ 1.4</jdk> <!-- this will be activated when the current JDK version is between 1.1 and 1.4 -->
<jdk>~ 1.3</jdk> <!-- this will be activated when the current JDK version is 1.3 or below -->
<jdk>1.4 ~</jdk. <!-- the same with 1.5+ -->
Attachments
Issue Links
| This issue relates to: | ||||
| MNG-4512 | [regression] Profile activation based on JDK version range fails if current version is close to range boundary |
|
|
|
| MNG-4517 | Support Maven 2.0.x style jdk activation in Maven 2.2.x |
|
|
|
| This issue is related to: | ||||
| MNG-3957 | [regression] For artifact {stax:stax-api:null:jar}: The version cannot be empty. |
|
|
|
| MNG-1910 | Allow jdk 1.4+ as profile requirement |
|
|
|
Activity
I just had brief look at the code and to me, implementing VersionRange-like syntax, comes down to three choices:
- Use the existing VersionRange classes (which seems rather artifact dependendant, at least when it comes to naming. It's coupled with, for example, ArtifactVersion)
- Copy the VersionRange class and make it compatible with the problem with try to solve here (code duplication?
- Make VersionRange more abstract, make it handle different types versions. Such as Java JDK versions? They are a bit special since they use '_' to denote upgrade releases. But if you'd really like to use the VersionRange class, I guess you can trick it to handle JDK versions like ArtifactVersions (upgrade number can become build number).
I'm rather new to the Maven source code, so I'm in need of some guidance on this.
- Use the existing VersionRange classes (which seems rather artifact dependendant, at least when it comes to naming. It's coupled with, for example, ArtifactVersion)
- Copy the VersionRange class and make it compatible with the problem with try to solve here (code duplication?
- Make VersionRange more abstract, make it handle different types versions. Such as Java JDK versions? They are a bit special since they use '_' to denote upgrade releases. But if you'd really like to use the VersionRange class, I guess you can trick it to handle JDK versions like ArtifactVersions (upgrade number can become build number).
applied, thanks!
I made one modification - ! is not valid for ranges. I think per the thread on dev@ this is a bit confusing - best to be range or nothing.
I added some tests, but still have an IT and docs to add before closing it out (more patches welcome
I like this and am voting for it. This is useful for instances like javax.management being already available in JDK 1.5 so you'll want to put the dependency for it and its implementation when the JDK is "~ 1.5".