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
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
On Wed, Jul 18, 2012 at 2:34 PM, Jason van Zyl ja...@tesla.io wrote:
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?
to show where it's defined and allow jumping to the location.
The only thing I would check, because I can't remember off the top of my head,
is if the merge code is generated or if it's a utility class. If it's a utility
class then it probably doesn't much matter but would be nice back in Modello.
If it's generated it should go back to Modello (or Plexus,
On Wed, Jul 18, 2012 at 2:44 PM, Jason van Zyl ja...@tesla.io wrote:
The only thing I would check, because I can't remember off the top of my
head, is if the merge code is generated or if it's a utility class. If it's a
utility class then it probably doesn't much matter but would be nice back
On 28/06/12 9:41 PM, Milos Kleint wrote:
Hello,
I'm in the process of rewriting the nbm-maven-plugin at mojo to use
the new annotations instead of javadoc tags. It appears to be working
fine, but I'm wondering why the retention policy is CLASS. Since it's
First up I must say I love the new
