[
https://issues.apache.org/jira/browse/MNG-8490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916628#comment-17916628
]
Guillaume Nodet commented on MNG-8490:
--------------------------------------
So here are a few arguments:
* decoupling is usually done through abstraction. Even if C++ has no concept
of interface, it can defines pure abstract classes and support multiple
inheritance. Interfaces were seen as an improvement over this pattern a few
decades ago IIRC.
* testing by using mocking requires abstraction, it's much more difficult to
achieve without that
* your argument about looking at the code and checking if there are multiple
implementations only works in a closed environment, where you actually know all
implementations. Maven can be extended through custom syntaxes, but plugin
configuration is represented by {{{}XmlNode{}}}. If we were to support yaml, I
can easily think about an {{XmlNode}} implementation backed by a yaml node that
has been returned by a parser. So imho, this argument does not hold. People
may want to provide their own implementation for unforeseen reasons, and I
prefer adding an abstraction now that can be used later, rather than not adding
it and having no way to extend when the time comes.
Anyway, if you propose a PR which fixes the various problems raised in the
other one, we can continue the discussion:
{quote}
A few points need to be addressed:
* no third party dependency in the API
* no dependency on plexus-xml, this would re-create a cyclic dependency
* use an interface + builder api, similar to other data classes in the API
* the merge code needs to be abstracted and decoupled using a service
interface so that it can be used from plugins (they are only provided with the
API jars)
For the merge service, maybe using a factory using {{ServiceLoader}} if we want
to make that generally available. However, if we only target plugins, a service
accessible from the {{Session}} could actually be used.
But we do have plugins that use {{Xpp3Dom.mergeXpp3Dom}} so that feature cannot
be removed from the API.
{quote}
> Combine XmlNode and XmlNodeImpl
> -------------------------------
>
> Key: MNG-8490
> URL: https://issues.apache.org/jira/browse/MNG-8490
> Project: Maven
> Issue Type: Improvement
> Reporter: Elliotte Rusty Harold
> Priority: Blocker
> Labels: up-for-grabs
>
> Single use interfaces are an antipattern. Make everything simpler by having a
> single concrete XmlNode class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
