There is such a thing we used to call 'code slurping' where when I co-authored "Java Persistence with Hibernate Second Edition" [1], we automatically compiled, ran, and slurped in Java code into the XHTML source for the book using https://github.com/4thline/lemma, meaning zero Java code duplication, insuring the book generated by Maven was always in sync with the code example.
Gary [1] https://www.amazon.com/Java-Persistence-Hibernate-Christian-Bauer/dp/1617290459/ref=pd_lpo_sbs_14_img_0?_encoding=UTF8&psc=1&refRID=13Y7TDAQCNP7KKHZ2BZF On Tue, Aug 27, 2019 at 9:50 AM Matt Sicker <boa...@gmail.com> wrote: > The idea of automatically using unit tests as code samples in the > documentation sounds great! This sounds fairly interesting to me. > > On Tue, Aug 27, 2019 at 08:00, Peter Verhas <pe...@verhas.com> wrote: > > > I have seen looking over the code of the LANG3 project that there are a > lot > > of places where the code is copy/paste. Many times these copy/paste code > is > > the result of the shortages of the Java language. We implement methods > that > > look more or less the same but they have to be created for all primitive > > types. The maintenance of this code is cumbersome, changed at one place > has > > to be changed at the other places as well. > > > > The framework Java::Geci can automate the maintenance of those code > > fragments. The framework is a test dependency ONLY, so it does not > present > > an extra dependency for the users. > > > > The application of the framework can also be used to automatically > > copy/update code from the unit tests into the JavaDoc documentation, like > > copying and converting assertion statements into tables with inputs and > > results. > > > > I would be happy to create a few pull requests as a demonstration of how > > Java::Geci can be used for the purposes. > > > > QUESTION: > > > > What is your attitude towards a new tool like this? I do not ask a final > > decision for "yes we want to use it" or "no we do not want". I just want > to > > know if the developer community would consider the use of such a tool. > > > > A last note: The tool is extremely non-invasive. Any project using it can > > decide at any point to discontinue the use. All it needs is to delete the > > tests that start the tool, remove the dependency from the POM file and > that > > is it. > > > > -- > > Peter Verhas > > pe...@verhas.com > > t: +41791542095 > > skype: verhas > > > -- > Matt Sicker <boa...@gmail.com> >
