You can't, this is why in the enforcer rule, I have to walk and
interpolate the entire tree. If I could get the model from maven
unmolested, I could cut out 99% of that code.
-Original Message-
From: Stephen Connolly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 6:31 AM
Grrr argh!
Ok, hmm I'll have a closer look at your code as you did not seem to be
parsing the XML from my initial reading of the code
On Wed, Sep 3, 2008 at 3:15 PM, Brian E. Fox [EMAIL PROTECTED]wrote:
You can't, this is why in the enforcer rule, I have to walk and
interpolate the entire
FWIW, the reimplemented cloneModel(..) method (which in part causes this
problem, because it clones too shallowly) should keep the originalModel
instance from being polluted with resolved plugin information.
I *think* the integration test for MNG-3710 should cover this case, but
I can't
That's in the stuff I've been putting out in RCs, to be clear...
John Casey wrote:
FWIW, the reimplemented cloneModel(..) method (which in part causes this
problem, because it clones too shallowly) should keep the originalModel
instance from being polluted with resolved plugin information.
I
I thought it needed a full deep copy to preserve the model and we
decided to back away from that in this release? I remember discussing
it, but not the exact outcome.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 1:20 PM
To: Maven
I wound up putting it in since the clone methods were a performance
problem, and the solution was to do direct object construction and avoid
all the tangled logic inside the inheritance assembler.
Now that we're [potentially] transitioning from concrete to dynamic and
back in the build
ok, so the end result is that if I want my plugin to work with 2.0.6+
I need to parse the pom by hand in order to determine what is in the
pluginManagement section and which bits are missing a version
specification?
Sent from my iPod
On 3 Sep 2008, at 19:18, John Casey [EMAIL PROTECTED]
