On Wed, Jul 18, 2012 at 2:44 PM, Jason van Zyl 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 in
> Model
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:34 PM, Jason van Zyl 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. haven't
thought
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
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 a
