You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Andrea Cosentino <an...@yahoo.com.INVALID> on 2016/07/03 07:06:22 UTC

Re: gitbook based doc generation

What do you prefer for the component/endpoint options tables or list?
 --
Andrea Cosentino 
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Thursday, June 30, 2016 3:52 PM, Andrea Cosentino <an...@yahoo.com.INVALID> wrote:
I believe that we need to maintain the base of documentation in a root folder /docs (like we are doing now). In that way we will have a separation between automatically generated docs and not.

I'll try migrating first all the docs we have and then we can adjust directory structure and so on :-)
--
Andrea Cosentino 
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd



----- Original Message -----
From: Claus Ibsen <cl...@gmail.com>
To: dev <de...@camel.apache.org>; Andrea Cosentino <an...@yahoo.com>
Sent: Thursday, June 30, 2016 3:39 PM
Subject: Re: gitbook based doc generation

Great work so far.

We also need to auto generate the EIP options. And the same for data
formats. And maybe also languages, though most of them don't have
options, but there a few that have some special options like jsonpath
for supressing exceptions.

And then we need to find a directory structure so there is no clash,
today they end up in src/main/docs.

But camel-core and others have many components/langauges etc and some
have naming clash.
For example mvel has both a component and language (afair).

But that said we can also work on a look and feel of how to show this
in a website, and on github.









On Thu, Jun 30, 2016 at 3:31 PM, Andrea Cosentino
<an...@yahoo.com.invalid> wrote:
> I finished with the components migration.
>
> Currently we miss only camel-ignite (it has a particular structure and the automatic generation of docs doesn't seem to work with it) and camel-tarfile (the page on confluence doesn't exist).
>
> I'll add all the other part from confluence and let you know.
>
> If someone would like to help, camel-ignite and camel-tarfile need asciidoc documentation.
>
> We are not so far from completing the migration of all the docs.
>
> Maybe, it's time to think to the new website...
>  --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Thursday, June 30, 2016 11:26 AM, Andrea Cosentino <an...@yahoo.com.INVALID> wrote:
> Any thoughts about list vs table?
> --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
> On Wednesday, June 29, 2016 3:56 PM, Andrea Cosentino <an...@yahoo.com.INVALID> wrote:
> Maybe it's a good idea to use a list, we can avoid the tables scrolling problem in this way.
>
> From the other side the readability can be difficult when you have components/endpoints with a lot of options.
>
> What do you think, guys?
> --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
>
> On Wednesday, June 29, 2016 12:04 PM, arno noordover <an...@gmail.com> wrote:
> When you search for best-practices for ascii-doc people say that you should
> only use tables for data that needs to be presented as a table.
> Based on this best-practice I would like to propose some kind of "list"
> presentation for the configurations.
> I have post my result on  http://www.noordover.net/ssh.html
> <http://www.noordover.net/ssh.html>  .
> Please provide comments on the way we should implement this.
>
> If this is the way forward we must also find a solution for the
> endpoint-configuration containing the groups.
> I think we should present the configurations grouped by "group".
> Does anybody know how this is done in mvel?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/gitbook-based-doc-generation-tp5776497p5784543.html
> Sent from the Camel Development mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2