Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

[Ron Wheeler]

This is a great step forward.

Thanks
Ron

On 22/07/2016 11:49 AM, Taher Alkhateeb wrote:

Oh I see Ron, this is already implemented. Every plugin can have a
build.gradle file. This file declares the dependencies specific to that
plugin (which actually points to jcenter).

So that part is already done for you :) now we need to figure out the
plugin API which was being discussed in the last few emails.

On Fri, Jul 22, 2016 at 5:53 PM, Ron Wheeler <rwhee...@artifact-software.com

wrote:
I was thinking more about the 3rd party artifacts that can not be included
in releases but need to be installed before OFBiz can run.

I guess that I am assuming that eventually a user will get some sort of
installer that will take all of the various components developed by OFBiz,
find all of the (OFBiz and3rd-party libraries) libraries required to run
the options (plug-ins or core features) selected during the installation
dialogue and organize them in a folder structure and run the required setup
processes to load the seed data and load any industry or
application-specific seed data selected.

I am also looking forward to the day that the framework will be available
as a separate product  with no dependencies on the ERP and the ERP will
have a number of modules with a hierarchy of dependencies rather than a web.


  Ron


On 22/07/2016 10:12 AM, Taher Alkhateeb wrote:


Hi Ron,

Maven and Jcenter are jar repositories. OFBiz components are not jars, so
I
am not sure but I think it would not fit, unless perhaps we can jar and
unjar the folder not sure.

On Friday, 22 July 2016, Ron Wheeler <rwhee...@artifact-software.com>
wrote:

For 3rd party libraries, would Maven Central be a good source?

Everything is there that does not need a license to access
There is a well defined and well supported service for getting artifacts.

Ron

On 22/07/2016 9:31 AM, Nicolas Malin wrote:

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the
business logic specific to each, Apache OFBiz can help to prepare this
but
do not more (I will like to have this as best practice)

I agree to add a new directory plugins and structure it for the future
vision :
* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding
contions

We can create the plugins directory, and keep specialpurpose on a first
step and move step by step each component present.

I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
   -> check if birt is present on the plugins directory, if not download
from

svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
   -> enable it on component-load
   -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache
ofbiz release, only plugins present on

svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/

Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding
of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned
above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like
install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks
that
add/remove components to the component-load.xml instead of editing it
by
hand so it is just using what exists. Gradle completely ignores a
component
if it does not exist in component-load.xml and would not even compile
it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for
that
plugin). For example, it might apply patches on some core applications
(and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this
feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for
the
existing components and at the same time a general purpose plugin
sys

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

[Ron Wheeler]

I was thinking more about the 3rd party artifacts that can not be 
included in releases but need to be installed before OFBiz can run.


I guess that I am assuming that eventually a user will get some sort of 
installer that will take all of the various components developed by 
OFBiz, find all of the (OFBiz and3rd-party libraries) libraries required 
to run the options (plug-ins or core features) selected during the 
installation dialogue and organize them in a folder structure and run 
the required setup processes to load the seed data and load any industry 
or application-specific seed data selected.


I am also looking forward to the day that the framework will be 
available as a separate product  with no dependencies on the ERP and the 
ERP will have a number of modules with a hierarchy of dependencies 
rather than a web.



 Ron

On 22/07/2016 10:12 AM, Taher Alkhateeb wrote:

Hi Ron,

Maven and Jcenter are jar repositories. OFBiz components are not jars, so I
am not sure but I think it would not fit, unless perhaps we can jar and
unjar the folder not sure.

On Friday, 22 July 2016, Ron Wheeler <rwhee...@artifact-software.com> wrote:


For 3rd party libraries, would Maven Central be a good source?
Everything is there that does not need a license to access
There is a well defined and well supported service for getting artifacts.

Ron

On 22/07/2016 9:31 AM, Nicolas Malin wrote:


Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the
business logic specific to each, Apache OFBiz can help to prepare this but
do not more (I will like to have this as best practice)

I agree to add a new directory plugins and structure it for the future
vision :
* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding
contions

We can create the plugins directory, and keep specialpurpose on a first
step and move step by step each component present.

I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
  -> check if birt is present on the plugins directory, if not download
from
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt
  -> enable it on component-load
  -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache
ofbiz release, only plugins present on
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/

Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :


Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned
above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like
install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a
component
if it does not exist in component-load.xml and would not even compile it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core applications
(and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this
feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for the
existing components and at the same time a general purpose plugin system.
We might even have a task like say "updatePlugin" in the future and it is
also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should
definitely
tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly
needed
to p

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

[Ron Wheeler]

For 3rd party libraries, would Maven Central be a good source?
Everything is there that does not need a license to access
There is a well defined and well supported service for getting artifacts.

Ron

On 22/07/2016 9:31 AM, Nicolas Malin wrote:

Hi,

Taher I like you proposal, and I wish to add some complement :)

hot-deploy is to manage specific customer site component with the 
business logic specific to each, Apache OFBiz can help to prepare this 
but do not more (I will like to have this as best practice)


I agree to add a new directory plugins and structure it for the future 
vision :

* add capacity to download a plugin from the asf repo
* support extension to download from a third plateform (like the 
/etc/apt/source.list on debian)
* manage namespace and as you said dependencies. Need give some coding 
contions


We can create the plugins directory, and keep specialpurpose on a 
first step and move step by step each component present.


I imagine a process like this :
* ./gradlew installPlugin org.apache.ofbiz.framework.birt :
 -> check if birt is present on the plugins directory, if not download 
from 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/framework/birt

 -> enable it on component-load
 -> compile, load init date and run init service

When you run ./gradlew installAllPlugin :
* Realize installPlugin on all know plugins, with the official apache 
ofbiz release, only plugins present on 
svn.apache.org/repos/asf/ofbiz-pulgins/branches/relatedRelease/org/apache/ofbiz/


Nicolas

Le 20/07/2016 à 07:29, Taher Alkhateeb a écrit :

Hi Pierre, all,

I think perhaps my proposal was short and therefore your 
understanding of

it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned 
above

to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like 
install,

uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a 
component
if it does not exist in component-load.xml and would not even compile 
it.

So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core 
applications (and

reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this 
feature

I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for 
the
existing components and at the same time a general purpose plugin 
system.
We might even have a task like say "updatePlugin" in the future and 
it is

also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should 
definitely

tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly 
needed
to protect the core framework and applications and to provide an 
eco-system

around it. I'm trying to reach a win-win solution if you will.

Regards,

Taher Alkhateeb

On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :


the graph needs to be checked/amended to possibly remove components
dependencies only introduced by the data model


Sorry, I have noticed I have the bad tendency of using the word
"introduced" instead of "put" or "add" (due to "introduire" false 
friend in

French) please replace for me when you see it, thanks! :)
Here the right word would have been "due to" instead of "introduced by"

Jacques

PS: http://www.etymonline.com/index.php?term=introduction








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal to modify the testing framework for OFBiz

[Ron Wheeler]

I think that your point was well received.
I am just happy that testing is getting attention.

Ron

On 19/07/2016 7:53 PM, Scott Gray wrote:

I'm not looking for any sort of response really.  I was just speaking in
favor of integration tests because I think they provide better coverage at
the cost of a little bit of speed (the framework has to be running to run
them).  Most of the responses coming in were of the form "unit tests are
great because [insert a reason that applies to any type of test]".  So I
was merely pointing out that the arguments weren't specific to unit tests
and hence weren't really adding value to the discussion.

Regards
Scott

On 20 July 2016 at 02:05, Ron Wheeler <rwhee...@artifact-software.com>
wrote:


It is not clear what you are expecting as a specific response.

As you move up the food chain, the definition of "units" changes and the
tests get more complicated and the design of the tests gets more complex
(mock objects, testing race conditions).

It is hard to make specific comments about what kind of testing will give
the highest level of confidence at each level but we are going in the right
direction.

The fact that we are considering tests as a major development activity is
a big step forward.

We can argue about specific cases (scope, tools, value, etc) as we get to
them.

I think that we are at the "good idea" stage rather than at the "policy"
stage at this point.

Ron



On 19/07/2016 4:23 AM, Scott Gray wrote:


I think people are missing my point because they keep replying with
generic
statements that aren't specific to unit tests.

On 19 July 2016 at 20:08, Montalbano Florian <
florian.montalb...@nereide.fr>
wrote:

Hi everyone,

unit tests and integration tests are complementary and with test, the
more
the better.
Implementing unit tests will be a great load of work but it is the same
with every kind of test. As Taher said, we will gain a lot from those
unit
tests for avoiding regression while refactoring the framework. From the
start component scope, it has already be proved useful.
And what Ron said about encouraging the creation of "smaller class that
can be tested easily" is very important too. It can be a first step to
reach TDD in the OFBiz development. TDD can help to give confidence to
newcomer and veteran when updating some part of the code and as Hans
said,
this lead to "continuous improvement and finally continuous deployment".

I'm aware that this does not solve the technical implementation stuff,
but
I think this is an improvement that need to be supported.

Have a nice day,

Florian Montalbano


Le 19/07/2016 09:04, Pierre Smits a écrit :

As with anything, the law of diminishing returns also applies to OFBiz

and
tests. This is not true for unit tests and system integration tests, but
also for user acceptance and performance tests.

Nevertheless, the work done up to now is a good start and - I feel
confident - appreciated. And unit tests are certainly valuable in the
framework stack. How it will be for functions (regarding components in
application and special purpose stack) needs to be addressed when we
reach
that bridge.


Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 8:22 AM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:

Hi Scott,

Well spoken thank you. Okay may I suggest that for any such work we
will
discuss it here see its Merit and if it makes sense then we take it in.
It
is a little early to discuss it right now because we did not yet go to
the
higher-level components. Once we do I'll be sure to have a conversation
about this in here and would appreciate your input to it.

Regards,

Taher Alkhateeb

On Jul 19, 2016 9:00 AM, "Scott Gray" <scott.g...@hotwaxsystems.com>
wrote:

Yeah I'm sure unit tests probably worked well for the start component
given

it is the lowest level component in the system and closest to a basic

java

app.  I just think the value proposition might decrease the further up

the

stack we move with them.  I'm not against unit tests when they prove

useful, but further up the stack I think we should prove the case for

them

before doing much work to support the mocking that will be required to

keep

them inline with 'best practices'.

In OFBiz "bad or unwanted" tends to come mostly in the way of
increasing
complexity from features that require more effort to maintain than the
value they provide to the community.  I think there's a chance
attempting
to mock service tests could fall into that bucket.  I could be wrong,

but I

think it's worth looking into before we declare that unit tests are the

best form of testing for OFBiz.

Regards
Scott

On 19 July 2016 at 17:37, Taher Alkhateeb <slidingfilame...@gmail.com
wrote:

Hi Scott,


Thank you for the feedback.

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

[Ron Wheeler]

sals:

Task 1 “Replace all the current jars in OFBiz with appropriate

remote

libraries from a download repository


--

The work to replace the jars is ongoing and we have already

removed 169

of

them. These libraries will now be automatically downloaded by

Gradle.

Work

will continue to remove the remaining files. As we are working

through,

we

are finding library migration issues with some of the

specialpurpose

components so would like *to propose to deactivate all

specialpurpose

components by default.*


Task 4. “ Move all java source files

to\u2002$component/src/main/java

and

introduce all unit tests

in\u2002\u2002$component/src/test/java”
-

Another area we need to progress is the re-design and changing

of

the

directory structure so that we can separate the Java files

between

main

and

test. This will help us simplify the implementation of a

testing

framework.

*The proposal for the directory structure is as follows:

componentname/src/main/java
componentname/src/test/java*


Task 10. “Propose the renaming specialpurpose to plugins or

such

an

appropriate name for clarity”


-

We would like * to propose changing the name of the

specialpurpose

folder to

'plugins'*

These are the 3 areas we would like to progress so please feel

free to

respond with your feedback and comments.

Thanks
Sharan




--
View this message in context:

http://ofbiz.135035.n4.nabble.com/DISCUSSION-Proposed-Task-List-for-Moving-Forward-with-Gradle-and-the-Trunk-tp4687808p4688257.html

Sent from the OFBiz - Dev mailing list archive at Nabble.com.






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal to modify the testing framework for OFBiz

[Ron Wheeler]

, Mridul Pathak <
mridul.pat...@hotwaxsystems.com <javascript:;>>


wrote:

+1

Makes perfect sense.

--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com

On Jun 8, 2016, at 2:41 PM, Taher Alkhateeb <
slidingfilame...@gmail.com <javascript:;>>
wrote:


Hello Everyone,

After refactoring the start component and while


starting

on

the

base

component I realized that the testing framework

for

OFBiz

is


not

good.

You

cannot do real test driven development or


red-green-refactor

with

the

current setup, hence my proposal to change it. I

explain

below:

Problem with current design


- What we have right now is not unit tests, it's


really

integration

tests.

You have to start the framework, the database,


the

service

engine,

the

entity engine and pretty much everything.

- Testing is very slow, because it's an


integration

test

as

I


mentioned

above. 10 minutes on a good computer!

- There is zero mocking! We actually have to


--load-data

for

things

to


work. Again, these are integration tests.

- Too complex: Integration tests by their nature


are

grabbing

too

much.

Mind you, I am not objecting to integration
tests

(I


actually

like

them)

but I am objecting to not having real
unit-tests.

Unit

tests

should

all

run


in a few seconds.

Proposed solution
--
- We keep what is considered real integration


tests

the

way

they

are

right

now and keep using them
- We move what should be unit tests into simple


JUnit

classes,

and

we

do

not run them using java -jar ofbiz.jar --test,
but

instead

run

them

directly from the build.xml script, so these

files

are

not

identified

in

any XML document, but are simply called
immediately

from

the

build

scripts.

- We clearly mark the difference between


integration

tests

and

unit

tests

(inside the source files or in the suite
declarations).

- We change the run-tests target in build.xml to

run

both

unit

tests

and

integration tests.

I intend to heavily refactor the framework and I


would

feel

better

about

introducing this change while refactoring. What
do

you

guys

think?

Ideas?

Suggestions? Approvals and thumbs up?

Regards,

Taher Alkhateeb






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal to modify the testing framework for OFBiz

[Ron Wheeler]

...@hotwaxsystems.com> wrote:


+1

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Fri, Jun 10, 2016 at 7:46 PM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:
Hello Everyone,

I was able to get a few tests running and this is very doable. But

I

faced

a big problem in designing the testing framework because of ANT.

The problem

The way the build scripts are designed in OFBiz are very complex. A

master

file calls other files which call other files. And in the middle

you

have

external libraries (ant-contrib) and macros, and variables, and

class

path

declarations, and and and 

I cannot declare the tests programmatically (with JUnit test

suites)

because this means lower level components would depend on higher

level

components. So I have to do it in ANT, by navigating this maze of

build

scripts, and it was a headache for me just to read them, let alone

modify

them to create a testing framework.

Suggested Solution

I suggest to implement the testing framework in Gradle, and simply

call

it

from within ant. This is a middle solution that sustains ant for

now,

but

can allow us to switch out later.

This means I will just add one more file called build.gradle in the

top

level directory, and figure out the business logic for calling the

test

suites from that file

I look forward to your feedback.

Regards,

Taher Alkhateeb

On Wed, Jun 8, 2016 at 6:00 PM, Taher Alkhateeb <
slidingfilame...@gmail.com>
wrote:


Hi Everyone,

Thank you all for your support, JIRA created in
https://issues.apache.org/jira/browse/OFBIZ-7254

I will start working on it and try to implement ASAP to get my

focus

back

on refactoring.

Cheers!

Taher Alkhateeb

On Wed, Jun 8, 2016 at 4:58 PM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:


+1

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

On Wed, Jun 8, 2016 at 7:12 PM, Mridul Pathak <
mridul.pat...@hotwaxsystems.com> wrote:


+1

Makes perfect sense.

--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com


On Jun 8, 2016, at 2:41 PM, Taher Alkhateeb <

slidingfilame...@gmail.com>

wrote:

Hello Everyone,

After refactoring the start component and while starting on

the

base

component I realized that the testing framework for OFBiz is

not

good.

You

cannot do real test driven development or red-green-refactor

with

the

current setup, hence my proposal to change it. I explain

below:

Problem with current design

- What we have right now is not unit tests, it's really

integration

tests.

You have to start the framework, the database, the service

engine,

the

entity engine and pretty much everything.
- Testing is very slow, because it's an integration test as

I

mentioned

above. 10 minutes on a good computer!
- There is zero mocking! We actually have to --load-data for

things

to

work. Again, these are integration tests.
- Too complex: Integration tests by their nature are

grabbing

too

much.

Mind you, I am not objecting to integration tests (I

actually

like

them)

but I am objecting to not having real unit-tests. Unit tests

should

all

run

in a few seconds.

Proposed solution
--
- We keep what is considered real integration tests the way

they

are

right

now and keep using them
- We move what should be unit tests into simple JUnit

classes,

and

we

do

not run them using java -jar ofbiz.jar --test, but instead

run

them

directly from the build.xml script, so these files are not

identified

in

any XML document, but are simply called immediately from the

build

scripts.

- We clearly mark the difference between integration tests

and

unit

tests

(inside the source files or in the suite declarations).
- We change the run-tests target in build.xml to run both

unit

tests

and

integration tests.

I intend to heavily refactor the framework and I would feel

better

about

introducing this change while refactoring. What do you guys

think?

Ideas?

Suggestions? Approvals and thumbs up?

Regards,

Taher Alkhateeb







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [jira] [Commented] (OFBIZ-1319) Split javascript files to have more generic ones includable in all screens, and the more specific ones included more locally

[Ron Wheeler]

On 02/07/2016 11:10 AM, Amardeep Singh Jhajj (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/OFBIZ-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15360207#comment-15360207
 ]

Amardeep Singh Jhajj commented on OFBIZ-1319:
-

I agree with you that having smaller files with their related topics. But I 
would suggest to have one file for now for all utilities because increasing 
number of js files in page will increase the HTTP request. Please read - 
Minimize HTTP Requests
Separating modules that are always required from modules that are only 
required for specific pages or groups of pages will increase the number 
of http requests but make them smaller. Depending on caching, the extra 
http requests might not be an issue. The organization's internal caching 
policies (local proxies or squid for example) might be easier to 
optimize the static code if the js files being cached are separate and 
identified.

https://developer.yahoo.com/performance/rules.html

Here, one thing can be done in future that we may add some mechanism for 
concatenation of js files (using binng uild tools) into one file, which 
normally done for js files which includes in all pages. This one file further 
minimized during build. So concatenation, minification can be a part of build 
process. I am not currently planned or thought about the build process for it.


Separating delivery packaging from coding packaging is almost always a 
good idea.




In that case we can break current selectall.js into smaller files. So its just 
my thought, i am open to suggestions from you :)

Currently, I am focusing on following things-

1. Simplify and improve currently written utilities so that it can be used from 
any where using class, id or data attributes. It will help us to remove inline 
js in ftls.
2. Removing unused code from selectall.js



Split javascript files to have more generic ones includable in all screens, and 
the more specific ones included more locally


 Key: OFBIZ-1319
 URL: https://issues.apache.org/jira/browse/OFBIZ-1319
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Priority: Minor

 From a David's E. Jones comment on ML :
We should split up javascript files to have the more generic ones includable in 
all screens, and the more specific ones (like the toggle* and selectAll* 
methods in there) into a file that can be included more locally.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Important Changes to Trunk and Use of Ant & Gradle

[Ron Wheeler]

This sounds like a great step forward.
In addition to the technical benefits, this identifies OFBiz as a 
"modern" project which will help in market acceptance when technical 
analysts are asked to comment.


Ron

On 20/06/2016 8:50 AM, Sharan Foga wrote:

Hi Everyone

This is the second of two emails to inform the community about what has been 
happening around how we are planning to handle external dependencies in the 
trunk. Two weeks ago the community discussed and agreed to the use of Gradle to 
help us put together a unit test framework. While trying to get this set up 
while Ant remained as our build tool became very difficult. This was because 
our Ant scripts:

- are massive and contain a lot of code
- are complex
- are very brittle and make it very hard to change things
- have no dependency management
- need everything to be declared

We realised very quickly that the re-factoring issues and limitations we are 
facing are because of our build tool – Ant.

Ant is verbose so it needs everything to be declared. We did a brief assessment 
of Maven and found it better than Ant but not a good fit for OFBiz because it 
has strict requirements for the convention-over-configuration rules to work. 
Instead we decided to take a closer look at Gradle.

So why Gradle?
As Taher was already looking at Gradle for unit testing, we decided to look at 
what we would need to do to totally replace Ant with Gradle. We received some 
great support and feedback from David, who is already using Gradle with Moqui.

After some preliminary tests we found that Gradle has some very good features 
such as:

- a much shorter code base (e.g. one single file of around 250 lines of 
code replaces all the build.xml files and thousands of lines of code)
-  Programming is DSL based and links in well with Groovy (e.g. the script 
is short because despite heavy custom requirements for OFBiz, two small 
functions took care of the complex directory structure)
- It handles all the external jar files by downloading any dependencies 
directly via internet
- Jars can be upgraded by simply changing a string
- It has matured a lot and has a high level of support in tools,IDEs, 
books, documentation
- It also has a lot of plugins which means that it works with pretty much 
all build systems, supports multiple programming languages, and many other 
features (e.g. OSGi)

We understand that it can help us make OFBiz more modular and also setting up a 
framework for managing addons would be a lot easier.

So what's been done?
Taher has been working very hard on a patch for the trunk that completely 
replaces Ant with Gradle.  (Huge thanks to David for providing some example 
scripts to help us get started!) The patch is now ready to be applied to the 
trunk and includes the following:

 - java -jar ofbiz.jar is now replaced with -> gradlew 'ofbiz 
--whatever-options-here'
 - In addition to gradlew 'ofbiz' we also have gradlew 'ofbizDebug 
--whatever'. What does that mean? It means we can run debug on ALL ofbiz 
commands, not just start
 - If we decide to change the source directory structure in components say 
from /src to /src/main, it would literally be a change of 5 characters in the 
build script
 - We can immediately move all jar files if we want to a unified location 
in /lib for example
 - We can delete most of the jars and declare them as dependencies saving 
space and resources
 - We can automate the creation of the .classpath file so when we update 
libraries no need to do this manually (under development)
 - We can ignore components that are not define in the xml files for 
loading (under development)
 - We can introduce unit tests with about 10 minutes of work

We are finding that the flexibility and control we are getting with Gradle is 
truly amazing. We know that Gradle will be a major change to the project but we 
think that it will significantly improve the project by removing a lot of build 
complexity and take care of that essential dependency management that we need 
to comply with.

Our next steps will be to apply the patch to the trunk and then continue the 
re-factoring work. We will need to organise some knowledge transfer so that all 
our committers understand what the changes are and how they would need to work 
in the future.

The PMC are very, very excited about having Gradle as part of future of OFBiz 
and we hope that the community will think so too. As always, feedback welcome.

Thanks
Sharan




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: We miss a QA team, we face too much regressions

[Ron Wheeler]

On 17/06/2016 5:19 AM, Jacques Le Roux wrote:

Le 16/06/2016 à 22:53, Ron Wheeler a écrit :
One of the side benefits of having a small number of committer's is 
that you prevent bad designs and poorly  tested code getting into the 
trunk.
The disadvantage is that the committers are easily overwhelmed by an 
active contributor community.


Would you say that with 31 committers (most active) we are currently a 
small number of committers?


Are the committers able to verify the code committed?
How many of the regressions should have been detected before the code 
was committed?


How many of the regressions were caused by lack of documentation of 
existing features so that people broke things that were "hidden" 
relationships?


It is hard to build and maintain a bullet-proof integration test suite 
so human engineering is still a big part of the solution.





You may want to put in some rules about unit tests so that code 
without adequate test coverage can not be updated until the unit 
tests are sufficient for the committer to feel confident about 
accepting it. This may cause people to work on tests for stuff that 
they did not write but are considered key functionality in the 
modules being updated.
There is no free ride and if you allow people to build up the 
technical debt of the project in order to meet their own deadlines, 
you will eventually have to face a large debt that comes due.


Taher is paying off the debt in the framework which is a great 
contribution.
It may be that others are going to have to take up the challenge in 
the application side.
You may have to have a short moratorium on enhancements until the 
debt is reduced to a manageable level.


There may also be the issue of people modifying too many layers at 
once so changes affect a lot of different services so unpleasant 
side-effects are easier to generate.


Are the regressions caused by a small group of contributors or from 
updates going through a few committers?


As I said it's recently fortunately small things. For now it's hard to 
answer to your question, because the HW effort is rip-roaring. I guess 
when it will settle a lot of things will be better/fixed, in the 
meantime me will certainly face some uncertainty.
My question was not about pointing finger put how to prevent issues. 
Hence my question about Selenium because our current set of tests is 
obviously not enough.
Your suggestion about more unit tests and rules is certainly to 
consider. I'd wait the end of the rip-roaring HW effort, for things to 
stabilise, and then try to introduce more constraints, or should we 
discuss it right away, community?




When you are in a hole, the first think to do is to stop digging!




It is an open source project so there has to be some sensitivity 
about asking people to do a bit more to clean up old debt but if that 
is a problem and it is not addressed, it can be a big mess.


I see a lot of skilled good will and clearly success for the last few 
years. I think we can achieve it, OFBiz is here to stay!


Jacques




Ron


On 16/06/2016 3:48 PM, Taher Alkhateeb wrote:

Hi Jacques,

Selenium tests cannot be unit tests in OFBiz because it requires 
firing up
the server. You can consider them part of the integration tests 
(existing
functionality). In fact, I would consider selenium tests to be 
functional

tests (higher than integration) ->
https://en.wikipedia.org/wiki/Functional_testing

So yeah we can add them, but I don't think we can do that to the raw
unit-tests (at least in the context discussed in the other proposal 
thread)


Taher Alkhateeb

On Thu, Jun 16, 2016 at 10:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

With the considerable HW effort, a lot of things are going on 
recently,
and it's hard to follow. I though noticed that we experience more 
and more

regressions (not all related to HW effort, far from it).

Fortunately it's so far mostly minor points and often related with 
the UI,

OFBIZ-7346 and OFBIZ-7363 being counter examples (OFBIZ-7346 can be
critical)

 From my experience, w/o a QA person or team, it's very hard to detect
those side effects at the UI level when you refactor or fix it. I 
remember
the (ex) Neogia team (mostly Erwan) tried to maintain a 
Selenium/Webdriver

set of tests. I don't know if they continue/d.

Since we spoke about Junit and unit tests recently, some prefer 
TestNG, at

least coupled with Selenium http://testng.org/doc/selenium.html

Does it make sense, do you think it's only an utopia?

Thanks

Jacques











--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: We miss a QA team, we face too much regressions

[Ron Wheeler]

One of the side benefits of having a small number of committer's is that 
you prevent bad designs and poorly  tested code getting into the trunk.
The disadvantage is that the committers are easily overwhelmed by an 
active contributor community.


You may want to put in some rules about unit tests so that code without 
adequate test coverage can not be updated until the unit tests are 
sufficient for the committer to feel confident about accepting it. This 
may cause people to work on tests for stuff that they did not write but 
are considered key functionality in the modules being updated.
There is no free ride and if you allow people to build up the technical 
debt of the project in order to meet their own deadlines, you will 
eventually have to face a large debt that comes due.


Taher is paying off the debt in the framework which is a great 
contribution.
It may be that others are going to have to take up the challenge in the 
application side.
You may have to have a short moratorium on enhancements until the debt 
is reduced to a manageable level.


There may also be the issue of people modifying too many layers at once 
so changes affect a lot of different services so unpleasant side-effects 
are easier to generate.


Are the regressions caused by a small group of contributors or from 
updates going through a few committers?


It is an open source project so there has to be some sensitivity about 
asking people to do a bit more to clean up old debt but if that is a 
problem and it is not addressed, it can be a big mess.



Ron


On 16/06/2016 3:48 PM, Taher Alkhateeb wrote:

Hi Jacques,

Selenium tests cannot be unit tests in OFBiz because it requires firing up
the server. You can consider them part of the integration tests (existing
functionality). In fact, I would consider selenium tests to be functional
tests (higher than integration) ->
https://en.wikipedia.org/wiki/Functional_testing

So yeah we can add them, but I don't think we can do that to the raw
unit-tests (at least in the context discussed in the other proposal thread)

Taher Alkhateeb

On Thu, Jun 16, 2016 at 10:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

With the considerable HW effort, a lot of things are going on recently,
and it's hard to follow. I though noticed that we experience more and more
regressions (not all related to HW effort, far from it).

Fortunately it's so far mostly minor points and often related with the UI,
OFBIZ-7346 and OFBIZ-7363 being counter examples (OFBIZ-7346 can be
critical)

 From my experience, w/o a QA person or team, it's very hard to detect
those side effects at the UI level when you refactor or fix it. I remember
the (ex) Neogia team (mostly Erwan) tried to maintain a Selenium/Webdriver
set of tests. I don't know if they continue/d.

Since we spoke about Junit and unit tests recently, some prefer TestNG, at
least coupled with Selenium http://testng.org/doc/selenium.html

Does it make sense, do you think it's only an utopia?

Thanks

Jacques





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal to delete stale java files

[Ron Wheeler]

Poorly documented, non-functioning code is not an attractive feature 
that will draw new users.


If there are pieces that are being removed that you think are worth 
remembering, write a wiki note (it can be searched by Google) 
documenting these partially implemented features that can be recovered 
from the SCM if anyone cares in the future.


The attic is a compromise to make hoarders feel comfortable but putting 
junk in the attic with no documentation about why things were written, 
why they are not finished or currently not used,  is of questionable 
value. Non-functioning code that may be written to older standards or, 
worse yet, bad programming practices is just dangerous.


Is anyone willing to QC the code placed in the attic?

Ron

On 14/06/2016 1:01 PM, Pierre Smits wrote:

As the majority of the referenced java files are related to 3rd party
solutions integrations, we should have done the smart thing and that is
provide them as optional Proof of Concept components. In stead we had/have
them as almost hard coded functionalities. Removing these from the code
base in trunk involves more. It means also removing the elements that
access these (directly and indirectly), including screen and form widgets,
templates, services and request and view map uris.

But if we remove them from the code base (to the attic), before long the
knowledge will be lost and the feature set of OFBiz will shrink. Some may
not care about that, but it will - again - make the uphill adoption battle
more difficult.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jun 14, 2016 at 4:10 PM, Taher Alkhateeb <slidingfilame...@gmail.com

wrote:
Hi Everyone,

I cannot actually believe it but while I was working on a project (I will
announce later) I discovered in the process that the below files cannot
compile!!! They existed for years in the code base without even being able
to compile. They reference non existent libraries or they have faulty code
(e.g. not importing used code)

I propose to delete them immediately from trunk


applications/accounting/src/org/ofbiz/accounting/thirdparty/cybersource/IcsPaymentServices.java

applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealEvents.java

applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java

applications/accounting/src/org/ofbiz/accounting/thirdparty/orbital/OrbitalPaymentServices.java

applications/accounting/src/org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java

applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java

applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayServiceTest.java

applications/accounting/src/org/ofbiz/accounting/thirdparty/verisign/PayflowPro.java

applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayInputStream.java

applications/content/src/org/ofbiz/content/openoffice/OpenOfficeByteArrayOutputStream.java

applications/content/src/org/ofbiz/content/openoffice/OpenOfficeServices.java
applications/content/src/org/ofbiz/content/openoffice/OpenOfficeWorker.java
applications/content/src/org/ofbiz/content/report

applications/content/src/org/ofbiz/content/report/JREntityListIteratorDataSource.java

applications/content/src/org/ofbiz/content/report/JRMapCollectionDataSource.java
applications/order/src/org/ofbiz/order/thirdparty/taxware

applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareException.java

applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java
applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
applications/product/src/ShipmentScaleApplet.java

applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java

framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java

framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java

Regards,

Taher Alkhateeb




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Proposal to delete stale java files

[Ron Wheeler]

rty/taxware/TaxwareException.java



applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareServices.java

applications/order/src/org/ofbiz/order/thirdparty/taxware/TaxwareUTL.java
applications/product/src/ShipmentScaleApplet.java



applications/securityext/src/org/ofbiz/securityext/thirdparty/truition/TruitionCoReg.java



framework/webapp/src/org/ofbiz/webapp/view/JasperReportsJXlsViewHandler.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPdfViewHandler.java



framework/webapp/src/org/ofbiz/webapp/view/JasperReportsPoiXlsViewHandler.java
framework/webapp/src/org/ofbiz/webapp/view/JasperReportsXmlViewHandler.java

Regards,

Taher Alkhateeb




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Taher Alkhateeb joins the OFBiz PMC

[Ron Wheeler]

Great addition to the team!
Ron

On 10/06/2016 2:05 AM, Jacopo Cappellato wrote:

Welcome, Taher! Keep up the great work.

Jacopo




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSSION] Setting Up Mentoring

[Ron Wheeler]

There are 2 current Skype channels that are actively in use.
One (9 members) is specifically designated for the framework.
 The general channel has 35 participants.

Ron
On 08/06/2016 4:36 AM, Sharan-F wrote:

Hi Everyone

I've created a page on the wiki to try and organise the mentoring. We have a
list of people who volunteered to be mentors, so if you want to be a mentor,
then please feel free to add your name ot this list.

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Mentors

I'm very conscious of the fact that we dont want to overload the mentors so
I suggest that we initially focus the mentoring on the framework
re-factoring work. This is a specific area where we know there is a lot of
complicated and difficult code that could be hard to understand.

My suggestion would be that anyone who has a re-factor task could be paired
up with a mentor to help them with it in case they encounter problems. What
do people think about this idea?

I've also been looking at different ways in which the mentoring could take
place. We need somewhere that is easy to use, and if one mentor isnt
available, a question could perhaps be managed by someone else. We could
make use of our existing IRC channel, Skype or Hipchat.

I think our IRC channel is underused which shows that people prefer not to
use it much. Skype is also an  option but out of the three I think Hipchat
could be a good to look at. It is the main communication method  used by our
ASF Infra team if you need to talk to anyone urgently and from experience I
know it works really well. We already have a Hipchat OFBiz room setup so
could easily implement something similar to ASF Infra with our mentors or
even create a group where our committers could hangout and quickly contact
each other.

In the past we talked about having a committers space where they could come
together, get to know each other and collaborate more, but never set
anything up so this could also be an opportunity to do that. I will send out
some invitations to our committers to join the Hipchat OFBiz room so you can
take a look around and see what you think.

As usual I'm happy to get feedback on any of the points raised.

Thanks
Sharan



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Setting-Up-Mentoring-tp4682877.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: My experience with refactoring the framework

[Ron Wheeler]

ey need to understand that there

are

different tasks at different levels of complexity and that there are

senior

out there who are willing to help. The tools we are using for

collaboration

makes it difficult to convey this fact.
- Impersonal and we cannot get people engaged. Things like

conversations,

brainstorming, assigning tasks, discussing, coaching, teaching and
encouraging are difficult to do. These personal elements are crucial

for

knowledge transfer and support.

In short, I think there are members in the society who are willing to
help, but not sure how. It's really unfortunate not to engage these
individuals because of communication barriers.

My 2 cents!

Taher Alkhateeb

-Original Message-
From: Sharan-F [mailto:sharan.f...@gmail.com]
Sent: 06 June 2016 10:57
To: dev@ofbiz.apache.org
Subject: Re: My experience with refactoring the framework

Hi Taher

Thanks for sharing your experience as I think it contains some real
insights and also re-confirms an important task – we need to tidy up

our

code. And the one crucial message I hear loud and clear in your email

is

that we need everyone to help out too.

(BTW I've seen the amount of work that you have done on the start.java
which is looking very elegant now :-)

Your list re-factoring ideas touch on a lot of areas that I'm sure will
generate discussion and I hope that we don't get too caught up in the
discussion that we don't act. We need to stay active by continually

doing

something that improves OFBiz.

I agree that we should look at holding off adding new features or
improvements now and just clean. I've seen the huge amount of activity

that

is happening at the moment so let's see if we can maybe focus some of

that

energy into tidying up our code and getting rid of our ' historic

technical

debt' (as mentioned by Jacques).

It sounds like you have already a list of tasks to replenish our

Current

Re-Factor To Do list so let's do that and get the message out to the
community about what they can do to help. I noticed that if we have a

list

of tasks that people can pick up easily, then they will.

Going forward we may need to have a bit more co-ordination and also

work

together in small groups focussing on particular areas so things dont

get

broken, especially once the applications start being affected.

I'm happy to help so just let me know how I can.

Thanks
Sharan



--
View this message in context:


http://ofbiz.135035.n4.nabble.com/My-experience-with-refactoring-the-framework-tp4682539p4682591.html

Sent from the OFBiz - Dev mailing list archive at Nabble.com.





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [DISCUSSION] Mentoring to Share Knowledge and Improve Code

[Ron Wheeler]

The current open Skype channels are a good place for quick mentoring 
activities.


If the question turns from a personal request for information to a 
design question or a discussion about bug fixes or enhancement, then 
relevant comments should be copied to the ML or a JIRA.
The Skype channel does keep a long term history so it is easy to go back 
to early comments and retrieve them.


Ron

On 06/06/2016 9:56 AM, Jacopo Cappellato wrote:

I like Sharan's proposal and I am willing to help. Even if most question
can and should be posted to the dev list (so that others can benefit from
the communication exchange) by experience I have learned that sometimes new
contributors/committers are worried to ask questions in the public...
having a direct way to communicate with a senior committer (either by mail,
chat or phone) may help in these cases.

Jacopo

On Mon, Jun 6, 2016 at 12:46 PM, Sharan-F <sharan.f...@gmail.com> wrote:


Hi All

One of the things that came up in the Committers Survey was related to
mentoring. I asked the question whether it would be a good idea if newer
Committers were mentored by a more experienced one and  63% of the
Committers surveyed agreed it would be.

I think that this could be something that could be worth exploring as we
have Committers with a lot of experience and knowledge that could be good
mentors to others. Mentoring could be something as simple as being
available
to answer questions or to give advice about how to approach something, but
the main thing is that there is someone to ask informally.

For example, I'm sure that Jacques has probably lost count of the amount of
times I approached him offline for help with all kinds of things :-), and
every response has really helped.

What do people think?  (And more importantly is anyone willing to be a
mentor?)

Thanks
Sharan




--
View this message in context:
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Mentoring-to-Share-Knowledge-and-Improve-Code-tp4682594.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Custom ClassLoader in OFBiz

[Ron Wheeler]

As you may know this was introduced by Adrian
at http://svn.apache.org/viewvc?view=revision=1676746
for https://issues.apache.org/jira/browse/OFBIZ-6268
after an effort by Jacopo at
https://issues.apache.org/jira/browse/OFBIZ-5768

Maybe this was done for something like




https://stackoverflow.com/questions/15635039/how-to-handle-shared-native-library-in-multiple-web-applications-on-tomcat

where another way of doing it in the Tomcat context is suggested
I did not dig further today, but I note this link here for myself
http://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html

Adrian also introduced InstrumentingClassLoader class then. It's

related

with Cobertura. But as Adrian said he was unable to have it working.

HTH

Jacques






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Framework & Code Re-Factoring: Maintaining Quality

[Ron Wheeler]

+1
Words to live by.
Words to review commits by.
The fact that code "works" is only one thing to consider before 
accepting the obligation of maintaining it forever.


Ron

On 26/05/2016 2:38 AM, Taher Alkhateeb wrote:

Hello everyone,

We already discussed in detail the best practices and guidelines for
refactoring (review the rest of this thread).

I am writing this email instead to focus on an important point that I'm
noticing in the code base and the refactoring exercise. Forget all the
details for a moment and focus on this one guiding principle: _Code should
be clear_

What this means is that the code you wrote is done with care and love.
Method names clearly explain what they're supposed to do. Your code starts
at high level and goes down to details. I can read it like a story, it
makes sense, it's easy on the eyes, You can almost say It's boring.

One of the best ways to confuse other developers is to have hidden state.
You declare a global variable and manipulate it in a 100 different places
in your code and it's not even passed to those places, you just yank it!

Another place which is badly implemented in many places in ofbiz is methods
(functions). All the below guidelines can improve these methods:
- The names should reflect intention. It's much better to name something
like retrievePersonDetails(...) than retrieveStringList(...)
- They should be small enough to fit in your screen, preferably even
shorter.
- They should do _only one thing_. Don't fetch data, validate it, and then
send it to the screen all in one place. Each one of those things is a
function, and then you can combine them in one master function or object.
- They should be at the same level of abstraction (don't mix high level
stuff with details)

Food for thought for those interested.

Taher Alkahteeb

On Fri, Apr 8, 2016 at 3:58 PM, Ron Wheeler <rwhee...@artifact-software.com>
wrote:


Just a reminder to everyone that there is an ongoing Skype conversation
around the framework refactoring sub-project.
If you are not part of the conversation, please ask to join.

It is not very active so you will not get a lot of notes to read
However, it provides a place where you can quickly get input from the rest
of the team working on the sub-project.

It is a good place to look for feedback or advice before you start to work
on a task or have to make a design choice that may have affects on other
parts of the project.

There is also a much larger group on Skype that is more active that
involves many of those working on OFBiz in general.

You can join these groups even if you are not currently actively
contributing to the project.

That being said, the Skype conversations are not designed to replace the
wiki of the ML so don't forget to confirm decisions or summarize important
discussions in the appropriate official record.

Ron
PS:
Taher's recommended readings are worth a quick read.
Well written.
Lots of good ideas and important reminders about coding practices.


-
On 08/04/2016 8:18 AM, Taher Alkhateeb wrote:


Hi Sharan and all,

To all contributors to the project, I highly recommend reading:

- Refactoring: Martin Fowler
- Clean Code: Robert Martin (AKA uncle Bob)
- SOLID principles of OOP
- Test Driven Development (TDD)

I also encourage fellow committers to think of design changes and areas
they dislike in the framework to add to the list in the wiki page. I'm
sure
with the combined expertise of everyone we can speed up this project a
lot.

Regards,
Taher Alkhateeb

On Friday, 8 April 2016, Pranay Pandey <pranay.pan...@hotwaxsystems.com>
wrote:

+1 will be extra careful going forward.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Fri, Apr 8, 2016 at 12:36 PM, Sharan-F <sharan.f...@gmail.com
<javascript:;>> wrote:

Hi Everyone

It's great to see the progress happening on the framework and code
re-factoring.  Tasks from our to do list are being picked up and worked


on,


so thank you to everyone involved in this.

As this is a code clean-up, I'd really like to emphasize that we need to


be


extra careful because we are changing the way we currently code. This


means


that there is some extra responsibility for the committers in the review
process to ensure that the quality of the code going in is an
improvement
to
the existing code (I.e we dont want to commit anything that keeps our


code


untidy or makes it even worse)

If we can include stronger quality checks while the re-factoring is
going
on, we can be sure that we are definitely making and delivering code
improvements.

What do people think?

Thanks
Sharan




--
View this message in context:



http://ofbiz.135035.n4.nabble.com/Framework-Code-Re-Factoring-Maintaining-Quality-tp4679123.html


Sent from the OFBiz - Dev mailing list archive at Nabble.com.



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Fwd: Re: Managing Emeritus Committers

[Ron Wheeler]

Given that Cloudstack (and Apache) considers "committer" status to be a 
permanent status and that an emeritus committer can reactivate 
unilaterally, it does not seems necessary (or even reasonable) to 
restrict their access, unless they request it.


Main points from the Cloudstack example:
1) rules are explicit and PMC decisions are recorded in the bylaws
2) clear recognition of past contribution (and perhaps remaining but 
passive  interest in the project) while keeping the "active" list 
accurately reflecting the people who are currently contributing in an 
on-going basis.


Ron

On 21/04/2016 1:49 AM, Sharan-F wrote:

Hi Jacques

I thought that the discussion Ron raised was more about communication rather
than actually disabling access. I agree with you in the sense that I think
it could turn out to be considerably more work than we would want to manage.

Thanks
Sharan



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Fwd-Re-Managing-Emeritus-Committers-tp4679835p4679850.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Fwd: [DISCUSS] Emeritus Committer Status

[Ron Wheeler]

There may be some merit in this idea from the Cloudstack team.

Ron


 Forwarded Message 

All,

As I am sure many have observed, we have a large number of committers [1] who 
are no longer active.  Currently, we no status that continues to recognize 
someone’s committer merit while allowing them to declare inactive in the 
project.  To address this gap, I am proposed amending our project bylaws [2] as 
follows:

2.3.4  A committer is considered "emeritus" by sending their declaration to 
priv...@cloudstack.apache.org.
  An emeritus committer may return to "active" status by sending their declaration to 
priv...@cloudstack.apache.org.
  No vote is required for a committer change from “emeritus" to “active" status.

2.3.5 "Active committters" are all non-emeritus committers.

These clauses were inspired by the Apache Cocoon [3] bylaws [4].  To be clear, 
a committer never loses their merit, and only a committer can decide to go 
emeritus.  Since merit is never lost, a emeritus committer may return to active 
status at anytime by simply informing the PMC of their intention to be active 
again.  No one can require that committer change to emeritus status.

On the website, we would place emeritus committers in a separate section — 
allowing users to more easily identify those that are actively participating in 
the project.

Thoughts?
-John

[1]: http://cloudstack.apache.org/who.html
[2]: https://cloudstack.apache.org/bylaws.html
[3]: http://cocoon.apache.org/
[4]: 
http://code.metager.de/source/xref/apache/cocoon/commons/bylaws/bylaws.txt#14

Regards,

John Burwell

john.burw...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue

Re: Spreadsheet file handler creation

[Ron Wheeler]

I focused on creating the XML since it is a big problem to transfer data 
exported  from other systems.


The data in the XML files that loads the OFBiz demos and base systems is 
pretty sparse and I am sure that a lot of this is caused by the 
difficulty of taking tabular data in a spreadsheet and generating all of 
the entities.


On the output side, I would investigate using ADTransform to execute 
queries using the OFBiz WebService interface to produce spreadsheets, 
html reports, visualizations.
I have not looked at the OFBiz webservice interface and it may be that 
several services might have to be used to acquire all of the data 
required to fill in a spreadsheet.


ADTransform can do table lookups to merge data.

For example, if I wanted to have a spreadsheet with customer info as 
well as the name and contact info for the sales rep,

it would require 4 steps:
- webservice call to extract the sales reps, assuming that OfBiz has a 
webservice that can be queried to get what you want.
- webservice call to extract the customers, assuming that OfBiz has a 
webservice that can be queried to get what you want.
- lookup operation to produce the denormalized table by looking up each 
sales person and copying the desired fields to the customer.
This is a single operation that requires the name of the "datastore" 
holding the master file(customer), the name of the datastore holding the 
lookup table(salesrep), the keys to match (salesrep name or id) and the 
list of columns in the salesrep datastore to copy each customer row.

- output the extended customer table to Excel or CSV (both are supported)

I would probably produce an HTML report as well just to have an easy way 
to look at the data.
If there are other mappings to convert codes to meaningful information 
that is possible.
Filtering is available to split data based on the contents of certain 
fields (list of customers in France separated from international)

Fields can be concatenated, sequence numbers can be added.

I have not written the Webservice plug-in but it should be pretty 
straightforward.

- open the connection,
- extract the data into rows and fields
- put each row in a the datastore mapping the webservice field names to 
the desired names in the datastore (if they are not the same).


This would follow the same pattern as the plug-in that reads CSV files 
without all of the screwing about to skip rows before and after optional 
headers, etc.


ADTransform is a standalone program that can be run as a batch job or 
spawned as a service.

There is an API for writing plug-ins.
Plug-ins can be added without affecting the core ADTransform jar files.
Plug-ins are referenced through Spring in the workflow configuration so 
you can use any plug-in that is in a jar file in the ADTransform bin folder.
Plug-in exist now that can manipulate local files and directories and 
use ftp to move data to and from external systems.

There is an e-mail plug-in.

It produces an error log and audit trail that are written to be read by 
a non-programmer. "Duplicate customer number 1345 found in rows 7 and 456".


Does this help?

Ron



On 14/04/2016 3:27 PM, Nicolas Malin wrote:
Hi Ron, I reviewed the proposal on Jira 
https://issues.apache.org/jira/browse/OFBIZ-6931


It's simple and faster, can you check it if you have a better idea 
with an other externe tools to send a flow on spread software through 
the screen engine ?


Nicolas

Le 21/03/2016 14:56, Ron Wheeler a écrit :

It can also output HTML files fully annotated for CSS styling.

It also can create reports using JasperReport.

It can read CSV (with and without headers) and Excel files.

It can be extended by plug-ins to read anything that you can parse 
into row and columns

Webservice and SQL connections are possible sources for data.


Ron




On 21/03/2016 9:16 AM, Leila Mekika wrote:

Hello Ron,

i didn't know about ADTransform and will look at it. Actually, my 
goal is to make an export file and it seems to allow spreadsheet 
output.
But i already had the need to make a spreadsheet to xml conversion 
for import purpose, so i'll keep that in mind (and your post in 
adtransform website)

Thanks !

Leila

Le 19/03/2016 02:38, Ron Wheeler a écrit :

ADTransform will do most (perhaps all) of what you want.

It will read a spreadsheet (or a CSV file), let you manipulate the 
data, verify it and then produce a set of XML files.
I have done a partial script to take multiple spreadsheets and 
create OFBiz XML entity files.


The OFBiz XML structure is fairly complex and to load a simple 
spreadsheet  containing a list of customers with their names, 
addresses, email, phone numbers starts with a pretty simple 
spreadsheet but ends up with many, many XML files. Spreadsheets 
with Customers, Customer Service employees and SIC codes generate 
19 XML files!



Ron


On 18/03/2016 6:05 AM, Leila wrote:

Hello everyone,

We had to do a spreadsheet file handler for a customer project

Re: Framework & Code Re-Factoring: Maintaining Quality

[Ron Wheeler]

Just a reminder to everyone that there is an ongoing Skype conversation 
around the framework refactoring sub-project.

If you are not part of the conversation, please ask to join.

It is not very active so you will not get a lot of notes to read
However, it provides a place where you can quickly get input from the 
rest of the team working on the sub-project.


It is a good place to look for feedback or advice before you start to 
work on a task or have to make a design choice that may have affects on 
other parts of the project.


There is also a much larger group on Skype that is more active that 
involves many of those working on OFBiz in general.


You can join these groups even if you are not currently actively 
contributing to the project.


That being said, the Skype conversations are not designed to replace the 
wiki of the ML so don't forget to confirm decisions or summarize 
important discussions in the appropriate official record.


Ron
PS:
Taher's recommended readings are worth a quick read.
Well written.
Lots of good ideas and important reminders about coding practices.


-
On 08/04/2016 8:18 AM, Taher Alkhateeb wrote:

Hi Sharan and all,

To all contributors to the project, I highly recommend reading:

- Refactoring: Martin Fowler
- Clean Code: Robert Martin (AKA uncle Bob)
- SOLID principles of OOP
- Test Driven Development (TDD)

I also encourage fellow committers to think of design changes and areas
they dislike in the framework to add to the list in the wiki page. I'm sure
with the combined expertise of everyone we can speed up this project a lot.

Regards,
Taher Alkhateeb

On Friday, 8 April 2016, Pranay Pandey <pranay.pan...@hotwaxsystems.com>
wrote:


+1 will be extra careful going forward.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Fri, Apr 8, 2016 at 12:36 PM, Sharan-F <sharan.f...@gmail.com
<javascript:;>> wrote:


Hi Everyone

It's great to see the progress happening on the framework and code
re-factoring.  Tasks from our to do list are being picked up and worked

on,

so thank you to everyone involved in this.

As this is a code clean-up, I'd really like to emphasize that we need to

be

extra careful because we are changing the way we currently code. This

means

that there is some extra responsibility for the committers in the review
process to ensure that the quality of the code going in is an improvement
to
the existing code (I.e we dont want to commit anything that keeps our

code

untidy or makes it even worse)

If we can include stronger quality checks while the re-factoring is going
on, we can be sure that we are definitely making and delivering code
improvements.

What do people think?

Thanks
Sharan




--
View this message in context:


http://ofbiz.135035.n4.nabble.com/Framework-Code-Re-Factoring-Maintaining-Quality-tp4679123.html

Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: End User Documentation

[Ron Wheeler]

Perfect.
Welcome to the gang.

Ron
On 24/03/2016 11:13 PM, james yong wrote:

Yes, the secretary from Apache has acknowledged the receipt of my ICLA file
submission. The acknowledgement is also sent to OFBiz private email.


Ron Wheeler wrote

Do you have an ICLA on file with Apache?

Ron


--
Ron Wheeler
President
Artifact Software Inc
email:
rwheeler@
skype: ronaldmwheeler
phone: 866-970-2435, ext 102





--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/End-User-Documentation-tp4678247p4678298.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: End User Documentation

[Ron Wheeler]

Do you have an ICLA on file with Apache?

Ron
On 24/03/2016 4:58 AM, james yong wrote:

Jacques Le Roux wrote

Also if ever you want to collaborate to the wiki, simply follow this
notice https://cwiki.apache.org/confluence/display/OFBIZ/No+Spam

BTW you asked on the right place, the user ML is the right place for this
kind of questions

Jacques

Le 24/03/2016 02:49, Craig Parker a écrit :

I asked over on the users list, and someone said I might have better luck
here. End user documentation appears to be a smidgen sketchy. I know a
lot
of apps use wikis, but I've got a wordpress template set up that kind of
mimics the ofbiz interface.  I'm about to sit down and try learning how
to
use this puppy over the next year or so, and figured that'd be the best
way to take notes.

Is there anyone kind of "in charge" of end user documentation I can
collaborate with?


Hi all,

Can anyone help me to register as a contributor to the wiki?
My Confluence usernames is jamesyong.

Regards,
James



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/End-User-Documentation-tp4678247p4678257.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Spreadsheet file handler creation

[Ron Wheeler]

It can also output HTML files fully annotated for CSS styling.

It also can create reports using JasperReport.

It can read CSV (with and without headers) and Excel files.

It can be extended by plug-ins to read anything that you can parse into 
row and columns

Webservice and SQL connections are possible sources for data.


Ron




On 21/03/2016 9:16 AM, Leila Mekika wrote:

Hello Ron,

i didn't know about ADTransform and will look at it. Actually, my goal 
is to make an export file and it seems to allow spreadsheet output.
But i already had the need to make a spreadsheet to xml conversion for 
import purpose, so i'll keep that in mind (and your post in 
adtransform website)

Thanks !

Leila

Le 19/03/2016 02:38, Ron Wheeler a écrit :

ADTransform will do most (perhaps all) of what you want.

It will read a spreadsheet (or a CSV file), let you manipulate the 
data, verify it and then produce a set of XML files.
I have done a partial script to take multiple spreadsheets and create 
OFBiz XML entity files.


The OFBiz XML structure is fairly complex and to load a simple 
spreadsheet  containing a list of customers with their names, 
addresses, email, phone numbers starts with a pretty simple 
spreadsheet but ends up with many, many XML files. Spreadsheets with 
Customers, Customer Service employees and SIC codes generate 19 XML 
files!



Ron


On 18/03/2016 6:05 AM, Leila wrote:

Hello everyone,

We had to do a spreadsheet file handler for a customer project and 
decided to use current csv renderer to generate a datafile, then 
convert it to xls with Workbook library.
It turns out to be very long when extracted file reaches a big load 
of data...


In order to resolve this, i am currently trying to make a new 
handler that generate a html table file which can be imported as 
spreadsheet in most office software suite (i've made a JIRA 
<https://issues.apache.org/jira/browse/OFBIZ-6931>). Cells are 
formatted via css (found this 
<http://niallodoherty.com/post.cfm/basic-html-to-excel-formatting>).
The generated file is an html file with application/xls response 
content-type, since i didnt' find any "html to ods" or "html to xls" 
converter. I think it's because it can be done from the software 
suite interface, but i was wondering: does anyone know of a library 
that can transform html to spreadsheet file ?


Does anyone has another suggestion than the html generation to 
achieve a fast spreadsheet file rendering ?

Thanks for any idea or advice

Leila Mekika










--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Draft Minutes from Skype Framework Re-Factor Call: 15th March 2016

[Ron Wheeler]

One of the issues that was identified as a problem with code quality is 
the number of warnings in the code.


There are 340 warnings in the system at the moment.
Most of them seem to be things that will make the code less prone to 
unintended consequences of changes.
They also give the impression that the code is of low quality and 
written in a careless way.


It would be a big help if all developers could stop digging this hole 
deeper.


If you are working on a piece of code and it has warning in it, fix them.
If the warning really is spurious, add a Suppress Warning annotation for 
the specific problem.

If you are not sure about how to fix the warning, ask.

It would be really helpful if the committers made warnings a reason for 
not approving a commit.


Ron


On 16/03/2016 7:25 AM, Taher Alkhateeb wrote:

Hi Sharan,

Excellent write-up. The only thing I would add is that the complex
refactoring would include design changes to the API signatures which might
affect existing systems as was raised by Ron Wheeler.

Regards,

Taher Alkhateeb

-Original Message-
From: Sharan-F [mailto:sharan.f...@gmail.com]
Sent: 16 March 2016 11:43
To: dev@ofbiz.apache.org
Subject: Draft Minutes from Skype Framework Re-Factor Call: 15th March 2016

Hi Everyone

A huge thank you goes out to everyone who participated in the Framework
Re-Factor Skype Group call yesterday. It was a very dynamic and active call
and I hope it helped to get us focussed on our general approach and our next
steps. There were a lot of good ideas and suggestions that came out - which
is great.

I've written up the draft minutes from the call based on my notes on the
following wiki page (so everyone please feel free to take a look though what
was discussed)

https://cwiki.apache.org/confluence/display/OFBIZ/Skype+Re-Factor+Group+Call
%3A+15th+March+2016

I hope that I've captured all the main points but just in case there is
something missing that is important or I've misunderstood then please let me
know.

Thanks
Sharan



--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Draft-Minutes-from-Skype-Framework-Re-Fact
or-Call-15th-March-2016-tp4677836.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Commit criteria

[Ron Wheeler]

In addition to the "no Warnings" policy for commits that I suggested 
earlier today,
I would suggest that a "no Missing or Incomplete JavaDocs" for commits, 
would go a long way to improving code quality.


It would also make it easier to review code if one could read a simple 
but complete  description of the class and its methods to decide if a 
class should be accepted.


I suspect that most reversions of committed code are not caused by 
programming bugs within methods but are caused by functional problems 
that probably could have been detected by reading the JavaDoc if it was 
written properly.

Just speculation!

It would also make it easier to detect classes and methods that are too 
complex or that duplicate existing functionality or that are designed to 
fit at the wrong level in the functional structure for the methods that 
they provide.


It clearly would make the system easier to learn and safer to modify.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Spreadsheet file handler creation

[Ron Wheeler]

ADTransform will do most (perhaps all) of what you want.

It will read a spreadsheet (or a CSV file), let you manipulate the data, 
verify it and then produce a set of XML files.
I have done a partial script to take multiple spreadsheets and create 
OFBiz XML entity files.


The OFBiz XML structure is fairly complex and to load a simple 
spreadsheet  containing a list of customers with their names, addresses, 
email, phone numbers starts with a pretty simple spreadsheet but ends up 
with many, many XML files. Spreadsheets with Customers, Customer Service 
employees and SIC codes generate 19 XML files!



Ron


On 18/03/2016 6:05 AM, Leila wrote:

Hello everyone,

We had to do a spreadsheet file handler for a customer project and 
decided to use current csv renderer to generate a datafile, then 
convert it to xls with Workbook library.
It turns out to be very long when extracted file reaches a big load of 
data...


In order to resolve this, i am currently trying to make a new handler 
that generate a html table file which can be imported as spreadsheet 
in most office software suite (i've made a JIRA 
<https://issues.apache.org/jira/browse/OFBIZ-6931>). Cells are 
formatted via css (found this 
<http://niallodoherty.com/post.cfm/basic-html-to-excel-formatting>).
The generated file is an html file with application/xls response 
content-type, since i didnt' find any "html to ods" or "html to xls" 
converter. I think it's because it can be done from the software suite 
interface, but i was wondering: does anyone know of a library that can 
transform html to spreadsheet file ?


Does anyone has another suggestion than the html generation to achieve 
a fast spreadsheet file rendering ?

Thanks for any idea or advice

Leila Mekika




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Release Information hopelessly outdated

[Ron Wheeler]

http://ofbiz.apache.org/download.html needs an update in the Release 
Information.

Some of the forecasted dates are from last year.

Can someone who knows what was done and what is planned to be done, 
update this so that it makes sense.



Should all references to 11.04.xx be removed and included in the 
superseded releases?


Do we really want new users downloading 12.04?

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Skype Group Call Next Week re-Framework Re-Factoring

[Ron Wheeler]

7:00 AM is not a problem if that is the best time available.

Ron


On 07/03/2016 2:27 AM, Sharan-F wrote:

Hi Taher

I didnt realise Ron was interested. If that's the case then that makes it
difficult for us to have our call today as it will only be 7am his time.

I think then it's better to postpone the call until next week to make sure
that we have the availability of everyone who is interested in a call.

We do have a Community Day coming up on the 19th March so as long as we can
have our call beforehand to co-ordinate the work then we should be able to
get things moving in time for that.

Thanks
Sharan






--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Skype-Group-Call-Next-Week-re-Framework-Re-Factoring-tp4677595p4677610.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Framework Re-Factor: List of Areas that Need Work

[Ron Wheeler]

needs to be
done.

I hope that people will take a look and select an area to begin working on.
We need as much help as we can get. I think that if we can get the work
started then we can gain the momentum to continue.

Thanks
Sharan




--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Framework-Re-Factor-List-of-Areas-that-Nee
d-Work-tp4677565.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Framework Cleanup Options - Tidy Up & Refactor?

[Ron Wheeler]

I think JIRAs are essential if you expect others to help out.


I don't think that it would be a bad thing to create the JIRA after you 
fix something and attach a patch to the JIRA showing all the little 
changes that you made as part of the JIRA rather than writing a 
description that is longer than the code being fixed.



Ron


On 04/02/2016 1:19 AM, Taher Alkhateeb wrote:

Hi Sharan and Everyone,

When we lost Adrian in the beginning of the rewrite project I really felt
lost. His feedback made things simple and I miss having him around for
mentoring and feedback. I think deferring the rewrite project is a good
idea for now.

I shifted my energy into just playing with the code and dabbling here and
there and I got surprised by the many problems that exist pretty much
everywhere. This would be things like:

- Extending classes from external libraries into the core APIs
- Writing to implementations instead of interfaces
- Files too long
- Different levels of abstractions mixed together
- Poor test coverage, lack of TDD
- Implicit (hidden) dependencies (I dislike this the most)

I think the above issues indicate that we really do need less energy on new
features, and much more on refactoring. We should refactor everything
including core API interfaces. Some examples of work we can do:

- EntitySaxReader implements javolution interfaces and looks hideous
- HtmlFormRenderer is 3000 lines of code and the interfaces it implements
are also huge
- XmlFormRenderer does not implement more than half of the methods
- Lots of dependencies on deprecated classes / constructors (e.g.
HtmlScreenRenderer, FoScreenRenderer)
- Start.java has some problems which I'm trying to tackle in JIRA:
OFBIZ-6783
- Lots of non-parameterized and non type checked declarations.
- Implementations with no interfaces (e.g. TemporalExpression, GroupModel,
Cache, etc ...)

The list goes on and on. Every one of the SOLID principles for Bob Martin
is violated in many places and most of the code smells in his book also
exist.

I started a thread a while back suggesting that I would like to start
refactoring without too many JIRAs because it would slow us down. However,
the feedback from the community I got is that JIRA creation is preferred.
This, however, would slow down progress especially if I'm just making minor
one-line changes. We need an efficient way to make continuous daily
improvements to the code base.

Also, we need to document our design philosophy for others to consider when
writing code. I don't mean just formatting conventions but also things like
writing to interfaces, TDD, design rules specific to OFBiz, and so on.

To summarize:
- We have a LOT of refactoring work, it's everywhere
- We need a more efficient workflow for continuous daily refactoring, the
current workflow is too bureaucratic
- We need help from everyone
- We need to expand the coding guidelines to introduce some design
concepts, not just formatting.

Those are my very long 2 cents.

Taher Alkhateeb

On Wed, Feb 3, 2016 at 8:19 PM, Sharan-F <sharan.f...@gmail.com> wrote:


Hi Everyone

A few months ago we started looking at a proposed framework re-write sub
project with Adrian as our mentor.

https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component

With Adrian gone it makes it hard for us to continue so have decided to
abandon this effort.

We don't want to give up on having a better framework and know that another
option is to tidy up our existing framework. (So yes – this means
refactoring, and yes it will be a lot of work)

In general we do sometimes tidy up or refactor as we go along and some work
has already started with movement of entity definitions into a separate
datamodel component. If we really do want to tidy up our framework then we
will need as many people from the community as possible to help out.

Now here comes the big question – is the community interested in really
doing this and are there people out there willing to help out?

Thanks
Sharan









--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-Refactor-tp4676797.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Fwd: [PROPOSAL] LTS Release Cycle

[Ron Wheeler]

There has been a long discussion about release strategies in the Apache 
Cloudstack forum.
This is an interesting proposal that has been fleshed out to a pretty 
good level of detail.


Although Cloudstack and OFBiz serve very different areas, both could be 
described as critical applications where downtime and instability will 
have very high corporate visibility.
Security is important to both and fixes to underlying third party 
software can come at any time and they may force upgrades to the 
application unexpectedly.

Bugs need to be fixed as well.

They are currently issuing an  official release every month which gets 
new features and bug fixes out quickly but is causing some discomfort 
for the majority of the system administrators who can not keep up with 
that pace given the amount of internal certification required and the 
inability to stand that frequency of maintenance downtime.


This tries to balance the thirst for new features with the need for 
stability and attempts to move the decision about upgrades to the user 
by reducing the pain of not upgrading so often while providing a way for 
those who need the bleeding edge to have access to bug fixes and new 
features quickly.


Ron

 Forwarded Message 

Motivation


The current monthly release cycle addresses the needs of users focused 
on deploying new functionality as quickly as possible. It does not 
address the needs of users oriented towards stability rather than new 
functionality. These users typically employ QA processes to comply with 
corporate policy and/or regulatory requirements. To maintain a growing, 
thriving community, we must address the needs of both user types. 
Therefore, I propose that we overlay a LTS release cycle onto the 
monthly release cycle to address the needs of stability-oriented users 
with minimal to no impact on the monthly release cycle. This proposed 
LTS release cycle has the following goals:


* Prefer Stability to New Functionality: Deliver releases that only 
address defects and CVEs. This narrowly focused change scope greatly 
reduces the upgrade risk/operational impact and shorter internal QA cycles.
* Reliable Release Lifetimes: Embracing a time-based release strategy, 
the LTS release cycle will provide users with a reliable support time 
frames. Users can use these time frames provide users with an 20 month 
window in which to plan upgrades.
* Support Sustainability: With a defined end of support for LTS releases 
and a maximum of two (2) LTS releases under active maintenance at any 
given time, community members can better plan their commitments to 
release support activities. We also have a agreed upon policy for 
release end-of-life (EOL) to debate about continuing work on old releases.


Proposed Process
==

LTS release branches will be cut twice year on 1 Jan and 1 July from the 
tag of the most recent monthly release. The branch will be named version>-LTS and each LTS release will be versioned in the form of version>-. For example, if we cut an LTS branch 
based on 4.7.0, the branch would be named 4.7.0-LTS and the version of 
the first LTS release would be 4.7.0-0, the second would be 4.7.0-1, 
etc. This release naming convention differentiates LTS and monthly 
releases, communicates the version on which the LTS release is based, 
and allows the maintenance releases for monthly releases without version 
number contention/conflict. Finally, like master, an LTS branch would be 
always deployable following its initial release. While it is unlikely 
that LTS users would deploy from the branch, the quality discipline of 
this requirement will benefit the long term stability of LTS releases. 
All PRs targeting an LTS would require two LGTMs in order to be merged.


The following are the types of changes that would permitted and 
guarantees provided to users:


* No features or enhancements would be backported to LTS release branches.
* Database changes would be limited to those required to address the 
backported defect fixes.
* Support for the release/version of the following components from the 
release on which the LTS is based throughout the entire release cycle:

* MySQL/MariaDB
* JDK/JRE
* Linux distributions
* API compatibility for between all LTS revisions. API changes would be 
limited to those required to fix defects or address security issues.


An LTS release would have a twenty (20) month lifetime from the date the 
release branch is cut. This support period allows up to two (2) months 
of branch stabilization before initial release with a minimum of 
eighteen (18) months of availability for deployment. LTS releases would 
have the following support periods:


* 0-14 months: backport all defect fixes in the scope of the LTS release 
functionality; fix all blocker and critical priority defects identified 
in the branch
* 14-20 months: backport only CVE fixes in the scope of the LTS release 
functionality; fix all blocker priority defects in the 

Re: The future of ofbiz cms

[Ron Wheeler]

http://www.meta64.com/ is a new open source CMS based on Jackrabbit Oak 
,Spring, MongoDb and Tomcat.


It seems to be a new project that needs some work.

Ron

On 04/01/2016 7:59 AM, Bruno Wegmüller wrote:

Hi Guys,

I'm interested about the state of the ofbiz cms and the plans for the
future development in this topic. After reading the mailing lists
concernig ofbiz cms i think there is still a wish for inproving the cms
component. We realized some projects with ofbiz and think about the idea
to improve the cms component. Maybe we can share our effort with the
community.

But there are some open questions:
There is a jackrabbit branch. Is this branch still "active"? Is it still
planned to integrate this branch with the trunk. Or do you rather prefer
to use the actual data model and only improve the GUI of the CMS Backend?

Kind regards!
Bruno




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Refactoring code and JIRA

[Ron Wheeler]

If you raise a JIRA for each refactoring exercise then people can 
comment on your plan.


The scope of the JIRA should be short so you can finish it, test it and 
close it before a lot of other bugs/enhancements get done that might 
affect the same code.


The scope should be short so that if you break anything, it is easy to 
know what to revert - I know that you will not break anything but I am 
speaking in general.


The scope should be short so that a release can be started with a finite 
and well understood list of JIRAs to be fixed before the release is 
ready to go.
I don't like a general JIRA since it would make it hard to tell how much 
work was included and it would have no expected completion or any way to 
estimate that.

Perhaps the lack of release strategy for OFBiz makes this a weak argument.

If the scope is well defined, others in the community can help if you 
are not able to find time to finish it.


Ron


On 23/12/2015 1:28 PM, Taher Alkhateeb wrote:

Thank you Jacques and Pierre

Ok so perhaps a middle ground is to have a central JIRA issue to which I
refer all commits. This way I can be lean in cleaning up the code base.

Oh and please disregard the other email, it was my bad for sending twice

Regards,

Taher Alkhateeb

On Wed, Dec 23, 2015 at 9:11 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


I assume pure code refactoring with no functional changes does not need a
Jira.
But what you could do is many commits with a sole Jira issue, for people
to refer in a sole place in case of need.

Jacques


Le 23/12/2015 18:33, Taher Alkhateeb a écrit :


Hi everyone,

Many times I have the itch to cleanup the code base but not sure whether a
JIRA issue is necessary.

Do i need to issue a JIRA for pure code refactoring (no functional
change)?
This would include things like function and variable rename, breaking up
big classes and functions, adding unit tests, rewiring classes and so on.

Cheers

Taher Alkhateeb





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler]

It seems that this discussion is just dancing around the core problem 
with the current structure of OFBiz.


There seems to be a natural set of almost separate projects that are 
lumped together into a rather tangled object.


This discussion is nibbling around the edge of the problem rather than 
addressing the problem straight up.


To get to the next level of product maturity, we need to find a way to 
break the product into manageable pieces with well defined rules about 
how it gets extended and how "new" features get integrated.
The framework should be the first to get untangled since that is 
supposed to be a separate product.
This is in progress but it not yet clear what the relationship will be 
between the new framework and the old one or even OFBiz.


At some point, the leaders of this project are going to have to decide 
what is the core ERP application. This means separating:

- core functionality
- core seed data
- seed Data for particular industries or
- demos
- optional application modules

Then there needs to be rules about how new things get added.

Breaking up the people who can commit to each area will add a bit of 
discipline to the process.
At the moment any committer can change every level of the structure to 
accomplish their goals.
This is very efficient for the person wanting to add something but 
creates havoc for the project as a whole.


Getting to a point where releases of individual components can be made 
without having to release everything at once will have a lot of benefits 
and make it easier to maintain an OFBiz installation.
If you can upgrade the framework without updating the ERP, framework 
improvements can be made more rapidly.
If the core ERP can be upgraded without having to worry about every 
"special purpose" component ever created, it will get a lot easier to 
get releases out.


This means that there will have to be rules and real APIs that you can 
not violate.


It will also mean that people wanting to change things that require 
changes to multiple levels will have to actually discuss their proposal 
and convince the framework team or ERP team to add the required 
functionality and test it to make sure that it does not break the API.


This will also increase the potential for community involvement. 
Currently, it is too risky to add committers who only want to work on 
one module or even a demo since there is no way to stop them breaking 
lots of things accidentally.


Ron

On 14/12/2015 1:01 AM, Jacques Le Roux wrote:

Le 08/12/2015 20:59, Nicolas Malin a écrit :



Le 19/11/2015 11:45, Jacques Le Roux a écrit :

Could we list, apart the well known Birt issue, special 
components which

are overriding main applications?


Directly by memory, the scrum components has defined new seca on cust
request to send email that break the standard customer request system

An other where I failed,  used service findProductsById instead of
findProductById, the first from hhfacilty and the second from 
catalog. And
want you start your hot-deploy component without specialpurpose 
... paff !

:)


Thanks for these points Nicolas, I agree with Pierre suggestion.

For instance does really the hhfacilty findProductById service needs 
to be named the same than in product? Etc.
Of course I'm also for this, but the problem isn't on the capacity to 
open a jira issue.


Nicolas



OK, I had an idea. Why not commenting out the specialpurpose 
components by default, but uncomment those which have proved to "not 
be a problem"?


"Not be a problem" means here which are not overriding applications 
component. So we could create a "Comment out specialpurpose components 
by default" Jira
with possible subtasks for litigious cases (when we find an issue 
after uncommenting out)


I suggest though that we don't do that on trunk (which would still 
contains all components active) but on the next frozen release. We 
could even do it on R14.12 if we have a consensus.


To start, I'd at least uncomment out:
example
exampleext
pos
ecommerce(? if not OK then we create the main Jira and a subtask for it)

Adds your please...

Opinions?

Jacques




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler]

On 14/12/2015 4:40 PM, Jacques Le Roux wrote:

Hi Ron,

It's interesting, and I agree with you we must organise the project 
and ourselves "more". But it's too early for me at the moment :/
Sorry but I prefer to keep focused on simple tasks (baby steps) for 
now, this one is about specialpurpose components :)
It is a start and is raising the discussion about structure even if it 
is not as sweeping as I would like.
The discussion itself is valuable in bringing some hidden agendas and 
undocumented usage and dreams to the fore.




Note that another baby step we have already decided on is to group the 
applications data model in one component.
This should hopefully clarify things at the applications level. I 
think most dependencies are due to the data model, but I'm not quite 
sure about that.
Anything that decouples the various parts is a good step and even if 
some problems are found that can not be solved immediately at least they 
will have been identified.




Jacques
PS: BTW I just found this article interesting 
http://breakingsmart.com/season-1/rough-consensus-and-maximal-interestingness 
. Seems that there are a bunch of others as interesting there.




It would be much easier to follow some of the idea expressed here about 
agility, freedom and rough consensus if the risks were minimized by 
limiting the scope of the impact of the decisions.


Ron



Le 14/12/2015 16:47, Ron Wheeler a écrit :
It seems that this discussion is just dancing around the core problem 
with the current structure of OFBiz.


There seems to be a natural set of almost separate projects that are 
lumped together into a rather tangled object.


This discussion is nibbling around the edge of the problem rather 
than addressing the problem straight up.


To get to the next level of product maturity, we need to find a way 
to break the product into manageable pieces with well defined rules 
about how it gets extended and how "new" features get integrated.
The framework should be the first to get untangled since that is 
supposed to be a separate product.
This is in progress but it not yet clear what the relationship will 
be between the new framework and the old one or even OFBiz.


At some point, the leaders of this project are going to have to 
decide what is the core ERP application. This means separating:

- core functionality
- core seed data
- seed Data for particular industries or
- demos
- optional application modules

Then there needs to be rules about how new things get added.

Breaking up the people who can commit to each area will add a bit of 
discipline to the process.
At the moment any committer can change every level of the structure 
to accomplish their goals.
This is very efficient for the person wanting to add something but 
creates havoc for the project as a whole.


Getting to a point where releases of individual components can be 
made without having to release everything at once will have a lot of 
benefits and make it easier to maintain an OFBiz installation.
If you can upgrade the framework without updating the ERP, framework 
improvements can be made more rapidly.
If the core ERP can be upgraded without having to worry about every 
"special purpose" component ever created, it will get a lot easier to 
get releases out.


This means that there will have to be rules and real APIs that you 
can not violate.


It will also mean that people wanting to change things that require 
changes to multiple levels will have to actually discuss their 
proposal and convince the framework team or ERP team to add the 
required functionality and test it to make sure that it does not 
break the API.


This will also increase the potential for community involvement. 
Currently, it is too risky to add committers who only want to work on 
one module or even a demo since there is no way to stop them breaking 
lots of things accidentally.


Ron

On 14/12/2015 1:01 AM, Jacques Le Roux wrote:

Le 08/12/2015 20:59, Nicolas Malin a écrit :



Le 19/11/2015 11:45, Jacques Le Roux a écrit :

Could we list, apart the well known Birt issue, special 
components which

are overriding main applications?

Directly by memory, the scrum components has defined new seca on 
cust
request to send email that break the standard customer request 
system


An other where I failed,  used service findProductsById instead of
findProductById, the first from hhfacilty and the second from 
catalog. And
want you start your hot-deploy component without specialpurpose 
... paff !

:)


Thanks for these points Nicolas, I agree with Pierre suggestion.

For instance does really the hhfacilty findProductById service 
needs to be named the same than in product? Etc.
Of course I'm also for this, but the problem isn't on the capacity 
to open a jira issue.


Nicolas



OK, I had an idea. Why not commenting out the specialpurpose 
components by default, but uncomment those which have proved to "not 
be a problem"

Fwd: Feature freeze ACS 4.7 next Monday

[Ron Wheeler]

This gives a bit of an insight about how another Apache project that 
builds a key infrastructure product, manages releases.


They seem to have an organized process of deciding how and when new 
features get added.


This also allows them to have a pattern of frequent releases so bug 
fixes get into an official release without having to backport everything.


Ron

 Forwarded Message 

Hi all,

Next Monday we'll feature freeze for our upcoming 4.7 release. We looked through all open 
Pull Requests and below is our "whish list" to get in 4.7. Feel free to 
nominate any other changes that should go in 4.7. No guarantees, there is limited time so 
only PRs that we actively work on will make it.

The RC of 4.7.0 is scheduled for Monday Dec 14th so that we all will have a 
nice Christmas present ;-)

Please help us review these PRs. Most have already had some review and when we 
can reach 2xLGTM we can include them in 4.7 on time and make another great 
release.

Happy testing and reviewing!

Regards,
Daan & Remi


Features & Fixes PRs:

Quota
https://github.com/apache/cloudstack/pull/768

Logging enhancement
https://github.com/apache/cloudstack/pull/1167

VMware diskcontrollers
https://github.com/apache/cloudstack/pull/1132

ACS allows to create isolated networks with invalid gateway ip
https://github.com/apache/cloudstack/pull/1125

Update nic IP address of stopped vm
https://github.com/apache/cloudstack/pull/1086

Hypervisor changes to support UserData for Nuage VSP
https://github.com/apache/cloudstack/pull/1142

Support shared networking in NiciraNVP Plugin
https://github.com/apache/cloudstack/pull/1094

Strongswan vpn feature
https://github.com/apache/cloudstack/pull/872

VM Snapshotting implementation for KVM
https://github.com/apache/cloudstack/pull/977

Redundant VPC improvement
(PR will follow over the weekend)


UI PRs:

[UI] fix bug: Cannot delete SSH keypairs in projects
https://github.com/apache/cloudstack/pull/1154

UI icon over VM snapshot to deploy user instance
https://github.com/apache/cloudstack/pull/1150

Newly added project is not showing in the drop down until the browser is 
refreshed
https://github.com/apache/cloudstack/pull/1082

Re: Feature freeze ACS 4.7 next Monday

[Ron Wheeler]

Yes

Ron
On 05/12/2015 12:49 PM, Jacques Le Roux wrote:

From Github links below seems to be Apache Cloud Stack
https://en.wikipedia.org/wiki/Apache_CloudStack
https://cloudstack.apache.org/

Jacques

Le 05/12/2015 16:06, Pierre Smits a écrit :

What is ACS?

Best regards,

Pierre

Op zaterdag 5 december 2015 heeft Ron Wheeler <
rwhee...@artifact-software.com> het volgende geschreven:


This gives a bit of an insight about how another Apache project that
builds a key infrastructure product, manages releases.

They seem to have an organized process of deciding how and when new
features get added.

This also allows them to have a pattern of frequent releases so bug 
fixes

get into an official release without having to backport everything.

Ron

 Forwarded Message 

Hi all,

Next Monday we'll feature freeze for our upcoming 4.7 release. We 
looked
through all open Pull Requests and below is our "whish list" to get 
in 4.7.

Feel free to nominate any other changes that should go in 4.7. No
guarantees, there is limited time so only PRs that we actively work 
on will

make it.

The RC of 4.7.0 is scheduled for Monday Dec 14th so that we all will 
have

a nice Christmas present ;-)

Please help us review these PRs. Most have already had some review and
when we can reach 2xLGTM we can include them in 4.7 on time and make
another great release.

Happy testing and reviewing!

Regards,
Daan & Remi


Features & Fixes PRs:

Quota
https://github.com/apache/cloudstack/pull/768

Logging enhancement
https://github.com/apache/cloudstack/pull/1167

VMware diskcontrollers
https://github.com/apache/cloudstack/pull/1132

ACS allows to create isolated networks with invalid gateway ip
https://github.com/apache/cloudstack/pull/1125

Update nic IP address of stopped vm
https://github.com/apache/cloudstack/pull/1086

Hypervisor changes to support UserData for Nuage VSP
https://github.com/apache/cloudstack/pull/1142

Support shared networking in NiciraNVP Plugin
https://github.com/apache/cloudstack/pull/1094

Strongswan vpn feature
https://github.com/apache/cloudstack/pull/872

VM Snapshotting implementation for KVM
https://github.com/apache/cloudstack/pull/977

Redundant VPC improvement
(PR will follow over the weekend)


UI PRs:

[UI] fix bug: Cannot delete SSH keypairs in projects
https://github.com/apache/cloudstack/pull/1154

UI icon over VM snapshot to deploy user instance
https://github.com/apache/cloudstack/pull/1150

Newly added project is not showing in the drop down until the 
browser is

refreshed
https://github.com/apache/cloudstack/pull/1082









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler]

rs to manually enable the components they need.

Jacopo

On Thu, Nov 19, 2015 at 8:22 AM, Taher Alkhateeb <
slidingfilame...@gmail.com


wrote:
Hi Nicolas,

I think If your finger hurts you don't cut it off. The project 
has too

many
pages, documentations, email threads and time dedicated to the 
special
purpose components. They existed for a long, long time in the 
history

of

OFBiz.

Some attempts were made in the past to reduce the size of the

framework

and
release 13.07 is a prime example of these attempts which 
failed IMHO.

This
is a reason why, for example, a rewrite of the framework is being
discussed
in the community.

I would suggest to you that to get really lean and clean, we 
need to

work
on the root of the problem which is the design of the 
framework and

its
architecture. We need a _plugin_ implementation that achieves 
_loose
coupling_ of the components in a way that sustains the quality 
of the

code
while at the same time allowing a small framework core to thrive.

Take a

look at this thread <

http://ofbiz.markmail.org/thread/7bipnq3ffoteliff>

in
which we discussed this issue and suggested one of several 
strategies.

There are other threads which I cannot recall at the moment.

For the record, I totally agree with keeping a small core and 
a lean
framework, It's how we get there that I'm worried about and I 
would

suggest
to you that we do this in a well thought out and gradual process.

My 2 cents

Taher Alkhateeb

On Wed, Nov 18, 2015 at 11:22 PM, Nicolas Malin <
nicolas.ma...@nereide.fr>
wrote:

Le 10/11/2015 05:54,slidingfilame...@gmail.com  a écrit :
This topic was heavily discussed in the past and I think a 
solution

like

turning off the components is very quick indeed but not ideal.

Completely, I'm sure a better ideal exist but difficult to 
reach.

A second step, easy to reach would be enable a specialpurpose

directly

by
an ant target :
$ ant load-component -D"component=ecommerce" load-demo start
or
$ ant load-component -D"components=ecommerce projectmgr 
myportal"

load-demo start

This help beginner through easy command line to copy/past from
documentation or expert by scripting to configure ofbiz.

Nicolas









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [Proposition] deactivate by default all specialpurpose component

[Ron Wheeler]

The old joke:

Why is it more important for women to be beautiful than smart?
Because men see better than they think!


If you need any help, let me know.

Ron

On 24/11/2015 10:37 AM, Jacques Le Roux wrote:

We know you like visual graphics ;) And it's a good idea!

Jacques

Le 24/11/2015 15:40, Ron Wheeler a écrit :
Would it be possible create a graphic in the docs identifying what 
overrides what as you find this out?
A description would be great but at least a visual summary would help 
the next person.


Ron

On 24/11/2015 8:31 AM, Jacques Le Roux wrote:
Yes I see, as suggested by Nicolas. But it seems not obvious for a 
non technical person,  and they are often those who assess the 
product by simply running the fasted and easiest ways (I do that 
also with other software, who don't? ;))
Like "Start" section at http://ofbiz.apache.org/download.html and 
others alike in wiki. Unfortunately you can only make 1 1st 
impression. Of course, we possibly could give them an UI for that 
but we should at least change (all) our documentation.


And even if we agree on this, the main part of the work remains: 
some components should not be "commented out".


1. AFAIK example and exampleext does not override anything and they 
are useful (at least to me), notably in official demo.
2. Obviously, as it was in R13.07, ecommerce. But not sure the 
ecommerce component does not override applications...
3. The POS is not concerned: not used in official demos, does not 
override anything.
4. I wonder about the WepPos, does it overrides something, I don't 
think so but not sure
5. Several persons spoke about the project manager, not sure it 
overrides applications.


So the 1st step should be to clearly identify which components are 
concerned.


Jacopo said <specialized behaviors>> We could have all released demos not using 
some specialpurpose components but trunk with all? It's bleeding 
edge after all.


Jacques

Le 21/11/2015 13:07, slidingfilame...@gmail.com a écrit :

Hi Jacques,

what about a parameter using -D for the build script. we can also 
do something programmatic in the ./tools directory.


Regards,
--

Taher Alkhateeb

On Nov 21, 2015, at 12:53 PM, Jacques Le 
Roux<jacques.le.r...@les7arts.com> wrote:


I'd veto something which would blindly applies to all 
specialpurpose components, see my last post about that


Jacques

Le 21/11/2015 09:22, Jacopo Cappellato a écrit :

Taher,

I like your proposal; in fact this feature would be useful not 
only for
automated deployments/tests but also to end users to easily 
enable the

components they like.

Jacopo

On Sat, Nov 21, 2015 at 8:53 AM,<slidingfilame...@gmail.com>  
wrote:


Hi Jacopo,

I would make a distinction between two things: a) preserve what 
exists and

b) prepare for the future.

Doubtless what you are saying below makes perfect sense as a design
decision to allow for better future developments. I am concerned 
however
with what currently exists in specialpurpose. Specifically, I 
worry about
unit tests and Java Source code for framework integration. 
Changes we make

to the framework now needs to be followed up closely and we need to
manually enable, test and re-disable the specialpurpose 
components to

ensure continuous compatibility with trunk. Can we at least have a
modification in build.xml to enable / disable specialpurpose so 
that the

buildbot would continually test against specialpurpose?

If you agree then I can try to write something to that effect in 
build.xml

at least to keep the code live in specialpurpose.

Regards,
--

Taher Alkhateeb


On Nov 19, 2015, at 4:36 PM, Jacopo Cappellato <

jacopo.cappell...@hotwaxsystems.com> wrote:
I was actually thinking to Birt as an example of this behavior: 
but in

the

future we may add other special purpose applications that need to

override
applications screens (in fact overriding screens and other 
artifacts to
specialize them is a best practice in OFBiz) and the problem 
will happen

again if we keep them all enabled.

Jacopo

On Thu, Nov 19, 2015 at 11:45 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Could we list, apart the well known Birt issue, special 
components which

are overriding main applications?

Then depending on cases we could be more surgical...

Jacques


Le 19/11/2015 09:46, Jacopo Cappellato a écrit :

I agree with Taher when he says that we should strive to move 
small

steps
in the direction of having a lean lightweight framework with 
pluggable

components.
But I think that Nicolas' proposal is actually one of these 
steps.

The fact that currently some of our specialized components are

overriding
the more generic behavior of other components (e.g. the ones 
under

"applications") is a problem that we have to fix asap.
Otherwise the default demo of OFBiz will only showcase the more
specialized
behaviors; for example, if tomorrow we will add a new special 
purpose
component for

Re: Building a Winning UX Strategy Using the Kano Model

[Ron Wheeler]

http://www.kanomodel.com/ has a short article with a graphic that shows 
the relationship between the various types of product features.


Ron
On 20/11/2015 4:32 AM, Jacques Le Roux wrote:

Interesting indeed

Jacques

Le 20/11/2015 09:47, Julien NICOLAS a écrit :

Hello Ron,

It's really interesting, thanks!

Julien.

Le 20/11/2015 07:41, Ron Wheeler a écrit :

This video is about the strategy surrounding the user experience.
https://www.youtube.com/watch?v=Hr1rN3jibIk

There are a lot of ideas about how to use the Kano Model to 
determine what features should be included in a product.
- There are features that are so basic that they do not show up in 
user requirements - Accounts must balance; Orders should not be lost.
  These are typically expensive to include and if they work, you get 
no user satisfaction but if they don't, you create a lot of user 
dissatisfaction.


- There are features that users consider key to the performance of 
the application and show up as "Features" in marketing docs and RFPs 
- good documentation, search, multi-tenancy, support for eCommerce 
gateways, etc.
  These have a linear line from "few features, unsatisfactory user 
experience" to "many features with great user experience"


- There are features that generate "the WOW reaction". They are not 
expected to be there but users/buyers are impressed when they are.
  If they are not included, this does not generate dissatisfaction 
but if they are there they generate user enthusiasm.


The trick is to know where each enhancement requested or suggested 
fits in the space.


As time goes on, the "WOW" features move into the performance class 
and eventually to the expected class.
For example, I can remember when touch screens were really exciting 
but now a tablet or phone that only supports a keypad could hardly 
be sold.


One of the more interesting parts of the discussion is about why you 
need a process for saying "No." to new features.
How do you keep a piece of software at exactly the right level of 
complexity?


Enjoy.

Ron









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Building a Winning UX Strategy Using the Kano Model

[Ron Wheeler]

This video is about the strategy surrounding the user experience.
https://www.youtube.com/watch?v=Hr1rN3jibIk

There are a lot of ideas about how to use the Kano Model to determine 
what features should be included in a product.
- There are features that are so basic that they do not show up in user 
requirements - Accounts must balance; Orders should not be lost.
  These are typically expensive to include and if they work, you get no 
user satisfaction but if they don't, you create a lot of user 
dissatisfaction.


- There are features that users consider key to the performance of the 
application and show up as "Features" in marketing docs and RFPs - good 
documentation, search, multi-tenancy, support for eCommerce gateways, etc.
  These have a linear line from "few features, unsatisfactory user 
experience" to "many features with great user experience"


- There are features that generate "the WOW reaction". They are not 
expected to be there but users/buyers are impressed when they are.
  If they are not included, this does not generate dissatisfaction but 
if they are there they generate user enthusiasm.


The trick is to know where each enhancement requested or suggested fits 
in the space.


As time goes on, the "WOW" features move into the performance class and 
eventually to the expected class.
For example, I can remember when touch screens were really exciting but 
now a tablet or phone that only supports a keypad could hardly be sold.


One of the more interesting parts of the discussion is about why you 
need a process for saying "No." to new features.
How do you keep a piece of software at exactly the right level of 
complexity?


Enjoy.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [FRAMEWORK] Notes from Skype Meeting - 23rd Oct 2015

[Ron Wheeler]

ronizations to 
do stuff on commit or rollback. While sometimes useful in application code it 
is very useful for other tools (in Moqui this includes data feeds generated 
based on entity data changes, the write-through per-transaction cache, etc).

- Messages and Notifications

It is helpful to have a central place to handle messages (error and otherwise) 
that get passed up through the various levels of the framework, and to 
determine if something deeper down generated an error without using exceptions 
(which don’t fit the service model for logic very well, especially not remote 
services). Notifications are handy for pushing data to users or other 
applications, eventually through something like web sockets or other interfaces.

Another note is the original list is more conceptual than something that should 
be used to organize an API… for various reasons structuring an API this way 
would result in some weird structures.

I’ll finish with the most important point, IMO, for any framework design: a 
convenient single interface for the entire framework. This makes lifecycle 
management and API use so much easier, plus provides a single variable space 
(context) for all tools that is consistently available. This interface in Moqui 
is the ExecutionContext (always available in screens, services, scripts, etc as 
simple “ec”):

http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html

To go along with that for management a primary factory is useful, for Moqui 
this is the ExecutionContextFactory:

http://www.moqui.org/javadoc/org/moqui/context/ExecutionContextFactory.html

If you want static initialization you can use the Java ServiceLoader, such as 
in:

https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/Moqui.java

And a META-INF/services file like:

https://github.com/moqui/moqui/blob/master/framework/src/main/resources/META-INF/services/org.moqui.context.ExecutionContextFactory

-David






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: A rant I could not hold (read: wanted to share)

[Ron Wheeler]

+1
As a newcomer, the docs were a big turn-off.

Sharan is doing a great job of organizing it.
I hope that we can do something with the Framework that makes a cleaner 
separation between the business application and the plumbing.


Ron

On 27/10/2015 4:12 AM, Jacques Le Roux wrote:

Hi All,

Don't take this too seriously, it's only a thought that crossed my 
mind while reading this snippet at https://db.apache.org/newproject.html


<products that rely [on] source code and JavaDocs alone.>>


And it's is too long for a Tweet :)

I know the OFBiz scope is very large, we are not focused on a topic 
like the DB project. So I believe it's harder to well organise our 
documentation, or rather, like the project, its scope is large (and 
sometimes confusing with not clear borders between topics)


But I think we also rely too much on examples in code. And 
documentation in XSDs is not enough (a contrario, see the excellent 
work by Adrian at 
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference) 
because this ways (code including properties files, JavaDocs, XSDs) we 
don't cover the business cases and other aspects. In other simpler 
words, it's not holistic!


I know, I do that myself everyday, and for a long time. I also believe 
the way I approach code in a new area in OFBiz (there are much) is 
often by analogy. To be frank in some case it's even kinda Cargo Cult 
(don't get me wrong I have nothing against real Cargo Cult ;))

https://en.wikipedia.org/wiki/Cargo_cult
https://www.google.com/search?q=Cargo+Cult=1=lnms=isch=X=0CAcQ_AUoAWoVChMIpOyj7ZbiyAIVgtQaCh1KygbV=2144=839=0.9 



The documentation in wiki has improved so far. But, as the DB project 
well stresses, if we could improve it more the OFBiz project would be 
taken more seriously and we would get more attention. I will try to 
get into this direction in the near future...


Thanks for your attention so far :)

Jacques




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: A rant I could not hold (read: wanted to share)

[Ron Wheeler]

On 27/10/2015 10:25 AM, Adrian Crum wrote:
Building out the documentation in the XSDs would be a huge step in the 
right direction.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/27/2015 1:12 AM, Jacques Le Roux wrote:

Hi All,

Don't take this too seriously, it's only a thought that crossed my mind
while reading this snippet at https://db.apache.org/newproject.html

<>

And it's is too long for a Tweet :)

I know the OFBiz scope is very large, we are not focused on a topic like
the DB project. So I believe it's harder to well organise our
documentation, or rather, like the project, its scope is large (and
sometimes confusing with not clear borders between topics)



Do  I hear a call for sub-projects with more direct ownership of 
/responsibility for topics? ;-)






But I think we also rely too much on examples in code. And documentation
in XSDs is not enough (a contrario, see the excellent work by Adrian at
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini+Language+-+minilang+-+simple-method+-+Reference) 


because this ways (code including properties files, JavaDocs, XSDs) we
don't cover the business cases and other aspects. In other simpler
words, it's not holistic!

I know, I do that myself everyday, and for a long time. I also believe
the way I approach code in a new area in OFBiz (there are much) is often
by analogy. To be frank in some case it's even kinda Cargo Cult (don't
get me wrong I have nothing against real Cargo Cult ;))
https://en.wikipedia.org/wiki/Cargo_cult
https://www.google.com/search?q=Cargo+Cult=1=lnms=isch=X=0CAcQ_AUoAWoVChMIpOyj7ZbiyAIVgtQaCh1KygbV=2144=839=0.9 




The documentation in wiki has improved so far. But, as the DB project
well stresses, if we could improve it more the OFBiz project would be
taken more seriously and we would get more attention. I will try to get
into this direction in the near future...

Thanks for your attention so far :)

Jacques





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Framework API design

[Ron Wheeler]

Adrian Crum added this note to the wiki.

"Please take some to watch this presentation by Joshua Bloch: How to 
Design a Good API & Why it Matters 
<http://www.infoq.com/presentations/effective-api-design>."


It is an hour long but is very engaging and chock full of ideas backed 
up by practical examples of good and sub-optimal design taken from the 
Java SDK and other projects.

Well worth your time if you are doing any software design.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

The problem with using a code repository is that it would open up the 
code repo to lots of people or prevent a lot of people from working on 
the project(s).


Ron

On 20/10/2015 12:54 AM, David E. Jones wrote:

It might work fine putting the proposed interfaces and XSDs in wiki pages, but 
seems really cumbersome compared to a code repository!

-David



On 17 Oct 2015, at 13:39, Ron Wheeler <rwhee...@artifact-software.com> wrote:

This seems like a very sound approach and something that can be started in the 
wiki.
That way no one will be tempted to start coding before we know what to code.


If the first things to be coded (even if the wiki is the repo) are interfaces 
and XML schemas, we should be able to divide up the implementation classes 
among a wide number of committers while still maintaining a sense of confidence 
that the result will be what was agreed upon.

It will also allow us to validate:
1) Is there a consensus about the design and function of a new framework
2) Is there enough of a community to actually build one.

Can we start with the pages that Adrian wrote way back then, as a basic outline 
of the components of a framework?
https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision


Ron


On 17/10/2015 2:07 PM, David E. Jones wrote:

This message has a lot of the right questions to ask about a new framework.

A big part of why the OFBiz framework suffers is because it was never planned 
in its entirety from the beginning, it is VERY much an emergent design as 
opposed to an intentional one.

The interest bits start appearing with intentional design, and for anyone 
serious about getting into a fresh framework rewrite I’d highly recommend doing 
the same thing I did with Moqui: define Java interfaces for the API and an XML 
schema (XSD files) for the intended XML files. The XML schema might be the same 
as the current one, though there is room for improvement in the current OFBiz 
XML files and the eventual framework would be much better if these are 
reconsidered as well.

You can see the Moqui interfaces here:

https://github.com/moqui/moqui/tree/master/framework/src/api/java/org/moqui

The central object at runtime, ie for most application code, is the 
implementation of the ExecutionContext interface. The whole API is structured 
around this:

https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/context/ExecutionContext.java

There is also a JavaDoc generated and available on moqui.org, might be easier 
to read for some:

http://www.moqui.org/javadoc/index.html
http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html

I include these links because they might be useful for ideas or even as a 
starting point for a next generation OFBiz framework API (take or leave each 
method/etc as you wish).

The nice thing about creating Java interfaces as opposed to a document is they 
are more clear and concise, and can be actually used in the framework 
implementation once interested community participants have reviewed it.

This doesn’t require nearly as much work as implementing the beast and is a 
great way to communicate concepts, so for anyone really serious about a 
framework rewrite in OFBiz I’d highly recommend this specific effort.

The other details like which tools (other open source projects and such) to use 
is less important. On the other hand if using something like Spring is a 
serious consideration it would change the API dramatically, and a lot of the 
design ideas as well (I’d recommend against this BTW, the Spring ecosystem is 
its own thing and VERY different conceptually from OFBiz).

-David



On 16 Oct 2015, at 08:47, Ron Wheeler <rwhee...@artifact-software.com> wrote:

Before we start to decide who can access code, we need to decide on a roadmap 
for the new framework.
How different will the API be from the current framework in each of the areas 
that the framework will offer services?

How modular will it be?
Foundation identifies
- Core with 3 main areas of functionality. Can they be separated into separate 
projects with clean interfaces? are there more projects such as authentication, 
persistence, logging and audit (see below) that are shared across the 
Foundation Core high level features.
- Script
- Imex
- Connect - seems to a number of projects here that could be tackled separately.
Is this it?

Will there be an application isolation layer that will support OFBiz's current 
interaction with the Framework. This should also be a separate project where 
OFBiz knowledge is really valuable.

What will go underneath the covers? Spring-Boot , Spring JPA, Hibernate, etc.

How many containers will be supported. Tomcat, Jetty, Glassfish, Spring-Boot.

How many persistence options will be supported? SQL, No-SQL

How many authentication services will be supported - internal, LDAP, Oauth, 
Google, LinkedIn, Facebook.

What administration functions will be offered? How?  JConsole, REST, 
browser/mobil

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

I fixed the linking of the parent to the child pages.

Ron
On 19/10/2015 11:39 AM, Adrian Crum wrote:

Sharan,

Please move the child pages also. The structure I had was:

Vision
  |
  |_ Implementation Overview
   |
   |___ Implementation Details A
   |
   |___ Implementation Details B
   |
   .
   .
   .


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/19/2015 8:24 AM, Sharan-F wrote:

Hi Everyone

I've moved Adrian's Framework Vision page into the wiki

https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision 

<https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision> 



and I've also created a page where people who are interested in 
helping can

'sign up' :-).

https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project 

<https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Sub+Project> 



Based on this we can see if we have enough momentum to start things 
moving.


Thanks
Sharan



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Why-A-Framework-Rewrite-Is-Necessary-tp4673385p4673586.html

Sent from the OFBiz - Dev mailing list archive at Nabble.com.






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Strange Feature List

[Ron Wheeler]

OK.
I will have a run at it.

Ron

On 17/10/2015 3:33 AM, Jacques Le Roux wrote:

If it could be fixed/amended it would be great :)

Jacques

Le 17/10/2015 09:26, Ron Wheeler a écrit :

OK.
Does it need to be fixed or just deleted?

I found the problems identified in my first post and can fix some of 
the easily if the page is still a useful part of the documentation.


Ron

On 16/10/2015 3:35 PM, Jacques Le Roux wrote:
This is a rewriting by Pierre (Smits) from an older effort based on 
https://cwiki.apache.org/confluence/display/OFBIZ/Main+New+Features


Jacques

Le 16/10/2015 17:49, Ron Wheeler a écrit :

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Features
This page is supposed to be a feature list but instead it reads 
like a release note; - fix this, added statusId to that, etc.
The order of features does not match the opening paragraph and does 
not seem to be in any order that makes sense to a person looking 
for an ERP.
The payment gateways are described in 2 places - once as core 
accounting features and once as part of "Special Purpose".


Should this be cleaned up or deleted?

Ron











--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Strange Feature List

[Ron Wheeler]

OK.
Does it need to be fixed or just deleted?

I found the problems identified in my first post and can fix some of the 
easily if the page is still a useful part of the documentation.


Ron

On 16/10/2015 3:35 PM, Jacques Le Roux wrote:
This is a rewriting by Pierre (Smits) from an older effort based on 
https://cwiki.apache.org/confluence/display/OFBIZ/Main+New+Features


Jacques

Le 16/10/2015 17:49, Ron Wheeler a écrit :

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Features
This page is supposed to be a feature list but instead it reads like 
a release note; - fix this, added statusId to that, etc.
The order of features does not match the opening paragraph and does 
not seem to be in any order that makes sense to a person looking for 
an ERP.
The payment gateways are described in 2 places - once as core 
accounting features and once as part of "Special Purpose".


Should this be cleaned up or deleted?

Ron






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

This seems like a very sound approach and something that can be started 
in the wiki.

That way no one will be tempted to start coding before we know what to code.


If the first things to be coded (even if the wiki is the repo) are 
interfaces and XML schemas, we should be able to divide up the 
implementation classes among a wide number of committers while still 
maintaining a sense of confidence that the result will be what was 
agreed upon.


It will also allow us to validate:
1) Is there a consensus about the design and function of a new framework
2) Is there enough of a community to actually build one.

Can we start with the pages that Adrian wrote way back then, as a basic 
outline of the components of a framework?

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision


Ron


On 17/10/2015 2:07 PM, David E. Jones wrote:

This message has a lot of the right questions to ask about a new framework.

A big part of why the OFBiz framework suffers is because it was never planned 
in its entirety from the beginning, it is VERY much an emergent design as 
opposed to an intentional one.

The interest bits start appearing with intentional design, and for anyone 
serious about getting into a fresh framework rewrite I’d highly recommend doing 
the same thing I did with Moqui: define Java interfaces for the API and an XML 
schema (XSD files) for the intended XML files. The XML schema might be the same 
as the current one, though there is room for improvement in the current OFBiz 
XML files and the eventual framework would be much better if these are 
reconsidered as well.

You can see the Moqui interfaces here:

https://github.com/moqui/moqui/tree/master/framework/src/api/java/org/moqui

The central object at runtime, ie for most application code, is the 
implementation of the ExecutionContext interface. The whole API is structured 
around this:

https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/context/ExecutionContext.java

There is also a JavaDoc generated and available on moqui.org, might be easier 
to read for some:

http://www.moqui.org/javadoc/index.html
http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html

I include these links because they might be useful for ideas or even as a 
starting point for a next generation OFBiz framework API (take or leave each 
method/etc as you wish).

The nice thing about creating Java interfaces as opposed to a document is they 
are more clear and concise, and can be actually used in the framework 
implementation once interested community participants have reviewed it.

This doesn’t require nearly as much work as implementing the beast and is a 
great way to communicate concepts, so for anyone really serious about a 
framework rewrite in OFBiz I’d highly recommend this specific effort.

The other details like which tools (other open source projects and such) to use 
is less important. On the other hand if using something like Spring is a 
serious consideration it would change the API dramatically, and a lot of the 
design ideas as well (I’d recommend against this BTW, the Spring ecosystem is 
its own thing and VERY different conceptually from OFBiz).

-David



On 16 Oct 2015, at 08:47, Ron Wheeler <rwhee...@artifact-software.com> wrote:

Before we start to decide who can access code, we need to decide on a roadmap 
for the new framework.
How different will the API be from the current framework in each of the areas 
that the framework will offer services?

How modular will it be?
Foundation identifies
- Core with 3 main areas of functionality. Can they be separated into separate 
projects with clean interfaces? are there more projects such as authentication, 
persistence, logging and audit (see below) that are shared across the 
Foundation Core high level features.
- Script
- Imex
- Connect - seems to a number of projects here that could be tackled separately.
Is this it?

Will there be an application isolation layer that will support OFBiz's current 
interaction with the Framework. This should also be a separate project where 
OFBiz knowledge is really valuable.

What will go underneath the covers? Spring-Boot , Spring JPA, Hibernate, etc.

How many containers will be supported. Tomcat, Jetty, Glassfish, Spring-Boot.

How many persistence options will be supported? SQL, No-SQL

How many authentication services will be supported - internal, LDAP, Oauth, 
Google, LinkedIn, Facebook.

What administration functions will be offered? How?  JConsole, REST, 
browser/mobile apps.

How delivered? Installer, Docker image, VM image,

What demo apps?

What test framework(s)? Test Applications.

What would be a reasonable set of functionality to be released in version 1.0? 
Minimum useful framework.

How many people would it take to do this in a reasonable timeframe?

Ron


On 16/10/2015 3:41 AM, Pierre Smits wrote:

On Fri, Oct 16, 2015 at 5:31 AM, David E. Jones <d...@me.com> wrote:


On 15 Oct 2015, at 0

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

ine will get
addressed (e.g. documentation, test definitions, marketing/promotions, etc)
in order to get this kite flying.

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

Is there any enthusiasm for incorporating Moqui as a separate third 
party dependency into the ERP?
What is involved? Does anyone have any sort of plan for using Moqui as a 
drop-in replacement for the current Framework?
A blog article would be a good start in adding some real flesh to this 
idea if it makes any sense.


If there is a desire for a new OFBiz framework, we should start by 
adding some details in the wiki.

I can not edit this or add comments.

Once we see how far we can get in a roadmap and functional overview, we 
can start to look at sub-projects.

It is too early now as far as I can tell.

Ron

On 15/10/2015 11:31 PM, David E. Jones wrote:



On 15 Oct 2015, at 07:58, Adrian Crum <adrian.c...@sandglass-software.com> 
wrote:

Keep in mind that much of David's code in OFBiz has been rewritten. So yes, we 
CAN do a better job than him.

I think there’s a name for this logical fallacy…


Also keep in mind that Moqui duplicates some of the problems I listed - so by 
using Moqui, we keep the same problems instead of fixing them.

Could you be more specific, other than the type conversion stuff you mentioned 
many years ago (which I fully disagree with)?

-David



On the other hand, it is David's responsibility to fix them, not ours.

If we created a sub-project, then we would have the opportunity to review 
committer permissions and perhaps restrict access to the new code.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/15/2015 6:34 AM, Al Byers wrote:

I was waiting for someone to bring this up. David Jones created Moqui with
the same end in mind that the rewrite is meant to accomplish. Do you think
that you will do a better job than him? Even if you could, would it be so
much better that it warrants the effort that it would take?

Is this a political thing? I don't know that David would give up control of
Moqui Core and I, for one, would not want him to. So many of OFBiz's
problems are the result of ineptitude on the part of committers who did not
know what they were doing (like me.) But I don't know that the Core will
change all that much going forward and there should be places in the Mantle
to contribute and, most certainly, in the Crust.

I know that there were some valid questions about licensing and project
management, but I would think that they could be worked out.

On Thu, Oct 15, 2015 at 4:46 AM, Hans Bakker <h.bak...@antwebsystems.com>
wrote:


Why not skip this step, using moqui which is already up and running and
then as Adrian states as a next step: applications could be pulled down and
adapted to it.

Hans



On 15/10/15 16:51, Jacques Le Roux wrote:


I'm in the same mood than Paul and Scott. So a sub-project could indeed
be a solution.

Jacques

Le 15/10/2015 03:11, Adrian Crum a écrit :


I agree that a sub-project would be nice to have. Once the new framework
is up and running, applications could be pulled down and adapted to it.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/14/2015 5:53 PM, Ron Wheeler wrote:


This seems to be very good advice.
A completely separate sub-project under OFBiz with its own mailing lists
would keep the people together yet all allow the new framework the
flexibility to move forward.

Ron
On 14/10/2015 8:27 PM, Scott Gray wrote:


My advice is as follows:
1. If people are interested, then get them together and start working
on it.
2. Find somewhere to do the work.  I don't think a branch is
appropriate
because it's completely new development rather than a refactoring.  I
don't
have any objections to it being done under the ASF OFBiz umbrella
(although
I don't really see the need either).
3. Set up a separate mailing list for discussion.  Generally I'd try
and
keep quiet about it in the early stages on the dev/user lists or other
marketing channels because it could potentially harm adoption of our
existing framework (think AngularJS 2.0).

There really isn't any need to get early stage sign-off from the PMC or
anyone else in the community.  You only need enough PMC approval to
get the
required infrastructure sorted, which I don't think would be an issue.
>From there, it's really up to the community to decide whether or not
the
thing will fly.

Regards
Scott


On 15 October 2015 at 08:21, Adrian Crum
<adrian.c...@sandglass-software.com


wrote:
I understand that Sharan brought up the framework rewrite subject at
ApacheCon, and some attendees felt that the framework is fine and no
action
needs to be taken.

In this message, I will try to give a detailed explanation of why a
framework rewrite is necessary. I don't plan to take any further
action on
this subject, because I've brought it up before without success, and
I'm
tired of discussing it. It is my hope that the light bulb will click
on in
someone's head and they will take action.

My Background
-

I became a member of the OFBiz community in 2004. I immediately
started
making contributions to the project by supplying pa

Strange Feature List

[Ron Wheeler]

https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Features
This page is supposed to be a feature list but instead it reads like a 
release note; - fix this, added statusId to that, etc.
The order of features does not match the opening paragraph and does not 
seem to be in any order that makes sense to a person looking for an ERP.
The payment gateways are described in 2 places - once as core accounting 
features and once as part of "Special Purpose".


Should this be cleaned up or deleted?

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

community decides to 
go ahead with a rewrite, then please feel free to use the Wiki pages 
as a guide.


Sandglass Foundation


Like David, I came to the conclusion that a framework rewrite would be 
easier outside the OFBiz community. So, I created my own library 
called Foundation:


http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf 



(PDF)

and I only mention it here to stress how wonderful it can be to start 
with a clean slate and design an API that is concise yet powerful. 
(Please do not discuss Foundation here, contact me privately if you 
want more information.)


Some examples of what can be done with a rewrite:

A single configuration file
Use ANSI/ISO SQL SELECT statement strings instead of constructing 
complicated Java structures

Simultaneous asynchronous queries
Relational integrity across multiple datasources
Multi-table SELECT across multiple datasources
Automatic and transparent row version control
Automatic and transparent multi-language datasource support
Abstract entities (similar to SQL user types)
Service engine throttling (protects against server over-utilization)
Simplified security (authorization) 
(https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
Pure interface-based API - so developers are free to modify 
framework behavior by using decorators

Thorough unit tests

Benefits of a rewrite:

Reduced resource requirements (lower hosting fees)
Reduce application development time - due to a simplified API
Easier framework code maintenance
Better reliability

Conclusion
--

Like I said at the start, this is all I will say about the subject. 
I'm done trying to convince everyone. I hope someone agrees with me 
and they are able to build support for the idea.





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

There are no details about the API on that page.
I was hoping that you might have some more details not yet added to the 
page.


Ron

On 14/10/2015 8:05 PM, Adrian Crum wrote:

On 10/14/2015 2:09 PM, Ron Wheeler wrote:

How much of the Foundation core either overlaps with Spring or could be
implemented using Spring?

How much of the design for an API has been thought out?


https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision 



Please take some time to follow the links I provided in my original 
message.




Are there other documents that give use cases and general instructions
for writing an application using the framework?
Is there any hypothetical code demonstrating how a developer could write
a trivial application with security, persistence, logging, etc. or is
the assumption that the current OFBiz framework API be preserved?

A sub-project under Apache OFBiz would be an alternative if the
community wanted to get behind a rewite.
This would allow people interested in framework concerns as opposed to
business applications to work together.


Ron

On 14/10/2015 3:21 PM, Adrian Crum wrote:

I understand that Sharan brought up the framework rewrite subject at
ApacheCon, and some attendees felt that the framework is fine and no
action needs to be taken.

In this message, I will try to give a detailed explanation of why a
framework rewrite is necessary. I don't plan to take any further
action on this subject, because I've brought it up before without
success, and I'm tired of discussing it. It is my hope that the light
bulb will click on in someone's head and they will take action.

My Background
-

I became a member of the OFBiz community in 2004. I immediately
started making contributions to the project by supplying patches to
the issue tracker. In 2007, I became a committer. Most of my initial
work was on the UI and some work in the applications (mainly Asset
Maintenance and Work Effort). I stayed away from touching the
framework code because it was deep, dark, and scary.

Eventually, I started to understand how the framework code works and I
made some minor modifications. As my understanding grew, I progressed
to rewriting large swaths of framework code - making it thread-safe,
fault tolerant, efficient, and easier to use.

I will list some of my contributions here, so everyone can have a
clear understanding of my experience with the framework code:

New Features

User Preferences

Visual Themes

Custom UI Label XML File Format

Temporal Expressions

Data Type Conversion Framework

Screen Widget Boundary Comments

Metrics

Integrations

UEL

iCalendar

JSR 223

WebDAV

LDAP

Refactorings/Improvements

FlexibleStringExpander

FlexibleMapExpander

FOP Integration

FreeMarkerWorker

Date-Time Handling

Mini-language

Job Scheduler

In addition, I have performed innumerable framework bug fixes.

So, the contents of this message come from years of experience mucking
about in the framework code.

Okay, let's get started...

Initial Problem Statement
-

In 2009, David Jones started a framework rewrite in a branch:

https://svn.apache.org/repos/asf/ofbiz/branches/executioncontext20090716 



At the time, there was some agreement that a rewrite was necessary,
but there was disagreement as to how the rewrite should be
incorporated into the project:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/200908.mbox/%3c455601.62605...@web63102.mail.re1.yahoo.com%3E 




There were concerns that a rewrite would break backward compatibility.
Work on the rewrite branch stopped. Eventually, Jacopo suggested the
community be more accepting of backward-incompatible changes:

https://mail-archives.apache.org/mod_mbox/ofbiz-dev/201004.mbox/%3cd24f129d-4f9f-444e-84af-aca46f499...@hotwaxmedia.com%3e 




Despite an effort to convince David to proceed with the framework
rewrite, he ended up doing it in a separate project:

http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201104.mbox/%3c07565c88-4023-4d24-93a3-a4906e86f...@me.com%3E 




This page describes differences between OFBiz and Moqui, and within it
you can extract information on the problems David was trying to solve:

http://sourceforge.net/p/moqui/discussion/1086127/thread/4c52f240/

There was an email he sent out on the OFBiz dev list where he listed
the problems he saw in the framework, but I can't find it. The rest of
this message will include the issues he mentioned (the ones I
remember). I was in agreement with him at the time, and I still agree
that a framework rewrite is necessary.

The Problems


Code is scattered everywhere - due to an initial effort to make the
framework modular. This causes serious problems. The mere fact that
components like entityext and securityext EXIST makes it clear that
there are problems

Re: Why A Framework Rewrite Is Necessary

[Ron Wheeler]

d start over from scratch. This time
around, there should be less push-back from people concerned about
backwards compatibility. A rewrite offers the advantage of reconsidering
everything - like API design, general problem solving, and new features.

I created a Wiki page for a framework design:


https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

but there hasn't been much interest in it. If the community decides to go
ahead with a rewrite, then please feel free to use the Wiki pages as a
guide.

Sandglass Foundation


Like David, I came to the conclusion that a framework rewrite would be
easier outside the OFBiz community. So, I created my own library called
Foundation:


http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf

(PDF)

and I only mention it here to stress how wonderful it can be to start with
a clean slate and design an API that is concise yet powerful. (Please do
not discuss Foundation here, contact me privately if you want more
information.)

Some examples of what can be done with a rewrite:

 A single configuration file
 Use ANSI/ISO SQL SELECT statement strings instead of constructing
complicated Java structures
 Simultaneous asynchronous queries
 Relational integrity across multiple datasources
 Multi-table SELECT across multiple datasources
 Automatic and transparent row version control
 Automatic and transparent multi-language datasource support
 Abstract entities (similar to SQL user types)
 Service engine throttling (protects against server over-utilization)
 Simplified security (authorization) (
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Security+Redesign)
 Pure interface-based API - so developers are free to modify framework
behavior by using decorators
 Thorough unit tests

Benefits of a rewrite:

 Reduced resource requirements (lower hosting fees)
 Reduce application development time - due to a simplified API
 Easier framework code maintenance
 Better reliability

Conclusion
--

Like I said at the start, this is all I will say about the subject. I'm
done trying to convince everyone. I hope someone agrees with me and they
are able to build support for the idea.

--
Adrian Crum
Sandglass Software
www.sandglass-software.com




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Java 8 and functional programming in trunk

[Ron Wheeler]

+1 on Tahar Alkhateeb's points.

I don't think that anyone is proposing to convert all existing code to 
use the latest Java 8 features.


I think that once you force people to run the Java 8 JVM by doing the 
compile with Java 8, you are pretty much done.


If someone adds a Stream function in their code and the code is 
validated to work correctly, that should be the end of the story.

We don't vote on other code changes.

Who is going to check new patches to ensure that they do not depend on 
Java 8 features or bugs fixed in Java 8?


What was the process when Java 7 features where allowed into the trunk? 
Was a 2 part vote required?


Ron

On 14/10/2015 6:17 AM, Taher Alkhateeb wrote:

Hi Jacques,

I am a bit confused? Why wait for a frozen branch for anything? I thought trunk 
is your development/unstable bleeding-edge part of the code. This is where you 
introduce changes without worrying about people's stable systems because they 
base their systems on release branches. In fact, branches exist only to 
stabilize trunk at certain points of time.

Furthermore, if we introduce Java 8 into trunk, what possible logical reason 
exists for _voting_ to use the new features of the language? Why did you 
upgrade in the first place if you do not intend to use the newer features?

Taher Alkhateeb

- Original Message -

From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
To: dev@ofbiz.apache.org
Sent: Wednesday, 14 October, 2015 12:23:31 PM
Subject: Re: Java 8 and functional programming in trunk

I tend to agree. Actually there are 2 points,
1) use Java 8 to compile
2) use new Java 8 features

We can already do 1, but we should maybe wait the next freezed branch to do 2. 
That should be discussed but does not prevent 1. Of course any commit
with 2 will be rejected as long as an agreement on 2 will not be reached

Jacques

Le 11/10/2015 19:09, Ron Wheeler a écrit :

I am not sure why backwards compatibility is an issue with moving to Java 8.

It works well,
it is the supported version of Java.
As far as I have heard, the Java 8 JVM runs code compiled with earlier versions 
of Java. (My own experience is uniformly positive).

I can see no reason to think that anyone who is developing or using OFBiz would 
need to compile or run with an older version of Java.

In this day of VM and Docker Containers, it is hard to imagine that someone 
would be stuck on an older JVM in a production environment and unable to
come up with a configuration that would allow them to run JVM 8 to support 
OFBiz.

IMHO, we should just move to requiring the supported version of Java as soon as 
possible.

Ron


On 11/10/2015 4:14 AM, Taher Alkhateeb wrote:

Hello Everyone,

We created and provided the patches for this issue since June and OFBiz is 
pretty much ready to move to JDK 8. I'm not sure if lazy consensus is
enough or whether a vote is warranted to move this issue forward?

Cheers,

Taher Alkhateeb

- Original Message -

From: "Pierre Smits" <pierre.sm...@gmail.com>
To: dev@ofbiz.apache.org
Sent: Thursday, 7 May, 2015 10:52:00 AM
Subject: Re: Java 8 and functional programming in trunk

I don't think that it is a question of using or not using J8. It is more
about when to move it into trunk, as from that moment on there will be
backward compatibility issues.
A helpful solution in this respect could be to designate a specific release
branch now (e.g. r15 or r16), create the version in JIRA and setup the dev
branch in svn. Doing it that way J8 related issues can get registered,
changes can get implemented and assessed (in the dev branch) without
breaking current stuff in trunk.

But it also ensures that we can create awareness prior to releasing stuff.

Best regards,



Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Thu, May 7, 2015 at 9:30 AM, Nicolas Malin <nicolas.ma...@nereide.fr>
wrote:


Ok Thanks Scott and Jacques.

So Who is against use java 8 and more on trunk ?

:)

Nicolas


Le 07/05/2015 08:46, Jacques Le Roux a écrit :


Yes (lazy) consensus over vote ;)

Jacques

Le 07/05/2015 05:02, Scott Gray a écrit :


I'm not sure if a vote is necessary, particularly if no one has any
objections.

Regards
Scott
On 7 May 2015 07:44, "Nicolas Malin" <nicolas.ma...@nereide.fr> wrote:

I'm favorable to use java 8.

I think it's will be pretty fin if you can support oracle jdk8 and
openjdk8 also.

I propose to organize a vote to validate or not this proposition

Nicolas

Le 03/05/2015 11:52, Jacques Le Roux a écrit :

Hi Taher,

Yes I think so. For now well known (I hope ;)) security reasons, if
people want to use Oracle JDK they need to use Java 8.
So implementing with new Java 8 features now in trunk sounds good to
me.
BTW this is only my opinion...

Note that our demos are still using OpenJDK 1.7 I'm not quite sure of
t

Re: Java 8 and functional programming in trunk

[Ron Wheeler]

Good point about the backporting.
This will have an effect on the enthusiasm for backporting fixes.

Comparing trunk and backported code will certainly make for some good 
examples about how to use Java 8 to write more concise and clearer code.


Ron

On 14/10/2015 8:29 AM, Jacques Le Roux wrote:
Yes I think I confused myself on this one (for my defense I got a 
*strong* cold recently and I'm just recovering :p)


Inline...

Le 14/10/2015 14:05, Ron Wheeler a écrit :

+1 on Tahar Alkhateeb's points.

I don't think that anyone is proposing to convert all existing code 
to use the latest Java 8 features.


I think that once you force people to run the Java 8 JVM by doing the 
compile with Java 8, you are pretty much done.


If someone adds a Stream function in their code and the code is 
validated to work correctly, that should be the end of the story.

We don't vote on other code changes.

Who is going to check new patches to ensure that they do not depend 
on Java 8 features or bugs fixed in Java 8?


As explained in my answer to Taher, we need to be sure we don't 
backport Java 8 features in released branches which are supposed to 
work with Java 7, that's all.




What was the process when Java 7 features where allowed into the 
trunk? Was a 2 part vote required?


Nope, mistake on my side

Jacques



Ron

On 14/10/2015 6:17 AM, Taher Alkhateeb wrote:

Hi Jacques,

I am a bit confused? Why wait for a frozen branch for anything? I 
thought trunk is your development/unstable bleeding-edge part of the 
code. This is where you introduce changes without worrying about 
people's stable systems because they base their systems on release 
branches. In fact, branches exist only to stabilize trunk at certain 
points of time.


Furthermore, if we introduce Java 8 into trunk, what possible 
logical reason exists for _voting_ to use the new features of the 
language? Why did you upgrade in the first place if you do not 
intend to use the newer features?


Taher Alkhateeb

- Original Message -

From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
To: dev@ofbiz.apache.org
Sent: Wednesday, 14 October, 2015 12:23:31 PM
Subject: Re: Java 8 and functional programming in trunk

I tend to agree. Actually there are 2 points,
1) use Java 8 to compile
2) use new Java 8 features

We can already do 1, but we should maybe wait the next freezed 
branch to do 2. That should be discussed but does not prevent 1. Of 
course any commit
with 2 will be rejected as long as an agreement on 2 will not be 
reached


Jacques

Le 11/10/2015 19:09, Ron Wheeler a écrit :
I am not sure why backwards compatibility is an issue with moving 
to Java 8.


It works well,
it is the supported version of Java.
As far as I have heard, the Java 8 JVM runs code compiled with 
earlier versions of Java. (My own experience is uniformly positive).


I can see no reason to think that anyone who is developing or using 
OFBiz would need to compile or run with an older version of Java.


In this day of VM and Docker Containers, it is hard to imagine that 
someone would be stuck on an older JVM in a production environment 
and unable to
come up with a configuration that would allow them to run JVM 8 to 
support OFBiz.


IMHO, we should just move to requiring the supported version of 
Java as soon as possible.


Ron


On 11/10/2015 4:14 AM, Taher Alkhateeb wrote:

Hello Everyone,

We created and provided the patches for this issue since June and 
OFBiz is pretty much ready to move to JDK 8. I'm not sure if lazy 
consensus is

enough or whether a vote is warranted to move this issue forward?

Cheers,

Taher Alkhateeb

- Original Message -

From: "Pierre Smits" <pierre.sm...@gmail.com>
To: dev@ofbiz.apache.org
Sent: Thursday, 7 May, 2015 10:52:00 AM
Subject: Re: Java 8 and functional programming in trunk

I don't think that it is a question of using or not using J8. It 
is more
about when to move it into trunk, as from that moment on there 
will be

backward compatibility issues.
A helpful solution in this respect could be to designate a 
specific release
branch now (e.g. r15 or r16), create the version in JIRA and setup 
the dev
branch in svn. Doing it that way J8 related issues can get 
registered,

changes can get implemented and assessed (in the dev branch) without
breaking current stuff in trunk.

But it also ensures that we can create awareness prior to 
releasing stuff.


Best regards,



Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Thu, May 7, 2015 at 9:30 AM, Nicolas Malin 
<nicolas.ma...@nereide.fr>

wrote:


Ok Thanks Scott and Jacques.

So Who is against use java 8 and more on trunk ?

:)

Nicolas


Le 07/05/2015 08:46, Jacques Le Roux a écrit :


Yes (lazy) consensus over vote ;)

Jacques

Le 07/05/2015 05:02, Scott Gray a écrit :

I'm not sure if a vote is ne

Re: Java 8 and functional programming in trunk

[Ron Wheeler]

I am not sure why backwards compatibility is an issue with moving to Java 8.

It works well,
it is the supported version of Java.
As far as I have heard, the Java 8 JVM runs code compiled with earlier 
versions of Java. (My own experience is uniformly positive).


I can see no reason to think that anyone who is developing or using 
OFBiz would need to compile or run with an older version of Java.


In this day of VM and Docker Containers, it is hard to imagine that 
someone would be stuck on an older JVM in a production environment and 
unable to come up with a configuration that would allow them to run JVM 
8 to support OFBiz.


IMHO, we should just move to requiring the supported version of Java as 
soon as possible.


Ron


On 11/10/2015 4:14 AM, Taher Alkhateeb wrote:

Hello Everyone,

We created and provided the patches for this issue since June and OFBiz is 
pretty much ready to move to JDK 8. I'm not sure if lazy consensus is enough or 
whether a vote is warranted to move this issue forward?

Cheers,

Taher Alkhateeb

- Original Message -

From: "Pierre Smits" <pierre.sm...@gmail.com>
To: dev@ofbiz.apache.org
Sent: Thursday, 7 May, 2015 10:52:00 AM
Subject: Re: Java 8 and functional programming in trunk

I don't think that it is a question of using or not using J8. It is more
about when to move it into trunk, as from that moment on there will be
backward compatibility issues.
A helpful solution in this respect could be to designate a specific release
branch now (e.g. r15 or r16), create the version in JIRA and setup the dev
branch in svn. Doing it that way J8 related issues can get registered,
changes can get implemented and assessed (in the dev branch) without
breaking current stuff in trunk.

But it also ensures that we can create awareness prior to releasing stuff.

Best regards,



Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Thu, May 7, 2015 at 9:30 AM, Nicolas Malin <nicolas.ma...@nereide.fr>
wrote:


Ok Thanks Scott and Jacques.

So Who is against use java 8 and more on trunk ?

:)

Nicolas


Le 07/05/2015 08:46, Jacques Le Roux a écrit :


Yes (lazy) consensus over vote ;)

Jacques

Le 07/05/2015 05:02, Scott Gray a écrit :


I'm not sure if a vote is necessary, particularly if no one has any
objections.

Regards
Scott
On 7 May 2015 07:44, "Nicolas Malin" <nicolas.ma...@nereide.fr> wrote:

I'm favorable to use java 8.

I think it's will be pretty fin if you can support oracle jdk8 and
openjdk8 also.

I propose to organize a vote to validate or not this proposition

Nicolas

Le 03/05/2015 11:52, Jacques Le Roux a écrit :

Hi Taher,

Yes I think so. For now well known (I hope ;)) security reasons, if
people want to use Oracle JDK they need to use Java 8.
So implementing with new Java 8 features now in trunk sounds good to
me.
BTW this is only my opinion...

Note that our demos are still using OpenJDK 1.7 I'm not quite sure of
the
policy

http://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-23642/version_id-138218/Oracle-Openjdk-1.7.0.html



Jacques


Le 03/05/2015 10:52, Taher Alkhateeb a écrit :

Hi everyone,

I would like to work on a few JIRAs and at the same refactor some
existing
code to utilize Lambdas and Streams utilizing Java 8 features.


Is it acceptable to develop with JDK 8 features into trunk?

Taher Alkhateeb








--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: DITA to Confluence Wiki

[Ron Wheeler]

This note from the DITA users forum may be very helpful if we move to DITA.

Ron

 Forwarded Message 

[Attachment(s) <#TopText> from kate.lopre...@harmonicinc.com 
[dita-users] included below]


All,

For those interested, here is a follow-up to testing for the DITA 
converter for Confluence:



INSTALLATION

Because I'm not a Confluence administrator on my company's instance of 
the wiki, I ended up installing Confluence on a web server (XAMPP) 
running locally on my computer. From there I could log in as an admin 
and install the addons conf2dita and ditamacro with no problem. Three 
commands were added to the Confluence Tools menu: Export to DITA XML, 
Import to DITA XML, and View DITA Map.



DITA FILE PREPARATION

When you Import to DITA XML you upload the DITA files as a single ZIP 
file. I used the DITA Packager Utility for Windows from Suite Solutions. 
It zips up all the files referenced in a ditamap 
(http://suite-sol.com/Downloads/dita-packager-utility/)



FILE IMPORT

I first imported the DITA sample files that are available from the 
conf2dita wiki page. This import was successful; topics came across as 
individual pages in an existing space. I was also able to import my own 
DITA files/as long as they did not have any nested maps/.
The imported DITA files are marked up with icons and change bars 
(vertical lines in left margin) (see attached image).



FILE EXPORT
My exported files were valid DITA but they did not have the same 
filenames they used during the import, at least not consistently.



That's all I have so far. If anyone can offer more information about 
this addon, I'd appreciate it.


Thanks,
Kate



__._,_.___

Attachment(s) from kate.lopre...@harmonicinc.com [dita-users] | View 
attachments on the web 



1 of 1 Photo(s)

dita2confluence.png 

dita2confluence.png 



Posted by: kate.lopre...@harmonicinc.com



Visit Your Group 
 



 * New Members
   

   9

Yahoo! Groups 
 

• Privacy  
• Unsubscribe 
 • 
Terms of Use 


__,_._,___

Webinar: This new assessment can improve your application

[Ron Wheeler]

This might provide some interesting ideas for visualization and reporting.

I suspect that it will demonstrate the ideas with Jaspersoft but the 
concepts should be applicable to other technologies.



Ron

 Forwarded Message 

Jaspersoft 


Dear Ron

Chances are your application provides reports or visualizations for end 
users. But, are they good enough? And if you want them to be better, 
what are your choices? This 10-min assessment can help you prepare 
whether to build or buy software that can improve how data is visualized 
and interacted with in your application.


The assessment was developed by Wayne Eckerson (expert BI analyst) using 
responses from over 2,000 software industry professionals. Each 
completed assessment provides a custom set of recommendations that can 
be used to enhance the value of your application and its data. 	






Button2.jpg 




TIBCO Jaspersoft | 350 Rhode Island Street, Suite 250 |
San Francisco, CA 94103
Copyright © 2000-2015 TIBCO Software Inc. All rights reserved
Legal Notices  | 
Policies 




Facebook  		Linkedin 
 		Twitter 
 		YouTube 






This email was sent to rwhee...@artifact-software.com. If you no longer 
wish to receive these emails you may unsubscribe 
 at any time.

[jira] [Commented] (OFBIZ-6644) Webhelp umbrella task

[Ron Wheeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900581#comment-14900581
 ] 

Ron Wheeler commented on OFBIZ-6644:


In response to the question "Can anyone please provide suggestions on how to 
implement the
automatic generation of documents from GIT?" this response was created in the 
DITA users forum with links to 2 articles that might be helpful for us.

--

I’ve given a few conference presentations on Automating DITA Builds
over the past few years. You may find this information useful as you
investigate automation options for your project.

The slides from my talk at DITA North America in Seattle last year are
available here:
<http://infotexture.net/2014/04/automating-dita-builds-seattle/>.

The presentation was expanded to an article for the CIDM Best Practices
Newsletter:
<http://infotexture.net/2014/09/best-practices-article-automating-dita-builds/>.

Both outline various automation approaches, including Git hooks and
continuous integration servers like Jenkins (as Radu suggested). Code
samples are included that you can use to trigger builds when you commit
changes to Git.

Hope that helps,

Roger

P.S.

The DITA For Small Teams project <http://www.dita-for-small-teams.org/>
is also putting together a series of sample projects and resources that
can be used to automate the build process. There has been some
discussion lately about preparing Docker containers that would provide a
pre-configured DITA-OT and Jenkins, but I’m not sure how far that idea
has come.


> Webhelp umbrella task
> -
>
> Key: OFBIZ-6644
> URL: https://issues.apache.org/jira/browse/OFBIZ-6644
> Project: OFBiz
>  Issue Type: Task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>
> This is only a placeholder to group the issues related with webhelp



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-6015) Move Online Help Documentation from Webhelp into Trunk

[Ron Wheeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14900577#comment-14900577
 ] 

Ron Wheeler commented on OFBIZ-6015:


in response to the question  "Can anyone please provide suggestions on how to 
implement the
automatic generation of documents from GIT?" this response was created in  the 
DITA users forum with links to 2 articles that might be helpful for us.

--

I’ve given a few conference presentations on Automating DITA Builds
over the past few years. You may find this information useful as you
investigate automation options for your project.

The slides from my talk at DITA North America in Seattle last year are
available here:
<http://infotexture.net/2014/04/automating-dita-builds-seattle/>.

The presentation was expanded to an article for the CIDM Best Practices
Newsletter:
<http://infotexture.net/2014/09/best-practices-article-automating-dita-builds/>.

Both outline various automation approaches, including Git hooks and
continuous integration servers like Jenkins (as Radu suggested). Code
samples are included that you can use to trigger builds when you commit
changes to Git.

Hope that helps,

Roger


P.S.

The DITA For Small Teams project <http://www.dita-for-small-teams.org/>
is also putting together a series of sample projects and resources that
can be used to automate the build process. There has been some
discussion lately about preparing Docker containers that would provide a
pre-configured DITA-OT and Jenkins, but I’m not sure how far that idea
has come. 

> Move Online Help Documentation from Webhelp into Trunk
> --
>
> Key: OFBIZ-6015
> URL: https://issues.apache.org/jira/browse/OFBIZ-6015
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL APPLICATIONS
>Reporter: Sharan Foga
>Assignee: Sharan Foga
>Priority: Minor
> Attachments: Webhelp Analysis.ods
>
>
> This Jira has been created to manage the migration of all the documentation 
> from the Webhelp branch into the current help system so that it will work 
> with what we already have (essentially so that we dont lose it!).  The 
> original issue for the Webhelp is 
> https://issues.apache.org/jira/browse/OFBIZ-4941
> As well as HR, there is also online documentation for Accounting, 
> Manufacturing (English, German and Dutch), Project Manager and Catalog - 
> though not as complete, so I will be consolidating and moving those too. The 
> files use the docbook format and are compatible with what we have although he 
> implemented everything into one file (i.e book) per module. I now think this 
> is the better way to go.
> Update as at July 2015
> ==
> The original code from the Webhelp branch was updated and converted to an 
> OFBiz addon. 
> The addon was created from the Webhelp branch but is setup as an addon.
> To see a what the webhelp will look like and function like. 
> Go to https://demo.ofbizextra.org/accounting/control/main
> Login as admin/ofbiz
> Select HR and then click the help button (The docbook webhelp should be 
> displayed)
> As well as using docbook and webhelp for displaying it. Some additonal 
> funcitonality has been added. These are as follows:
> 1) There are some ant targets created (e.g. ant webhelp, clean-webhelp)
> 2) There is a flag setup to indicate whether a module has webhelp or uses 
> OFBiz standard help (i.e. what we are using now). 
> To test it on the ofbizextra demo 
> Select Facilities and then click the help button (The normal OFBiz help menu 
> is displayed because no webhelp exists for this module)
> I think this could be good thing as we convert the existing documentation 
> from the current online help format to the webhelp because it wont break 
> anything and leaves the option open for people who are using the existing 
> help system.
> 3) There is also some functionality related to language that looks at the 
> language of the user to see if the webhelp exists in that language. If it 
> doesn't there is a message saying so but that documentation exists in another 
> language 
> The addon uses the patch Files. (.patch) I think this is because the addon 
> tries to maintain compatibility with different OFBiz versions but I think 
> it's still just xml or java code.
> I have done an initial (non technical) analysis of the files and attached 
> that too



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Automating generation of PDF and Webhelp from GIT

[Ron Wheeler]

An interesting reference for anyone who is looking at the issue of 
generating docs and help automatically

I suppose that it could be adapted to SVN.

This might encourage developers to keep the docs in synch with the code:
- same repo and developent tools
- automatic update of documentation when code changed.

Ron

 Forwarded Message 

On Thursday, 2015-09-17, at 12:58 CEST, sinha.son...@yahoo.com
[dita-users] wrote:

Can anyone please provide suggestions on how to implement the
automatic generation of documents from GIT?



Hi Sonika,

I’ve given a few conference presentations on Automating DITA Builds
over the past few years. You may find this information useful as you
investigate automation options for your project.

The slides from my talk at DITA North America in Seattle last year are
available here:
.

The presentation was expanded to an article for the CIDM Best Practices
Newsletter:
.

Both outline various automation approaches, including Git hooks and
continuous integration servers like Jenkins (as Radu suggested). Code
samples are included that you can use to trigger builds when you commit
changes to Git.

Hope that helps,

Roger


P.S.

The DITA For Small Teams project 
is also putting together a series of sample projects and resources that
can be used to automate the build process. There has been some
discussion lately about preparing Docker containers that would provide a
pre-configured DITA-OT and Jenkins, but I’m not sure how far that idea
has come.




Posted by: "Roger Sheen" 





Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/dita-users/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/dita-users/join
(Yahoo! ID required)

<*> To change settings via email:
dita-users-dig...@yahoogroups.com
dita-users-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
dita-users-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

Drop framework as a separate product

[Ron Wheeler]

Since we seem to have decided not to adopt Moqui, we are left with the 
problems of what to do about the current framework.


It appears that in its current state it is not usable as a separate 
product at least until the dependency issues are resolved and the 
definition of the Party Component is refined to cover the bits that have 
to move to the Framework to make the Framework usable (roles, security, 
authentication, authorization, etc.).


The immediate consequence is on the web-site where removing the 
discussion of the framework as a separate product will likely improve 
the focus and usability of the remaining information.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: OFBiz going mobile

[Ron Wheeler]

I gather that this was all done with the existing framework.

Do we have to put the framework issue to bed before starting to work on 
mobile or is the REST interface(API) sufficiently stable or framework 
independent to move forward with a mobile strategy while still wondering 
about the future of the framework?


Ron

On 31/07/2015 8:06 AM, Divesh Dutta wrote:

We have delivered mobile applications which are in production with the help
of Ionic framework (http://ionicframework.com/ ) on top of OFBiz .
Experience so far is good and ionic community is really active , growing
and helping community.

As Ean mentioned,  *you no longer render pages on the server and send them
to the client. **To behave like an actual app you need to approach it as
a program written in Javascript that renders HTML interfaces locally and
communicates with the server using a combination of JSON-RPC and REST.* 
This is really important point here when you are building mobile apps.

Jacopo also have done  improvements in OFBiz, with the help of them  you
can call OFBiz out of the box services and events as APIs . Services and
events are able to accept Json and return Json in OFBiz which will help you
to build mobile applications on top of OFBiz.

Thanks
--
Divesh Dutta.

On Wed, Jul 29, 2015 at 1:22 AM, Ean Schuessler e...@brainfood.com wrote:


The trouble with AngularJS is that they have a terrible case of NIH and are
re-inventing all the existing popular patterns like IOC, dependency
management and observer style data change events. In the 1.0 version they
were dismissive of problems like dependency management and let rediscover
the pains of not being able to fractionally load their infrastructure even
though it has been a solved problem for tools like RequireJS for a long
time. Now the roadmap for AngularJS 2.0 is so different from 1.0 that it
might as well be regarded as a different product and there is also real
cloudiness around the relationship between AngularJS and Polymer. Google is
developing both so the it's made by Google argument that usually puts
wind in Angular's sails isn't applicable.

On Tue, Jul 28, 2015 at 10:11 AM, Ron Wheeler 
rwhee...@artifact-software.com wrote:


Good analysis.

I wonder if Ionic is a good choice for a portable mobile framework.
http://ionicframework.com/

One does not want to get tied up in low level support for all the flavors
of mobile devices.

It is open source and supports AngularJS which seems to be a good model
for building Javascript applications,


Ron


On 28/07/2015 10:25 AM, Ean Schuessler wrote:


The real difficulty is that if you want a genuinely mobile app and not
just
mobile web then the approach has to completely switch. With a Cordova
app
you no longer render pages on the server and send them to the client. To
behave like an actual app you need to approach it as a program written
in
Javascript that renders HTML interfaces locally and communicates with

the

server using a combination of JSON-RPC and REST. This would represent an
enormous refactoring of the entire interface but it would open whole new
horizons from a UI perspective. David has made some real improvements to
handle REST in Moqui's version of the control servlet that we would also
need to bring in (ie. you can bind services to a combination of URL and
HTTP method).

On Wed, Jul 8, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com
wrote:

  Hi all,

There are a lot of mobile specific development frameworks out there.
There
are even a few projects under the ASF umbrella that cater to that need.

What would you consider the best solution to pair OFBiz with? Of are

the

capabilities it delivers sufficient?

Please share your thoughts.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com

skype: ronaldmwheeler
phone: 866-970-2435, ext 102




--
Ean Schuessler, Brainfood Co-Founder
e...@brainfood.com
214-720-0700




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Framework status

[Ron Wheeler]

There was a lot of discussion a few months ago about replacing the 
framework.

That seems to have died down.

At the same time, we are talking about the documentation and in the 
documentation plan, the framework is mentioned as a separately 
marketable product.


To me, it is clear that one should not be promoting a framework that 
will be replaced.


If the framework is a separate product that can be delivered separately, 
it needs to be separated from the ERP and have a life of its own with 
clear documentation and a distribution that does not include a whole lot 
of seed data or bits and pieces that are not required.

The dependencies that are screwed up need to be fixed.

Now is the time to make a decision about the framework.
1- Going to replace it - remove discussion about having a framework 
product from all documentation and web sites
2 - Going to muddle along with existing dependency structure and merged 
distribution - remove from docs until ready to turn it into a product.
3 - Going to commit to framework as a product - fix code and seed data 
to have a distribution for the framework, fix docs to clearly describe 
the framework and its use. I would prefer to see the framework as a 
separate sub-project with a technical team of people with expertise and 
interest in persistence, caching, performance, etc. supporting it and 
marketing it to other developers rather than keeping it mixed in with 
a product that is sold based on support for business process. (No 
surprise here).



There is no right or wrong answer but the current approach seems a bit 
muddled and negatively affects the project's ability to project a clear 
vision.


It would be nice if this decision was made soon so that we can get the 
documentation cleaned up.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: OFBiz going mobile

[Ron Wheeler]

Good analysis.

I wonder if Ionic is a good choice for a portable mobile framework. 
http://ionicframework.com/


One does not want to get tied up in low level support for all the 
flavors of mobile devices.


It is open source and supports AngularJS which seems to be a good model 
for building Javascript applications,



Ron

On 28/07/2015 10:25 AM, Ean Schuessler wrote:

The real difficulty is that if you want a genuinely mobile app and not just
mobile web then the approach has to completely switch. With a Cordova app
you no longer render pages on the server and send them to the client. To
behave like an actual app you need to approach it as a program written in
Javascript that renders HTML interfaces locally and communicates with the
server using a combination of JSON-RPC and REST. This would represent an
enormous refactoring of the entire interface but it would open whole new
horizons from a UI perspective. David has made some real improvements to
handle REST in Moqui's version of the control servlet that we would also
need to bring in (ie. you can bind services to a combination of URL and
HTTP method).

On Wed, Jul 8, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com
wrote:


Hi all,

There are a lot of mobile specific development frameworks out there. There
are even a few projects under the ASF umbrella that cater to that need.

What would you consider the best solution to pair OFBiz with? Of are the
capabilities it delivers sufficient?

Please share your thoughts.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Fwd: Re: OFBiz going mobile

[Ron Wheeler]

http://www.manning.com/wilken/IonicinA_MEAP_ch01.pdf is the introductory 
chapter for a manual on building mobile applications using a modern stack.

Short read for someone who wants to see a possible technology stack.

Ron

 Forwarded Message 

Good analysis.

I wonder if Ionic is a good choice for a portable mobile framework.
http://ionicframework.com/

One does not want to get tied up in low level support for all the
flavors of mobile devices.

It is open source and supports AngularJS which seems to be a good model
for building Javascript applications,


Ron

On 28/07/2015 10:25 AM, Ean Schuessler wrote:

The real difficulty is that if you want a genuinely mobile app and not just
mobile web then the approach has to completely switch. With a Cordova app
you no longer render pages on the server and send them to the client. To
behave like an actual app you need to approach it as a program written in
Javascript that renders HTML interfaces locally and communicates with the
server using a combination of JSON-RPC and REST. This would represent an
enormous refactoring of the entire interface but it would open whole new
horizons from a UI perspective. David has made some real improvements to
handle REST in Moqui's version of the control servlet that we would also
need to bring in (ie. you can bind services to a combination of URL and
HTTP method).

On Wed, Jul 8, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com
wrote:


Hi all,

There are a lot of mobile specific development frameworks out there. There
are even a few projects under the ASF umbrella that cater to that need.

What would you consider the best solution to pair OFBiz with? Of are the
capabilities it delivers sufficient?

Please share your thoughts.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: OFBiz and nabble

[Ron Wheeler]

+1
On 10/07/2015 6:44 AM, Jacques Le Roux wrote:
There is already an explanation in the more options link 
http://ofbiz.135035.n4.nabble.com/mailing_list/MailingListOptions.jtp?forum=135036 
but I agree a small tagline would help users to better understand how 
things works
Please provide the tagline you envision and we will put it there if we 
all agree (ie nobody disagree, lazy consensus)


Thanks

Jacques

Le 10/07/2015 11:50, Pierre Smits a écrit :

Hi all,

OFBiz ml messages are made available through Nabble, but there are still
contributors that use that platform to start new mail threads and/or 
reply
to postings. Not all messages posted directly in Nabble don't get 
through

to the mailing lists of the project (at least that is my experience).

Could we have the tagline on this
http://ofbiz.135035.n4.nabble.com/OFBiz-User-f135036.html to reflect 
that

we urge people to subscribe to the mailing lists of the project? And
similar for each subordinate ml archive?

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: [jira] [Commented] (OFBIZ-6504) how to Create PDF with password Protected in Ofbiz

[Ron Wheeler]

This looks like a mailing list discussion not a JIRA issue.

Ron

On 10/07/2015 9:26 AM, Shi Jinghai (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622274#comment-14622274
 ]

Shi Jinghai commented on OFBIZ-6504:


Sachin,

In OFBiz, we use FOP to generate PDF, that's the way you mentioned above, by 
FTL. AFAIK, FOP can use password to protect PDF, so it's unnecessary to 
introduce itext.

I'll try to add a example to support this function.


how to Create PDF with password Protected in Ofbiz
--

 Key: OFBIZ-6504
 URL: https://issues.apache.org/jira/browse/OFBIZ-6504
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
 Environment: linux
Reporter: Sachin Manjule
Assignee: Shi Jinghai

We can create PDF using FTL that is OK, but how to generate PDF with Encryption 
password protected?
itext is best option for this. but can we emmber in ftl or other places?
pleas Help us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: OFBiz going mobile

[Ron Wheeler]

An interesting combination for developing mobile portable apps
http://www.academia.edu/9722319/Building_Mobile_Apps_with_Cordova_AngularJS_and_Ionic

Ron


On 08/07/2015 12:47 PM, Taher Alkhateeb wrote:

Ahhh .. for a thin solution i think it already exists with jquery mobile +
bootstrap
On Jul 8, 2015 7:44 PM, Erik Schuessler e...@brainfood.com wrote:


I would like to work on a clean mobile interface for ofbiz. I worked on the
tomahawk theme a couple years ago. I would also like to figure out a thin
back end as well.

Thanks
Erik


On Wed, Jul 8, 2015 at 11:16 AM, Taher Alkhateeb 
slidingfilame...@gmail.com

wrote:
My personal preference would be apache cordova

Taher Alkhateeb
On Jul 8, 2015 7:14 PM, Pierre Smits pierre.sm...@gmail.com wrote:


Hi all,

There are a lot of mobile specific development frameworks out there.

There

are even a few projects under the ASF umbrella that cater to that need.

What would you consider the best solution to pair OFBiz with? Of are

the

capabilities it delivers sufficient?

Please share your thoughts.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com




--
Erik Schuessler
Vice President / Partner
www.Brainfood.com
214.720.0700 e323




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Coding standards

[Ron Wheeler]

https://github.com/adaptlearning/documentation/blob/master/01_cross_workstream/style_guide.md
is a guide for coding of Adapt - Open Source course delivery tool .

I am not sure that I agree with all of the rules.
Some are much better than the ones that I would choose but perhaps I am 
just too lazy to do the extra work to make my code easier to read.


They seem to think that computers have more time to parse code than 
people do to ponder obscurity and seem to feel that the addition of 
extra lines of code to make the code clearer is worth the extra 1/1000 
of a nanosecond that it costs.
Use descriptive conditions is an example of a frivolous waste of 
valuable computer time just to save people having to think.
Meaningful aliases is another example of adding a line of code just to 
make the code easier for humans.


If you are not offended by the waste of computer resources at compile 
time, you might consider adapting some of these rules to OFBiz java.


I am not sure that they their Don't use setters instructions will help 
the DI  or IoC crowd but they are JavaScript devotees who apparently do 
not follow the Spring model.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Possible Documentation and help solutions - DITA

[Ron Wheeler]

On 14/06/2015 7:08 PM, Paul Foxworthy wrote:

Hi all,


Ron Wheeler wrote

I expect that everyone has an IDE that can edit and validate XML. All
the other tools required are free.

...

OFBiz is pretty XML intensive so I would be surprised if OFBiz
developers did not use an IDE that can validate XML.

Do we only want developers to help documenting OFBIz? Expecting *any* IDE
and XML is already a barrier to a business expert who knows how to use OFBiz
but doesn't understand XML.


The nice thing about DITA is that you can use whatever DITA authoring 
tool that you want (with a few exceptions) to produce DITA without 
impacting others ability to use their tool to edit the files that you 
altered.


The same is true about AsciiDoc but the other issues that I have 
mentioned previous make me a bit hesitant about AsciiDOC.


DocBook and DITA are very closely related and share many of the same 
benefits and issues.

DITA is a newer standard and is replacing DocBook in most organizations.




Ron Wheeler wrote

Yes but we do have multiple destinations to support - multiple
languages, multiple customizations, multiple brandings.
Topics are likely shared between the same on-line help topic - concepts
shared with different task descriptions.
Eliminate duplication of background material and ensure that there is
only one version of each concept description and that the up to date
description appears in each help screen.

Sharing of topics and multiple destinations are not unique to DITA.

Cheers

Paul Foxworthy



-
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Possible-Documentation-and-help-solutions-DITA-tp4669377p4670019.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

[Ron Wheeler]

On 14/06/2015 2:16 AM, Jacques Le Roux wrote:

Le 13/06/2015 14:12, Ron Wheeler a écrit :
a) I am not sure why applications/datamodel/entitidef/ could not be 
entitydef / since it is shorter and unambiguous and spells entity 
correctly.


Applications was suggested because there are underneath mechanisms to 
handle the specialised folders framework, applications, specialpurpose 
and hot-deploy (which is a confusing name, eg extensions would have 
been better)
Datamodel is a real unambiguous name, while entitydef is less (HTML 
entities? etc.: https://en.wikipedia.org/wiki/Entity), this is a moot 
point.

I meant locally unambiguous within the OFBiz source structure.


b) I thought that hot-deploy was for local customizations. 
entitydef/... are user contributed libraries that are part of the 
standard OFBiz project to support industry-specific or 
locale-specific requirements.


Jacopo's suggestion is straightforward. It's the 1st move we are 
currently discussing to agree on.  Your propositon is interesting but 
to avoid confusion should be discussed later, in another thread.
I am trying to avoid a short term solution that makes a long-term 
solution more difficult for no real reason. I am not sure how many 
specialized entity definitions are stting on shelves today that could be 
shared (either for free or as commercial offerings).


c) I am suggesting a structure that makes it easy for someone 
customizing their implementation. Take all the xml files under 
entitydef ( or entitydef/default or entity/basic) and overwrite them 
with the set of XML files suitable for the particular locale that you 
want such as entitydef/eCommerce/NAFTA to get the definitions that 
match an eCommerce site in North America US and Canada terminology 
and the extensions or modifications required to support an 
eCommerce-only OFBiz aimed at a North American clientele.
If the system integrator does further customization and wants to put 
their branding or  customer-specific overrides in hot-deploy at 
run-time to keep them separate from the XML files that come from 
OFBiz, that sounds like a good practice but is different from the 


How to realise you idea needs to be discussed (again separately). A 
new mechanism might need to be created. In OFBiz a last read entity 
definition overrides the previous . How to separate/aggregate is not 
obvious to me in your proposition. Did you think about optional entity 
extensions (defined using the extend-entity mechanism) which would not 
be activated OOTB but could be loaded by users when needed (Oops, you 
see I'm  already discussing your proposition)?
I was suggesting a scheme where the file names are identical but the 
files come from different paths so the run-time situation would have no 
duplication of file names but the files might come from different 
sources (accounting-entitymodel.xml from 
entitydef/general/accounting-entitymodel.xml being overwritten by 
entitydef/general/UK/accounting-entitymodel.xml in the case where the 
installation required the UK version of accounting-entitymodel.xml
This implies that all of the definitions in 
entitydef/general/UK/accounting-entitymodel.xml are also in 
entitydef/general/accounting-entitymodel.xml.


Ron


Jacques


shared library structure we are discussing.

Does that clarify my points?

Ron



On 12/06/2015 9:51 AM, Nicolas Malin wrote:
Ron I didn't understand why you want adding specialization directory 
directly on main component (like entitydef/general/UK/).


For me this information need to be set on the dedicate component in 
hot-deploy.


Nicolas

Le 12/06/2015 13:17, Ron Wheeler a écrit :
It would be nice to get the philosophy of the structure agreed at 
the beginning even if there is only one variant of 
accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files 
and encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working 
set of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking 
something that others are using.


An alternative scheme that might be easier to use would be to 
structure the files as

entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds 
any value

entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default 
entity definitions are in one folder and general/UK would all be in 
another.
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required 
t create the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels

Re: Move Application Entity Definitions to A Separate Component

[Ron Wheeler]

a) I am not sure why applications/datamodel/entitidef/ could not be 
entitydef/ since it is shorter and unambiguous and spells entity correctly.
b) I thought that hot-deploy was for local customizations. 
entitydef/... are user contributed libraries that are part of the 
standard OFBiz project to support industry-specific or locale-specific 
requirements.
c) I am suggesting a structure that makes it easy for someone 
customizing their implementation. Take all the xml files under entitydef 
( or entitydef/default or entity/basic) and overwrite them with the set 
of XML files suitable for the particular locale that you want such as 
entitydef/eCommerce/NAFTA to get the definitions that match an eCommerce 
site in North America US and Canada terminology and the extensions or 
modifications required to support an eCommerce-only OFBiz aimed at a 
North American clientele.
If the system integrator does further customization and wants to put 
their branding or  customer-specific overrides in hot-deploy at run-time 
to keep them separate from the XML files that come from OFBiz, that 
sounds like a good practice but is different from the shared library 
structure we are discussing.


Does that clarify my points?

Ron



On 12/06/2015 9:51 AM, Nicolas Malin wrote:
Ron I didn't understand why you want adding specialization directory 
directly on main component (like entitydef/general/UK/).


For me this information need to be set on the dedicate component in 
hot-deploy.


Nicolas

Le 12/06/2015 13:17, Ron Wheeler a écrit :
It would be nice to get the philosophy of the structure agreed at the 
beginning even if there is only one variant of 
accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files and 
encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working 
set of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking something 
that others are using.


An alternative scheme that might be easier to use would be to 
structure the files as

entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds 
any value

entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default entity 
definitions are in one folder and general/UK would all be in another.
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required t 
create the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels to the structure so that 
specializations are easy to add without creating conflicts or 
constant flux as people alter the accounting-entitymodel.xml to 
suit their needs and submit it as the right version.


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml 


applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or 
region to get the vocabulary or regulatory compliance 
particularities separated


applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml 

applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml 


applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml 

applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml 



Clearly we would start out with only the demo set but I think that 
we could quickly get some of the other alternatives in place as 
people contribute versions that they want to be part of the basic set.


Would it make sense to break accounting-entitymodel.xml into 
separate files for mandatory and optional entities to make it clear 
the entities that can be modified or dropped without affecting OOB 
functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps

Re: Move Application Entity Definitions to A Separate Component

[Ron Wheeler]

I am not sure that restructuring the folder and separating the 
definitions mean that we have to consolidate all accounting entities 
into one file but separating code from data is the core of this idea.


Ron


On 12/06/2015 2:45 AM, Pierre Smits wrote:

I don't agree that moving in this direction will convince our potential
adopters to chose OFBiz. Having all entities in one component doestn't give
them more choice. Neither does having all eecas in one component.

Today it is already possible to have the entity definitions split up into
multiple files to create more clarity as to what each component delivers.
The same can be said for eecas and other services. Maybe we should embark
on that, before we decide to move it all to one monolithical entity
component.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Fri, Jun 12, 2015 at 8:39 AM, Jacques Le Roux 
jacques.le.r...@les7arts.com wrote:


Le 11/06/2015 21:10, Ron Wheeler a écrit :


I would suggest adding other levels  to the structure so that
specializations are easy to add without creating conflicts or constant flux
as people alter the accounting-entitymodel.xml to suit their needs and
submit it as the right version.

applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml

applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region to
get the vocabulary or regulatory compliance particularities separated

applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml

applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml

applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml

Clearly we would start out with only the demo set but I think that we
could quickly get some of the other alternatives in place as people
contribute versions that they want to be part of the basic set.

Would it make sense to break accounting-entitymodel.xml into separate
files for mandatory and optional entities to make it clear the entities
that can be modified or dropped without affecting OOB functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps as Jacopo
suggested

Jacques




Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:


On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb slidingfilame...@gmail.com
wrote:

  I would like to help and I think we need to think carefully of the

layout / structure though i.e. how to breakup the entities in files and/or
directories.


I would suggest that, at least in the first step, we do it in a simple
way like the following:

1) create the new component, named for example datamodel (please
suggest a better name)
2) move all the entity xml files from the applications to the
datamodel component keeping the files separated as they are, but adding a
prefix; for example

applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a datamodel component with an entitidef/ folder
containing several files, approximately one per application component

3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

[Ron Wheeler]

It would be nice to get the philosophy of the structure agreed at the 
beginning even if there is only one variant of accounting-entitymodel.xml .
It might prevent conflicts over the content of some of the files and 
encourage more contributors who are confident about how their 
definitions work but are unwilling to change someone else's working set 
of entities, to contribute their variants.


For example, I could  supply my idea of what the Canadian 
accounting-entitymodel.xml should contain without breaking something 
that others are using.


An alternative scheme that might be easier to use would be to structure 
the files as

entitydef/accounting-entitymodel.xml
entitydef/ecommerce-entitymodel.xml
entitydef/general/UK/accounting-entitymodel.xml
entitydef/general/UK/ecommerce-entitymodel.xml

I am not sure that adding applications/datamodel to the front adds any value
entitydef is pretty unambiguous.

Putting the variants first would mean that all of the default entity 
definitions are in one folder and general/UK would all be in another.
To get a complete set, copy everything from entitydef and then copy 
everything from entitydef/general/UK to get the overrides required t 
create the UK variant.


Ron

On 12/06/2015 2:39 AM, Jacques Le Roux wrote:

Le 11/06/2015 21:10, Ron Wheeler a écrit :
I would suggest adding other levels  to the structure so that 
specializations are easy to add without creating conflicts or 
constant flux as people alter the accounting-entitymodel.xml to suit 
their needs and submit it as the right version.


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml 


applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region 
to get the vocabulary or regulatory compliance particularities separated


applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml 

applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml 


applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml 

applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml 


applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml

Clearly we would start out with only the demo set but I think that we 
could quickly get some of the other alternatives in place as people 
contribute versions that they want to be part of the basic set.


Would it make sense to break accounting-entitymodel.xml into separate 
files for mandatory and optional entities to make it clear the 
entities that can be modified or dropped without affecting OOB 
functionality?


I'm not against the idea, though it needs to be discussed more
Anyway it can be done later as we will go with baby steps as Jacopo 
suggested


Jacques



Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:
On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb 
slidingfilame...@gmail.com wrote:


I would like to help and I think we need to think carefully of the 
layout / structure though i.e. how to breakup the entities in files 
and/or directories.
I would suggest that, at least in the first step, we do it in a 
simple way like the following:


1) create the new component, named for example datamodel (please 
suggest a better name)
2) move all the entity xml files from the applications to the 
datamodel component keeping the files separated as they are, but 
adding a prefix; for example


applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a datamodel component with an entitidef/ 
folder containing several files, approximately one per application 
component


3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo











--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

[Ron Wheeler]

I would suggest adding other levels  to the structure so that 
specializations are easy to add without creating conflicts or constant 
flux as people alter the accounting-entitymodel.xml to suit their needs 
and submit it as the right version.


applications/datamodel/entitidef/accounting-entitymodel.xml
might be better structured as
applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/general/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/accounting-entitymodel.xml
applications/datamodel/entitidef/professionalServices/accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/accounting-entitymodel.xml

It may be that the first specialization will be by country or region to get the 
vocabulary or regulatory compliance particularities separated

applications/datamodel/entitidef/general/UK/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/general/NAFTA_MX/accounting-entitymodel.xml
applications/datamodel/entitidef/general/EU/accounting-entitymodel.xml

applications/datamodel/entitidef/demo/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/demo/NAFTA/accounting-entitymodel.xml
applications/datamodel/entitidef/manufacturing/EU/accounting-entitymodel.xml
applications/datamodel/entitidef/professionalServices/EU?accounting-entitymodel.xml
applications/datamodel/entitidef/eCommerce/EU/accounting-entitymodel.xml

Clearly we would start out with only the demo set but I think that we could 
quickly get some of the other alternatives in place as people contribute 
versions that they want to be part of the basic set.

Would it make sense to break accounting-entitymodel.xml into separate files for 
mandatory and optional entities to make it clear the entities that can be 
modified or dropped without affecting OOB functionality?

Ron


On 11/06/2015 10:18 AM, Jacopo Cappellato wrote:

On Jun 11, 2015, at 3:51 PM, Taher Alkhateeb slidingfilame...@gmail.com wrote:


I would like to help and I think we need to think carefully of the layout / 
structure though i.e. how to breakup the entities in files and/or directories.

I would suggest that, at least in the first step, we do it in a simple way like 
the following:

1) create the new component, named for example datamodel (please suggest a 
better name)
2) move all the entity xml files from the applications to the datamodel 
component keeping the files separated as they are, but adding a prefix; for example

applications/accounting/entitidef/entitymodel.xml

will be moved to:

applications/datamodel/entitidef/accounting-entitymodel.xml

The end result will be a datamodel component with an entitidef/ folder 
containing several files, approximately one per application component

3) similar approach for eeca files

4) add the relevant entries in

applications/datamodel/ofbiz-component.xml

Regards,

Jacopo






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Move Application Entity Definitions to A Separate Component

[Ron Wheeler]

+1
Would like to see the definitions organized in a way that makes it easy 
to see what entities are mandatory as is as opposed to customizable.


Might also want to consider having multiple variations of the entities 
to support different industries, different management focuses or languages.


These could be contributed by users and maintained by users rather than 
developers.


Ron


On 11/06/2015 3:46 AM, Sharan-F wrote:

Hi All

I'd like to get some feedback on the a proposal Jacopo made a while ago to
find out if we have enough consenus to include it in our upcoming Community
Day.

*/Some time ago I proposed to move all entity definitions from the
applications components into a separate one; this component could also
contain crud/generic services: in this way it will be easier to deploy the
framework+data-model without the user interfaces that are not as generic and
universal as the data model is. In my opinion this would be a good step in
the right direction and it would be very easy to implement. /*

So my questions to you all are :

 1. Can we reach a consenus as to whether or not we want to do it?
 2. And if so, whether we want to include it as part of the work for our
Community Day next week?

Thanks
Sharan



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Move-Application-Entity-Definitions-to-A-Separate-Component-tp4669903.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Possible Documentation and help solutions - DITA

[Ron Wheeler]

On 06/06/2015 5:19 PM, Jacques Le Roux wrote:

Le 06/06/2015 08:10, Paul Foxworthy a écrit :

Sharan-F wrote

I'm a bit unclear about what you are suggesting.

   * Is it about replacing the Docbook implementation we currently have
 within OFBiz with something else (e.g Asciidoc)?
   * Is it about extracting the Docbook content from what we currently
 have in OFBiz and then generating it into another format that we
 could possibly re-introduce?
   * Or is it something else?

Hi Sharan,

My suggestion is much more modest than that. I think there's no need to
replace existing DocBook content, or to totally change the DocBook 
process

we have.

All I am suggesting is that people consider AsciiDoc as a first step 
when
authoring help information. If they prefer to work with DocBook 
directly,

fine. There are tools to transform AsciDoc into DocBook XML, such as
AsciiDoctor (http://asciidoctor.org/), so in effect (correctly written)
AsciiDoc *is* DocBook.

I'll repeat the reasons why I like AsciiDoc. It's more human-readable 
than
XML. You can write your documentation in any text editor. Both of 
these are
important. In contrast, requiring XML and some more specialised tool 
is a
barrier to entry, so less people could and would participate in 
documenting

OFBiz.


That's exactly the point indeed, thanks to stress that Paul.
I expect that everyone has an IDE that can edit and validate XML. All 
the other tools required are free.





When I last looked into DITA quite a few years ago, it seemed to be a
heavyweight thing that only made sense if you wanted multiple 
destinations


This seems to answer to my question just asked to Ron on the user ML. 
So you think Docbook (more aimed to create book when DITA is more of 
online help kind, I read) or AsciiDoc are not able to OOTB deliver in 
this way?
Yes but we do have multiple destinations to support - multiple 
languages, multiple customizations, multiple brandings.
Topics are likely shared between the same on-line help topic - concepts 
shared with different task descriptions.
Eliminate duplication of background material and ensure that there is 
only one version of each concept description and that the up to date 
description appears in each help screen.


and were willing to invest in proprietary tools like Framemaker, 
Oxygen or
Arbortext. I am perfectly willing to believe that DITA is more 
complete

than DocBook, and would allow better documentation, if only anyone was
willing to invest the time, trouble and money to be able to use it.

I would not advise purchasing anything unless you are strictly working 
as a technical documentation writter and do not have an IDE and do not 
understand XML.
I'm pleased to hear there's now DITA support for Eclipse. Eclipse is 
not my
favourite IDE, but I could be persuaded to use it. How much better 
would it
be to say to potential contributors that they can use their favourite 
IDE or

text editor, whatever that is?


I am sure that other IDE's support XML and auto-completion of XML.
What IDE's are important?
OFBiz is pretty XML intensive so I would be surprised if OFBiz 
developers did not use an IDE that can validate XML.


http://when-others-then-null.blogspot.co.uk/2012/12/Validate-XML-against-an-XSD-using-npp.html 
talks about using Notepad++ as a validating editor.


If everybody else loves DITA, I would work with it. But I worry that it 
will

put many people off.
Possibly but then again OFBiz would be built with Visual Basic if 
popularity was the main criteria:-)


That's the point we need to clarify...

Jacques



Thanks

Paul Foxworthy



-
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Possible-Documentation-and-help-solutions-DITA-tp4669377p4669576.html

Sent from the OFBiz - Dev mailing list archive at Nabble.com.






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: References for DITA as a tool for on-line help

[Ron Wheeler]

I agree that a lot of the official DITA stuff is pretty intimidating 
since the early adopters where heavy duty tech writers from IBM who had 
pretty serious expert teams involved.

It is actually a lot simpler.
If you look at my demo and notes, you can see that it is pretty simple 
to use if you do not need to get into the really obscure stuff.

I only use a few of the tags (20?).

Ron
On 06/06/2015 5:33 PM, Jacques Le Roux wrote:
OK DITA seems powerful but not an easy tool to work with (not only 
because of XML verbosity but also tags and concepts to learn)
Sincerely the examples in 
http://fr.wikipedia.org/wiki/Darwin_Information_Typing_Architecture 
frightens me a bit (and remembers me how verbose is XML)
We would need to convince the community it's the gith tool for OFBiz 
documentation... and more...


Also I wonder if we simply don't know Docbook enough to be really able 
to compare them...

What would be the cost of moving from DocBook to DITA in OFBiz?

Is http://www.dita-ot.org/ of value?
Found this by change 
https://doconv.readthedocs.org/en/latest/features.html
With http://www.dita-ot.org/2.0/readme/dita2docbook.html this would 
allow to mix tools (I think we should go that way, but have a tool of 
reference in OFBiz, still to choose if we don't keep Docbook)


Jacques

Le 05/06/2015 16:13, Ron Wheeler a écrit :
I have found another great reference for planning a DITA project in 
order to maximize the possibilities for reuse.

http://www.stilo.com/article-dita-reuse-conversion-together/

It is useful reading if you want reverse engineer some ideas about 
where the big benefits will come from DITA.
For example, it talks about creating a warehouse for conrefs where 
is recommends writing fragments conrefs that are included by name.

It suggests that these should be used for

 * GUI objects, fields, buttons, icons
 * Frequently used steps, with step results and info
 * All your notes and warnings
 * Pre-requisites that are commonly mentioned, like having
   administrative privileges
 * Boilerplate - legal, copyright, notices,

When you think about each of these as a multilingual fragment that 
can be called in by referencing a key, you can see that this
a) reduces translation - translate the key once and every place it is 
referenced has the translation done

b) improves consistency
c) makes customization a lot simpler - if you have changed a field 
label or button label, you only have to change the conref once and it 
is changed in your documentation.


There is also a discussion on using keys.
If we define variables such as version numbers, it makes it easier to 
ensure that versions (Java, Tomcat, OFBiz, etc.) are consistent 
everywhere with a single variable to change.
If URLs are keys, you only have to change one key when a web page or 
file moves.
Keys can also be used to select or exclude content which will make it 
easier for System Integrators to prepare manuals related to different 
configurations - include or exclude e-commerce, control industry 
specific content, etc.


It has specific ideas about how to plan and execute a conversion.

Ron




- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev dev@ofbiz.apache.org
Sent: Thursday, 4 June, 2015 6:14:56 PM
Subject: References for DITA as a tool for on-line help

http://www.slideshare.net/abelsp/using-dita-for-online-help
Slideshare has a lot of other presentations on DITA

http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
Short with Hello World example

http://en.wikipedia.org/wiki/Online_help
Alternatives for producing on-line help - DocBooks and DITA considered
together since they are closely related

http://www.ditawriter.com/sample-dita-produced-output/ Has links to
actual documents produced from DITA sources.

https://www.oasis-open.org/committees/download.php/30122/DHSC_BestPractices_November20_rdr.pdf 


exhaustive article on ways to deliver help authored by DITA tools. It
shows that an investment in DITA content will always be protected even
if the OFBiz UI and help delivery technology changes.

Table of Contents
*Introduction to the DITA Help Best Practices Guide*

*Developing DITA-based Help for Existing Help Environments*
-Arbortext Digital Media Publisher
-Eclipse Help
-CSHelp Plug-in
-Eclipse_CSH Plug-in for Dynamic Context-Sensitive Help
-Eclipse Help
-Leximation AIR Help Plug-in
-Microsoft HTMLHelp
-Context-Sensitive Help using the Enhanced HTML (htmlhelp2) Plug-In
-The DITA Open Toolkit HTMLHelp Transform

*Developing Custom DITA-based Help Systems**
*-DHTML Effects in HTML Generated from DITA
-DITA-OT Plug-ins
-HTMLSearch Plug-in
-TOCJS and TOCJSBIS Plug-ins
-Dynamic Rendering of DITA into XHTML
-JavaScript-Based Context Sensitive Help
-WinANT Options Supporting HTML-Based Output
-WinANT Options Supporting Microsoft® HTML Help

*Developing DITA-based Help for Existing Help Authoring Tools**
*-Converting DITA Content to WebHelp using RoboHelp®

There are a lot more

Re: Possible Documentation and help solutions - DITA

[Ron Wheeler]

On 06/06/2015 5:20 PM, Jacques Le Roux wrote:

Thanks Taher,

Let's see...

Jacques

Le 06/06/2015 11:19, Taher Alkhateeb a écrit :

Hi Paul,

I am starting to use DITA and really like it. But I can see your 
point regarding people being put off. It might be in a sense a bit 
too powerful for OFBiz and it takes a while to wrap your head around 
the concepts like maps, topics, etc ... I'm on the fence, maybe 
leaning slightly towards keeping DocBook, but if a PoC shows how DITA 
can shine, then why not!

I agree that PoC is the next step.


Taher Alkhateeb

- Original Message -

From: Paul Foxworthy p...@cohsoft.com.a Pau
To: dev@ofbiz.apache.org
Sent: Saturday, 6 June, 2015 9:10:28 AM
Subject: Re: Possible Documentation and help solutions - DITA

Sharan-F wrote

I'm a bit unclear about what you are suggesting.

* Is it about replacing the Docbook implementation we currently have
within OFBiz with something else (e.g Asciidoc)?
* Is it about extracting the Docbook content from what we currently
have in OFBiz and then generating it into another format that we
could possibly re-introduce?
* Or is it something else?

Hi Sharan,

My suggestion is much more modest than that. I think there's no need to
replace existing DocBook content, or to totally change the DocBook 
process

we have.

All I am suggesting is that people consider AsciiDoc as a first step 
when
authoring help information. If they prefer to work with DocBook 
directly,

fine. There are tools to transform AsciDoc into DocBook XML, such as
AsciiDoctor (http://asciidoctor.org/), so in effect (correctly written)
AsciiDoc *is* DocBook.

I'll repeat the reasons why I like AsciiDoc. It's more human-readable 
than
XML. You can write your documentation in any text editor. Both of 
these are
important. In contrast, requiring XML and some more specialised tool 
is a
barrier to entry, so less people could and would participate in 
documenting

OFBiz.

When I last looked into DITA quite a few years ago, it seemed to be a
heavyweight thing that only made sense if you wanted multiple 
destinations
and were willing to invest in proprietary tools like Framemaker, 
Oxygen or
Arbortext. I am perfectly willing to believe that DITA is more 
complete

than DocBook, and would allow better documentation, if only anyone was
willing to invest the time, trouble and money to be able to use it.

I'm pleased to hear there's now DITA support for Eclipse. Eclipse is 
not my
favourite IDE, but I could be persuaded to use it. How much better 
would it
be to say to potential contributors that they can use their favourite 
IDE or

text editor, whatever that is?

If everybody else loves DITA, I would work with it. But I worry that 
it will

put many people off.

Thanks

Paul Foxworthy



-





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: References for DITA as a tool for on-line help

[Ron Wheeler]

I use
- Eclipse/STS for authoring http://blog.artifact-software.com/tech/?p=206
- Maven with DITA-OT for publishing in Eclipse
- Subversion for SCM
- Bugzilla for issue tracking

This is all integrated into Eclipse.


Ron

On 05/06/2015 9:15 AM, Taher Alkhateeb wrote:

Hi Ron,

DITA-OT ! :)

Taher Alkhateeb

- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev@ofbiz.apache.org
Sent: Friday, 5 June, 2015 4:13:39 PM
Subject: Re: References for DITA as a tool for on-line help

What tools are you using?

Ron

On 05/06/2015 4:38 AM, Taher Alkhateeb wrote:

Great resources Ron. Thank you for sharing. FYI I find DITA-OT to be nice and 
powerful. I'm beginning to do some of our own documentation on it.

- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev dev@ofbiz.apache.org
Sent: Thursday, 4 June, 2015 6:14:56 PM
Subject: References for DITA as a tool for on-line help

http://www.slideshare.net/abelsp/using-dita-for-online-help
Slideshare has a lot of other presentations on DITA

http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
Short with Hello World example

http://en.wikipedia.org/wiki/Online_help
Alternatives for producing on-line help - DocBooks and DITA considered
together since they are closely related

http://www.ditawriter.com/sample-dita-produced-output/ Has links to
actual documents produced from DITA sources.

https://www.oasis-open.org/committees/download.php/30122/DHSC_BestPractices_November20_rdr.pdf
exhaustive article on ways to deliver help authored by DITA tools. It
shows that an investment in DITA content will always be protected even
if the OFBiz UI and help delivery technology changes.

Table of Contents
*Introduction to the DITA Help Best Practices Guide*

*Developing DITA-based Help for Existing Help Environments*
-Arbortext Digital Media Publisher
-Eclipse Help
-CSHelp Plug-in
-Eclipse_CSH Plug-in for Dynamic Context-Sensitive Help
-Eclipse Help
-Leximation AIR Help Plug-in
-Microsoft HTMLHelp
-Context-Sensitive Help using the Enhanced HTML (htmlhelp2) Plug-In
-The DITA Open Toolkit HTMLHelp Transform

*Developing Custom DITA-based Help Systems**
*-DHTML Effects in HTML Generated from DITA
-DITA-OT Plug-ins
-HTMLSearch Plug-in
-TOCJS and TOCJSBIS Plug-ins
-Dynamic Rendering of DITA into XHTML
-JavaScript-Based Context Sensitive Help
-WinANT Options Supporting HTML-Based Output
-WinANT Options Supporting Microsoft® HTML Help

*Developing DITA-based Help for Existing Help Authoring Tools**
*-Converting DITA Content to WebHelp using RoboHelp®

There are a lot more articles on using DITA content in On-line help.

The same content is available for other uses.

Ron






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: References for DITA as a tool for on-line help

[Ron Wheeler]

Have you done a lot of branding and customizing the output from DITA-OT?

I have not done anything yet but I will need to do this to make a nice 
looking manual.
I want to do a bit of branding and I need to change the fonts in my code 
examples since most don't fit the width of the blocks and the font and 
colors are not very attractive in my opinion.


Ron

On 05/06/2015 9:15 AM, Taher Alkhateeb wrote:

Hi Ron,

DITA-OT ! :)

Taher Alkhateeb

- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev@ofbiz.apache.org
Sent: Friday, 5 June, 2015 4:13:39 PM
Subject: Re: References for DITA as a tool for on-line help

What tools are you using?

Ron

On 05/06/2015 4:38 AM, Taher Alkhateeb wrote:

Great resources Ron. Thank you for sharing. FYI I find DITA-OT to be nice and 
powerful. I'm beginning to do some of our own documentation on it.

- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev dev@ofbiz.apache.org
Sent: Thursday, 4 June, 2015 6:14:56 PM
Subject: References for DITA as a tool for on-line help

http://www.slideshare.net/abelsp/using-dita-for-online-help
Slideshare has a lot of other presentations on DITA

http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
Short with Hello World example

http://en.wikipedia.org/wiki/Online_help
Alternatives for producing on-line help - DocBooks and DITA considered
together since they are closely related

http://www.ditawriter.com/sample-dita-produced-output/ Has links to
actual documents produced from DITA sources.

https://www.oasis-open.org/committees/download.php/30122/DHSC_BestPractices_November20_rdr.pdf
exhaustive article on ways to deliver help authored by DITA tools. It
shows that an investment in DITA content will always be protected even
if the OFBiz UI and help delivery technology changes.

Table of Contents
*Introduction to the DITA Help Best Practices Guide*

*Developing DITA-based Help for Existing Help Environments*
-Arbortext Digital Media Publisher
-Eclipse Help
-CSHelp Plug-in
-Eclipse_CSH Plug-in for Dynamic Context-Sensitive Help
-Eclipse Help
-Leximation AIR Help Plug-in
-Microsoft HTMLHelp
-Context-Sensitive Help using the Enhanced HTML (htmlhelp2) Plug-In
-The DITA Open Toolkit HTMLHelp Transform

*Developing Custom DITA-based Help Systems**
*-DHTML Effects in HTML Generated from DITA
-DITA-OT Plug-ins
-HTMLSearch Plug-in
-TOCJS and TOCJSBIS Plug-ins
-Dynamic Rendering of DITA into XHTML
-JavaScript-Based Context Sensitive Help
-WinANT Options Supporting HTML-Based Output
-WinANT Options Supporting Microsoft® HTML Help

*Developing DITA-based Help for Existing Help Authoring Tools**
*-Converting DITA Content to WebHelp using RoboHelp®

There are a lot more articles on using DITA content in On-line help.

The same content is available for other uses.

Ron






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: References for DITA as a tool for on-line help

[Ron Wheeler]

What tools are you using?

Ron

On 05/06/2015 4:38 AM, Taher Alkhateeb wrote:

Great resources Ron. Thank you for sharing. FYI I find DITA-OT to be nice and 
powerful. I'm beginning to do some of our own documentation on it.

- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev dev@ofbiz.apache.org
Sent: Thursday, 4 June, 2015 6:14:56 PM
Subject: References for DITA as a tool for on-line help

http://www.slideshare.net/abelsp/using-dita-for-online-help
Slideshare has a lot of other presentations on DITA

http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
Short with Hello World example

http://en.wikipedia.org/wiki/Online_help
Alternatives for producing on-line help - DocBooks and DITA considered
together since they are closely related

http://www.ditawriter.com/sample-dita-produced-output/ Has links to
actual documents produced from DITA sources.

https://www.oasis-open.org/committees/download.php/30122/DHSC_BestPractices_November20_rdr.pdf
exhaustive article on ways to deliver help authored by DITA tools. It
shows that an investment in DITA content will always be protected even
if the OFBiz UI and help delivery technology changes.

Table of Contents
*Introduction to the DITA Help Best Practices Guide*

*Developing DITA-based Help for Existing Help Environments*
-Arbortext Digital Media Publisher
-Eclipse Help
-CSHelp Plug-in
-Eclipse_CSH Plug-in for Dynamic Context-Sensitive Help
-Eclipse Help
-Leximation AIR Help Plug-in
-Microsoft HTMLHelp
-Context-Sensitive Help using the Enhanced HTML (htmlhelp2) Plug-In
-The DITA Open Toolkit HTMLHelp Transform

*Developing Custom DITA-based Help Systems**
*-DHTML Effects in HTML Generated from DITA
-DITA-OT Plug-ins
-HTMLSearch Plug-in
-TOCJS and TOCJSBIS Plug-ins
-Dynamic Rendering of DITA into XHTML
-JavaScript-Based Context Sensitive Help
-WinANT Options Supporting HTML-Based Output
-WinANT Options Supporting Microsoft® HTML Help

*Developing DITA-based Help for Existing Help Authoring Tools**
*-Converting DITA Content to WebHelp using RoboHelp®

There are a lot more articles on using DITA content in On-line help.

The same content is available for other uses.

Ron




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: References for DITA as a tool for on-line help

[Ron Wheeler]

I have found another great reference for planning a DITA project in 
order to maximize the possibilities for reuse.

http://www.stilo.com/article-dita-reuse-conversion-together/

It is useful reading if you want reverse engineer some ideas about where 
the big benefits will come from DITA.
For example, it talks about creating a warehouse for conrefs where is 
recommends writing fragments conrefs that are included by name.

It suggests that these should be used for

 * GUI objects, fields, buttons, icons
 * Frequently used steps, with step results and info
 * All your notes and warnings
 * Pre-requisites that are commonly mentioned, like having
   administrative privileges
 * Boilerplate - legal, copyright, notices,

When you think about each of these as a multilingual fragment that can 
be called in by referencing a key, you can see that this
a) reduces translation - translate the key once and every place it is 
referenced has the translation done

b) improves consistency
c) makes customization a lot simpler - if you have changed a field label 
or button label, you only have to change the conref once and it is 
changed in your documentation.


There is also a discussion on using keys.
If we define variables such as version numbers, it makes it easier to 
ensure that versions (Java, Tomcat, OFBiz, etc.) are consistent 
everywhere with a single variable to change.
If URLs are keys, you only have to change one key when a web page or 
file moves.
Keys can also be used to select or exclude content which will make it 
easier for System Integrators to prepare manuals related to different 
configurations - include or exclude e-commerce, control industry 
specific content, etc.


It has specific ideas about how to plan and execute a conversion.

Ron




- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev dev@ofbiz.apache.org
Sent: Thursday, 4 June, 2015 6:14:56 PM
Subject: References for DITA as a tool for on-line help

http://www.slideshare.net/abelsp/using-dita-for-online-help
Slideshare has a lot of other presentations on DITA

http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
Short with Hello World example

http://en.wikipedia.org/wiki/Online_help
Alternatives for producing on-line help - DocBooks and DITA considered
together since they are closely related

http://www.ditawriter.com/sample-dita-produced-output/ Has links to
actual documents produced from DITA sources.

https://www.oasis-open.org/committees/download.php/30122/DHSC_BestPractices_November20_rdr.pdf 


exhaustive article on ways to deliver help authored by DITA tools. It
shows that an investment in DITA content will always be protected even
if the OFBiz UI and help delivery technology changes.

Table of Contents
*Introduction to the DITA Help Best Practices Guide*

*Developing DITA-based Help for Existing Help Environments*
-Arbortext Digital Media Publisher
-Eclipse Help
-CSHelp Plug-in
-Eclipse_CSH Plug-in for Dynamic Context-Sensitive Help
-Eclipse Help
-Leximation AIR Help Plug-in
-Microsoft HTMLHelp
-Context-Sensitive Help using the Enhanced HTML (htmlhelp2) Plug-In
-The DITA Open Toolkit HTMLHelp Transform

*Developing Custom DITA-based Help Systems**
*-DHTML Effects in HTML Generated from DITA
-DITA-OT Plug-ins
-HTMLSearch Plug-in
-TOCJS and TOCJSBIS Plug-ins
-Dynamic Rendering of DITA into XHTML
-JavaScript-Based Context Sensitive Help
-WinANT Options Supporting HTML-Based Output
-WinANT Options Supporting Microsoft® HTML Help

*Developing DITA-based Help for Existing Help Authoring Tools**
*-Converting DITA Content to WebHelp using RoboHelp®

There are a lot more articles on using DITA content in On-line help.

The same content is available for other uses.

Ron







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Fwd: [dita-users] Free Webinar 6/9 9 AM PT - Patrick Bosek, easyDITA, Key Referencing - The Key to Reuse

[Ron Wheeler]

This is an introductory webinar that should give some ideas about why 
DITA is a good solution for OFBiz where we need translations and 
branding for different installations.
The presenter represents a company that offers a commercial tool that 
simplifies editing of DITA.
I don't use it but it could be a good tool for authors with no desire to 
learn any markup.



Ron


 Forwarded Message 



In the next TC Dojo Open Session webinar:

Key Referencing - The Key to Reuse
 with Visiting Dojo Master: Patrick Bosek, easyDITA


SIGN UP:
Register: http://bit.ly/1FMYvv3


Audience: B - Beginner
Cost: Free


Description:

Topic based content enables organizations to piece content together to 
fit different customer needs. But often times this content can't be 
shared and reused to its full potential because it contains product 
names, specific values, screenshots, links, or other content that would 
be out of place in another context. This means that conceptually or 
procedurally identical content is duplicated for different audiences, 
products, or even brandings.


This webinar will take a look at how to reduce or eliminate this issue 
using DITA Key-referencing.



About Patrick:

Patrick is a co-founder of Jorsek LLC, a company primarily focused on 
it’s flagship product easyDITA. Since beginning with Jorsek LLC in 2005 
Patrick has worked on a wide range of projects all focused on improving 
authoring, production, and distribution of content. Most recently, his 
primary focus has been perfecting easyDITA and generally advancing the 
product documentation industry.


Patrick is a software industry professional specializing in developing, 
productizing, and solving problems with product communications software. 
He is a highly skilled developer, thoughtful manager, passionate 
customer advocate.




SIGN UP FOR ALL THREE PARTS:

SIGN UP:
Register: http://bit.ly/1FMYvv3


__._,_.___

Posted by: Liz Fraley l...@caltonia.com



Visit Your Group 
https://groups.yahoo.com/neo/groups/dita-users/info;_ylc=X3oDMTJmMTk2bTIyBF9TAzk3MzU5NzE0BGdycElkAzEyNzQ0MjA5BGdycHNwSWQDMTcwNjAzMDM5MARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0MzM0MjU3NjA- 



 * New Members
   
https://groups.yahoo.com/neo/groups/dita-users/members/all;_ylc=X3oDMTJncmI1cGdkBF9TAzk3MzU5NzE0BGdycElkAzEyNzQ0MjA5BGdycHNwSWQDMTcwNjAzMDM5MARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxNDMzNDI1NzYw
   2

Yahoo! Groups 
https://groups.yahoo.com/neo;_ylc=X3oDMTJlZHBubGo5BF9TAzk3NDc2NTkwBGdycElkAzEyNzQ0MjA5BGdycHNwSWQDMTcwNjAzMDM5MARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQzMzQyNTc2MA-- 

• Privacy https://info.yahoo.com/privacy/us/yahoo/groups/details.html 
• Unsubscribe 
mailto:dita-users-unsubscr...@yahoogroups.com?subject=Unsubscribe • 
Terms of Use https://info.yahoo.com/legal/us/yahoo/utos/terms/


__,_._,___

References for DITA as a tool for on-line help

[Ron Wheeler]

http://www.slideshare.net/abelsp/using-dita-for-online-help
Slideshare has a lot of other presentations on DITA

http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
Short with Hello World example

http://en.wikipedia.org/wiki/Online_help
Alternatives for producing on-line help - DocBooks and DITA considered 
together since they are closely related


http://www.ditawriter.com/sample-dita-produced-output/  Has links to 
actual documents produced from DITA sources.


https://www.oasis-open.org/committees/download.php/30122/DHSC_BestPractices_November20_rdr.pdf 
exhaustive article on ways to deliver help authored by DITA tools. It 
shows that an investment in DITA content will always be protected even 
if the OFBiz UI and help delivery technology changes.


Table of Contents
*Introduction to the DITA Help Best Practices Guide*

*Developing DITA-based Help for Existing Help Environments*
-Arbortext Digital Media Publisher
-Eclipse Help
-CSHelp Plug-in
-Eclipse_CSH Plug-in for Dynamic Context-Sensitive Help
-Eclipse Help
-Leximation AIR Help Plug-in
-Microsoft HTMLHelp
-Context-Sensitive Help using the Enhanced HTML (htmlhelp2) Plug-In
-The DITA Open Toolkit HTMLHelp Transform

*Developing Custom DITA-based Help Systems**
*-DHTML Effects in HTML Generated from DITA
-DITA-OT Plug-ins
-HTMLSearch Plug-in
-TOCJS and TOCJSBIS Plug-ins
-Dynamic Rendering of DITA into XHTML
-JavaScript-Based Context Sensitive Help
-WinANT Options Supporting HTML-Based Output
-WinANT Options Supporting Microsoft® HTML Help

*Developing DITA-based Help for Existing Help Authoring Tools**
*-Converting DITA Content to WebHelp using RoboHelp®

There are a lot more articles on using DITA content in On-line help.

The same content is available for other uses.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Possible Documentation and help solutions - DITA

[Ron Wheeler]

I am willing to work on a DITA PoC.

Ron

On 04/06/2015 4:01 AM, Sharan-F wrote:

Hi Taher

It would be good to understand what exactly is missing from our Docbook
implementation. It might  be that we have set the tags at a specific level
(e.g section etc) which means that we cant use  chapters etc.

I'm still thinking but the main thing that concerns me is this.

There is a lot of focus about changing the technology but no focus on how we
integrate it or manage it. It's not only about changing the technology - we
need to address the underlying problems.

Why is our online documentation not being kept up to date?  These are the
main reasons I think are:

- it is too hard to keep up to date as each change needs to be submitted as
a patch
- you need to understand and create the new data items for the CMS for each
page of documentation - existing items need to be linked into the correct
place in the document hierarchy
- the docbook implementation isn't complete and there are a lot standard
tags that cannot be used

One the End User documentation side remember that Confluence is the Apache
approved tools for wiki so we still need to work within this constraint for
now. In any case – I think we firstly need to do some review of the all the
documentation we have before we start structuring it.

If changing to another format (DITA, Asciidoc etc) within OFBiz itself is
going to generate a lot of work on the framework etc – why don't we try some
small steps first just to see what we can do. It will also show if we can
really start adding some value.

Paul mentioned that Asciidoc could be a good compromise as it converts to
Docbook and other formats.

What about doing a small proof of concept (PoC) just to see what editing
using Asciidoc could be like?

The scope would be not to replace Docbook in OFBiz but just to see how we
can use and edit in Asciidoc and how it can generate Docbook or other
formats.

- Could we extract the existing OFBiz online help and put it into Asciidoc
format
- Put the Online help Asciidoc somewhere where it can be edited and updated
- Extract updated Asciidoc back into Docbook (or other) format
- See if it can be re-introduced back into OFBiz (e.g. directly as a patch
or as part as an ant target)

Does this seem reasonable? If so are there any volunteers who'd like to work
with me on this PoC?

Thanks
Sharan




--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Possible-Documentation-and-help-solutions-DITA-tp4669377p4669411.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Possible Documentation and help solutions - DITA

[Ron Wheeler]

There are free tools - Eclipse/STS if you do not already have an IDE.
The publishing tool DITA-OT is open source.

There are tools that can be purchased.
I have not purchased anything.


On 03/06/2015 4:47 AM, Paul Foxworthy wrote:

Hi Ron,

For serious use of DITA, would it be necessary to invest in specialist
tools? That would be a real barrier for an open source project.

I've have had good results in another project using AsciiDoc, which is a
wiki-like markup language. Unlike Markdown and all those others, it's not
limited to a brain-damaged subset of what you need in a manual. It can
convey anything in DocBook, and AsciiDoc can be converted to DocBook. To me
this is the best of all worlds. No specialist tools required for editing
and maintenance, human-readable, but with the entire DocBook toolchain
available. pandoc (pandoc.org) can translate DocBook to a huge list of
other structured formats.

Thanks

Paul Foxworthy


On 3 June 2015 at 03:28, Ron Wheeler rwhee...@artifact-software.com wrote:


Anne Rockley is one of the top DITA experts and her webinars are excellent.
If you want to see how DITA could help improve the production and
utilization of documentation for OFBiz, you might look for a webinar that
relates to your particular concerns.

She is an expert in the pharmaceutical area but a lot of her concerns also
apply to regulated industries or business functions that are regulated such
as accounting (localization is a common issue).

19 June - Join Charles Cooper at ETC for his session on Software,
Documentation and Agile Development 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVGCO8y5J0LCNrluDdwSUd4f9WqyMtVtzdU4iUvYLE8gHYaxHEp7GiHnXU91MZQlCvJQmSSxqW1qMS90KgOVj0jCZz7XUq4o8y2HrSIpCCC1pvty9zVdsbWad85_8zRNttYSNLZaji3a3c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==
sounds like something that might be relevant to us.

The Intelligent Content: What Does Reusable Mean? 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVIKcq5t7_sGa_YrYZcPP_xveuxMDyIJOq0NL2T01f13TSS56TTCCpGDrgsZf35E_GQhKjAqaQZ-eok4xWgT8JGSSCXzPYsUu-Hf0EpZ6IVS8zUiX7UVwvOA9NZFpMGb5bQnx9PgZv04uStMHJAgB1UJqa-g_s8BLBacNZSXegB5Gov7l9r-kfBIvkx4sU3NZE7di-GHeu_0mlNG7OV1QMKYJ9yF0Mqoc01uZTFw-QnQzkdObw-tX4mo=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==
blog post addresses Jacques' question about how to use a library of
reusable content much better than I did.


Ron



 Forwarded Message 


Having trouble viewing this email? Click here 
http://campaign.r20.constantcontact.com/render?ca=fcaa0b03-86df-4c67-bf37-d645ce38f8eac=8f7153c0-e1fa-11e4-a4b6-d4ae52844279ch=8f9c3450-e1fa-11e4-a4de-d4ae52844279






http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVIz0RR4E3aPj1d7wqoOmD03Aya0ayMj7-AgoYI1Q8jMzgxi5OPHr-9kecHlyI_KcNsuYThWc0tgCI1JWLCg1_wkaYdETLixWpz_mA3YqzY4d90I3-fyVpA4=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==



*
*
*Webinars with Ann Rockley*
**
*Recently Recorded Webinars*

Results of the Second Annual Challenges of Creating and Managing Content
in Life Sciences and Healthcare Survey 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVPAoxrJqBq8BsuVDhC1MXkBPtRuVcjavHIB69fqUJQc0XInBL8j6m1OqwvcE50qH7AClNrk1L6KHec3LO3_4IfyxzAq2BCTYgMrHmQvnEj-oC8_1T6u_4umpDR5elMhfypJuzjQzmNZZH06irReDYNKwY9uEhJ6HiAzfsAyyGIPuAQbH0J9taNgHIHV87AQlvd9bRzEFqHHa1RuOIAV_DUctsI2wCR4toOjyKztJhEoLjdTD4Y1Ren2vX3ZehMrhjBScQO1s5npvjaGD4gMUa2M=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==
Localizing Regulated Content While Saving Time and Money 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVBVnHwvucfHT2zNvF1yPKz-NSvdYGJIul-7dtewqWjcn18DV-CMGgiz67VaaXrAnbGxcEphlVOUfA7iyRqmz3MJOvS60jTD9VX9GWA0F4hmIg-gVS8NhsxfPiZWO0IKTzMzMr2h12horjIiz66wAcvRqjmkzh3Wj4g==c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==
Bridging Pharma Content Silos: Managing Content from Clinical Through
Labeling and Marketing https://www.brighttalk.com/webcast/9273/146095

Intelligently Managing the Complexities of the Core Data Sheet 
https://www.brighttalk.com/webcast/9273/146091


*Upcoming Events and Presentations*

*LocWorld 28 - Localization World 2015 in Berlin, Germany*

03 June - Join Ann Rockley and others for the Life Sciences Business
Roundtable 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVGCO8y5J0LCNKkQku0rPdubcmGs9xZj-nU756cGD8h9GUq0niuPwDarZHhfLSyhyXG-TwKft5pJ4gYmRgftjttrmcQ_Pdb-g1syVUc4058f35z53DcsvP_-BV25Cw1yUYd2db4QnPe1d0JsoaDXGKTxnkedl-GtzB6zLwWhkZWerXTd1OF3vk8PXHCuojL_CRQ==c=ji_CL3u5I7wrq8E-36UYX

Re: Possible Documentation and help solutions - DITA

[Ron Wheeler]

On 03/06/2015 5:09 AM, Sharan Foga wrote:

Hi Paul

I've got some other threads open on the user mailing lists about 
documentation strategies because I wanted to get some feedback from 
the user community and I'm a bit unclear about what you are suggesting.


 * Is it about replacing the Docbook implementation we currently have
   within OFBiz with something else (e.g Asciidoc)?

Yes

 * Is it about extracting the Docbook content from what we currently
   have in OFBiz and then generating it into another format that we
   could possibly re-introduce?

Yes


 * Or is it something else?
Yes. building a library of topics that can be used to assemble user 
documentation, create marketing materials, creating proposals, creating 
contracts, etc





Thanks
Sharan


On 03/06/15 10:47, Paul Foxworthy wrote:

Hi Ron,

For serious use of DITA, would it be necessary to invest in specialist
tools? That would be a real barrier for an open source project.

I've have had good results in another project using AsciiDoc, which is a
wiki-like markup language. Unlike Markdown and all those others, it's 
not

limited to a brain-damaged subset of what you need in a manual. It can
convey anything in DocBook, and AsciiDoc can be converted to DocBook. 
To me

this is the best of all worlds. No specialist tools required for editing
and maintenance, human-readable, but with the entire DocBook toolchain
available. pandoc (pandoc.org) can translate DocBook to a huge list of
other structured formats.

Thanks

Paul Foxworthy


On 3 June 2015 at 03:28, Ron Wheeler rwhee...@artifact-software.com 
wrote:


Anne Rockley is one of the top DITA experts and her webinars are 
excellent.

If you want to see how DITA could help improve the production and
utilization of documentation for OFBiz, you might look for a webinar 
that

relates to your particular concerns.

She is an expert in the pharmaceutical area but a lot of her 
concerns also
apply to regulated industries or business functions that are 
regulated such

as accounting (localization is a common issue).

19 June - Join Charles Cooper at ETC for his session on Software,
Documentation and Agile Development 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVGCO8y5J0LCNrluDdwSUd4f9WqyMtVtzdU4iUvYLE8gHYaxHEp7GiHnXU91MZQlCvJQmSSxqW1qMS90KgOVj0jCZz7XUq4o8y2HrSIpCCC1pvty9zVdsbWad85_8zRNttYSNLZaji3a3c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 


sounds like something that might be relevant to us.

The Intelligent Content: What Does Reusable Mean? 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVIKcq5t7_sGa_YrYZcPP_xveuxMDyIJOq0NL2T01f13TSS56TTCCpGDrgsZf35E_GQhKjAqaQZ-eok4xWgT8JGSSCXzPYsUu-Hf0EpZ6IVS8zUiX7UVwvOA9NZFpMGb5bQnx9PgZv04uStMHJAgB1UJqa-g_s8BLBacNZSXegB5Gov7l9r-kfBIvkx4sU3NZE7di-GHeu_0mlNG7OV1QMKYJ9yF0Mqoc01uZTFw-QnQzkdObw-tX4mo=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 


blog post addresses Jacques' question about how to use a library of
reusable content much better than I did.


Ron



 Forwarded Message 


Having trouble viewing this email? Click here 
http://campaign.r20.constantcontact.com/render?ca=fcaa0b03-86df-4c67-bf37-d645ce38f8eac=8f7153c0-e1fa-11e4-a4b6-d4ae52844279ch=8f9c3450-e1fa-11e4-a4de-d4ae52844279 








http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVIz0RR4E3aPj1d7wqoOmD03Aya0ayMj7-AgoYI1Q8jMzgxi5OPHr-9kecHlyI_KcNsuYThWc0tgCI1JWLCg1_wkaYdETLixWpz_mA3YqzY4d90I3-fyVpA4=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 





*
*
*Webinars with Ann Rockley*
**
*Recently Recorded Webinars*

Results of the Second Annual Challenges of Creating and Managing 
Content

in Life Sciences and Healthcare Survey 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVPAoxrJqBq8BsuVDhC1MXkBPtRuVcjavHIB69fqUJQc0XInBL8j6m1OqwvcE50qH7AClNrk1L6KHec3LO3_4IfyxzAq2BCTYgMrHmQvnEj-oC8_1T6u_4umpDR5elMhfypJuzjQzmNZZH06irReDYNKwY9uEhJ6HiAzfsAyyGIPuAQbH0J9taNgHIHV87AQlvd9bRzEFqHHa1RuOIAV_DUctsI2wCR4toOjyKztJhEoLjdTD4Y1Ren2vX3ZehMrhjBScQO1s5npvjaGD4gMUa2M=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 


Localizing Regulated Content While Saving Time and Money 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVBVnHwvucfHT2zNvF1yPKz-NSvdYGJIul-7dtewqWjcn18DV-CMGgiz67VaaXrAnbGxcEphlVOUfA7iyRqmz3MJOvS60jTD9VX9GWA0F4hmIg-gVS8NhsxfPiZWO0IKTzMzMr2h12horjIiz66wAcvRqjmkzh3Wj4g==c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 


Bridging Pharma Content Silos: Managing Content from Clinical Through
Labeling and Marketing https://www.brighttalk.com/webcast/9273/146095

Possible Documentation and help solutions - DITA

[Ron Wheeler]

Anne Rockley is one of the top DITA experts and her webinars are excellent.
If you want to see how DITA could help improve the production and 
utilization of documentation for OFBiz, you might look for a webinar 
that relates to your particular concerns.


She is an expert in the pharmaceutical area but a lot of her concerns 
also apply to regulated industries or business functions that are 
regulated such as accounting (localization is a common issue).


19 June - Join Charles Cooper at ETC for his session on Software, 
Documentation and Agile Development 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVGCO8y5J0LCNrluDdwSUd4f9WqyMtVtzdU4iUvYLE8gHYaxHEp7GiHnXU91MZQlCvJQmSSxqW1qMS90KgOVj0jCZz7XUq4o8y2HrSIpCCC1pvty9zVdsbWad85_8zRNttYSNLZaji3a3c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 
sounds like something that might be relevant to us.


The Intelligent Content: What Does Reusable Mean? 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVIKcq5t7_sGa_YrYZcPP_xveuxMDyIJOq0NL2T01f13TSS56TTCCpGDrgsZf35E_GQhKjAqaQZ-eok4xWgT8JGSSCXzPYsUu-Hf0EpZ6IVS8zUiX7UVwvOA9NZFpMGb5bQnx9PgZv04uStMHJAgB1UJqa-g_s8BLBacNZSXegB5Gov7l9r-kfBIvkx4sU3NZE7di-GHeu_0mlNG7OV1QMKYJ9yF0Mqoc01uZTFw-QnQzkdObw-tX4mo=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 
blog post addresses Jacques' question about how to use a library of 
reusable content much better than I did.



Ron



 Forwarded Message 


Having trouble viewing this email? Click here 
http://campaign.r20.constantcontact.com/render?ca=fcaa0b03-86df-4c67-bf37-d645ce38f8eac=8f7153c0-e1fa-11e4-a4b6-d4ae52844279ch=8f9c3450-e1fa-11e4-a4de-d4ae52844279 






http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVIz0RR4E3aPj1d7wqoOmD03Aya0ayMj7-AgoYI1Q8jMzgxi5OPHr-9kecHlyI_KcNsuYThWc0tgCI1JWLCg1_wkaYdETLixWpz_mA3YqzY4d90I3-fyVpA4=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA== 




*
*
*Webinars with Ann Rockley*
**
*Recently Recorded Webinars*

Results of the Second Annual Challenges of Creating and Managing Content 
in Life Sciences and Healthcare Survey 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVPAoxrJqBq8BsuVDhC1MXkBPtRuVcjavHIB69fqUJQc0XInBL8j6m1OqwvcE50qH7AClNrk1L6KHec3LO3_4IfyxzAq2BCTYgMrHmQvnEj-oC8_1T6u_4umpDR5elMhfypJuzjQzmNZZH06irReDYNKwY9uEhJ6HiAzfsAyyGIPuAQbH0J9taNgHIHV87AQlvd9bRzEFqHHa1RuOIAV_DUctsI2wCR4toOjyKztJhEoLjdTD4Y1Ren2vX3ZehMrhjBScQO1s5npvjaGD4gMUa2M=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==


Localizing Regulated Content While Saving Time and Money 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVBVnHwvucfHT2zNvF1yPKz-NSvdYGJIul-7dtewqWjcn18DV-CMGgiz67VaaXrAnbGxcEphlVOUfA7iyRqmz3MJOvS60jTD9VX9GWA0F4hmIg-gVS8NhsxfPiZWO0IKTzMzMr2h12horjIiz66wAcvRqjmkzh3Wj4g==c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==


Bridging Pharma Content Silos: Managing Content from Clinical Through 
Labeling and Marketing https://www.brighttalk.com/webcast/9273/146095


Intelligently Managing the Complexities of the Core Data Sheet 
https://www.brighttalk.com/webcast/9273/146091



*Upcoming Events and Presentations*

*LocWorld 28 - Localization World 2015 in Berlin, Germany*

03 June - Join Ann Rockley and others for the Life Sciences Business 
Roundtable 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVGCO8y5J0LCNKkQku0rPdubcmGs9xZj-nU756cGD8h9GUq0niuPwDarZHhfLSyhyXG-TwKft5pJ4gYmRgftjttrmcQ_Pdb-g1syVUc4058f35z53DcsvP_-BV25Cw1yUYd2db4QnPe1d0JsoaDXGKTxnkedl-GtzB6zLwWhkZWerXTd1OF3vk8PXHCuojL_CRQ==c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==



04 June - Join Charles Cooper for his session on Content Strategy for 
Advanced Display and Localization 
http://r20.rs6.net/tn.jsp?f=001R3KFEYl9u4YXuWSn36IeeWypLQwhAjSruFHWEtyCLXWNyrGpgLHuVGCO8y5J0LCNCF4PQ26RGO5CT9b3f8FCBu3Ad8g5NgJ1Wq0YvckiFbP-1E3Zk43gAtqvYyyc4Sn7jTNAExWoQr69qY3NtkXYc-CQb5kHBUUdTpvzi3Yq6hZrB_tlzuVdIzmSkpuNJHI_bDkj0cDMbQ_m2Uf8NyYA4wl0Cnool6NQvhwGmNHaxSTh2MYNjh4Y5P7hPG96nxQDbDjZYeualr8=c=ji_CL3u5I7wrq8E-36UYX-p1saH9RZwBYzb34hER04NnWuVlGp420g==ch=tgy69stNq6UApiTWE6T_W92FpfW1afoA1FjL-2Y35bbnhPW-qnWbDA==


04 June - Join Charles Cooper, Diana Ballard, Laurence Dansokho and 
Michael Rosinski for Smart Products and Connected Devices Require 
Intelligent Localized Content 

Framework Architecture

[Ron Wheeler]

If there is an interest in redoing the framework or upgrading it or 
changing the base technology and the application interface, perhaps this 
is something that should be investigated to see if it simplifies the 
process and adds an optimization layer that we don't have to write.


Ron


 Forwarded Message 
From:   - Mon Jun 01 11:37:38 2015
X-Account-Key:  account4
X-UIDL: 0010f909471c11b5
X-Mozilla-Status:   0001
X-Mozilla-Status2:  
X-Mozilla-Keys: 
Return-Path: 
announce-return-2677-rwheeler=artifact-software@apache.org

X-Original-To:  rwhee...@artifact-software.com
Delivered-To:   rwhee...@artifact-software.com
Received: 	from localhost (localhost.localdomain [127.0.0.1]) by 
smtp.artifact-software.com (Postfix) with ESMTP id 1D40F6A657F for 
rwhee...@artifact-software.com; Mon, 1 Jun 2015 11:34:50 -0400 (EDT)

X-Virus-Scanned:amavisd-new at artifact-software.com
Received: 	from smtp.artifact-software.com ([127.0.0.1]) by localhost 
(smtp.artifact-software.com [127.0.0.1]) (amavisd-new, port 10024) with 
ESMTP id HyInAOj1ZKaX for rwhee...@artifact-software.com; Mon, 1 Jun 
2015 11:34:48 -0400 (EDT)
Received: 	from mail.apache.org (hermes.apache.org [140.211.11.3]) by 
smtp.artifact-software.com (Postfix) with SMTP id D7AFA6A657E for 
rwhee...@artifact-software.com; Mon, 1 Jun 2015 11:34:47 -0400 (EDT)

Received:   (qmail 36279 invoked by uid 500); 1 Jun 2015 15:34:37 -
Mailing-List:   contact announce-h...@apache.org; run by ezmlm
Precedence: bulk
List-Help:  mailto:announce-h...@apache.org
List-Unsubscribe:   mailto:announce-unsubscr...@apache.org
List-Post:  mailto:annou...@apache.org
List-Id:announce.apache.org
Delivered-To:   mailing list annou...@apache.org
Delivered-To:   moderator for annou...@apache.org
Received:   (qmail 39773 invoked by uid 99); 1 Jun 2015 06:47:06 -
MIME-Version:   1.0
X-Received: 	by 10.202.218.132 with SMTP id 
r126mr15814831oig.69.1433141224794; Sun, 31 May 2015 23:47:04 -0700 (PDT)

Date:   Sun, 31 May 2015 23:47:04 -0700
Message-ID: 
CAPSgeESugYSqTQ=P=v69epreed+3soteq4o6ws0jtyk+8cg...@mail.gmail.com

Subject:[ANNOUNCE] Apache Calcite 1.3.0 (incubating) released
From:   Julian Hyde jh...@apache.org
To: annou...@apache.org
Cc: d...@calcite.incubator.apache.org
Content-Type:   multipart/alternative; boundary=001a113d5dfa9df0c805176f3127



The Apache Calcite team is pleased to announce the release ofApache 
Calcite 1.3.0 (incubating).
Calcite is a dynamic data management framework. Its cost-basedoptimizer 
converts queries, represented in relational algebra,into executable 
plans. Calcite supports many front-end languagesand back-end data 
engines, and includes an SQL parser and theAvatica JDBC driver.

The release is available here:
http://www.apache.org/dyn/closer.cgi/incubator/calcite/apache-calcite-1.3.0-incubating/
and the release notes here:
http://calcite.incubator.apache.org/docs/history.html#v1-3-0
We welcome your help and feedback. For more information on how toreport 
problems, and to get involved, visit the project website at

http://calcite.incubator.apache.org
(We just revised the website. Hope you like the new look!)
Julian Hyde, on behalf of the Apache Calcite Team

Disclaimer: Apache Calcite is an effort undergoing incubation at 
TheApache Software Foundation (ASF), sponsored by Apache 
Incubator.Incubation is required of all newly accepted projects until a 
furtherreview indicates that the infrastructure, communications, and 
decisionmaking process have stabilized in a manner consistent with 
othersuccessful ASF projects. While incubation status is not necessarily 
areflection of the completeness or stability of the code, it 
doesindicate that the project has yet to be fully endorsed by the ASF.

Framework Architecture

[Ron Wheeler]

If there is an interest in redoing the framework or upgrading it or 
changing the base technology and the application interface, perhaps this 
is something that should be investigated to see if it simplifies the 
process and adds an optimization layer that we don't have to write.


Ron


 Forwarded Message 

The Apache Calcite team is pleased to announce the release ofApache 
Calcite 1.3.0 (incubating).
Calcite is a dynamic data management framework. Its cost-basedoptimizer 
converts queries, represented in relational algebra,into executable 
plans. Calcite supports many front-end languagesand back-end data 
engines, and includes an SQL parser and theAvatica JDBC driver.

The release is available here:
http://www.apache.org/dyn/closer.cgi/incubator/calcite/apache-calcite-1.3.0-incubating/
and the release notes here:
http://calcite.incubator.apache.org/docs/history.html#v1-3-0
We welcome your help and feedback. For more information on how toreport 
problems, and to get involved, visit the project website at

http://calcite.incubator.apache.org
(We just revised the website. Hope you like the new look!)
Julian Hyde, on behalf of the Apache Calcite Team

Disclaimer: Apache Calcite is an effort undergoing incubation at 
TheApache Software Foundation (ASF), sponsored by Apache 
Incubator.Incubation is required of all newly accepted projects until a 
furtherreview indicates that the infrastructure, communications, and 
decisionmaking process have stabilized in a manner consistent with 
othersuccessful ASF projects. While incubation status is not necessarily 
areflection of the completeness or stability of the code, it 
doesindicate that the project has yet to be fully endorsed by the ASF.

Re: Discussion: Replace framework by Moqui.

[Ron Wheeler]

Is the some reason to use CC0 rather than Apache?

Ron

On 22/05/2015 5:08 PM, David E. Jones wrote:

On 22 May 2015, at 11:29, David E. Jones d...@me.com wrote:



On 21 May 2015, at 06:28, Ron Wheeler rwhee...@artifact-software.com wrote:

I am not a lawyer and Apache's legal team should be approached before we embark 
on a plan that involves the use of a third party tool that does not have an 
Apache license or a license that is known to be compatible with inclusion in an 
Apache product.

At the moment, from my reading of the source that Jacques found, it would not 
be possible to release a Moqui-based framework under an Apache license.
Moqui is in a no-man's land where your right to use it depends on what country 
you are in and unless you are the owner, it is not clear how your can 
redistribute it internationally.
If we write a layer to go between Moqui and the OFBiz components to replace the 
framework, users would have to decide if they could legally run Moqui and would 
have to go get it on their own and install it separately.

For the moment my preference would be to focus on getting the current framework into a 
separate sub-project, clean up the current dependency issues, document it and release it 
as a separate deliverable with an Apache license and its own roadmap and 
marketing plan.

That is based on assertions from knowledgeable people in this project that it 
is valuable on its own for others who want to develop other sorts of business 
applications.

Even if Moqui is a better framework technically, the Apache license would make 
the Apache OFBiz Framework a more desirable product for an organization wanting 
to invest in creating an application.

This is a straw man argument, doesn’t seem to apply to actual public domain 
“licensing” at all.

Software in the public domain has far fewer restrictions than the Apache 2 
license, simpler legal terms, and exists under a well established legal 
framework, one that has been around for centuries and remains largely unchanged 
by the continually shifting sands of copyright law around the world. It is true 
that some jurisdictions have limits on which authors rights can be disclaimed, 
licensed, or transferred but that applies to ALL copyright licenses including 
open source and commercial ones, and to clarify for different jurisdictions is 
handled by specific wording in headers and LICENSE files, such as:

https://github.com/moqui/moqui/blob/master/LICENSE.md

The best source for general information about the concept and legal specifics 
is:

http://unlicense.org

I appreciate your comments Ron. I looked into this a little more and found that 
there appear to be certain jurisdictions (though I can’t find any references 
about which…) don’t recognize public domain status and for this reason the CC0 
public domain attribution has alternate terms for such jurisdictions (making it 
an improvement over the unlicense.org legal wording):

http://creativecommons.org/publicdomain/zero/1.0/

I’ve updated the Moqui/etc files to use CC0 instead of unlicense.org.

This should clarify any questions or doubts about the licensing and public 
domain status of Moqui/etc. On the topic of legal clearance (in this case 
copyright waiver, somewhat like the Apache CLA) I’m also putting in place 
AUTHORS files signed by git commit. There are only a small number of 
contributors other than me, but this will help establish a more firm legal 
position.

-David






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Discussion: Replace framework by Moqui.

[Ron Wheeler]

I think that you can restate some of the benefits into a value proposition.

I just don't think that benefits cited turn into a value proposition 
that is worth the effort.


The uncertainty about the legal aspects of using a product with no 
ownership or license regime must be resolved before spending effort on 
any technical ideas.


In the short term, I am not sure if there is any urgency to replacing 
the Framework.
Fixing the blur between the components and the framework is more of an 
urgent issue.


Once the Framework turns into a product (if it does), the team looking 
after the framework could revise the value proposition and deal with the 
licensing as a product management issue based on the Framework's 
position in the framework market.


Ron

On 21/05/2015 10:14 AM, Taher Alkhateeb wrote:

Hi everyone,

I spent some time reading through this thread again. I read the advantages of 
adopting moqui especially those mentioned by David Jones including:
- smaller cleaner code base
- simplified security
- RESTful services
- elastic search
- easier learning curve for new comers
- pure service layer instead of object/service hybrid
- simpler order logic as the shopping cart resides in the database
- there is probably more!

I also read some of the objections including backward incompatibility, huge 
effort, dependency risk and so on.

But I didn't find anywhere in this thread the _value proposition_ for this 
move. In other words, what value are we providing if we give ofbiz+moque 
instead of moqui alone? Why would people choose the ofbiz+moqui solution and 
not just switch to moqui? I wasn't at the ApacheCon which started this thread 
so maybe I'm missing something?

Taher Alkhateeb

- Original Message -

From: Ron Wheeler rwhee...@artifact-software.com
To: dev@ofbiz.apache.org
Sent: Thursday, 21 May, 2015 4:28:52 PM
Subject: Re: Discussion: Replace framework by Moqui.

I am not a lawyer and Apache's legal team should be approached before we
embark on a plan that involves the use of a third party tool that does
not have an Apache license or a license that is known to be compatible
with inclusion in an Apache product.

At the moment, from my reading of the source that Jacques found, it
would not be possible to release a Moqui-based framework under an Apache
license.
Moqui is in a no-man's land where your right to use it depends on what
country you are in and unless you are the owner, it is not clear how
your can redistribute it internationally.
If we write a layer to go between Moqui and the OFBiz components to
replace the framework, users would have to decide if they could legally
run Moqui and would have to go get it on their own and install it
separately.

For the moment my preference would be to focus on getting the current
framework into a separate sub-project, clean up the current dependency
issues, document it and release it as a separate deliverable with an
Apache license and its own roadmap and marketing plan.

That is based on assertions from knowledgeable people in this project
that it is valuable on its own for others who want to develop other
sorts of business applications.

Even if Moqui is a better framework technically, the Apache license
would make the Apache OFBiz Framework a more desirable product for an
organization wanting to invest in creating an application.

Ron


On 21/05/2015 4:49 AM, Scott Gray wrote:

Advance cast of -1 in case I miss the vote if it ever comes.

Moqui is it's own eco-system. The only way to replace the framework with
Moqui is to rewrite the apps to be moqui apps. If that was done, what
does it have to do with OFBiz@Apache? We could rename the project to Apps
for Moqui and become application curators and essentially be a different
project. But what's the point of doing that here rather than over at
moqui? (wherever at moqui is)

The work I think Adrian is suggesting is introducing Moqui as some sort of
hybrid into OFBiz until we can phase out the OFBiz framework completely.
To me that seems like a convoluted way to go instead of just rewriting the
apps.

Regards
Scott

On 27 April 2015 at 02:11, Jacopo Cappellato 
jacopo.cappell...@hotwaxsystems.com wrote:


On Apr 26, 2015, at 3:09 PM, Adrian Crum 
adrian.c...@sandglass-software.com wrote:


How about Replace framework core functionality - like entity engine,

service engine, and security with Moqui.

Is that specific enough?


Not really: we have talked about bringing the whole Moqui codebase into
the OFBiz trunk (bad idea in my opinion), or migrating the applications to
Moqui, or reimplementing them and the sentence above doesn't specify a
direction.
And why entity engine, service and security and not for example
transaction management, connection pooling, ui technology, logging etc...?

Jacopo


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/26/2015 1:47 PM, Jacopo Cappellato wrote:

The discussion is interesting and fascinating but in this thread

completely different ideas have