Also see
https://svn.apache.org/repos/asf/maven/surefire/trunk/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
line 494.
I tried to fix this a while back but it's a big mess and has a lot of unwanted
side effects.
Accessors shouldn't change a property, but this one does because only when you
really need the version, it's resolved (lazy init). Though I don't understand
why X-SNAPSHOT needs to be resolved to the timestamped version to determine
wheter it is a snapshot..
btw, baseversion is the version containing the SNAPSHOT keyword,
version is the one containing the timestamp-buildernumber IIRC.
-- Kenney
Hervé BOUTEMY wrote:
Le mercredi 20 juin 2007, Brian E. Fox a écrit :
I discovered http://jira.codehaus.org/browse/MNG-2961 while working on
mdep a while back.
same for me while working on http://jira.codehaus.org/browse/MANTTASKS-18
It should be an easy fix but I'm pondering what the
least intrusive fix is.
thought it would be easy too, but as you mention, it must be the least
intrusive: that's the hard part.
Clearly calling a Boolean method shouldn't
result in a change to some other variable so we should do something.
Changing it to always returns xxx-SNAPSHOT as it does after calling
isSnapshot has the potential to break things depending on existing
behavior. The cleanest way forward is most likely to not have isSnapshot
modify the version, and to create a new method that returns xxx-SNAPSHOT
and leave getBaseVersion to return just the xxx-timestamp. (not sure
what this method would be called...getNonResolvedBaseVersion)
WDYT?
creating a new method is intrusive since this new method has to be used now:
in this case, I know of
o.a.m.artifact.repository.layout.DefaultRepositoryLayout.pathOf(), but I
suppose there are others.
To avoid a change in the API, I was thinking at modifying setVersion() and
setBaseVersion() to do the job actually done in isSnapshot(). But I don't
really understand the semantics of setBaseVersion(): as you noted, this has
the potential to break things.
To make a good decision, I think the first thing is to clearly describe the
semantics of version and baseVersion: perhaps it is already clearly explained
somewhere, but I don't know where. Depending the result, we'll be able to
decide if the API has to be extended, or only the implementation fixed (and
assume if it breaks something that works now but shouldn't because
baseVersion had been used where version should have).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
