You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Michael Brohl <mi...@ecomify.de> on 2018/03/12 09:04:25 UTC

Re: [Discussion] documentation framework for OFBiz

Hi Taher,

I worked on the documentation over the weekend.

It would be very nice if the documentation gets updated even if the main 
document has not changed. If you change only included documents, the 
change does not go into the main document.

I briefly searched for a configuration parameter but did not find any.

Best regards,

Michael


Am 24.02.18 um 15:44 schrieb Michael Brohl:
> I have tried Taher's latest patch and it is working great for me. I 
> used Intellij Idea with the Asciidoc Plugin.
>
> Differently from Olivier's observation, the main developer-manual ist 
> updated when I make a change in developer-manual.adoc. Both html and 
> pdf include the change.
>
> It is not updated when I only change an included document like 
> accounting.adoc. I think it would be good to recreate all files if 
> they have chnaged or not. If I'm not wrong, both SVN and Git notice if 
> a file has not be changed even if it is rewritten so it should be no 
> problem.
>
> I think this is a good starting point, more pints might come up if we 
> use it more intensely.
>
> Thanks,
>
> Michael
>
>
> Am 21.02.18 um 14:08 schrieb Olivier Heintz:
>> Thank you for the work, Taher
>>
>> I have played with it and merge with my tests.
>> Currently, I have start from Accounting_Agreement, convert from 
>> docbook and update and
>> test renderer by both your gradle task and by AsciidocFx html button
>>
>> With a lot of include, result html file would be very large and in 
>> some case it will be good to be able to put a link in place
>> of include. Currenlty the generateOfbizDocumentation task doesn't 
>> generate file for doc in component even if the adoc file is
>> not in the _include directory.
>>
>> Just for information: With AsciidocFx (I have understood it use 
>> asciidoctor for generate html file, but I'm not sure)
>> it's not necessary to say include file is in _include directory, it 
>> read both in the current directory and in the _include one.
>> The generateOfbizDocumentation task doesn't use the same rule, we 
>> should say explicitly it's in the _include directory.
>>
>> The main "malfunction" of the generateOfbizDocumentation task is that 
>> it not re-generate the html file if it already exist
>> even if the main adoc file was modified. So it's needed to remove it 
>> manually before call generateOfbizDocumentation.
>>
>> Thank you for your usage of leveloffset, it's generated by docbook 
>> conversion, but now I understand how it works ;-)
>>
>>
>> Olivier
>>
>> Le 20/02/2018 à 17:48, Taher Alkhateeb a écrit :
>>> Hello documentation team and everyone
>>>
>>> I have created a slightly modified design of the documentation
>>> framework with some sample contents in [1]. I highlight the changes
>>> below:
>>> - Created a new top-level directory called "docs/asciidoc". The reason
>>> is so that we have more than one possible manual.
>>> - Created "Apache OFBiz User Manual" in docs/asciidoc/user-manual.adoc
>>> - Created "Apache OFBiz Developer Manual" in 
>>> docs/asciidoc/developer-manual.adoc
>>> - Created a sample document in the accounting component to show how
>>> documents are linked together.
>>> - Used a special directive called "leveloffset" in the include
>>> directive. This directive shifts the headers of the included document
>>> (H2 becomes H3, and so on) so that sub-sections can be published
>>> separately.
>>> - Created a task called generateOfbizDocumentation to generate the
>>> documentation (both PDF and HTML) for framework + core apps
>>> - Created a task called generatePluginDocumentation
>>> -PpluginId=whatever to generate the documentation for a single plugin.
>>>
>>> That's it. It's simple, easy to understand and I think you might like
>>> it. Any feedback is welcome, and I'll talk to you soon over Skype.
>>>
>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9873
>>>
>>> On Tue, Jan 30, 2018 at 4:38 PM, Sharan Foga <sh...@apache.org> wrote:
>>>> Hi Taher
>>>>
>>>> I think a documentation team would be a great idea. There are 
>>>> people that have indicated that they'd like to help out with 
>>>> documentation tasks on the user list so that is where I'd recruit 
>>>> some people from. As long as people know what they need to do to 
>>>> create the patches then it will become a funnel process of getting 
>>>> it committed.
>>>>
>>>> We need a plan to consolidate the information sitting in the wiki 
>>>> and getting it put into the documentation framework (and this work 
>>>> will then significantly clear up the wiki!).
>>>>
>>>> My availability is pretty bad this week so hope to pick this up 
>>>> again or start the recruitment campaign next week :-)
>>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>> On 2018/01/28 10:12:41, Taher Alkhateeb 
>>>> <sl...@gmail.com> wrote:
>>>>> Like Michael I think it is also a minor point. The reason I chose 
>>>>> this
>>>>> structure is because it is the default one for asciidoctor and is 
>>>>> flexible
>>>>> for the future, so Paul also makes a good point. Any structure is 
>>>>> fine by
>>>>> me, the real important work is getting the documentation right 
>>>>> which is
>>>>> very exciting to me.
>>>>>
>>>>> I will create a patch soon for a base level structure and publishing
>>>>> options for both HTML and PDF. It would be fantastic if we can 
>>>>> unify _all_
>>>>> of our documentation here including stuff currently in the wiki. 
>>>>> This way
>>>>> any changes to code are reflected (probably in the same commit) 
>>>>> with the
>>>>> relevant documentation.
>>>>>
>>>>> I think we should start to consider maybe forming a team willing 
>>>>> to help.
>>>>> This is a big, but extremely important thing to have. If we do 
>>>>> this right
>>>>> then I think adoption rates would increase and our community would 
>>>>> get
>>>>> larger.
>>>>>
>>>>> On Jan 28, 2018 12:19 PM, "Michael Brohl" 
>>>>> <mi...@ecomify.de> wrote:
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> this is only a minor point for me, it just saves one 
>>>>> folder/structure level.
>>>>>
>>>>> If we want to stay open for other documentation frameworks in the 
>>>>> future,
>>>>> it might be better to keep the proposed structure.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 28.01.18 um 02:54 schrieb Paul Foxworthy:
>>>>>
>>>>> On 26 January 2018 at 19:53, Michael Brohl 
>>>>> <mi...@ecomify.de> wrote:
>>>>>>
>>>>>> with a small modification: I don't think we'll need a two-folder 
>>>>>> structure
>>>>>>> /docs/asciidoc, only /docs should be sufficient, no?
>>>>>>>
>>>>>>> Hi Michael,
>>>>>> We have streamlined the build system in other places by having 
>>>>>> folders for
>>>>>> the source language: groovyScripts, minilang, src/main/java .
>>>>>>
>>>>>> It means Groovy and other build tools can have default rules for 
>>>>>> what to do
>>>>>> with the contents of a language folder, and allows for the 
>>>>>> possibility of
>>>>>> other languages in future if necessary.
>>>>>>
>>>>>> The extra layer is only a minor nuisance. I think I'd prefer to 
>>>>>> keep it.
>>>>>> What do you see as the disadvantages?
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Paul Foxworthy
>>>>>>
>>>>>>
>
>



Re: Listing All Menu Items

Posted by Craig Parker <cr...@fossfolks.com>.
This is kind of what I'm looking for. Thanks. I think I can grab what I 
need now that I from about those files. I was hoping to make a "world 
atlas" of OFBiz, mostly to keep track of what is even out there (I 
haven't nearly been to all of it) and then down the road I hope to use 
some form of it, maybe as part of a larger PHP app, on my end to keep 
track of which end users have received training on which applications.

I was also trying to find a way to get the list automatically. I think 
that with Deepak's latest reply I can write a short shell script that 
will grab at least the top two levels and stick them into a format I can 
use, then down the road I can just run it again if the menus have 
changed. I've done it manually once, when creating a Wordpress theme 
menu that matched the menu layout in the OFBiz Tomahawk theme, and just 
didn't want to go through that whole process by hand again.


On 03/13/2018 02:18 AM, Deepak Dixit wrote:
> Hi Craig,
>
> Main menu item rendered through webapp not from component. A component can
> have multiple webapp. Ex.
>
> https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/applications/accounting/ofbiz-component.xml
>
>
> All webapp will be display by defuaut as menu item, if app-bar-display is
> set false it will not display as menu item.
> https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk/ecommerce/ofbiz-component.xml
>
>
> And sub-menu items display from Decorator, We can set secondary menu at
> decorator level
>
> <set field="applicationMenuName" value="OrderAppBar" global="true"/>
> <set field="applicationMenuLocation"
> value="component://order/widget/ordermgr/OrderMenus.xml"
> global="true"/>
>
>   MenuFactory.getMenuFromLocation method render these sub-menu items.
> Please refer
> https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/themes/tomahawk/template/AppBarOpen.ftl
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Tue, Mar 13, 2018 at 1:30 AM, Craig Parker <cr...@fossfolks.com> wrote:
>
>> I'm not a dev, so a lot of what you had me read wasn't clear. I am
>> familiar with MySQL though. These menu "sub items" aren't listed in the db
>> anywhere? I'm looking manually now in my servers information_schema db, but
>> if you know how to save me looking through a gazillion column names, I'm
>> all ears. :) If you can't, no biggie. I'd just hate to look all this time
>> and find out in the end that they're not there.
>>
>>
>> On 03/12/2018 01:47 PM, Deepak Dixit wrote:
>>
>>> Hi Craig,
>>>
>>> Please have a look at LoginWorker.getAppBarWebInfos and ComponentConfig.
>>> getAppBarWebInfos method.
>>> For reference you can have a look at themes/flatgrey/template/AppBar.ftl
>>>
>>> Thanks & Regards
>>> --
>>> Deepak Dixit
>>> www.hotwaxsystems.com
>>> www.hotwax.co
>>>
>>> On Mon, Mar 12, 2018 at 9:56 PM, Craig Parker <cr...@fossfolks.com>
>>> wrote:
>>>
>>> I'm running a clean slate install on MySQL, and trying to locate the main
>>>> OFBiz menu. Looks like there's a db named ofbiztenant with a table called
>>>> COMPONENT, and that appears to have at least the top level menu items.
>>>> Where are the others?
>>>>
>>>> Nothing official, but I'm trying to make a spreadsheet or something I can
>>>> print out for myself so that I can keep track of things going on in each
>>>> part of the software. I don't see the big picture yet, and I'm hoping
>>>> this
>>>> might help. :)
>>>>
>>>>


Re: Listing All Menu Items

Posted by Rajesh Mallah <ma...@gmail.com>.
Hi Deepak ,

I guess you suggested the below:

<#assign displayApps =
Static["org.apache.ofbiz.webapp.control.LoginWorker"].*getAppBarWebInfos*(security,
userLogin, ofbizServerName, "*main*")>
<#assign displaySecondaryApps =
Static["org.apache.ofbiz.webapp.control.LoginWorker"].*getAppBarWebInfos*(security,
userLogin, ofbizServerName, "*secondary*")>


Are there entities that back *getAppBarWebInfos *?

I guess that would help .


regds
mallah.


On Tue, Mar 13, 2018 at 7:49 AM, Paul Foxworthy <pa...@cohsoft.com.au> wrote:

> Hi Craig,
>
> The major menu items correspond to major entities in the data model (Party,
> Product, Facility and so on). But many of the menu items are verbs and the
> entities are nouns.
>
> To explore the data model:
>
> Read the Data Model Resource Books, especially volume 1.
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Related+Books#
> OFBizRelatedBooks-TheDataModelResourceBook,Volumes1,2&3
>   http://isbn.nu/9781118082324
>
> Download the Big Book of Apache OFBiz Data Model from
> https://cwiki.apache.org/confluence/display/OFBIZ/Data+Model+Diagrams
>
> Use the Web Tools to explore the entities and the data. On the demo site,
> start at https://demo-trunk.ofbiz.apache.org/webtools/control/entitymaint
> .
>
> Cheers
>
> Paul Foxworthy
>
>
> On 13 March 2018 at 07:00, Craig Parker <cr...@fossfolks.com> wrote:
>
> > I'm not a dev, so a lot of what you had me read wasn't clear. I am
> > familiar with MySQL though. These menu "sub items" aren't listed in the
> db
> > anywhere? I'm looking manually now in my servers information_schema db,
> but
> > if you know how to save me looking through a gazillion column names, I'm
> > all ears. :) If you can't, no biggie. I'd just hate to look all this time
> > and find out in the end that they're not there.
> >
> >
> >
> > On 03/12/2018 01:47 PM, Deepak Dixit wrote:
> >
> >> Hi Craig,
> >>
> >> Please have a look at LoginWorker.getAppBarWebInfos and ComponentConfig.
> >> getAppBarWebInfos method.
> >> For reference you can have a look at themes/flatgrey/template/
> AppBar.ftl
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Dixit
> >> www.hotwaxsystems.com
> >> www.hotwax.co
> >>
> >> On Mon, Mar 12, 2018 at 9:56 PM, Craig Parker <cr...@fossfolks.com>
> >> wrote:
> >>
> >> I'm running a clean slate install on MySQL, and trying to locate the
> main
> >>> OFBiz menu. Looks like there's a db named ofbiztenant with a table
> called
> >>> COMPONENT, and that appears to have at least the top level menu items.
> >>> Where are the others?
> >>>
> >>> Nothing official, but I'm trying to make a spreadsheet or something I
> can
> >>> print out for myself so that I can keep track of things going on in
> each
> >>> part of the software. I don't see the big picture yet, and I'm hoping
> >>> this
> >>> might help. :)
> >>>
> >>>
> >
>
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: +61 3 9585 6788
> Web: http://www.coherentsoftware.com.au/
> Email: info@coherentsoftware.com.au
>

Re: Listing All Menu Items

Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Hi Craig,

The major menu items correspond to major entities in the data model (Party,
Product, Facility and so on). But many of the menu items are verbs and the
entities are nouns.

To explore the data model:

Read the Data Model Resource Books, especially volume 1.
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Related+Books#OFBizRelatedBooks-TheDataModelResourceBook,Volumes1,2&3
  http://isbn.nu/9781118082324

Download the Big Book of Apache OFBiz Data Model from
https://cwiki.apache.org/confluence/display/OFBIZ/Data+Model+Diagrams

Use the Web Tools to explore the entities and the data. On the demo site,
start at https://demo-trunk.ofbiz.apache.org/webtools/control/entitymaint .

Cheers

Paul Foxworthy


On 13 March 2018 at 07:00, Craig Parker <cr...@fossfolks.com> wrote:

> I'm not a dev, so a lot of what you had me read wasn't clear. I am
> familiar with MySQL though. These menu "sub items" aren't listed in the db
> anywhere? I'm looking manually now in my servers information_schema db, but
> if you know how to save me looking through a gazillion column names, I'm
> all ears. :) If you can't, no biggie. I'd just hate to look all this time
> and find out in the end that they're not there.
>
>
>
> On 03/12/2018 01:47 PM, Deepak Dixit wrote:
>
>> Hi Craig,
>>
>> Please have a look at LoginWorker.getAppBarWebInfos and ComponentConfig.
>> getAppBarWebInfos method.
>> For reference you can have a look at themes/flatgrey/template/AppBar.ftl
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Mon, Mar 12, 2018 at 9:56 PM, Craig Parker <cr...@fossfolks.com>
>> wrote:
>>
>> I'm running a clean slate install on MySQL, and trying to locate the main
>>> OFBiz menu. Looks like there's a db named ofbiztenant with a table called
>>> COMPONENT, and that appears to have at least the top level menu items.
>>> Where are the others?
>>>
>>> Nothing official, but I'm trying to make a spreadsheet or something I can
>>> print out for myself so that I can keep track of things going on in each
>>> part of the software. I don't see the big picture yet, and I'm hoping
>>> this
>>> might help. :)
>>>
>>>
>


-- 
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: info@coherentsoftware.com.au

Re: Listing All Menu Items

Posted by Deepak Dixit <de...@hotwaxsystems.com>.
Hi Craig,

Main menu item rendered through webapp not from component. A component can
have multiple webapp. Ex.

https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/applications/accounting/ofbiz-component.xml


All webapp will be display by defuaut as menu item, if app-bar-display is
set false it will not display as menu item.
https://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk/ecommerce/ofbiz-component.xml


And sub-menu items display from Decorator, We can set secondary menu at
decorator level

<set field="applicationMenuName" value="OrderAppBar" global="true"/>
<set field="applicationMenuLocation"
value="component://order/widget/ordermgr/OrderMenus.xml"
global="true"/>

 MenuFactory.getMenuFromLocation method render these sub-menu items.
Please refer
https://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk/themes/tomahawk/template/AppBarOpen.ftl


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Tue, Mar 13, 2018 at 1:30 AM, Craig Parker <cr...@fossfolks.com> wrote:

> I'm not a dev, so a lot of what you had me read wasn't clear. I am
> familiar with MySQL though. These menu "sub items" aren't listed in the db
> anywhere? I'm looking manually now in my servers information_schema db, but
> if you know how to save me looking through a gazillion column names, I'm
> all ears. :) If you can't, no biggie. I'd just hate to look all this time
> and find out in the end that they're not there.
>
>
> On 03/12/2018 01:47 PM, Deepak Dixit wrote:
>
>> Hi Craig,
>>
>> Please have a look at LoginWorker.getAppBarWebInfos and ComponentConfig.
>> getAppBarWebInfos method.
>> For reference you can have a look at themes/flatgrey/template/AppBar.ftl
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Mon, Mar 12, 2018 at 9:56 PM, Craig Parker <cr...@fossfolks.com>
>> wrote:
>>
>> I'm running a clean slate install on MySQL, and trying to locate the main
>>> OFBiz menu. Looks like there's a db named ofbiztenant with a table called
>>> COMPONENT, and that appears to have at least the top level menu items.
>>> Where are the others?
>>>
>>> Nothing official, but I'm trying to make a spreadsheet or something I can
>>> print out for myself so that I can keep track of things going on in each
>>> part of the software. I don't see the big picture yet, and I'm hoping
>>> this
>>> might help. :)
>>>
>>>
>

Re: Listing All Menu Items

Posted by Craig Parker <cr...@fossfolks.com>.
I'm not a dev, so a lot of what you had me read wasn't clear. I am 
familiar with MySQL though. These menu "sub items" aren't listed in the 
db anywhere? I'm looking manually now in my servers information_schema 
db, but if you know how to save me looking through a gazillion column 
names, I'm all ears. :) If you can't, no biggie. I'd just hate to look 
all this time and find out in the end that they're not there.


On 03/12/2018 01:47 PM, Deepak Dixit wrote:
> Hi Craig,
>
> Please have a look at LoginWorker.getAppBarWebInfos and ComponentConfig.
> getAppBarWebInfos method.
> For reference you can have a look at themes/flatgrey/template/AppBar.ftl
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Mon, Mar 12, 2018 at 9:56 PM, Craig Parker <cr...@fossfolks.com> wrote:
>
>> I'm running a clean slate install on MySQL, and trying to locate the main
>> OFBiz menu. Looks like there's a db named ofbiztenant with a table called
>> COMPONENT, and that appears to have at least the top level menu items.
>> Where are the others?
>>
>> Nothing official, but I'm trying to make a spreadsheet or something I can
>> print out for myself so that I can keep track of things going on in each
>> part of the software. I don't see the big picture yet, and I'm hoping this
>> might help. :)
>>


Re: Listing All Menu Items

Posted by Deepak Dixit <de...@hotwaxsystems.com>.
Hi Craig,

Please have a look at LoginWorker.getAppBarWebInfos and ComponentConfig.
getAppBarWebInfos method.
For reference you can have a look at themes/flatgrey/template/AppBar.ftl

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Mon, Mar 12, 2018 at 9:56 PM, Craig Parker <cr...@fossfolks.com> wrote:

> I'm running a clean slate install on MySQL, and trying to locate the main
> OFBiz menu. Looks like there's a db named ofbiztenant with a table called
> COMPONENT, and that appears to have at least the top level menu items.
> Where are the others?
>
> Nothing official, but I'm trying to make a spreadsheet or something I can
> print out for myself so that I can keep track of things going on in each
> part of the software. I don't see the big picture yet, and I'm hoping this
> might help. :)
>

Listing All Menu Items

Posted by Craig Parker <cr...@fossfolks.com>.
I'm running a clean slate install on MySQL, and trying to locate the 
main OFBiz menu. Looks like there's a db named ofbiztenant with a table 
called COMPONENT, and that appears to have at least the top level menu 
items. Where are the others?

Nothing official, but I'm trying to make a spreadsheet or something I 
can print out for myself so that I can keep track of things going on in 
each part of the software. I don't see the big picture yet, and I'm 
hoping this might help. :)

Re: [Discussion] documentation framework for OFBiz

Posted by Michael Brohl <mi...@ecomify.de>.
If the asciidoctor plugin provides no smarter way, I think this would be ok.

The documentation generation process is fast (at least with the few 
pages we have) so this should be no problem.

Thanks,

Michael


Am 12.03.18 um 16:38 schrieb Taher Alkhateeb:
> Maybe one way to accomplish this is to delete and regenerate every
> time. What do you think of that?
>
> On Mon, Mar 12, 2018 at 12:04 PM, Michael Brohl
> <mi...@ecomify.de> wrote:
>> Hi Taher,
>>
>> I worked on the documentation over the weekend.
>>
>> It would be very nice if the documentation gets updated even if the main
>> document has not changed. If you change only included documents, the change
>> does not go into the main document.
>>
>> I briefly searched for a configuration parameter but did not find any.
>>
>> Best regards,
>>
>> Michael
>>
>>
>> Am 24.02.18 um 15:44 schrieb Michael Brohl:
>>> I have tried Taher's latest patch and it is working great for me. I used
>>> Intellij Idea with the Asciidoc Plugin.
>>>
>>>
>>> Differently from Olivier's observation, the main developer-manual ist
>>> updated when I make a change in developer-manual.adoc. Both html and pdf
>>> include the change.
>>>
>>> It is not updated when I only change an included document like
>>> accounting.adoc. I think it would be good to recreate all files if they have
>>> chnaged or not. If I'm not wrong, both SVN and Git notice if a file has not
>>> be changed even if it is rewritten so it should be no problem.
>>>
>>> I think this is a good starting point, more pints might come up if we use
>>> it more intensely.
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> Am 21.02.18 um 14:08 schrieb Olivier Heintz:
>>>> Thank you for the work, Taher
>>>>
>>>> I have played with it and merge with my tests.
>>>> Currently, I have start from Accounting_Agreement, convert from docbook
>>>> and update and
>>>> test renderer by both your gradle task and by AsciidocFx html button
>>>>
>>>> With a lot of include, result html file would be very large and in some
>>>> case it will be good to be able to put a link in place
>>>> of include. Currenlty the generateOfbizDocumentation task doesn't
>>>> generate file for doc in component even if the adoc file is
>>>> not in the _include directory.
>>>>
>>>> Just for information: With AsciidocFx (I have understood it use
>>>> asciidoctor for generate html file, but I'm not sure)
>>>> it's not necessary to say include file is in _include directory, it read
>>>> both in the current directory and in the _include one.
>>>> The generateOfbizDocumentation task doesn't use the same rule, we should
>>>> say explicitly it's in the _include directory.
>>>>
>>>> The main "malfunction" of the generateOfbizDocumentation task is that it
>>>> not re-generate the html file if it already exist
>>>> even if the main adoc file was modified. So it's needed to remove it
>>>> manually before call generateOfbizDocumentation.
>>>>
>>>> Thank you for your usage of leveloffset, it's generated by docbook
>>>> conversion, but now I understand how it works ;-)
>>>>
>>>>
>>>> Olivier
>>>>
>>>> Le 20/02/2018 à 17:48, Taher Alkhateeb a écrit :
>>>>> Hello documentation team and everyone
>>>>>
>>>>> I have created a slightly modified design of the documentation
>>>>> framework with some sample contents in [1]. I highlight the changes
>>>>> below:
>>>>> - Created a new top-level directory called "docs/asciidoc". The reason
>>>>> is so that we have more than one possible manual.
>>>>> - Created "Apache OFBiz User Manual" in docs/asciidoc/user-manual.adoc
>>>>> - Created "Apache OFBiz Developer Manual" in
>>>>> docs/asciidoc/developer-manual.adoc
>>>>> - Created a sample document in the accounting component to show how
>>>>> documents are linked together.
>>>>> - Used a special directive called "leveloffset" in the include
>>>>> directive. This directive shifts the headers of the included document
>>>>> (H2 becomes H3, and so on) so that sub-sections can be published
>>>>> separately.
>>>>> - Created a task called generateOfbizDocumentation to generate the
>>>>> documentation (both PDF and HTML) for framework + core apps
>>>>> - Created a task called generatePluginDocumentation
>>>>> -PpluginId=whatever to generate the documentation for a single plugin.
>>>>>
>>>>> That's it. It's simple, easy to understand and I think you might like
>>>>> it. Any feedback is welcome, and I'll talk to you soon over Skype.
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9873
>>>>>
>>>>> On Tue, Jan 30, 2018 at 4:38 PM, Sharan Foga <sh...@apache.org> wrote:
>>>>>> Hi Taher
>>>>>>
>>>>>> I think a documentation team would be a great idea. There are people
>>>>>> that have indicated that they'd like to help out with documentation tasks on
>>>>>> the user list so that is where I'd recruit some people from. As long as
>>>>>> people know what they need to do to create the patches then it will become a
>>>>>> funnel process of getting it committed.
>>>>>>
>>>>>> We need a plan to consolidate the information sitting in the wiki and
>>>>>> getting it put into the documentation framework (and this work will then
>>>>>> significantly clear up the wiki!).
>>>>>>
>>>>>> My availability is pretty bad this week so hope to pick this up again
>>>>>> or start the recruitment campaign next week :-)
>>>>>>
>>>>>> Thanks
>>>>>> Sharan
>>>>>>
>>>>>> On 2018/01/28 10:12:41, Taher Alkhateeb <sl...@gmail.com>
>>>>>> wrote:
>>>>>>> Like Michael I think it is also a minor point. The reason I chose this
>>>>>>> structure is because it is the default one for asciidoctor and is
>>>>>>> flexible
>>>>>>> for the future, so Paul also makes a good point. Any structure is fine
>>>>>>> by
>>>>>>> me, the real important work is getting the documentation right which
>>>>>>> is
>>>>>>> very exciting to me.
>>>>>>>
>>>>>>> I will create a patch soon for a base level structure and publishing
>>>>>>> options for both HTML and PDF. It would be fantastic if we can unify
>>>>>>> _all_
>>>>>>> of our documentation here including stuff currently in the wiki. This
>>>>>>> way
>>>>>>> any changes to code are reflected (probably in the same commit) with
>>>>>>> the
>>>>>>> relevant documentation.
>>>>>>>
>>>>>>> I think we should start to consider maybe forming a team willing to
>>>>>>> help.
>>>>>>> This is a big, but extremely important thing to have. If we do this
>>>>>>> right
>>>>>>> then I think adoption rates would increase and our community would get
>>>>>>> larger.
>>>>>>>
>>>>>>> On Jan 28, 2018 12:19 PM, "Michael Brohl" <mi...@ecomify.de>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Paul,
>>>>>>>
>>>>>>> this is only a minor point for me, it just saves one folder/structure
>>>>>>> level.
>>>>>>>
>>>>>>> If we want to stay open for other documentation frameworks in the
>>>>>>> future,
>>>>>>> it might be better to keep the proposed structure.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> Am 28.01.18 um 02:54 schrieb Paul Foxworthy:
>>>>>>>
>>>>>>> On 26 January 2018 at 19:53, Michael Brohl <mi...@ecomify.de>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> with a small modification: I don't think we'll need a two-folder
>>>>>>>> structure
>>>>>>>>> /docs/asciidoc, only /docs should be sufficient, no?
>>>>>>>>>
>>>>>>>>> Hi Michael,
>>>>>>>> We have streamlined the build system in other places by having
>>>>>>>> folders for
>>>>>>>> the source language: groovyScripts, minilang, src/main/java .
>>>>>>>>
>>>>>>>> It means Groovy and other build tools can have default rules for what
>>>>>>>> to do
>>>>>>>> with the contents of a language folder, and allows for the
>>>>>>>> possibility of
>>>>>>>> other languages in future if necessary.
>>>>>>>>
>>>>>>>> The extra layer is only a minor nuisance. I think I'd prefer to keep
>>>>>>>> it.
>>>>>>>> What do you see as the disadvantages?
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> Paul Foxworthy
>>>>>>>>
>>>>>>>>
>>>
>>



Re: [Discussion] documentation framework for OFBiz

Posted by Sharan Foga <sh...@apache.org>.

On 2018/03/13 16:37:31, Taher Alkhateeb <sl...@gmail.com> wrote: 
> Hey guys, feature implemented in r1826656. Now both plugins and ofbiz
> manual will delete before re-generating their artifacts. I believe
> this will solve the problem and I think we won't have a big problem
> with performance, and probably won't be until we reach maybe thousands
> of documents.
> 
> By the way, may I also recommend that we minimize the number of
> documents in the beginning. So instead of creating new files, just
> create new headers, and split the file later when it gets too big.
> This way we do not overly complicate the design unless it makes sense.

Good point and agreed.  Let's get some content in and see how it evolves.

Thanks
Sharan

> 
> On Mon, Mar 12, 2018 at 6:44 PM, Sharan Foga <sh...@apache.org> wrote:
> > Hi  Taher
> >
> > Manually deleting and regenerating is what I've been doing :-)  so it could be a start. We are evolving - right?  We might need to look at it again if it becomes an issue as we fill up the content..
> >
> > Thanks
> > Sharan
> >
> >
> > On 2018/03/12 15:38:44, Taher Alkhateeb <sl...@gmail.com> wrote:
> >> Maybe one way to accomplish this is to delete and regenerate every
> >> time. What do you think of that?
> >>
> >> On Mon, Mar 12, 2018 at 12:04 PM, Michael Brohl
> >> <mi...@ecomify.de> wrote:
> >> > Hi Taher,
> >> >
> >> > I worked on the documentation over the weekend.
> >> >
> >> > It would be very nice if the documentation gets updated even if the main
> >> > document has not changed. If you change only included documents, the change
> >> > does not go into the main document.
> >> >
> >> > I briefly searched for a configuration parameter but did not find any.
> >> >
> >> > Best regards,
> >> >
> >> > Michael
> >> >
> >> >
> >> > Am 24.02.18 um 15:44 schrieb Michael Brohl:
> >> >>
> >> >> I have tried Taher's latest patch and it is working great for me. I used
> >> >> Intellij Idea with the Asciidoc Plugin.
> >> >>
> >> >>
> >> >> Differently from Olivier's observation, the main developer-manual ist
> >> >> updated when I make a change in developer-manual.adoc. Both html and pdf
> >> >> include the change.
> >> >>
> >> >> It is not updated when I only change an included document like
> >> >> accounting.adoc. I think it would be good to recreate all files if they have
> >> >> chnaged or not. If I'm not wrong, both SVN and Git notice if a file has not
> >> >> be changed even if it is rewritten so it should be no problem.
> >> >>
> >> >> I think this is a good starting point, more pints might come up if we use
> >> >> it more intensely.
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Michael
> >> >>
> >> >>
> >> >> Am 21.02.18 um 14:08 schrieb Olivier Heintz:
> >> >>>
> >> >>> Thank you for the work, Taher
> >> >>>
> >> >>> I have played with it and merge with my tests.
> >> >>> Currently, I have start from Accounting_Agreement, convert from docbook
> >> >>> and update and
> >> >>> test renderer by both your gradle task and by AsciidocFx html button
> >> >>>
> >> >>> With a lot of include, result html file would be very large and in some
> >> >>> case it will be good to be able to put a link in place
> >> >>> of include. Currenlty the generateOfbizDocumentation task doesn't
> >> >>> generate file for doc in component even if the adoc file is
> >> >>> not in the _include directory.
> >> >>>
> >> >>> Just for information: With AsciidocFx (I have understood it use
> >> >>> asciidoctor for generate html file, but I'm not sure)
> >> >>> it's not necessary to say include file is in _include directory, it read
> >> >>> both in the current directory and in the _include one.
> >> >>> The generateOfbizDocumentation task doesn't use the same rule, we should
> >> >>> say explicitly it's in the _include directory.
> >> >>>
> >> >>> The main "malfunction" of the generateOfbizDocumentation task is that it
> >> >>> not re-generate the html file if it already exist
> >> >>> even if the main adoc file was modified. So it's needed to remove it
> >> >>> manually before call generateOfbizDocumentation.
> >> >>>
> >> >>> Thank you for your usage of leveloffset, it's generated by docbook
> >> >>> conversion, but now I understand how it works ;-)
> >> >>>
> >> >>>
> >> >>> Olivier
> >> >>>
> >> >>> Le 20/02/2018 à 17:48, Taher Alkhateeb a écrit :
> >> >>>>
> >> >>>> Hello documentation team and everyone
> >> >>>>
> >> >>>> I have created a slightly modified design of the documentation
> >> >>>> framework with some sample contents in [1]. I highlight the changes
> >> >>>> below:
> >> >>>> - Created a new top-level directory called "docs/asciidoc". The reason
> >> >>>> is so that we have more than one possible manual.
> >> >>>> - Created "Apache OFBiz User Manual" in docs/asciidoc/user-manual.adoc
> >> >>>> - Created "Apache OFBiz Developer Manual" in
> >> >>>> docs/asciidoc/developer-manual.adoc
> >> >>>> - Created a sample document in the accounting component to show how
> >> >>>> documents are linked together.
> >> >>>> - Used a special directive called "leveloffset" in the include
> >> >>>> directive. This directive shifts the headers of the included document
> >> >>>> (H2 becomes H3, and so on) so that sub-sections can be published
> >> >>>> separately.
> >> >>>> - Created a task called generateOfbizDocumentation to generate the
> >> >>>> documentation (both PDF and HTML) for framework + core apps
> >> >>>> - Created a task called generatePluginDocumentation
> >> >>>> -PpluginId=whatever to generate the documentation for a single plugin.
> >> >>>>
> >> >>>> That's it. It's simple, easy to understand and I think you might like
> >> >>>> it. Any feedback is welcome, and I'll talk to you soon over Skype.
> >> >>>>
> >> >>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9873
> >> >>>>
> >> >>>> On Tue, Jan 30, 2018 at 4:38 PM, Sharan Foga <sh...@apache.org> wrote:
> >> >>>>>
> >> >>>>> Hi Taher
> >> >>>>>
> >> >>>>> I think a documentation team would be a great idea. There are people
> >> >>>>> that have indicated that they'd like to help out with documentation tasks on
> >> >>>>> the user list so that is where I'd recruit some people from. As long as
> >> >>>>> people know what they need to do to create the patches then it will become a
> >> >>>>> funnel process of getting it committed.
> >> >>>>>
> >> >>>>> We need a plan to consolidate the information sitting in the wiki and
> >> >>>>> getting it put into the documentation framework (and this work will then
> >> >>>>> significantly clear up the wiki!).
> >> >>>>>
> >> >>>>> My availability is pretty bad this week so hope to pick this up again
> >> >>>>> or start the recruitment campaign next week :-)
> >> >>>>>
> >> >>>>> Thanks
> >> >>>>> Sharan
> >> >>>>>
> >> >>>>> On 2018/01/28 10:12:41, Taher Alkhateeb <sl...@gmail.com>
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>> Like Michael I think it is also a minor point. The reason I chose this
> >> >>>>>> structure is because it is the default one for asciidoctor and is
> >> >>>>>> flexible
> >> >>>>>> for the future, so Paul also makes a good point. Any structure is fine
> >> >>>>>> by
> >> >>>>>> me, the real important work is getting the documentation right which
> >> >>>>>> is
> >> >>>>>> very exciting to me.
> >> >>>>>>
> >> >>>>>> I will create a patch soon for a base level structure and publishing
> >> >>>>>> options for both HTML and PDF. It would be fantastic if we can unify
> >> >>>>>> _all_
> >> >>>>>> of our documentation here including stuff currently in the wiki. This
> >> >>>>>> way
> >> >>>>>> any changes to code are reflected (probably in the same commit) with
> >> >>>>>> the
> >> >>>>>> relevant documentation.
> >> >>>>>>
> >> >>>>>> I think we should start to consider maybe forming a team willing to
> >> >>>>>> help.
> >> >>>>>> This is a big, but extremely important thing to have. If we do this
> >> >>>>>> right
> >> >>>>>> then I think adoption rates would increase and our community would get
> >> >>>>>> larger.
> >> >>>>>>
> >> >>>>>> On Jan 28, 2018 12:19 PM, "Michael Brohl" <mi...@ecomify.de>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>> Hi Paul,
> >> >>>>>>
> >> >>>>>> this is only a minor point for me, it just saves one folder/structure
> >> >>>>>> level.
> >> >>>>>>
> >> >>>>>> If we want to stay open for other documentation frameworks in the
> >> >>>>>> future,
> >> >>>>>> it might be better to keep the proposed structure.
> >> >>>>>>
> >> >>>>>> Best regards,
> >> >>>>>>
> >> >>>>>> Michael
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Am 28.01.18 um 02:54 schrieb Paul Foxworthy:
> >> >>>>>>
> >> >>>>>> On 26 January 2018 at 19:53, Michael Brohl <mi...@ecomify.de>
> >> >>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> with a small modification: I don't think we'll need a two-folder
> >> >>>>>>> structure
> >> >>>>>>>>
> >> >>>>>>>> /docs/asciidoc, only /docs should be sufficient, no?
> >> >>>>>>>>
> >> >>>>>>>> Hi Michael,
> >> >>>>>>>
> >> >>>>>>> We have streamlined the build system in other places by having
> >> >>>>>>> folders for
> >> >>>>>>> the source language: groovyScripts, minilang, src/main/java .
> >> >>>>>>>
> >> >>>>>>> It means Groovy and other build tools can have default rules for what
> >> >>>>>>> to do
> >> >>>>>>> with the contents of a language folder, and allows for the
> >> >>>>>>> possibility of
> >> >>>>>>> other languages in future if necessary.
> >> >>>>>>>
> >> >>>>>>> The extra layer is only a minor nuisance. I think I'd prefer to keep
> >> >>>>>>> it.
> >> >>>>>>> What do you see as the disadvantages?
> >> >>>>>>>
> >> >>>>>>> Cheers
> >> >>>>>>>
> >> >>>>>>> Paul Foxworthy
> >> >>>>>>>
> >> >>>>>>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> 

Re: [Discussion] documentation framework for OFBiz

Posted by Taher Alkhateeb <sl...@gmail.com>.
Hey guys, feature implemented in r1826656. Now both plugins and ofbiz
manual will delete before re-generating their artifacts. I believe
this will solve the problem and I think we won't have a big problem
with performance, and probably won't be until we reach maybe thousands
of documents.

By the way, may I also recommend that we minimize the number of
documents in the beginning. So instead of creating new files, just
create new headers, and split the file later when it gets too big.
This way we do not overly complicate the design unless it makes sense.

On Mon, Mar 12, 2018 at 6:44 PM, Sharan Foga <sh...@apache.org> wrote:
> Hi  Taher
>
> Manually deleting and regenerating is what I've been doing :-)  so it could be a start. We are evolving - right?  We might need to look at it again if it becomes an issue as we fill up the content..
>
> Thanks
> Sharan
>
>
> On 2018/03/12 15:38:44, Taher Alkhateeb <sl...@gmail.com> wrote:
>> Maybe one way to accomplish this is to delete and regenerate every
>> time. What do you think of that?
>>
>> On Mon, Mar 12, 2018 at 12:04 PM, Michael Brohl
>> <mi...@ecomify.de> wrote:
>> > Hi Taher,
>> >
>> > I worked on the documentation over the weekend.
>> >
>> > It would be very nice if the documentation gets updated even if the main
>> > document has not changed. If you change only included documents, the change
>> > does not go into the main document.
>> >
>> > I briefly searched for a configuration parameter but did not find any.
>> >
>> > Best regards,
>> >
>> > Michael
>> >
>> >
>> > Am 24.02.18 um 15:44 schrieb Michael Brohl:
>> >>
>> >> I have tried Taher's latest patch and it is working great for me. I used
>> >> Intellij Idea with the Asciidoc Plugin.
>> >>
>> >>
>> >> Differently from Olivier's observation, the main developer-manual ist
>> >> updated when I make a change in developer-manual.adoc. Both html and pdf
>> >> include the change.
>> >>
>> >> It is not updated when I only change an included document like
>> >> accounting.adoc. I think it would be good to recreate all files if they have
>> >> chnaged or not. If I'm not wrong, both SVN and Git notice if a file has not
>> >> be changed even if it is rewritten so it should be no problem.
>> >>
>> >> I think this is a good starting point, more pints might come up if we use
>> >> it more intensely.
>> >>
>> >> Thanks,
>> >>
>> >> Michael
>> >>
>> >>
>> >> Am 21.02.18 um 14:08 schrieb Olivier Heintz:
>> >>>
>> >>> Thank you for the work, Taher
>> >>>
>> >>> I have played with it and merge with my tests.
>> >>> Currently, I have start from Accounting_Agreement, convert from docbook
>> >>> and update and
>> >>> test renderer by both your gradle task and by AsciidocFx html button
>> >>>
>> >>> With a lot of include, result html file would be very large and in some
>> >>> case it will be good to be able to put a link in place
>> >>> of include. Currenlty the generateOfbizDocumentation task doesn't
>> >>> generate file for doc in component even if the adoc file is
>> >>> not in the _include directory.
>> >>>
>> >>> Just for information: With AsciidocFx (I have understood it use
>> >>> asciidoctor for generate html file, but I'm not sure)
>> >>> it's not necessary to say include file is in _include directory, it read
>> >>> both in the current directory and in the _include one.
>> >>> The generateOfbizDocumentation task doesn't use the same rule, we should
>> >>> say explicitly it's in the _include directory.
>> >>>
>> >>> The main "malfunction" of the generateOfbizDocumentation task is that it
>> >>> not re-generate the html file if it already exist
>> >>> even if the main adoc file was modified. So it's needed to remove it
>> >>> manually before call generateOfbizDocumentation.
>> >>>
>> >>> Thank you for your usage of leveloffset, it's generated by docbook
>> >>> conversion, but now I understand how it works ;-)
>> >>>
>> >>>
>> >>> Olivier
>> >>>
>> >>> Le 20/02/2018 à 17:48, Taher Alkhateeb a écrit :
>> >>>>
>> >>>> Hello documentation team and everyone
>> >>>>
>> >>>> I have created a slightly modified design of the documentation
>> >>>> framework with some sample contents in [1]. I highlight the changes
>> >>>> below:
>> >>>> - Created a new top-level directory called "docs/asciidoc". The reason
>> >>>> is so that we have more than one possible manual.
>> >>>> - Created "Apache OFBiz User Manual" in docs/asciidoc/user-manual.adoc
>> >>>> - Created "Apache OFBiz Developer Manual" in
>> >>>> docs/asciidoc/developer-manual.adoc
>> >>>> - Created a sample document in the accounting component to show how
>> >>>> documents are linked together.
>> >>>> - Used a special directive called "leveloffset" in the include
>> >>>> directive. This directive shifts the headers of the included document
>> >>>> (H2 becomes H3, and so on) so that sub-sections can be published
>> >>>> separately.
>> >>>> - Created a task called generateOfbizDocumentation to generate the
>> >>>> documentation (both PDF and HTML) for framework + core apps
>> >>>> - Created a task called generatePluginDocumentation
>> >>>> -PpluginId=whatever to generate the documentation for a single plugin.
>> >>>>
>> >>>> That's it. It's simple, easy to understand and I think you might like
>> >>>> it. Any feedback is welcome, and I'll talk to you soon over Skype.
>> >>>>
>> >>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9873
>> >>>>
>> >>>> On Tue, Jan 30, 2018 at 4:38 PM, Sharan Foga <sh...@apache.org> wrote:
>> >>>>>
>> >>>>> Hi Taher
>> >>>>>
>> >>>>> I think a documentation team would be a great idea. There are people
>> >>>>> that have indicated that they'd like to help out with documentation tasks on
>> >>>>> the user list so that is where I'd recruit some people from. As long as
>> >>>>> people know what they need to do to create the patches then it will become a
>> >>>>> funnel process of getting it committed.
>> >>>>>
>> >>>>> We need a plan to consolidate the information sitting in the wiki and
>> >>>>> getting it put into the documentation framework (and this work will then
>> >>>>> significantly clear up the wiki!).
>> >>>>>
>> >>>>> My availability is pretty bad this week so hope to pick this up again
>> >>>>> or start the recruitment campaign next week :-)
>> >>>>>
>> >>>>> Thanks
>> >>>>> Sharan
>> >>>>>
>> >>>>> On 2018/01/28 10:12:41, Taher Alkhateeb <sl...@gmail.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Like Michael I think it is also a minor point. The reason I chose this
>> >>>>>> structure is because it is the default one for asciidoctor and is
>> >>>>>> flexible
>> >>>>>> for the future, so Paul also makes a good point. Any structure is fine
>> >>>>>> by
>> >>>>>> me, the real important work is getting the documentation right which
>> >>>>>> is
>> >>>>>> very exciting to me.
>> >>>>>>
>> >>>>>> I will create a patch soon for a base level structure and publishing
>> >>>>>> options for both HTML and PDF. It would be fantastic if we can unify
>> >>>>>> _all_
>> >>>>>> of our documentation here including stuff currently in the wiki. This
>> >>>>>> way
>> >>>>>> any changes to code are reflected (probably in the same commit) with
>> >>>>>> the
>> >>>>>> relevant documentation.
>> >>>>>>
>> >>>>>> I think we should start to consider maybe forming a team willing to
>> >>>>>> help.
>> >>>>>> This is a big, but extremely important thing to have. If we do this
>> >>>>>> right
>> >>>>>> then I think adoption rates would increase and our community would get
>> >>>>>> larger.
>> >>>>>>
>> >>>>>> On Jan 28, 2018 12:19 PM, "Michael Brohl" <mi...@ecomify.de>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>> Hi Paul,
>> >>>>>>
>> >>>>>> this is only a minor point for me, it just saves one folder/structure
>> >>>>>> level.
>> >>>>>>
>> >>>>>> If we want to stay open for other documentation frameworks in the
>> >>>>>> future,
>> >>>>>> it might be better to keep the proposed structure.
>> >>>>>>
>> >>>>>> Best regards,
>> >>>>>>
>> >>>>>> Michael
>> >>>>>>
>> >>>>>>
>> >>>>>> Am 28.01.18 um 02:54 schrieb Paul Foxworthy:
>> >>>>>>
>> >>>>>> On 26 January 2018 at 19:53, Michael Brohl <mi...@ecomify.de>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> with a small modification: I don't think we'll need a two-folder
>> >>>>>>> structure
>> >>>>>>>>
>> >>>>>>>> /docs/asciidoc, only /docs should be sufficient, no?
>> >>>>>>>>
>> >>>>>>>> Hi Michael,
>> >>>>>>>
>> >>>>>>> We have streamlined the build system in other places by having
>> >>>>>>> folders for
>> >>>>>>> the source language: groovyScripts, minilang, src/main/java .
>> >>>>>>>
>> >>>>>>> It means Groovy and other build tools can have default rules for what
>> >>>>>>> to do
>> >>>>>>> with the contents of a language folder, and allows for the
>> >>>>>>> possibility of
>> >>>>>>> other languages in future if necessary.
>> >>>>>>>
>> >>>>>>> The extra layer is only a minor nuisance. I think I'd prefer to keep
>> >>>>>>> it.
>> >>>>>>> What do you see as the disadvantages?
>> >>>>>>>
>> >>>>>>> Cheers
>> >>>>>>>
>> >>>>>>> Paul Foxworthy
>> >>>>>>>
>> >>>>>>>
>> >>
>> >>
>> >
>> >
>>

Re: [Discussion] documentation framework for OFBiz

Posted by Sharan Foga <sh...@apache.org>.
Hi  Taher

Manually deleting and regenerating is what I've been doing :-)  so it could be a start. We are evolving - right?  We might need to look at it again if it becomes an issue as we fill up the content..

Thanks
Sharan


On 2018/03/12 15:38:44, Taher Alkhateeb <sl...@gmail.com> wrote: 
> Maybe one way to accomplish this is to delete and regenerate every
> time. What do you think of that?
> 
> On Mon, Mar 12, 2018 at 12:04 PM, Michael Brohl
> <mi...@ecomify.de> wrote:
> > Hi Taher,
> >
> > I worked on the documentation over the weekend.
> >
> > It would be very nice if the documentation gets updated even if the main
> > document has not changed. If you change only included documents, the change
> > does not go into the main document.
> >
> > I briefly searched for a configuration parameter but did not find any.
> >
> > Best regards,
> >
> > Michael
> >
> >
> > Am 24.02.18 um 15:44 schrieb Michael Brohl:
> >>
> >> I have tried Taher's latest patch and it is working great for me. I used
> >> Intellij Idea with the Asciidoc Plugin.
> >>
> >>
> >> Differently from Olivier's observation, the main developer-manual ist
> >> updated when I make a change in developer-manual.adoc. Both html and pdf
> >> include the change.
> >>
> >> It is not updated when I only change an included document like
> >> accounting.adoc. I think it would be good to recreate all files if they have
> >> chnaged or not. If I'm not wrong, both SVN and Git notice if a file has not
> >> be changed even if it is rewritten so it should be no problem.
> >>
> >> I think this is a good starting point, more pints might come up if we use
> >> it more intensely.
> >>
> >> Thanks,
> >>
> >> Michael
> >>
> >>
> >> Am 21.02.18 um 14:08 schrieb Olivier Heintz:
> >>>
> >>> Thank you for the work, Taher
> >>>
> >>> I have played with it and merge with my tests.
> >>> Currently, I have start from Accounting_Agreement, convert from docbook
> >>> and update and
> >>> test renderer by both your gradle task and by AsciidocFx html button
> >>>
> >>> With a lot of include, result html file would be very large and in some
> >>> case it will be good to be able to put a link in place
> >>> of include. Currenlty the generateOfbizDocumentation task doesn't
> >>> generate file for doc in component even if the adoc file is
> >>> not in the _include directory.
> >>>
> >>> Just for information: With AsciidocFx (I have understood it use
> >>> asciidoctor for generate html file, but I'm not sure)
> >>> it's not necessary to say include file is in _include directory, it read
> >>> both in the current directory and in the _include one.
> >>> The generateOfbizDocumentation task doesn't use the same rule, we should
> >>> say explicitly it's in the _include directory.
> >>>
> >>> The main "malfunction" of the generateOfbizDocumentation task is that it
> >>> not re-generate the html file if it already exist
> >>> even if the main adoc file was modified. So it's needed to remove it
> >>> manually before call generateOfbizDocumentation.
> >>>
> >>> Thank you for your usage of leveloffset, it's generated by docbook
> >>> conversion, but now I understand how it works ;-)
> >>>
> >>>
> >>> Olivier
> >>>
> >>> Le 20/02/2018 à 17:48, Taher Alkhateeb a écrit :
> >>>>
> >>>> Hello documentation team and everyone
> >>>>
> >>>> I have created a slightly modified design of the documentation
> >>>> framework with some sample contents in [1]. I highlight the changes
> >>>> below:
> >>>> - Created a new top-level directory called "docs/asciidoc". The reason
> >>>> is so that we have more than one possible manual.
> >>>> - Created "Apache OFBiz User Manual" in docs/asciidoc/user-manual.adoc
> >>>> - Created "Apache OFBiz Developer Manual" in
> >>>> docs/asciidoc/developer-manual.adoc
> >>>> - Created a sample document in the accounting component to show how
> >>>> documents are linked together.
> >>>> - Used a special directive called "leveloffset" in the include
> >>>> directive. This directive shifts the headers of the included document
> >>>> (H2 becomes H3, and so on) so that sub-sections can be published
> >>>> separately.
> >>>> - Created a task called generateOfbizDocumentation to generate the
> >>>> documentation (both PDF and HTML) for framework + core apps
> >>>> - Created a task called generatePluginDocumentation
> >>>> -PpluginId=whatever to generate the documentation for a single plugin.
> >>>>
> >>>> That's it. It's simple, easy to understand and I think you might like
> >>>> it. Any feedback is welcome, and I'll talk to you soon over Skype.
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9873
> >>>>
> >>>> On Tue, Jan 30, 2018 at 4:38 PM, Sharan Foga <sh...@apache.org> wrote:
> >>>>>
> >>>>> Hi Taher
> >>>>>
> >>>>> I think a documentation team would be a great idea. There are people
> >>>>> that have indicated that they'd like to help out with documentation tasks on
> >>>>> the user list so that is where I'd recruit some people from. As long as
> >>>>> people know what they need to do to create the patches then it will become a
> >>>>> funnel process of getting it committed.
> >>>>>
> >>>>> We need a plan to consolidate the information sitting in the wiki and
> >>>>> getting it put into the documentation framework (and this work will then
> >>>>> significantly clear up the wiki!).
> >>>>>
> >>>>> My availability is pretty bad this week so hope to pick this up again
> >>>>> or start the recruitment campaign next week :-)
> >>>>>
> >>>>> Thanks
> >>>>> Sharan
> >>>>>
> >>>>> On 2018/01/28 10:12:41, Taher Alkhateeb <sl...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Like Michael I think it is also a minor point. The reason I chose this
> >>>>>> structure is because it is the default one for asciidoctor and is
> >>>>>> flexible
> >>>>>> for the future, so Paul also makes a good point. Any structure is fine
> >>>>>> by
> >>>>>> me, the real important work is getting the documentation right which
> >>>>>> is
> >>>>>> very exciting to me.
> >>>>>>
> >>>>>> I will create a patch soon for a base level structure and publishing
> >>>>>> options for both HTML and PDF. It would be fantastic if we can unify
> >>>>>> _all_
> >>>>>> of our documentation here including stuff currently in the wiki. This
> >>>>>> way
> >>>>>> any changes to code are reflected (probably in the same commit) with
> >>>>>> the
> >>>>>> relevant documentation.
> >>>>>>
> >>>>>> I think we should start to consider maybe forming a team willing to
> >>>>>> help.
> >>>>>> This is a big, but extremely important thing to have. If we do this
> >>>>>> right
> >>>>>> then I think adoption rates would increase and our community would get
> >>>>>> larger.
> >>>>>>
> >>>>>> On Jan 28, 2018 12:19 PM, "Michael Brohl" <mi...@ecomify.de>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi Paul,
> >>>>>>
> >>>>>> this is only a minor point for me, it just saves one folder/structure
> >>>>>> level.
> >>>>>>
> >>>>>> If we want to stay open for other documentation frameworks in the
> >>>>>> future,
> >>>>>> it might be better to keep the proposed structure.
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Michael
> >>>>>>
> >>>>>>
> >>>>>> Am 28.01.18 um 02:54 schrieb Paul Foxworthy:
> >>>>>>
> >>>>>> On 26 January 2018 at 19:53, Michael Brohl <mi...@ecomify.de>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> with a small modification: I don't think we'll need a two-folder
> >>>>>>> structure
> >>>>>>>>
> >>>>>>>> /docs/asciidoc, only /docs should be sufficient, no?
> >>>>>>>>
> >>>>>>>> Hi Michael,
> >>>>>>>
> >>>>>>> We have streamlined the build system in other places by having
> >>>>>>> folders for
> >>>>>>> the source language: groovyScripts, minilang, src/main/java .
> >>>>>>>
> >>>>>>> It means Groovy and other build tools can have default rules for what
> >>>>>>> to do
> >>>>>>> with the contents of a language folder, and allows for the
> >>>>>>> possibility of
> >>>>>>> other languages in future if necessary.
> >>>>>>>
> >>>>>>> The extra layer is only a minor nuisance. I think I'd prefer to keep
> >>>>>>> it.
> >>>>>>> What do you see as the disadvantages?
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>>
> >>>>>>> Paul Foxworthy
> >>>>>>>
> >>>>>>>
> >>
> >>
> >
> >
> 

Re: [Discussion] documentation framework for OFBiz

Posted by Taher Alkhateeb <sl...@gmail.com>.
Maybe one way to accomplish this is to delete and regenerate every
time. What do you think of that?

On Mon, Mar 12, 2018 at 12:04 PM, Michael Brohl
<mi...@ecomify.de> wrote:
> Hi Taher,
>
> I worked on the documentation over the weekend.
>
> It would be very nice if the documentation gets updated even if the main
> document has not changed. If you change only included documents, the change
> does not go into the main document.
>
> I briefly searched for a configuration parameter but did not find any.
>
> Best regards,
>
> Michael
>
>
> Am 24.02.18 um 15:44 schrieb Michael Brohl:
>>
>> I have tried Taher's latest patch and it is working great for me. I used
>> Intellij Idea with the Asciidoc Plugin.
>>
>>
>> Differently from Olivier's observation, the main developer-manual ist
>> updated when I make a change in developer-manual.adoc. Both html and pdf
>> include the change.
>>
>> It is not updated when I only change an included document like
>> accounting.adoc. I think it would be good to recreate all files if they have
>> chnaged or not. If I'm not wrong, both SVN and Git notice if a file has not
>> be changed even if it is rewritten so it should be no problem.
>>
>> I think this is a good starting point, more pints might come up if we use
>> it more intensely.
>>
>> Thanks,
>>
>> Michael
>>
>>
>> Am 21.02.18 um 14:08 schrieb Olivier Heintz:
>>>
>>> Thank you for the work, Taher
>>>
>>> I have played with it and merge with my tests.
>>> Currently, I have start from Accounting_Agreement, convert from docbook
>>> and update and
>>> test renderer by both your gradle task and by AsciidocFx html button
>>>
>>> With a lot of include, result html file would be very large and in some
>>> case it will be good to be able to put a link in place
>>> of include. Currenlty the generateOfbizDocumentation task doesn't
>>> generate file for doc in component even if the adoc file is
>>> not in the _include directory.
>>>
>>> Just for information: With AsciidocFx (I have understood it use
>>> asciidoctor for generate html file, but I'm not sure)
>>> it's not necessary to say include file is in _include directory, it read
>>> both in the current directory and in the _include one.
>>> The generateOfbizDocumentation task doesn't use the same rule, we should
>>> say explicitly it's in the _include directory.
>>>
>>> The main "malfunction" of the generateOfbizDocumentation task is that it
>>> not re-generate the html file if it already exist
>>> even if the main adoc file was modified. So it's needed to remove it
>>> manually before call generateOfbizDocumentation.
>>>
>>> Thank you for your usage of leveloffset, it's generated by docbook
>>> conversion, but now I understand how it works ;-)
>>>
>>>
>>> Olivier
>>>
>>> Le 20/02/2018 à 17:48, Taher Alkhateeb a écrit :
>>>>
>>>> Hello documentation team and everyone
>>>>
>>>> I have created a slightly modified design of the documentation
>>>> framework with some sample contents in [1]. I highlight the changes
>>>> below:
>>>> - Created a new top-level directory called "docs/asciidoc". The reason
>>>> is so that we have more than one possible manual.
>>>> - Created "Apache OFBiz User Manual" in docs/asciidoc/user-manual.adoc
>>>> - Created "Apache OFBiz Developer Manual" in
>>>> docs/asciidoc/developer-manual.adoc
>>>> - Created a sample document in the accounting component to show how
>>>> documents are linked together.
>>>> - Used a special directive called "leveloffset" in the include
>>>> directive. This directive shifts the headers of the included document
>>>> (H2 becomes H3, and so on) so that sub-sections can be published
>>>> separately.
>>>> - Created a task called generateOfbizDocumentation to generate the
>>>> documentation (both PDF and HTML) for framework + core apps
>>>> - Created a task called generatePluginDocumentation
>>>> -PpluginId=whatever to generate the documentation for a single plugin.
>>>>
>>>> That's it. It's simple, easy to understand and I think you might like
>>>> it. Any feedback is welcome, and I'll talk to you soon over Skype.
>>>>
>>>> [1] https://issues.apache.org/jira/browse/OFBIZ-9873
>>>>
>>>> On Tue, Jan 30, 2018 at 4:38 PM, Sharan Foga <sh...@apache.org> wrote:
>>>>>
>>>>> Hi Taher
>>>>>
>>>>> I think a documentation team would be a great idea. There are people
>>>>> that have indicated that they'd like to help out with documentation tasks on
>>>>> the user list so that is where I'd recruit some people from. As long as
>>>>> people know what they need to do to create the patches then it will become a
>>>>> funnel process of getting it committed.
>>>>>
>>>>> We need a plan to consolidate the information sitting in the wiki and
>>>>> getting it put into the documentation framework (and this work will then
>>>>> significantly clear up the wiki!).
>>>>>
>>>>> My availability is pretty bad this week so hope to pick this up again
>>>>> or start the recruitment campaign next week :-)
>>>>>
>>>>> Thanks
>>>>> Sharan
>>>>>
>>>>> On 2018/01/28 10:12:41, Taher Alkhateeb <sl...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Like Michael I think it is also a minor point. The reason I chose this
>>>>>> structure is because it is the default one for asciidoctor and is
>>>>>> flexible
>>>>>> for the future, so Paul also makes a good point. Any structure is fine
>>>>>> by
>>>>>> me, the real important work is getting the documentation right which
>>>>>> is
>>>>>> very exciting to me.
>>>>>>
>>>>>> I will create a patch soon for a base level structure and publishing
>>>>>> options for both HTML and PDF. It would be fantastic if we can unify
>>>>>> _all_
>>>>>> of our documentation here including stuff currently in the wiki. This
>>>>>> way
>>>>>> any changes to code are reflected (probably in the same commit) with
>>>>>> the
>>>>>> relevant documentation.
>>>>>>
>>>>>> I think we should start to consider maybe forming a team willing to
>>>>>> help.
>>>>>> This is a big, but extremely important thing to have. If we do this
>>>>>> right
>>>>>> then I think adoption rates would increase and our community would get
>>>>>> larger.
>>>>>>
>>>>>> On Jan 28, 2018 12:19 PM, "Michael Brohl" <mi...@ecomify.de>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Paul,
>>>>>>
>>>>>> this is only a minor point for me, it just saves one folder/structure
>>>>>> level.
>>>>>>
>>>>>> If we want to stay open for other documentation frameworks in the
>>>>>> future,
>>>>>> it might be better to keep the proposed structure.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Am 28.01.18 um 02:54 schrieb Paul Foxworthy:
>>>>>>
>>>>>> On 26 January 2018 at 19:53, Michael Brohl <mi...@ecomify.de>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> with a small modification: I don't think we'll need a two-folder
>>>>>>> structure
>>>>>>>>
>>>>>>>> /docs/asciidoc, only /docs should be sufficient, no?
>>>>>>>>
>>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> We have streamlined the build system in other places by having
>>>>>>> folders for
>>>>>>> the source language: groovyScripts, minilang, src/main/java .
>>>>>>>
>>>>>>> It means Groovy and other build tools can have default rules for what
>>>>>>> to do
>>>>>>> with the contents of a language folder, and allows for the
>>>>>>> possibility of
>>>>>>> other languages in future if necessary.
>>>>>>>
>>>>>>> The extra layer is only a minor nuisance. I think I'd prefer to keep
>>>>>>> it.
>>>>>>> What do you see as the disadvantages?
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Paul Foxworthy
>>>>>>>
>>>>>>>
>>
>>
>
>