...
The default specification should be composed as follows:
{{ Wiki Markup <major>.<minor>.<revision>(
\[
\ -<qualififer>
\ ]
\ |
\ [
\ -<build>
\ ])
}}
where:
- the qualifier section is optional (and is SNAPSHOT, alpha-1, alpha-2)
- the build section is optional (and increments starting at 1 if specified)
- any '0' build or revision elements can be omitted.
- only one of build and qualifier can be given (note that the timestamped qualifier includes a build number, but this is not the same)
- the build number is for those that repackage the original artifact (eg, as is often done with rpms)
For ordering, the following is done in order until an element is found that are not equal:
- numerical comparison of major version
- numerical comparison of minor version
- if revision does not exist, add ".0" for comparison purposes
- numerical comparison of revision
- if qualifier does not exist, it is newer than if it does
- case-insensitive string comparison of qualifier
- this ensures timestamps are correctly ordered, and SNAPSHOT is newer than an equivalent timestamp
- this also ensures that beta comes after alpha, as does rc
- if no qualifier, and build does not exist, add "-0" for comparison purposes
- numerical comparison of build
Note also the proposed extension from a user in an rpm environment: Extending Maven 2.0 Dependencies
...
Range | Meaning | ||
---|---|---|---|
| x <= 1.0 | ||
| "Soft" requirement on 1.0 (just a recommendation - helps select the correct version if it matches all ranges) <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="90da0bd3-9eb4-4076-94f1-c46b20766c40"><ac:plain-text-body><![CDATA[ | ||
| Hard requirement on 1.0 ]]></ac:plain-text-body></ac:structured-macro><ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f830027e-7600-4b29-9ced-a4d5edd66a4e"><ac:plain-text-body><! | ||
| 1.2 <= x <= 1.3 | ||
]]></ac:plain-text-body></ac:structured-macro> | <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3069ee62-b9e7-4231-8cce-feb9a8328231"><ac:plain-text-body><![CDATA | 1.0 <= x < 2.0 | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="72c9892a-57e9-48cc-95cf-5b1a23b1d9b8"><ac:plain-text-body><! | x >= 1.5 | ]]></ac:plain-text-body></ac:structured-macro> | <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c29e5cb0-d9b0-4777-8a09-7536c807d4c4"><ac:plain-text-body><![CDATA[ |
| x <= 1.0 or x >= 1.2. Multiple sets are comma-separated | ]]></ac:plain-text-body></ac:structured-macro> | |
| This excludes 1.1 if it is known not to work in combination with this library |
...
This is inherited, and gives a full profile over your dependency set. While it will not add new dependencies itself, it will enforce the following constraints:
- your policy on the version allowed for a dependency
- affects both your declared dependencies and transitive dependencies
- apply a specific scope to a dependency
Resolve Dependencies once only
...
Preventing RELEASE
dependencies
Given that an open ended version specification such as {{\ Wiki Markup [1.0,)
}} will use a {{RELEASE
}} version dependency if available, there is no reason to allow and resolve such a version for a dependency.
Version specifications for Parents
...