Hi Jacques,
I have created https://issues.apache.org/jira/browse/INFRA-20311 "we need
directories per release under ci.apache.org/projects/ofbiz/site/"
Currently there is :
projects/ofbiz/site/
├── javadocs
├── ofbizdoc
└── pluginsdoc
we want
projects/ofbiz/site/
├── stable
| ├── javadocs
| ├── ofbizdoc
| └── pluginsdoc
├── next
| ├── javadocs
| ├── ofbizdoc
| └── pluginsdoc
└── trunk
├── javadocs
├── ofbizdoc
└── pluginsdoc
I have prepared modification in buildbot/.../ofbiz.conf
who can commit it when new directory will be created,
me or you prefer I create a OFBiz Jira ?
Olivier
Le 23/05/2020 à 11:51, Jacques Le Roux a écrit :
> Hi Olivier:
>
> It's only in R17, see content of a
> https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins build
>
> If you want to know more look at 'f_ofb_branch17_framework_plugins' in
> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/ofbiz.conf/
> (only committers)
>
> All builds mention: "The Documentation is only generated for the next stable
> version, at the moment R17"
>
> Jobs to do are:
>
> Adds the same in trunk and R18
>
> And especially before ask the same than in
> https://issues.apache.org/jira/browse/INFRA-17258 distinguishing each case.
> Better call them stable, next
> and trunk than R17, R18 and trunk (OK trunk never "change" ;) )...
>
> HTH
>
> Jacques
>
> Le 23/05/2020 à 11:27, Olivier Heintz a écrit :
>> Thanks Jacques for the clarification,
>>
>> But, I'm not sure to understand,
>> currently, doc is generated only for R17 and are only included in buildbot
>> job for trunkFrameworkPlugin ?
>> Work to do is to add for job R17Framework and R18Framework ?
>> Infra help is needed to publish for multi-release ?
>>
>> can I help about one of these points ?
>>
>> Olivier
>>
>> Le 20/05/2020 à 17:15, Jacques Le Roux a écrit :
>>> Thanks Olivier,
>>>
>>> I must add that it's the current location and it would need more work to
>>> change it, notably Infra help
>>>
>>> Jacques
>>>
>>> Le 20/05/2020 à 16:24, Olivier Heintz a écrit :
>>>> Yes, of course
>>>>
>>>> My explanation was not clear, I propose to have one documentation by
>>>> release and use it in the relative help
>>>>
>>>> My question is more about using (or not)
>>>> ci.apache.org/projects/ofbiz/site/${release}/ofbizdoc
>>>>
>>>> Le 20/05/2020 à 08:32, Michael Brohl a écrit :
>>>>> Hi Olivier,
>>>>>
>>>>> wouldn't it be better to have different documentation paths for the
>>>>> different branches?
>>>>>
>>>>> If we would show the trunk documentation/help for stable branches, it
>>>>> will most likely be wrong in some cases.
>>>>>
>>>>> Another thought: it would be great if we could have the docs available
>>>>> at ofbiz.apache.org/docs/trunk/, ofbiz.apache.org/docs/r18.12/ etc.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael Brohl
>>>>>
>>>>> ecomify GmbH - www.ecomify.de
>>>>>
>>>>>
>>>>> Am 19.05.20 um 11:54 schrieb Olivier Heintz:
>>>>>> Hi Community,
>>>>>>
>>>>>> I need some comment or thought about one of point of the solution
>>>>>> proposed.
>>>>>>
>>>>>> Is there some people against the fact of used
>>>>>> ci.apache.org/projects/ofbiz/site/ofbizdoc (generate for the trunk) for
>>>>>> the ofbiz help ?
>>>>>>
>>>>>> As I explained in my previous email,
>>>>>> ci.apache.org/projects/ofbiz/site/ofbizdoc would be the default value
>>>>>> for userDocUri, (but value in
>>>>>> general.properties can be change with the local place of doc generation).
>>>>>>
>>>>>> If community think, it's a good step solution (on the road to the new
>>>>>> help system), I will create a JIRA for generating the doc on all
>>>>>> supported
>>>>>> branches (currently, it's only done for r17)
>>>>>>
>>>>>> I just finished to migrate AccountingHelpData.xml to added the <set
>>>>>> field="helpAnchor" to the correct screens, so now it's really possible
>>>>>> to see if
>>>>>> it's usable. I will updated the JIRA 11693.
>>>>>>
>>>>>> Olivier
>>>>>>
>>>>>> Le 12/05/2020 à 16:42, Olivier Heintz a écrit :
>>>>>>> Jira 11693 created with a patch proposed
>>>>>>>
>>>>>>> if this solution is accepted, (and all asciidoc integrated) next step
>>>>>>> is to work component by component
>>>>>>> For each:
>>>>>>> 1. add in the component decorator <set field="helpAnchor" to to
>>>>>>> component Title in user-documentation
>>>>>>> 2. using heldata.xml to update all screens which had a dedicated text
>>>>>>> for help, with the new helpAnchor value
>>>>>>>
>>>>>>> It's not a too large task, which can be maybe add in the task list for
>>>>>>> the next community days, and so finish the migration from docbook to
>>>>>>> asciidoc ;-)
>>>>>>>
>>>>>>> any thoughts?
>>>>>>>
>>>>>>> ps: this week, I will do this job for accounting component
>>>>>>>
>>>>>>> Le 11/05/2020 à 15:38, Olivier Heintz a écrit :
>>>>>>>> Hi community,
>>>>>>>>
>>>>>>>> First step about Docbook migration to asciidoc is done, all existing
>>>>>>>> files have been converted
>>>>>>>> (waiting a review before PR merge)
>>>>>>>>
>>>>>>>> Next step is to have a new help system,
>>>>>>>>
>>>>>>>> I propose to do a very simple solution which would be a link to a
>>>>>>>> documentation site.
>>>>>>>> This solution would use
>>>>>>>> 1. at ofbiz level, a default proprety for documentation website
>>>>>>>> uri
>>>>>>>> 2. at the screen level
>>>>>>>> * it would be possible to give a other uri (for user
>>>>>>>> documentation)
>>>>>>>> * if the anchor in the user documentation for this screen is
>>>>>>>> put, the new help is used otherwise the older link is used
>>>>>>>>
>>>>>>>> If this solution is validated, next step will be to update all the
>>>>>>>> screens with the correct link value
>>>>>>>>
>>>>>>>> I propose to create the Jira (and the implmentation) with this very
>>>>>>>> simple solution (using the doc generated by Buildbot as documentation
>>>>>>>> site)
>>>>>>>> when some other people with a good knowledge of gradle and/or ofbiz
>>>>>>>> cms have time to do a internal documentation website, it will be
>>>>>>>> possible to
>>>>>>>> change the default uri ;-)
>>>>>>>>
>>>>>>>> what's your opinion about ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 26/02/2020 à 17:10, Olivier Heintz a écrit :
>>>>>>>>> inline
>>>>>>>>>
>>>>>>>>> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit :
>>>>>>>>>> Hello Olivier,
>>>>>>>>>>
>>>>>>>>>> Without digging into much detail, I can say that it's a good idea to
>>>>>>>>>> switch the online help system to asciidoc.
>>>>>>>>>>
>>>>>>>>>> The current structure of asciidoc templates is designed to be a full
>>>>>>>>>> manual document. To link up different pages to different sections,
>>>>>>>>>> you
>>>>>>>>>> need to break the documentation down to smaller files and then
>>>>>>>>>> combine
>>>>>>>>>> them. This way you can have both the "big" manual and the "per
>>>>>>>>>> screen"
>>>>>>>>>> help section.
>>>>>>>>> In my experience, as I'm working with
>>>>>>>>> - current ofbiz online help
>>>>>>>>> - ofbiz webhelp
>>>>>>>>> - some static doc website done with Grav (build with multiple
>>>>>>>>> small files)
>>>>>>>>> - some static doc website done with asciidoc (only one large
>>>>>>>>> file)
>>>>>>>>> - ...
>>>>>>>>>
>>>>>>>>> With multiple small files it's needed to have a very good search
>>>>>>>>> engine and a global index / TOC
>>>>>>>>>
>>>>>>>>> With the One page doc, the TOC is very large and not always very
>>>>>>>>> convenient, but exist and the browser-find works
>>>>>>>>> and it's easy to navigate between details and generality
>>>>>>>>>
>>>>>>>>> So, as a user, I prefer help base on One page documentation.
>>>>>>>>>> Also, gradle might not be enough for online help. A more robust
>>>>>>>>>> solution could involve integrating asciidoc at the framework level to
>>>>>>>>>> dynamically generate help. So this is another idea to consider.
>>>>>>>>> When we have tried, in the past to dynamically generate html from
>>>>>>>>> standard docbook process it was too slow
>>>>>>>>> it's why it was decide to use a freemarker template to do the
>>>>>>>>> generation, even if only 5% of docbook syntax
>>>>>>>>> was managed.
>>>>>>>>>
>>>>>>>>> Documentation not change very often, static page seem enough for our
>>>>>>>>> need.
>>>>>>>>>
>>>>>>>>>> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Currently OFBiz Online help work with docbook files with html
>>>>>>>>>>> generation done by a ftl template.
>>>>>>>>>>> Link between screen and file to show is done with some content
>>>>>>>>>>> associated with key-word
>>>>>>>>>>>
>>>>>>>>>>> Decision has been done to no more used docbook format but now use
>>>>>>>>>>> asciidoc format.
>>>>>>>>>>>
>>>>>>>>>>> User-manual.adoc should be the new reference for user help. How to
>>>>>>>>>>> use it for online help ?
>>>>>>>>>>>
>>>>>>>>>>> I think it's important that online help is link to a internal help
>>>>>>>>>>> (which can be modified) not to a Apache-OFBiz-website-Help
>>>>>>>>>>> but this point of view can be discuss.
>>>>>>>>>>>
>>>>>>>>>>> To be able to have OFBiz internal help, three points should be
>>>>>>>>>>> solved :
>>>>>>>>>>> 1) with asciidoc we have multiple documentations, it seem important
>>>>>>>>>>> to have a "website" to be able to access easily all the doc.
>>>>>>>>>>> how to "encapsulate" each html documentation generated in a
>>>>>>>>>>> "website"
>>>>>>>>>>> 2) generation doc process put html and pdf files in build
>>>>>>>>>>> directory, how it's possible to access them from ofbiz
>>>>>>>>>>> 3) For online help it's necessary to be able to create link between
>>>>>>>>>>> screen and html anchor.
>>>>>>>>>>> In documentation generate from asciidoc, all title can be
>>>>>>>>>>> used.
>>>>>>>>>>> How to to say this screen should go to this documentation at
>>>>>>>>>>> this title.
>>>>>>>>>>>
>>>>>>>>>>> I suppose content application, can help to solve this points.
>>>>>>>>>>> I need some help from OFBiz-Content experts.
>>>>>>>>>>>
>>>>>>>>>>> For point (1) I'm using jBake but maybe it's possible to do
>>>>>>>>>>> something similar with templating in Content
>>>>>>>>>>> Who has some idea ?
>>>>>>>>>>>
>>>>>>>>>>> For point (2) I suppose it's a "gradle configuration" and "content
>>>>>>>>>>> configuration"
>>>>>>>>>>> Who has some idea ?
>>>>>>>>>>>
>>>>>>>>>>> For point (3) the more simple solution is to add 1 (or 2) field in
>>>>>>>>>>> context which contain help_title,(help_documentation) and
>>>>>>>>>>> so it will be simple to build the correct help link
>>>>>>>>>>>
