On Tue, Mar 14, 2017 at 7:38 PM, Nadun De Silva <[email protected]> wrote:
> Hi, > > Thank you for the response. I have researched a bit more and have few more > follow-up questions > > It will not be in the current Siddhi format, we are thinking of a plain >> HTML and MD files which can be part of Siddhi Docs in Github. > > > Then I think when the Mojo is executed, I should create the HTML and MD > files inside the maven project so that with each push, the GitHub repos are > updated. Is this what is expected? > Yes > > Can have multiple pages (one per namespace) and having index and >> navigation across is good. Please present your suggestion we can discuss >> and come to a conclusion on this. >> > > Since by the time the combination happens, all the documentation is in > GitHub repos, my suggestion would be to get the content of the generated > HTML files using the GitHub contents API [1] and then combine them. But > this will be a separate program which will be run for the combination alone. > > If we decide to use this approach, I would suggest implementing one of the > following or any other method for rerunning the combination process. > > - A server listening to GitHub webhooks [2] > - A scheduled task > > What is your opinion about this approach? > > We are moving extensions to wso2-extensions repo[5] and going to host all of them in the extension store[6] so each extension will have it's own doc, and siddhi-core might have one with the predefined functions. We might not need to combine multiple repos together at this point, but when there are multiple extsnsions within the same repo they need to be properly organized. If time permits we can explore how we can merge then, but it's not a requirement at this point. [5]https://github.com/wso2-extensions/?q=siddhi&type=&language= [6]https://store.wso2.com/store/assets/analyticsextension/list > I also have a question about the Siddhi annotations. At the moment, all > the details are in one annotation called "@Extension" [3] and it does not > contain the "return value" of the extension. How can I fetch the return > value of functions from the current annotation system? > > We have to change the previous implementation to bring all into one annotation as we did some improvements to optimize extension class loading and that needed a single extension annotation. To identify the return value use the "returnAttributes()": for functions this will have only the return type and no names, for windows this will return empty, and for stream processors this can have some attributes with names. Regards Suho [1] https://developer.github.com/v3/repos/contents/#get-contents > [2] https://developer.github.com/webhooks/ > [3] https://github.com/wso2/siddhi/blob/master/modules/ > siddhi-annotations/src/main/java/org/wso2/siddhi/annotation/Extension.java > > Thank you. > > On Mon, Mar 13, 2017 at 10:04 PM, Sriskandarajah Suhothayan <[email protected] > > wrote: > >> >> >> On Sat, Mar 11, 2017 at 8:45 PM, Nadun De Silva <[email protected]> >> wrote: >> >>> Hi, >>> >>> I am an undergraduate at the University of Moratuwa in my final year. I >>> also worked as an intern at WSO2 last year. >>> >>> I am interested in *"Siddhi Extension Doc Auto Generation"* GSoC >>> project. I have worked with WSO2 CEP and Siddhi during my internship and I >>> am also familiar with the Siddhi annotations. >>> >>> I went through the references provided and I would be very grateful if I >>> can get more guidance on how I can learn more details about the project. >>> Some of the questions I have are as follows. >>> >>> 1. Does the final HTML pages need to be deployed into the current >>> Siddhi documentation and if so is that part of the project scope? >>> >>> It will not be in the current Siddhi format, we are thinking of a plain >> HTML and MD files which can be part of Siddhi Docs in Github. >> >>> >>> 1. Does the combined documentation (Deliverable 3) need to be in the >>> same structure the current documentation is in? (If not the combination >>> can >>> maybe be achieved by having separate pages for extension namespaces with >>> proper navigation between them) >>> >>> Can have multiple pages (one per namespace) and having index and >> navigation across is good. Please present your suggestion we can discuss >> and come to a conclusion on this. >> >>> >>> 1. If I understood correctly the project does not cover the inbuilt >>> processors. Please correct me if I'm wrong. >>> >>> We have now done some improvements, and now the internal functions too >> support annotations, so they can also be generated with the approach. >> >> Regards >> Suho >> >> >>> Thank you. >>> >>> Nadun De Silva >>> Undergraduate of Computer Science and Engineering >>> University of Moratuwa >>> https://lk.linkedin.com/in/nadundesilva >>> >> >> >> >> -- >> >> *S. Suhothayan* >> Associate Director / Architect & Team Lead of WSO2 Complex Event >> Processor >> *WSO2 Inc. *http://wso2.com >> * <http://wso2.com/>* >> lean . enterprise . middleware >> >> >> *cell: (+94) 779 756 757 <077%20975%206757> | blog: >> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: >> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: >> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* >> > > > > -- > > [image: profile_pic.jpg] > > Nadun De Silva > > Undergraduate of Computer Science and Engineering > > University of Moratuwa > > [image: GitHub.png] <https://github.com/nadundesilva> [image: > LinkedIn.png] <http://www.linkedin.com/in/nadundesilva> [image: > Facebook.png] <https://www.facebook.com/nadunrds> > > Mobile: > > (+94) 77 8 222 607 > > Email: > > [email protected] > -- *S. Suhothayan* Associate Director / Architect & Team Lead of WSO2 Complex Event Processor *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
