Jason van Zyl wrote:
The other issues identify a problem that is a little harder to fix
only because I haven't figured out how it could be done without being
incompatible, even if what is currently happening - deploying poms
with a variable in the version element - is just wrong.
Not necessarily. A property referring to a profile activated on a
particular platform where it was expected to be evaluated during the
build would cause a problem. I don't think it's as straight forward as
interpolating prior to deployment. This is part of the overall process
we need a spec for. This is not a very concrete answer but there are
probably a range of things that can safely be interpolated and
probably make sense, any properties associated with profiles activate
by OS, JDK, or some other ad-hoc property referring to an environment
will probably cause problems. Should people do this, probably not. But
we never told them not to. Then how to you categorize what's allowed
and what's not. No idea.
I think Brian wanted to cut from 2.0.9 instead of 2.0.10 but you guys
should go for it. We just need to make sure the integration tests
actually mean something so when I try to match capabilities with a
potentially different implementation/solution it don't whack everyone.
This is somewhat off topic from versioning. I was specifically calling
out using a property for the artifact version. To leave that in the pom
when it is deployed is just wrong. I can think of all kinds of other
properties that shouldn't be replaced, so full interpolation is clearly
unacceptable.
I'm also a little unclear on the integration tests. I see a couple of
branches that appear to be for specific jira issues, but nothing else.
How are different tests run against maven trunk vs 2.0.x?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
