[
https://issues.apache.org/jira/browse/GROOVY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-5363:
------------------------------
Description:
Currently there is MarkupBuilder and StreamingMarkupBuilder. These should be
different implementations of the same interface. The choice of streaming or
non-streaming should be a constructor parameter or static virtual constructor
parameter, not a difference in (visible) class name.
The design should factor in JDK8's stream capabilities.
Assuming Groovy adds support for Java9 modules, this class would likely reside
in a new XML module along with a revamped slurper/parser. While designing the
module system or setting up the envisaged XML module aren't really within scope
of this issue, it would be good to factor in the requirements we know for
JDK9's module capabilities, i.e., it should have a unique package structure.
was:
Currently there is MarkupBuilder and StreamingMarkupBuilder. These should be
different implementations of the same interface. The choice of streaming or
non-streaming should be a constructor parameter or static virtual constructor
parameter, not a difference in (visible) class name.
The design should factor in JDK8's stream capabilities and almost certainly
JDK9's module capabilities, i.e., it would belong in a new xml module along
with a revamped slurper/parser. It should have a unique package structure
> MarkupBuilder and StreamingMarkupBuilder should merge
> -----------------------------------------------------
>
> Key: GROOVY-5363
> URL: https://issues.apache.org/jira/browse/GROOVY-5363
> Project: Groovy
> Issue Type: Bug
> Components: XML Processing
> Affects Versions: 2.0-beta-2
> Reporter: Russel Winder
> Labels: contrib
> Fix For: 3.x
>
>
> Currently there is MarkupBuilder and StreamingMarkupBuilder. These should be
> different implementations of the same interface. The choice of streaming or
> non-streaming should be a constructor parameter or static virtual constructor
> parameter, not a difference in (visible) class name.
> The design should factor in JDK8's stream capabilities.
> Assuming Groovy adds support for Java9 modules, this class would likely
> reside in a new XML module along with a revamped slurper/parser. While
> designing the module system or setting up the envisaged XML module aren't
> really within scope of this issue, it would be good to factor in the
> requirements we know for JDK9's module capabilities, i.e., it should have a
> unique package structure.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
