Hi,
as per MNG-1957, Maven introduced support to activate profiles based on
a version range for the JDK version:
<profile>
<id>test</id>
<activation>
<jdk> (1.4,1.5] </jdk>
</activation>
</profile>
Now, when do you think does this profile get activated in case the
current Java version (as given by ${java.version}) happens to be
a) 1.4.0_07
b) 1.4.0_14
c) 1.4.2_07
d) 1.5.0_07
e) 1.5.0_14
f) 1.5.1_14
I'm questioning Maven's current implementation of this feature regarding
the principle of least surprise or user intuition and would like to see
what others think. It basically boils down to the question when do we
consider a given Java version to match a boundary in the version range.
The actual results from Maven 2.2.1 (see end of mail) are rather
interesting so I suggest we attempt to fix the behavior, well knowing
that those JRE-sensitive profiles could affect dependency resolution.
In detail, I suggest to have Maven core adopt the approach taken by the
Enforcer Plugin [0] regarding normalization of the version with the
deviation to consider only the first three numeric parts (assume missing
parts to be 0) for the comparison. This should make profile activation
more sane yet minimize disruption on existing POMs.
The rationale for the comparison using only three numeric parts is as
follows. The version format X.Y.Z is the greatest common denominator
between Maven- and OSGi-style versions. So in case we ever moved our
versioning scheme closer to OSGi, the comparison rule for the JDK-based
profile activator would we expressible in both worlds and not stick out
as some exceptional case. Besides, three numeric parts should really be
sufficient to denote Java versions, for instance IBM JDKs only report
three digits in java.version.
Benjamin
[0] http://maven.apache.org/enforcer/enforcer-rules/requireJavaVersion.html
a) inactive
b) active
c) active
d) active
e) inactive
f) inactive
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
