Is your use case providing the user the path to navigate back to the originating model/element from the effective POM? Or is it refactoring the POM or both?
On Jul 18, 2012, at 2:32 AM, Milos Kleint wrote: > Hello, > > I've created issue https://jira.codehaus.org/browse/MNG-5309 along > with a prototype patch to tackle the issue of missing InputLocation > elements for Xpp3Dom part of the model, that's mostly plugin's > configuration.. > > The patch replaces the plexus-utils Xpp3Dom code for merging with one > that additionally merges the InputLocation trees. The key used in > InputLocation's children is the Xpp3Dom object itself. Appears to be > working even though the hashcode and equals methods for Xpp3Dom change > based on content *and* child nodes. > issue 1: do we attempt to push the location aware merging code back > down to plexus-utils or keep it in maven? > > issue2: the populating of InputLocation tree is not covered so far, > just proof of concept post-processing after the Xpp3 reader creates > the Model object tree. Should this go to modello? where are the > current master sources of modello? > > Thank you > > Milos Kleint > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
