You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "François Martin (JIRA)" <ji...@apache.org> on 2017/09/29 20:24:06 UTC

[jira] [Commented] (GROOVY-5363) MarkupBuilder and StreamingMarkupBuilder should merge

    [ https://issues.apache.org/jira/browse/GROOVY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16186340#comment-16186340 ] 

François Martin commented on GROOVY-5363:
-----------------------------------------

I've just taken a look at the classes. As far as I can see, the obvious choice here would be to refactor the StreamingMarkupBuilder to MarkupBuilder, so that (like mentioned in the description) the choice of streaming or not would be made in the constructor. However, doing this would be quite a breaking change, since all code using the "StreamingMarkupBuilder" would need to be rewritten to be used with "MarkupBuilder", is this a consequence that we're willing to take into account for that? If yes, I can have a go at it.

> 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.4.14#64029)