ndrea Cosentino
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 op
ne 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
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
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.
Any thoughts about list vs table?
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Wednesday, June 29, 2016 3:56 PM, Andrea Cosentino
wrote:
Maybe
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
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
Yeah! Thanks!
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Thursday, June 9, 2016 3:43 PM, Claus Ibsen wrote:
Hi
I added so the tool will skip
Hi
I added so the tool will skip some modules in that check
https://github.com/apache/camel/commit/9491da8f393fa95fb33cf3afcb65dab88be63f86
We can add to that list later if we find out some more do not need adoc files.
On Thu, Jun 9, 2016 at 3:25 PM, Andrea Cosentino
wrote:
> Yeah, sorry my m
Yeah, sorry my mistake. I always forge to clean up :-)
New list
[WARNING] Missing document detected: 28
[WARNING] camel-atmos
[WARNING] camel-cm-sms
[WARNING] camel-coap
[WARNING] camel-context
[WARNING] camel-core-osgi
[
Hi
Great to hear we are so far away already.
For that list there is some false alarms we can turn off, such as some
of those test modules etc.
Also the list seems to look in dirs that has been removed.
You can try run
git clean -d -f
On Thu, Jun 9, 2016 at 2:33 PM, Andrea Cosentino
wrote:
Currently I've migrated the biggest part of components from confluence to
Asciidoc.
Maybe there are still asciidoc file that don't have the placeholder for
automatic generation of docs. If you find them, please commit the change and
re-generate documentation.
Using the catalog maven plugin I h
On Wed, Jan 27, 2016 at 4:10 PM, Antonin Stefanutti
wrote:
> I’ve just tried it successfully for the Twitter component (both component and
> endpoint options).
>
> That’d be nice to have the ability to style the description. For example
> {@code TwitterComponent} from the Javadoc would render as
I’ve just tried it successfully for the Twitter component (both component and
endpoint options).
That’d be nice to have the ability to style the description. For example {@code
TwitterComponent} from the Javadoc would render as an inline code block in the
description column.
Antonin
> On 27
Hi
I just added support for component option as well, so its similar
style. Add comments but use component instead of endpoint.
And I enabled the goal to run on components/pom.xml so it runs by default now.
So you should be able to try this on all the existing .adoc files.
On Wed, Jan 27, 201
Ok, then we'll continue to import docs and when we have enough material we can
add comments everywhere :-)
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Wednesday, January
> On 27 Jan 2016, at 13:51, Claus Ibsen wrote:
>
> On Wed, Jan 27, 2016 at 1:07 PM, Antonin Stefanutti
> wrote:
>> Yes I think we should add the comments.
>>
>> For the SJMS and Metrics components, it shows the need to be able to
>> categorise the options. Obvious categories would be 'consume
On Wed, Jan 27, 2016 at 1:07 PM, Antonin Stefanutti
wrote:
> Yes I think we should add the comments.
>
> For the SJMS and Metrics components, it shows the need to be able to
> categorise the options. Obvious categories would be 'consumer' and 'producer'
> though for components like Metrics, some
On Wed, Jan 27, 2016 at 12:42 PM, Andrea Cosentino
wrote:
> Maybe we can start adding the comments
>
Yeah we could try that, basically move the plugin from camel-ahc to
the components/pom.xml so it runs for all those components.
It only do changes if there is an .adoc file and that it has those
Yes I think we should add the comments.
For the SJMS and Metrics components, it shows the need to be able to categorise
the options. Obvious categories would be 'consumer' and 'producer' though for
components like Metrics, some options are only applicable to a certain URI
remaining that are com
Maybe we can start adding the comments
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Wednesday, January 27, 2016 11:25 AM, Claus Ibsen
wrote:
Hi
I worked a bit more on
Maybe we can start adding the comments
// endpoint options: START
// endpoint options: END
on the asciidoc we've already committed.
WDYT?
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github:
Hi
I worked a bit more on this and have made the plugin update the
existing adoc file (if present). And I have used the camel-ahc as
experiment.
The online page at
https://github.com/apache/camel/blob/master/components/camel-ahc/src/main/docs/ahc.adoc
Has all those endpoint options generated fro
Great stuff,
Looking forward for the end of the docs migration to Asciidoc and the
integration of this in the full build process! :-)
Andrea
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Gi
Hi
I just pushed some code I started end of last year on a train ride
back when returning from x-mas holiday.
The code is in tooling/maven/camel-package-maven-plugin where there is
a new maven goal called update-readme.
https://github.com/apache/camel/blob/master/tooling/maven/camel-package-maven
For what it's worth, I've integrated gitbook into my maven build with the
help of a docker container:
maven-antrun-plugin
${maven-antrun-plugin.version}
gitbook-pdf
prepare-package
Hi Hiram
Thanks for experimenting with this.
Better documentation and ... website is something I would love to see happen.
All the hard work we have done with making Camel components "self
documenting" plays a part here, as we should be able to auto generate
part of the documentation, such as al
I took a crack at converting one of the wiki pages, the JMS component
reference. Seems like we can automate most of the work of exporting to
asciidoc format. I used the cxf-web tool [1] to export all the pages
with a template which only includes the body content. Then ran
`pandoc --from html --to
Hi Hiram,
Great! Thanks!
--
Andrea Cosentino
--
Apache Camel PMC Member
Apache Karaf Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd
On Thursday, January 21, 2016 4:29 PM, Hiram Chirino
wrote:
Hi folks,
The artemis project has been u
29 matches
Mail list logo
