[
https://jira.jboss.org/jira/browse/SHRINKWRAP-81?page=com.atlassian.jira....
]
Andrew Lee Rubinger commented on SHRINKWRAP-81:
-----------------------------------------------
I'm not understanding why we'd desire the use cases above?
In my opinion (and I think this is an issue for developer preference), and export is the
end of the chain. Consider:
archive.as(ZipExporter.class).exportZip();
This returns an InputStream, so the no-arg version can never continue method chaining
(unless we wrap the InputStream and return it, an unnecessary step for most uses). In
this setup the no-arg version would not be chainable, but the version that accepts File or
OutputStream would.
My feeling is that after export, developers can hit the RETURN button and start a new line
of code. My thought process while writing is:
1) Make an archive, add this, add that, add another thing
2) Export as ZIP.
2) Add something else to the archive, export in another format.
A more compelling case I haven't thought of?
Create non chain breaking versions of Exporter methods
------------------------------------------------------
Key: SHRINKWRAP-81
URL:
https://jira.jboss.org/jira/browse/SHRINKWRAP-81
Project: ShrinkWrap
Issue Type: Task
Reporter: Aslak Knutsen
We should support to continue the method chaining after a Export.
use case:
archive.as(ZipExporter).zip(output)
.as(TarExporter).tar(output)
archive.as(ZipExporter).zip(output)
.addResource(javaDoc)
.addResource(Source)
.as(TarExporter).tar(fulldist)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira