Re: [VOTE] Create the "security" mailing list for the OFBiz project

[David E. Jones]

+1

-David


> On 24 Jul 2016, at 05:32, Jacopo Cappellato 
>  wrote:
> 
> Rationale: every ASF project needs a private list to discuss product
> vulnerabilities; for OFBiz the "private" list has been used for this
> purpose until now; however an ad-hoc list may be useful because it could
> provide a more focused space to discuss the security issues and could
> provide more flexibility to invite in the private list persons willing to
> help that are trusted by the PMC.
> 
> Please vote,
> 
> +1
> 
> to create a "security" list (i.e. secur...@ofbiz.apache.org) and move all
> the security related discussions and notifications currently happening on
> the private list to this new list: according to the ASF policies [*] the
> list will be a private list used by the persons willing to help to resolve
> security issues; the list of subscribers will be approved by the OFBiz PMC.
> 
> Otherwise vote -1 to continue to use the "private" mailing list for
> vulnerability handling.
> 
> [*] http://www.apache.org/security/

Re: [VOTE] Create a "notifications" mailing list

[David E. Jones]

+1

-David


> On 24 Jul 2016, at 05:59, Jacopo Cappellato 
>  wrote:
> 
> Rationale: Jira notifications are currently sent to the "dev" list, causing
> a lot of traffic and sometimes distracting from actual conversations; the
> creation of a "notification" email (similar to the "commits" mailing list)
> will solve this problem; in the future we may vote to use the
> "notification" list to host traffic coming from buildbot etc... thus the
> proposal for naming it "notifications" rather than just "issues"; however
> this vote is only about traffic from Jira (we will discuss if we want to
> extend the usage of this list in the future).
> 
> Please vote,
> 
> +1
> 
> to create a "notifications" mailing list (i.e.
> notificati...@ofbiz.apache.org) and redirect to it all the traffic coming
> from Jira notifications.
> 
> Otherwise vote -1 to continue to use the "dev" list for Jira notifications.

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

[David E. Jones]

Some thoughts inline...


> On 24 Oct 2015, at 07:59, Sharan-F  wrote:
> 
> *What do we want to Achieve?*
> We had previously reviewed Adrian’s documentation   Initial Framework Vision
> Document
>   
> and  Initial Framework Design Document
> 
>   
> , and agreed during the meeting that this would be a good starting base for
> us. In this proposed subproject we would like to implement a framework that
> would initially comprise as follows:
> 
>   •   Configuration.
>   •   Globalization (locale, time zone, currency).
>   •   Logging.
>   •   Security (authentication/authorization).
>   •   Actor Management (profiles, roles - required for security; Actors -
> people, external services) Think of UML Actor. Required to remove dependency
> on Party

Is this just the user concept, or something bigger? In a framework, IMO, there 
is no need for the “Party” concept, but the user concept for authc/authz is 
critical.

Some side notes: Apache Shiro may be very useful in OFBiz for authentication 
and generic authorization, and I’d highly recommend looking at the 
artifact-aware authorization concept in Moqui for inheritable authz specific to 
screens, services, entities, etc. It is hugely useful for have this 
configurable external to the screens, services, etc themselves… much more 
flexible and simplifies code.

>   •   Persistence (file system or database).

This seems a little broad, files are very different in nature from database 
records (assume relational DB referred to here, like the Entity Engine).

A file/resource interface can be backed by a filesystem, content repository, or 
even database tables that mimic the structure of a filesystem with DB records. 
For example see the ResourceFacade and ResourceReference in Moqui:

http://www.moqui.org/javadoc/org/moqui/context/ResourceFacade.html
http://www.moqui.org/javadoc/org/moqui/context/ResourceReference.html

Because a relational database is used so much a special interface to it is well 
worth the effort (like the Entity Engine). There are interfaces for this in 
Moqui, but no need to reference them here as the generic concept is the same 
(even if the API and design is very different).

One thing I would recommend for the new API is a find object instead of all the 
find methods on the delegator, ie something like:

http://www.moqui.org/javadoc/org/moqui/entity/EntityFind.html

It might be interesting to look at a generic interface for NoSQL databases like 
document, graph, etc DBs. However, the APIs for these are far less consistent 
than for relational databases so it is very difficult (impossible?) to design a 
generally useful interface, ends up being the least common denominator of the 
various underlying DBs.

>   •   Lang package to provide classes that are fundamental to the framework

This is an area where OFBiz has a lot of room for improvement, and by 
improvement I mean getting rid of dozens of utility classes and using existing 
open source libraries instead.

>   •   Services.
>   •   Runtime management

What does Runtime management mean?

There are some key things missing for an adequate framework to replace the one 
in OFBiz, including:

- User Interface

How will screens and forms be implemented? How are they mapped to web requests? 
There is a lot of room for improvement in OFBiz here. Having to use a bunch of 
files and such for a single screen is a pain (controller request and view, 
screen, form, menu, tree, etc… often have 3-4 files open when working on a 
single screen). There is also no concept of a screen hierarchy (which is very 
useful) in OFBiz, just a flat list of supported requests.

- Integration (and non-UI web)

This might start with using something like Apache Camel, but also needs 
framework support for handling incoming integration web requests that may tie 
to entity or service operations, etc.

- Caching

Even if this is backed by something like Ehcache it may be nice to have a 
framework interface for using and managing caches.

- Transaction Management

Transactions are useful for more than just DB operations, but even with just DB 
stuff it is useful to make it easier to handle things like synchronizations 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 

Re: Why A Framework Rewrite Is Necessary

[David E. Jones]

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 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…
>>> 
>>> And this could also be called a logical fallacy. But let us not make it
>> into a pissing contest again, like we had in the past regarding the
>> opposing viewpoints on this.
>> 
>> 
>>>> Also keep in mind t

Re: Why A Framework Rewrite Is Necessary

[David E. Jones]

> On 16 Oct 2015, at 01:41, Pierre Smits  wrote:
> 
> I understand the reluctance of the community, because the impact will be
> huge. When looking at the data in OpenHub I see OFBiz having an estimate
> effort spend of 519 person years vs 6 for the combined
> Moqui-Mantle-HiveMindPM-PopCommerce suite. And one of the reasons behind it
> is simple: Many more have worked on OFBiz (from day 1) than on the Moqui
> suite. One could even argue that both directions took the same number of
> years in duration to get where they are now. Without all the experiences
> regarding the OFBiz product there couldn't have been an evolution called
> the Moqui suite.

Quick note on this: the OpenHub stats for Moqui are messed up somehow, ie the 
code analysis is messed up showing around negative 21k lines of code (the real 
number is around 60k lines of code, 75k lines of text), so the COCOMO estimate 
is way off.

That said, for the same functionality fewer lines of code is easier to maintain 
and IMO OFBiz could do a lot better in this respect, ie the same functionality 
in probably 20-25% of the lines of code. There is a lot of unused an 
inefficient code in OFBiz, and overall it would be more valuable if the code 
size were smaller (not so much to end users, but to contributors, committers, 
customizers, etc).

Your point about Moqui not being possible without OFBiz is absolutely true. 
Most of the ideas for early versions of Moqui/Mantle came from OFBiz and in 
fact it was the ever growing list of things that would be really nice in OFBiz 
that were the impetus for even starting Moqui/Mantle/etc.

OFBiz itself has huge value as it is, even if there is big room for improvement 
and innovation. Unfortunately there are barriers to that as well, including 
backward compatibility which for many cleanups and innovations just has to go. 
That is why this discussion of a fresh implementation of the framework in OFBiz 
is a big step.

More comments on that in another reply… the idea of defining an API and XSDs 
for the various XML files as a first step to a fresh framework implementation 
is a very good one.

-David

Re: Why A Framework Rewrite Is Necessary

[David E. Jones]

> On 15 Oct 2015, at 18:48, Scott Gray  wrote:
> 
> By the way, I'm surprised I haven't seen any efforts within the Moqui
> community to rewrite any of the OFBiz apps.  I don't have any ideas as to
> why that hasn't happened, but I'm curious about it.  Surely it would be
> easier for the Moqui community who already know the framework and are
> probably also familiar with OFBiz to try this than us.

This I can comment on. The business level data model in Mantle Business 
Artifacts (separate from Moqui Framework) is very different from the one in 
OFBiz. It is not only the framework that has room for cleanup and enhancement, 
but the data model, services and UI as well.

The data model and services in Mantle are now on par or more advanced that 
similar parts of OFBiz in many areas, though there are still various areas of 
business functionality supported in OFBiz that are not yet supported in Mantle 
services and such. Overall Mantle is being built in the context of very 
different contracts than early OFBiz, more ERP oriented in general, which is 
why certain things like payroll exist in Mantle but never were implemented in 
OFBiz. As strange as it may be (and really not my preference), the initial 
standards based in integrations in Mantle are for various EDI X12 messages as 
opposed to the OAGIS ones in OFBiz (I still like that standard MUCH more and 
plan to build around it eventually… but contracts do set priority, especially 
for larger efforts like that).

The UI layer in the HiveMind (ERP and project management for service orgs) and 
POP Commerce (ERP and ecommerce for retail and wholesale) are also being built 
from scratch, and now in the hundreds of screens.

The goal has always been to start from scratch with Moqui/Mantle/etc, based on 
many of the ideas and patterns that emerged over time in OFBiz. As for the 
application structure, and even screen designs, in OFBiz: they could be much 
better. Without customization and enhancement so many business processes are 
left hanging with no UI to complete them (though sometimes there are services 
in place). The menu structure and such is also little short of painful, and in 
all larger OFBiz based projects I’ve been on the application level has been 
redesigned and rewritten, to a lesser or greater extent reusing 
screens/forms/etc from the OOTB OFBiz apps.

Even as open source contributors with limited time and resources, we can do 
better. OFBiz can be much more usable than it is now, the potential is there. 
In the mean time, I’ll admit there are other applications I take more 
inspiration from than OFBiz, on the UI level at least. On the data model and 
service/logic level there is a lot of inspiration to be taken from OFBiz, even 
if there is a lot of room for improvement (doing much more with much less code, 
and much more flexibly too).

A framework rewrite may make things more efficient, easy, and clean in OFBiz, 
but there is a lot of room for improvement in the data model, logic, and UI 
layer implementations as well. Those sorts of changes can be done maintaining 
backward compatibility, and without starting over. 

The accounting in OFBiz is close to adequate to run a business on, but not 
there in various painful ways that I’ve been through with many clients. The 
order processing based on the ShoppingCart* objects is abysmal… inflexible and 
unnecessarily complex. What a revolution in OFBiz? Kill the ShoppingCart* 
objects, move all the logic to services, and keep cart state in the database 
instead of session objects. The menu structure in so many applications, and 
accounting may be the worst of them, is painful and confusing at best. I still 
see some of the bad decisions I made over a decade ago persisting there.

Yes, I know these because they are my sins, my early mistakes… and I gave up on 
atoning for them as part of OFBiz. Whatever Adrian says, be careful of his 
comments and direction, he is a big part of the reason I gave up improving 
things in OFBiz itself.

-David

Re: Why A Framework Rewrite Is Necessary

[David E. Jones]

> On 15 Oct 2015, at 07:58, Adrian Crum  
> 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 
>> 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
>>> >> 
 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 

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

 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

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

 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

-David

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

Thank Scott… my thoughts are largely along these lines and have been for some 
time: why migrate OFBiz data model, service, and applications to Moqui 
Framework when there is also an opportunity to clean up the data model, 
services, and make the applications more usable OOTB and more targeted to 
specific sorts of organizations?

My main reason for supporting an OFBiz migration toward Moqui Framework (and 
not including Mantle, etc) would be based on interest within the OFBiz 
community. There is some justification for sticking with the same data model, 
etc even with a different underlying framework so that the upgrade path for 
current OFBiz users is easier. However, I think the number of people interested 
in or needing such a thing is pretty limited, not likely to result in a 
collaborative open source effort of a sufficient scale.

-David


 On 21 May 2015, at 01:49, Scott Gray scott.g...@hotwaxsystems.com 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 been expressed: from forking Moqui into
 OFBiz to rewriting OFBiz applications from scratch on top of Moqui etc...
 
 My vote will be negative if the vote will be as generic as replace
 OFBiz framework with Moqui is because it would not be an actionable item
 and there could be 1000 totally different ways to implement it.
 
 Jacopo
 
 
 On Apr 26, 2015, at 1:58 PM, Adrian Crum 
 adrian.c...@sandglass-software.com wrote:
 
 This has been discussed for nearly a week now. Shall we start a vote?
 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com
 
 On 4/20/2015 6:31 AM, Hans Bakker wrote:
 Again, as discussed at the ApacheCon in Austin we should start setting
 up a plan how to best move the ERP application to the Moqui framework.
 Moqui should not be part of the Apache foundation however the ERP
 application should remain there.
 
 Not only will it improve development of the ERP system but also will
 establish a clean separation between application and frameworks and
 hopefully getting David Jones back into the project.
 
 Yes, I realize i open the pandora box :-) but we need to make some
 major
 decisions
 
 Regards,
 Hans Bakker
 antwebsystems.com
 
 
 
 
 

Re: VOTE RESULT: Begin Replacing OFBiz Framework With Moqui

[David E. Jones]

This doesn’t seem to represent the responses very well. My vote shouldn’t be 
considered a +1 unless my interpretation of the proposal (as a PoC in a branch) 
was correct, and I saw no comment on that… in fact from this message it seems 
that is explicitly NOT what the vote was supposed to be about based on the 
comment that doing a PoC in a branch requires no vote.

Overall the vote proposal and discussion thread was very confusing, I don’t see 
how you could get any sort of vote count out of it… most people replied with 
multiple votes with different clarifications!

This VOTE RESULT never should have been done, the vote should simply have been 
cancelled or reframed.

-David


 On 30 Apr 2015, at 00:55, Adrian Crum adrian.c...@sandglass-software.com 
 wrote:
 
 Here is the tally of the votes. This was a challenge because many replies 
 included votes for other things, so this tally represents my best effort at 
 counting votes for the original subject.
 
 PMC Members (Binding)
 -
 +0 | 2  (Adam Heath, Jacques Le Roux)
 +1 | 1  (David Jones)
 -1 | 3  (Nicolas Malin, Scott Gray, Jacopo Cappellato)
 
 
 Others (non-Binding)
 
 +0 | 1  (Adrian Crum)
 -1 | 2  (Ron Wheeler, Martin Becker)
 
 The vote failed to pass with 3 -1 votes and 1 +1 vote.
 
 The replies included a discussion about creating a POC branch to explore the 
 subject further. That can be done without a vote, so I will consider this 
 vote closed.
 
 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com
 
 On 4/26/2015 3:44 PM, Adrian Crum wrote:
 As was discussed last week, there is some interest in replacing some (or
 all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html).
 
 To the scope reasonable, I propose that we begin by converting the
 following parts of the OFBiz framework with Moqui:
 
 Entity Engine
 Service Engine
 Security
 
 Other parts of the OFBiz framework could be converted as well, but I
 think this would be a good starting point, and if is successful, then
 more of OFBiz can be converted later.
 
 I believe we can create a thunk component to help solve compatibility
 problems, but that is a separate discussion. I only mention it here in
 case compatibility concerns might influence a vote.
 

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

[David E. Jones]

 On 30 Apr 2015, at 05:31, Ron Wheeler rwhee...@artifact-software.com wrote:
 
 My point was about the suggestion that you might want to add it as a TLP in 
 ASF but there were concerns about the amount of effort to start an ASF 
 project.

For Moqui Framework as an ASF project my concern really isn’t about the effort 
required, it would be WAY easier than when OFBiz went through the incubator. My 
concerns are about the community management approach, the forced growth of the 
community to graduate from the incubator (leading to hurried and possibly bad 
decisions about who to include as committers and PMC members), the ASF 
trademark policy and it’s use to go beyond what the Apache 2 license requires 
using trademarks as another channel for legal threats, the infrastructure 
constraints, and so on.

The main benefit to joining the ASF: branding. It is a HUGE taboo to even say 
such a thing (and in the incubator proposals they want an ack that this is NOT 
a reason for joining the ASF), but it is the reality. For OFBiz the main 
benefit we've seen over time, IMO, had nothing to do with the oversight or 
community structure or infra or anything legal, but just having the Apache name 
on the project to boost confidence in the software. The irony is that the ASF 
has no policies related to software quality, but this is the public perception, 
helped along by no shortage of public statements by many people involved with 
the ASF. Maybe it’s more acceptable to say the ASF community model leads to 
higher quality software, that’s the general mantra anyway, but compared to 
other models I haven’t found that to be especially true.

The ASF approach has it’s place and it’s great for certain types of software, 
but IMO is too inflexible for greater innovation to happen which is why most 
ASF projects start outside the ASF and join the foundation after reaching a 
certain point of maturity, and mostly by companies wanting to grow a community 
around a piece of software to reduce maintenance and support costs. That isn’t 
a bad thing, such software tends to do very well long term!

-David

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

[David E. Jones]

 On 29 Apr 2015, at 00:41, Jacques Le Roux jacques.le.r...@les7arts.com 
 wrote:
 
 I was rather reluctant about this but after the PoC concept has been 
 introduced by several persons and reading  the last exchange between Adam and 
 David (where David said with the clarification that to me begin replacing 
 implies a PoC effort in a branch) I sort of changed my mind, unlike Nicolas 
 I will not vote -1 but 0.
 
 Like him I don't like the idea of plugging Moqui jars in OFBiz. On the other 
 hand I understand Moqui is open source and everybody has access once a Github 
 account is created hence 0 and not -1. It's still not a +1 because this adds 
 extra complexitiy (2 repos, 2 set of tools, how to communicate, etc.) I don't 
 like much :/

Moqui Framework IS a separate project, more or less like any other JAR or set 
of JARs included in OFBiz. It would always be maintained separately. If you 
think of using Moqui as adding another repo, that’s strange… like saying that 
OFBiz is currently split across dozens of repositories, one for each other open 
source project used in OFBiz.

Also keep in mind that there are other applications, both open source and 
commercial, based on Moqui. The ecosystem around Moqui and the applications 
around it are what have driven it to the point where it is now, and whether or 
not OFBiz uses Moqui all of that will continue.

 David mentioned  There is a chance Moqui Framework could become a separate 
 ASF project, though the name Apache Moqui is oddly contradictory  I guess 
 still using Git as preferred commit medium (but as said Jacopo with anyway 
 Svn as ultimate repo at the ASF). David also said he would prefer  the 
 distributed and moderated approaches used in the Linux kernel more than the 
 community approach mandated by the ASF. which I believe was David's main 
 concern when he created Moqui.
 
 That's could seem contradictory with ASF policy but remember that each 
 project can define its own policy. Personnaly I don't see a problem with 
 that, I trust David not wanting to become a benevolent dictator, he many 
 times always proved to simply want the best for the OFBiz project. Mixed with 
  I would rather let people come along, express interest, and thoroughly 
 prove merit before they take on such a role.  I understand that a Moqui 
 podling would be created without direct connection with OFBiz committers.
 
 It's certainly too early to get conclusions about having 2 separate projects 
 working together (in ASF or not), but I can already see some concerns
 
 If we introduce Moqui in OFBiz we can't avoid to speak about the 2 diverging 
 ways of doing things at the UI level. Though I have not used Moqui I believe 
 it is more flexible for this aspect, but again this add complexity. I know we 
 are speaking about that yet, just saying, because if the PoC works it's the 
 next step.
 
 Sorry for the long and confusing post, it's hard to explain what I feel 
 better.

This is the crux of the discussion for OFBiz: how much of the development 
approach driven by the framework do you want to change? Do you want to continue 
doing things the same way or look at alternative approaches that might be 
better (cleaner application artifacts, easier customization, better security, a 
wider variety of tools, more efficient development)?

You mentioned above the community structure as my main reason for creating 
Moqui… it is partly true in that it is the reason I chose to do it as a 
separate project and not an ASF project. However, the real reason was 
continuing to explore some of the principles that went into the design of the 
OFBiz Framework and taking them to the next level… including significant 
cleanups and modernization that the OFBiz Framework needs badly.

My list of desired changes to OFBiz (after nearly a decade) got more and more 
into things that would have required dramatic refactoring and breaking 
backwards compatibility in MAJOR ways. After trying a bit within OFBiz it 
became obvious that was impossible, and would have been extremely inefficient 
in terms of the time required. Doing it as a separate project solved that.

The real question behind this vote is: how do you want to do things in the 
future? If it is similar to how things are done in Moqui then it’s there for 
you to use. If you like the OFBiz framework tools as they are, then there’s no 
reason to even consider it.

-David

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

[David E. Jones]

 On 29 Apr 2015, at 08:01, Ron Wheeler rwhee...@artifact-software.com wrote:
 
 What is the reason not to absorb Moqui or a fork of Moqui into OFBiz if we 
 decide to replace the existing framework with Moqui.
 
 Is there a reason to have Moqui as a separate Apache project? Seems like 
 extra overhead for no advantage.

Moqui is already a separate project. The OFBiz community could certainly create 
a fork of Moqui and change whatever is desired (though that shouldn’t be 
necessary), but Moqui Framework is already a separate project with its own 
ecosystem of business artifacts and applications. That won’t ever change, Moqui 
will always be a separate project.

-David

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

[David E. Jones]

 On 28 Apr 2015, at 07:42, Adam Heath doo...@brainfood.com wrote:
 
 
 On 04/28/2015 03:39 AM, David E. Jones wrote:
 +1 - with the clarification that to me begin replacing implies a PoC 
 effort in a branch.
 
 
 I just saw this thread and need a little time to think over the best 
 approach, but off the top of my head it would look something like:
 
 - add the moqui-framework-version.jar file and all dependent jars to a 
 component directory under ofbiz/framework (these could go in the base or 
 common components, but might be best separate for clarity); if needed update 
 jars currently used in OFBiz where an older version is used (don't know if 
 this is the case for any, mention for the sake of completeness)
 
 There are 2 separate items in this bullet point.  I'll talk about the second, 
 updating jar versions.
 
 HAHAHAHAHAHAHA!
 
 I have discovered that ofbiz is using hc.apache.org(HttpClient), and 
 commons-httpclient.  The former is the newer, rewritten, rearchitected, 
 replacement for the latter.
 
 The rest of the versioned jars are just as bad.

Sounds like a small project of its own...

 - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui 
 uses this for various things); this would contain the Moqui tools components 
 (with the Tools and System apps) so we have a UI to look at Moqui internals, 
 OFBiz data, etc
 
 Do each of the separate moqui sub-tools need their own runtime folder?  How 
 difficult would it be to have $OFBIZ_HOME/runtime/$tool1, runtime/$tool2, etc?

The Moqui runtime folder is similar to the one in OFBiz with component 
directories, and framework specific directories for classes, conf, db, 
elasticsearch, lib, log, template, and txlog. The Derby DB files go under the 
db directory (similar to in OFBiz) and the same is true for the Elasticsearch 
files (if you are running an embedded ES node with local storage).

Some of these Moqui needs as separate folders, some can be combined with OFBiz 
ones, like the Derby and log dirs.

 - either in the Moqui runtime directory or as an OFBiz component add a 
 webroot webapp; Moqui is designed to run in a single webapp, and I'd 
 recommend this be separate from the existing OFBiz webapps for now; when 
 this webapp loads it will init the Moqui ExecutionContextFactory, when it 
 shuts down it will destroy it
 
 Wait.  The webapp initializes the context factory?  There isn't a separate 
 way to do this?  Does that mean Moqui is tied to a webapp? What kind of 
 webapp?  I hope it isn't servlets.
 
 You mention it as weboot.  Does that mean it runs at the root of the 
 webserver?  This might be a noob question.

Moqui is designed to facilitate deployment as a single WAR file. The Screen 
definitions in Moqui live in an hierarchy and you can add the root screen of 
each of your apps under the /apps screen, or under the root screen if you don’t 
want the /apps screen decorations. There are other ways to deploy it, like the 
static init approach mentioned below, but for most use this is by far the 
easiest. There is even support to add the runtime directory to the WAR file 
which gets picked up automatically when present, making it possible to throw 
the whole thing into one big WAR file and drop it into Tomcat or upload it to 
AWS ElasticBeanstalk or the myriad of similar hosting options.

 - because initializing Moqui when the webroot webapp starts may not be 
 adequate, make sure the Moqui static init stuff is in place and working (in 
 the Moqui.java class)
 Ah.  So that means that means that moqui-component needs a container 
 definition.  Ignore the above then.
 
 I have never liked that ofbiz startup delays initialization of certain 
 components until they are magically called from some random bit of java code, 
 aka, the web container starting up.

Even though Moqui has a real init/destroy lifecycle, many things are 
lazy-loaded and cached just like in OFBiz. This provides a lot of flexibility 
in both development and for production maintenance/etc. Moqui does have some 
cache warming code for entities, services, and screens that is on by default in 
production mode.

 - run my little templates to transform current OFBiz data model XML files 
 into Moqui ones and put those in a Moqui component in the Moqui runtime 
 directory
 
 Sorry for the noob question, but does that mean that both ofbiz entityengine 
 and moqui could talk to the same database backend(s), at the same time?

Yes. Initially this would be the easiest way to run them together. An early 
priority would be to use the Moqui transaction management (based on Bitronix or 
Atomikos, Bitronix being WAY faster and with the latest update far more 
reliable too) so that OFBiz Entity Engine and Moqui Entity Facade operations 
would share TX contexts.

 This would be a basic PoC to get Moqui running inside OFBiz, and then we 
 could start the real PoC of either a thunk layer as Adrian proposed, 
 probably accessing the statically initialized Moqui

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

[David E. Jones]

+1 - with the clarification that to me begin replacing implies a PoC effort 
in a branch.


I just saw this thread and need a little time to think over the best approach, 
but off the top of my head it would look something like:

- add the moqui-framework-version.jar file and all dependent jars to a 
component directory under ofbiz/framework (these could go in the base or common 
components, but might be best separate for clarity); if needed update jars 
currently used in OFBiz where an older version is used (don't know if this is 
the case for any, mention for the sake of completeness)

- add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui 
uses this for various things); this would contain the Moqui tools components 
(with the Tools and System apps) so we have a UI to look at Moqui internals, 
OFBiz data, etc

- either in the Moqui runtime directory or as an OFBiz component add a 
webroot webapp; Moqui is designed to run in a single webapp, and I'd 
recommend this be separate from the existing OFBiz webapps for now; when this 
webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down 
it will destroy it

- because initializing Moqui when the webroot webapp starts may not be 
adequate, make sure the Moqui static init stuff is in place and working (in the 
Moqui.java class)

- run my little templates to transform current OFBiz data model XML files into 
Moqui ones and put those in a Moqui component in the Moqui runtime directory

This would be a basic PoC to get Moqui running inside OFBiz, and then we could 
start the real PoC of either a thunk layer as Adrian proposed, probably 
accessing the statically initialized Moqui ExecutionContextFactory since most 
OFBiz framework classes are statically initialized, or using the more dynamic 
initialization through the Moqui webroot webapp.

For those who want a brief introduction to some of the differences between 
OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to 
Moqui? section at: 

http://www.moqui.org/framework/index.html

That is an older document and isn't meant to be any sort of exhaustive list of 
the features of Moqui versus the features of OFBiz Framework, but gives a 
general idea about how some of the similar tools are different.

For those who want to dive a bit deeper the Tutorial may be helpful:

http://www.moqui.org/framework/docs/Tutorial.html

For those who want to dive in neck deep the Making Apps with Moqui book is 
the more exhaustive reference to Moqui (though about 8 months old now and there 
are many new features, summarized in the ReleaseNotes.txt file for those 
curious):

http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf
https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt

I would be happy to participate in this effort... if nothing else should be an 
interesting technical diversion.

-David



 On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com 
 wrote:
 
 As was discussed last week, there is some interest in replacing some (or all) 
 of OFBiz with Moqui (http://www.moqui.org/framework/index.html).
 
 To the scope reasonable, I propose that we begin by converting the following 
 parts of the OFBiz framework with Moqui:
 
 Entity Engine
 Service Engine
 Security
 
 Other parts of the OFBiz framework could be converted as well, but I think 
 this would be a good starting point, and if is successful, then more of OFBiz 
 can be converted later.
 
 I believe we can create a thunk component to help solve compatibility 
 problems, but that is a separate discussion. I only mention it here in case 
 compatibility concerns might influence a vote.
 
 -- 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com

Re: move to git.

[David E. Jones]

An FYI for all committers: create an account on GitHub (if you don't already 
have one) and add your @apache.org email address to it, and within a few hours 
you'll show up in the contributor graphs. I tried this and am now showing up 
there:

https://github.com/apache/ofbiz/graphs/contributors

If nothing else it's entertaining, I had no idea that I had this volume of 
commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note 
that changes to lines show up in both counts).

On a side note, my commit count is relatively low... ie most commits with a 
larger number of changes. I remember working more than way before using git... 
perhaps with its explicit approach to saying which files to include it 
encourages that more (unless you use git commit -a), or perhaps for other 
reasons my habits have changed.

I don't get nearly as fancy as what Adam described recently with his rebase 
approach, but to his point I find my commits being much cleaner and better 
organized.

-David


 On 22 Apr 2015, at 10:31, Ean Schuessler e...@brainfood.com wrote:
 
 That raises another irritating thing about the JIRA SVN workflow vs GIT
 pull requests.
 
 If you look at the contributor graph on GitHub for OFBiz you will see
 that it currently has only 3 contributors. Foremost this is because the
 project committers have mostly not configured their Apache addresses into
 their GitHub accounts. Secondly, however, it is caused by the fact that
 all JIRA committed patches will show the name of the person who merged
 the patch rather than its original author.
 
 https://github.com/apache/ofbiz/graphs/contributors
 
 We can make up stories about why this is desirable but I think any honest
 assessment would conclude that it is an inconvenience at best and a hazard
 at worst. Eventually if these dots are not connected the origins of some
 OFBiz code could become as mysterious as the early CVS commits. With the
 GIT pull request workflow we would not only know who wrote the code but
 would still know who performed the merge. We could also sign the commits
 so that their origin is cryptographically confirmed.
 
 - Original Message -
 From: Gil Portenseigne gil.portensei...@nereide.fr
 Subject: Re: move to git.
 
 Yes, but these are commiters contributions, i mean non-commiters one should 
 go
 thru jira.

Re: Proposal: redefining the components' directory layout for source files

[David E. Jones]

 On 21 Jan 2015, at 09:24, Jacques Le Roux jacques.le.r...@les7arts.com 
 wrote:
 
 
 Le 21/01/2015 15:45, Jacques Le Roux a écrit :
 5) moving a step forward in the direction of allowing the adoption of Maven 
 like tools (Maven, Gradle etc..) that could make it easier to share 
 external components (grow the ecosystem)
 
 Maven, are you serious (have mercy!)?
 And Gradle seems still a bit unstable (this is a year old opinion based on 
 exchanges in the Moqui community so could be biased) and no longer backed by 
 Pivotal, I read those last days (Groovy as well)
 
 I was wrong only Groovy and Grails are directly concerned, not Gradle  
 (though indirectly)
 https://www.voxxed.com/blog/2015/01/sad-odd-decision-pivotal-set-groovy-adrift/
  (see also link to Pivotal FAQ)

That was from January. I don't know where Grails is headed, but Groovy has 
already found a new home:

http://incubator.apache.org/projects/groovy.html

-David

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[David E. Jones]

 On 21 Apr 2015, at 14:09, Pierre Smits pierre.sm...@gmail.com wrote:
 
 Is this the path you want to walk? Code over Community? Engage in commit
 wars, just to force your way? Please don't!  Collaborating is easier than
 forcing. The latter harms the project more than the first.

Really? Doing a POC and proposing a direction implies all of this to you?

-David

Re: move to git.

[David E. Jones]

Tracking the original contributor is an important point.

The nice thing about git is that every commit has a UUID so even as that commit 
is pulled from one repository to another the contributor and other details can 
be tracked. In SVN as things go from one repo to another this is lost (unless 
it's something like a full repository import).

-David


 On 22 Apr 2015, at 10:31, Ean Schuessler e...@brainfood.com wrote:
 
 That raises another irritating thing about the JIRA SVN workflow vs GIT
 pull requests.
 
 If you look at the contributor graph on GitHub for OFBiz you will see
 that it currently has only 3 contributors. Foremost this is because the
 project committers have mostly not configured their Apache addresses into
 their GitHub accounts. Secondly, however, it is caused by the fact that
 all JIRA committed patches will show the name of the person who merged
 the patch rather than its original author.
 
 https://github.com/apache/ofbiz/graphs/contributors
 
 We can make up stories about why this is desirable but I think any honest
 assessment would conclude that it is an inconvenience at best and a hazard
 at worst. Eventually if these dots are not connected the origins of some
 OFBiz code could become as mysterious as the early CVS commits. With the
 GIT pull request workflow we would not only know who wrote the code but
 would still know who performed the merge. We could also sign the commits
 so that their origin is cryptographically confirmed.
 
 - Original Message -
 From: Gil Portenseigne gil.portensei...@nereide.fr
 Subject: Re: move to git.
 
 Yes, but these are commiters contributions, i mean non-commiters one should 
 go
 thru jira.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[David E. Jones]

 On 21 Apr 2015, at 14:17, Adam Heath doo...@brainfood.com wrote:
 
 Gradle is a non-starter.  When I saw that mentioned, I actually did do some 
 comparisons.
 
 In google, search for maven, then gradle.  See how many responses each one 
 gets.
 
 Then, go to trends.google.com, compare the above 2 items, and then add ant.  
 You might want to say apache ant or apache maven, and/or add java terms.
 
 Then, also do a A vs B vs C search, aka, maven vs gradle vs ant.
 
 After doing this, maven is still the right choice.

This is an appeal to popularity, not utility.

-David

Re: move to git.

[David E. Jones]

 On 22 Apr 2015, at 16:49, Adam Heath doo...@brainfood.com wrote:
 
 
 On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:
 On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote:
 
 When this happened, we had to relicense the entire project from GPL to 
 Apache 2.0.
 Gr It was not GPL! :-)
 
 It was something tho; I may be wrong on that, I didn't actually look it up.  
 I do recall that switching was quite the ordeal.

It was MIT, but that wasn't the real issue with all the CLAs... the ASF 
requires them but they are not generally required for other users of the Apache 
2 license.

This was a pain... took months of effort. Even under the ASF we don't know who 
all code has come from, there is no way to get a list from SVN or any other 
tool... not even from Jira (though that's closer, but we only have associations 
between those who opened issues or attached a patch or those sorts of 
activities, doesn't always match exactly which patch gets committed, etc... AND 
not all commits get linked back to the Jira issues... oh and mentioning a name 
in a commit, pretty useless from a reporting perspective... parsing 
difficulties, data cleanliness/consistency issues... nightmare).

-David

Re: move to git.

[David E. Jones]

 On 22 Apr 2015, at 16:14, Pierre Smits pierre.sm...@gmail.com wrote:
 
 Indeed, let's not amalgamate everything and keep the discussion clean. The
 https://fisheye6.atlassian.com/graph/ofbiz does show information about the
 jira issue (including the contributor, if done correctly). Just click on
 the blue i icon to the right of the comment excerpt.  You'll see  a modal
 window appearing with more info. Take as an example the commit done on
 April 18th starting with comment: 'A patch from Pierre Smits...'
 
 Thank you for sharing insights in how Git could work for this project. I
 appreciate it.
 
 Can you provide links to examples of an Apache project using Git that shows
 a contribution from a non-privileged contributor as you describe? It would
 surely help understanding the described visibility and help this community
 to make a sound decision when all has been said.

Not an ASF project, but here is an example of what that can look like (and 
demonstrating the shameful lack of community in Moqui Framework). In this case 
I am the only person with push/write permission to this git repository, so all 
others came through pull requests after they committed to their own fork 
repositories:

https://github.com/moqui/moqui/graphs/contributors

 Quoting:
 
 which non-committer has submitted the most code to OFBiz and what was the
 distribution of their changes amongst the various OFBiz components?
 
 
 I would love to see that too. Maybe our PMC chair can clarify and comment
 on that?

The PMC chair doesn't have access to any magic tools that are unavailable to 
the rest of us... this is an unknown (even if we can get approximate data from 
Jira and SVN).

-David

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

Fascinating diagram in that link from The Economist. I had no idea IBM had such 
huge market share in the past! It's good to see the industry becoming more 
distributed, ie market share spread across a larger number of companies.

Thanks, nice to be engaged in the project here and there. No, I wasn't at 
ApacheCon last week, a bit outside my current budgets (both time and money), 
especially with competing priorities like visiting family and friends... which 
I'm sure is the case for many would have liked to attend.

-David


 On 21 Apr 2015, at 01:12, Pierre Smits pierre.sm...@gmail.com wrote:
 
 Nice to have you back and engaged, David. My apologies if I didn't express
 that earlier.
 
 Were you at ACNA15 also?
 
 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 Tue, Apr 21, 2015 at 8:59 AM, Pierre Smits pierre.sm...@gmail.com
 wrote:
 
 Quoting:
 
 I suspect that the world is heading to git. I am just starting to get
 acquanted with it and beginning to feel like a bit of a dinosaur using SVN
 for our projects internally.
 
 
 That should be in another thread. Nevertheless, such can be said regarding
 a lot of (also unrelated) subjects/things which are still happily used by a
 great number. See the 'dinosaur' in this:
 http://cdn.static-economist.com/sites/default/files/imagecache/original-size/images/print-edition/20150404_WBC737_0.png
 
 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 Tue, Apr 21, 2015 at 3:43 AM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:
 
 On 20/04/2015 5:07 PM, David E. Jones wrote:
 
 On 20 Apr 2015, at 12:48, Ron Wheeler rwhee...@artifact-software.com
 wrote:
 
 On 20/04/2015 3:11 PM, David E. Jones wrote:
 
 On 20 Apr 2015, at 11:35, Ron Wheeler rwhee...@artifact-software.com
 wrote:
 
 Would Moqui become a sub-project of OFBiz with distinct deliverable
 with an Apache license?
 Or is that too much community?
 
 IMO they are better as distinct projects. There is a chance Moqui
 Framework could become a separate ASF project, though the name Apache
 Moqui is oddly contradictory (I chose the name based on Moqui Marbles, 
 but
 it is also another name for the Hopi tribe). More seriously, these days I
 like the distributed and moderated approaches used in the Linux kernel 
 more
 than the community approach mandated by the ASF.
 
 What would be the problem of it being part of OFBiz in the same way
 that FOP and Batik are part of the XLMGraphics project or Jetspeed is part
 of the Portals project.
 A lot less work than a TLP but still benefiting from Apache.
 Would not have to call of Apache Moqui. It would just be Moqui , part
 of Apache OfBiz
 
 XML Graphics and Portals are both umbrella projects, meant to have
 sub-projects, and OFBiz is not. OFBiz could be restructured that way, and
 perhaps even have sub-projects without that restructuring sort of like the
 Jackrabbit Oak project, but still not sure if it makes sense. On that note:
 if a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it
 might make sense as a sub-project just like Oak is of Jackrabbit. On a far
 side note: Oak looks great but I wish it ran on something other than
 MongoDB so it could be embedded for dev and smaller deployments!
 
 The process of becoming a TLP isn't that much of a concern to me. It
 takes time, but is worth it to establish a firm foundation for the project
 going forward.
 
 The main issues that concern me are the various and changing policies of
 the ASF. I have a hard time seeing the point of trademarks for open source
 projects, for example.
 
 Not sure if this is key to the current discussion but I would not mind
 hearing details of your concerns since we have put a bit of an effort into
 that area recently.
 
 The community model is another concern, I don't like the structure as
 much as certain alternatives in the open source world (even if I used to
 think it was the best approach, or at least something similar to the ASF
 approach). It may be possible to manage a more distributed community and
 code base with various fork repositories and feature/issue branches in the
 style of git (ie actually using git within the ASF).
 
 I suspect that the world is heading to git. I am just starting to get
 acquanted with it and beginning to feel like a bit of a dinosaur using SVN
 for our projects internally.
 
 
 During incubation the biggest community risk is _forcing_ a certain
 number of committers and PMC members. I don't want to scrape to include
 people in these roles as they are vital to the future of the project. I
 would rather let people come along, express interest, and thoroughly prove
 merit before they take on such a role.
 
 One of the advantages of joning an existing

Re: move to git.

[David E. Jones]

 On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@gmail.com wrote:
 
 Quoting:
 
 We are also prepared to be assertive regarding this situation. If the
 project
 does not move to GIT then Brainfood is willing to participate in a
 consortium of
 organizations that will peer with each other to share updates to the master
 branch for their local OFBiz repository. Such an arrangement will,
 effectively,
 result in a distributed master repository image.
 
 Thanks Ean for the position of *Brainfood* in this position. It comes
 across as 'Do it our way, or else'. You are free to make such statements
 and when followed through there will be consequences. For all participating
 in this project. One I can see standing out clearly is: no more
 participation in/contribution from the employees of Brainfood and from the
 other companies in that consortium back into the project.

That's not at all what I get from Ean's comments. The magic of a 
community-driven project is that people can collaborate on anything they want, 
within the scope of the main project or as side projects. If the main project 
doesn't provide something desired, then it is perfectly appropriate for others 
to collaborate on that... better than doing it totally isolated.

What Ean is talking about ties in with the general idea of distributed source 
management and distributed development. The general idea is that there may be 
many forks of the main source repo, potentially with various branches for 
different improvements and changes. These are generally made available 
publicly, like public GitHub forks of other public repositories (though with 
git they can be hosted anywhere).

Those who make changes can request that particular changes be pulled into 
upstream repositories and then those who maintain the upstream repos (or the 
main project repo if it bubbles up that high) can review them and pull the 
changes if desired. Those who maintain upstream repos can also look around for 
useful changes in forked repos and pull them in as desired. Others who run 
their own forks can pull in changes from peer repositories too.

It may seem like chaos to have forks and changes spread all over the place... 
but that isn't caused by the distributed source management approach, it's just 
made visible and clear by the approach. Right now this exists on a large scale 
for OFBiz, tons of forks and changes in them, but they are mostly not visible 
or publicly available so there is no way for OFBiz committers to pull changes 
from other repos... they basically have to be extracted into a patch file and 
submitted through a Jira issue.

In other words, the chaos exists and the distributed source management enabled 
by git just makes it easier to track it all and tame it a bit.

On a side note, this is one of the reasons I have concerns about making Moqui 
and related projects part of the ASF: the ASF community approach doesn't fit 
very well with this distributed source management model (pull requests are 
discouraged, all contributions should go through Jira issues... though I don't 
know that this is a strict policy).

-David


 If that is going to happen, I will say: 'I thank you for all the
 contributions you did to the project'. And I will check in my sentiments at
 the door. I do hope that if you do you also resign totally from this
 project.
 
 
 I rather have the community comes to its decision based on sound/valid
 arguments, not (veiled) threats.
 
 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 Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler e...@brainfood.com wrote:
 
 - Original Message -
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 Subject: Re: move to git.
 
 Like Adrian and mostly for the same reasons, I don't believe we need Git.
 
 But there is one other major reason which has already been discussed in
 the
 other common ASF MLs.  As Taher exulted, it's possible to create local
 branches. So people are able to do a lot of work alone without
 exchanging before
 committing or submitting. It will certainly not help to have this
 possibility.
 
 I disagree. It is useful in many situations for OFBiz developers to create
 a
 local repository that is not globally shared. Some customers may even
 require
 such a situation for security or legal reasons.
 
 Remember our recent discussion on the lack or core commits reviews.
 With Git you end with commits bursts or big patches and it's then
 hard to review and too late to share ideas.
 
 So unlike Adrian, I'm even strongly against it. I will not hesitate to
 use a -1
 if necessary!
 
 We are also prepared to be assertive regarding this situation. If the
 project
 does not move to GIT then Brainfood is willing to participate in a
 consortium of
 organizations that will peer with each other to share updates to the master
 branch for their local 

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

 On 20 Apr 2015, at 12:48, Ron Wheeler rwhee...@artifact-software.com wrote:
 
 On 20/04/2015 3:11 PM, David E. Jones wrote:
 On 20 Apr 2015, at 11:35, Ron Wheeler rwhee...@artifact-software.com 
 wrote:
 
 Would Moqui become a sub-project of OFBiz with distinct deliverable with an 
 Apache license?
 Or is that too much community?
 IMO they are better as distinct projects. There is a chance Moqui Framework 
 could become a separate ASF project, though the name Apache Moqui is oddly 
 contradictory (I chose the name based on Moqui Marbles, but it is also 
 another name for the Hopi tribe). More seriously, these days I like the 
 distributed and moderated approaches used in the Linux kernel more than the 
 community approach mandated by the ASF.
 What would be the problem of it being part of OFBiz in the same way that FOP 
 and Batik are part of the XLMGraphics project or Jetspeed is part of the 
 Portals project.
 A lot less work than a TLP but still benefiting from Apache.
 Would not have to call of Apache Moqui. It would just be Moqui , part of 
 Apache OfBiz

XML Graphics and Portals are both umbrella projects, meant to have 
sub-projects, and OFBiz is not. OFBiz could be restructured that way, and 
perhaps even have sub-projects without that restructuring sort of like the 
Jackrabbit Oak project, but still not sure if it makes sense. On that note: if 
a Moqui-based (or Moqui and Mantle based) version of OFBiz were built it might 
make sense as a sub-project just like Oak is of Jackrabbit. On a far side note: 
Oak looks great but I wish it ran on something other than MongoDB so it could 
be embedded for dev and smaller deployments!

The process of becoming a TLP isn't that much of a concern to me. It takes 
time, but is worth it to establish a firm foundation for the project going 
forward.

The main issues that concern me are the various and changing policies of the 
ASF. I have a hard time seeing the point of trademarks for open source 
projects, for example. The community model is another concern, I don't like the 
structure as much as certain alternatives in the open source world (even if I 
used to think it was the best approach, or at least something similar to the 
ASF approach). It may be possible to manage a more distributed community and 
code base with various fork repositories and feature/issue branches in the 
style of git (ie actually using git within the ASF).

During incubation the biggest community risk is _forcing_ a certain number of 
committers and PMC members. I don't want to scrape to include people in these 
roles as they are vital to the future of the project. I would rather let people 
come along, express interest, and thoroughly prove merit before they take on 
such a role.

 As for community, regardless of the structure the various Moqui projects are 
 now in a good place for a bigger community and it is needed for more 
 significant growth in the projects. There are parallels to OFBiz which was 
 mostly two people until around 2004-2005 when the project exploded (we had 
 other contributors before then, but most not so involved or enduring). 
 Jacopo was the first really strong contributor in 2003, and remains to this 
 day! I'm still looking for a Jacopo for Moqui... heck, maybe it'll be 
 Jacopo. ;) (No pressure Jacopo: I know you're a busy man and doing fantastic 
 and important work elsewhere including OFBiz, Hotwax, and other projects you 
 contribute to.)
 
 As for licensing: the public domain license is even less restrictive than 
 the Apache 2 license. The one thing that bothers me about the licensing 
 approach, that I'll freely admit but that I'm not sure how to handle better, 
 is the explicit patent grant that is in the Apache 2 license (which made it 
 incompatible with GPL2, though GPL3 has it too so it is compatible, ie no 
 additional restrictions). In theory this shouldn't be a legal issue because 
 releasing it as public domain means giving up most IP rights, and there is 
 the prior art aspect of it too, but patent courts these days (at least in 
 the USA) are awful and they don't seem to care about prior art unless you 
 pay a few million USD to lawyers along with substantial court fees to get 
 that recognized. In theory it shouldn't be an issue, not sure if it ever has 
 been even for Apache 2 licensed code, but it could be and in theory the 
 terms in the Apache 2 license make it cheaper to defend against patent 
 claims (again in theory... chances are there would still be significant, 
 possibly bankrupting, legal fees to defend against such).
 Being a part of an Apache project makes it harder to try to steal the IP or 
 claim ownership.

Because of the ASF legal fund?

-David

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

 On 20 Apr 2015, at 13:21, Adrian Crum adrian.c...@sandglass-software.com 
 wrote:
 
 On 4/20/2015 7:39 PM, David E. Jones wrote:
 This is where I question whether it is a good idea to just replace the 
 framework and leave all else as-is in OFBiz. I know very well that bringing 
 this up is likely to stall the discussion and reduce the chances of OFBiz 
 ever using Moqui, and the great thing for Moqui and OFBiz that it could be. 
 Still, the effort required to do that migration is significant and IMO it 
 would be far less effort to start with Moqui and Mantle and basically 
 rewrite OFBiz to be a comprehensive business automation application suite, 
 just as it is now, but cleaned up and streamlined for both developers and 
 end-users in ways that are only dreamed of for OFBiz right now.
 
 The discussions so far have been around just replacing the OFBiz framework 
 with Moqui. There is a separate discussion going on about reorganizing higher 
 level artifacts differently.
 
 I was thinking we could create a thunk component to ease the transition to 
 Moqui. The thunk component would map existing Java packages to the Moqui API, 
 and then we can make changes to client code as time allows.

My first thought in this is it would be messy. :) Moqui objects have a 
lifecycle with init/destroy methods, especially the ExecutionContext which is 
created for each general operation such as processing an HTTP request (for web 
page, web service call, whatever) or running a background service job. There is 
a static method to get the main ExecutionContextFactory, but then you can only 
ever have one of those (usually not a big deal), and from there get the current 
ExecutionContext or create one. When you're done with the ExecutionContext it 
needs to be destroyed though.

The Moqui features that aren't in the OFBiz framework anywhere could be 
accessed directly, so that shouldn't be an issue. There could be issues in the 
other direction, parts of the OFBiz framework that are left out of Moqui in 
favor of other tools (these could be wrapped as well... though unwrapping them 
is much cleaner... I guess there are already a dozen or more classes in the 
OFBiz framework that are just thin veneers around other tools!) or that just 
don't exist because they didn't seem useful and no need for them has come up.

Anyway, it a good thought, might be interesting to try...

-David

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[David E. Jones]

 On 20 Apr 2015, at 12:29, Ron Wheeler rwhee...@artifact-software.com wrote:
 
 On 20/04/2015 3:19 PM, David E. Jones wrote:
 Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based 
 and so has more affinity with OFBiz. Continuum is a different sort of 
 animal, a continuous integration tool that can run a variety of build tools.
 
 BTW, what is an expert, let alone a real expert? A little like the term 
 true Scotsman and the corresponding logical fallacy IMO...
 I was always told that an expert was a man with a briefcase 50 miles from 
 home.
 Not sure how this translates into the modern virtual world taking into 
 account the role of women.

Not a bad definition, representative of the concept including often arbitrary 
inclusion/exclusion. ;)

I say that having been a man with a briefcase over 50 miles from home on 
regular occasions...

-David

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

I'll admit I got a chuckle out of this one. Yes, my activity in OFBiz dropped 
to pretty close to zero in 2010 after I started Moqui/Mantle/etc. I think that 
was before you got more closely involved Pierre. 

OpenHub keeps a good history of this, for commits anyway, though note that for 
OFBiz the history for mid-2003 to early 2006 was lost with the demise of the 
OFBiz project on java.net (where we were before the ASF):

https://www.openhub.net/accounts/jonesde/positions

I'll reply to other messages with more thoughts on Moqui in OFBiz.

-David


 On 20 Apr 2015, at 02:11, Pierre Smits pierre.sm...@gmail.com wrote:
 
 Quoting Hans: 'getting David Jones back into the project'
 
 Was he out? I didn't notice.
 
 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

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[David E. Jones]

That gets back to the question of why change in the first place... build files 
may be smaller and easier to maintain, but there may not be a good reason!

-David


 On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com wrote:
 
 David,
 
 Thanks for sharing your insights. You talk about 'pretty much anything
 can be done with'. What, in your experience, can't be done -at the
 moment- in relation to OFBiz?
 
 Best regards,
 
 Pierre
 
 Op maandag 20 april 2015 heeft David E. Jones d...@me.com het volgende
 geschreven:
 
 
 Not to muddy the waters... but Gradle might be a good alternative. There
 is a lot more in it than Ant that just works without needing to be
 explicit, especially when you follow Maven conventions for layout of src
 directories.
 
 One big upside of Gradle is that all build files are Groovy scripts and
 you can do pretty much anything in them. One downside is the learning
 curve... there is an extensive DSL with pretty good documentation, but some
 things that would seem simple are non-obvious (to put it generously). On
 the other hand, there is fairly wide use so I still have yet to run
 anything where I couldn't find a solution quickly with a google search.
 
 -David
 
 
 On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com
 javascript:; wrote:
 
 We should seriously consider the comments from Adam and move to maven.
 
 Regards,
 Hans
 antwebsystems.com
 
 
 On 18/04/15 00:41, Adam Heath wrote:
 
 On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
 Thanks for your detailed heads-up Martin, notably your last point!
 
 I mostly agree, and indeed I also think Maven might not be so bad when
 you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
 
 Jacques
 
 Le 17/04/2015 16:27, Martin Becker a écrit :
 +1 for lack of benefit (and for fear ;-))
 
 The commit I did last night took me 45 minutes.  Full stop.  I started
 at 12:03am.  And I did it while drinking a second beer. Maven was that
 simple.  I had resisted for years.  Years!  But when I actually sat down to
 do it, I realized that I did *not* have to change what I was doing.  Maven
 could be configured to work with the existing design.
 
 The benefits are:
 
 * not having to write our own build system; ant is not a build system.
 
 * full external dependency management.  This can be done very
 incrementally.  I just got framework/base to compile, by reusing the
 previously downloaded jars in framework/base/lib.  Then, when all
 dependencies are *properly* listed, we can switch to the download
 mechanism, and suddenly, the checkout becomes smaller.
 
 * full internal dependency support.  As part of framework/base now
 having a working pom.xml, it has a dep on framework/start.  This can allow
 for end-users wanting to just install applications/party, and having just
 what is required get downloaded.
 
 * Each ofbiz component could be moved to separate repos, and
 development can progress on its own.  All that specialpurpose/* stuff no
 longer needs to be carried along with the rest of the codebase.
 
 * continuous integration becomes so much simpler; the standard mvn
 package call does command-line unit tests, *by default*.
 
 * these poms do not break anything.  Nothing calls them.  Everyone can
 continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
 So, having them in trunk won't cause issue for anyone else.  This is the
 way linux-kernel functions.  Completely new, isolated features, that affect
 no one else, are added to master/linux-next, so that they can get pushed
 out to more users, for more testing.  If something is done in a separate
 branch, they have discovered it doesn't recieve enough widespread testing.
 
 
 
 My first thoughts:
 
 = If a change is desired, than Gradle would surely be a good choice
 as it is the next generation build tool witch tries to combine the
 advantages from tools like ant, maven and others…
 
 Sure, why not?
 
 
 Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
 common.xml, but really, lets not go there.
 
 
 = I think the stability of Gradle is not a question as it is used by
 projects like Spring, Hibernate, Grails, Groovy and others…
 
 = With the ability to use ant tasks and whole ant build scripts
 within Gradle, a smooth migration could be an option
 
 
 Maven can call ant.  I'm even doing so in the 2 poms that I added.
 
 = Maven rely on it’s convention over configuration pattern, so it is
 never a good idea to NOT follow it’s conventions by configuring it for a
 different project structure for example. So there may be the need for
 massive changes to the OFBiz project structure and so on.
 
 
 I just got framework/base to compile with maven.  This includes *NO*
 changes to ofbiz layout.  framework/base/lib still exists. Nothing is being
 downloaded(except maven plugins, of course).
 
 = Also the ability to only produce one artifact per project in maven
 would perhaps end up in configuring sub projects for each

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

 On 20 Apr 2015, at 02:24, Jacques Le Roux jacques.le.r...@les7arts.com 
 wrote:
 
 Le 20/04/2015 09:47, Adrian Crum a écrit :
 Generally speaking, I am in favor of using another framework. I have two 
 reservations about Moqui:
 
 1. It is controlled by a single person - so responsiveness to issues are 
 dependent on that person's availability.
 
 This is indeed a regression from the current community sharing. On the other 
 hand a such change would not be done in one day, so we would have a long 
 period to experiment in parallel before possibly switching to Moqui.
 I also guess in such cases David could open the Moqui to people he trusts. I 
 though wonder how this would be linked together. Nothing blocking but to be 
 seriously thought about, not only technically but legally. I know it's 
 David's will to share and he proved it already with OFBiz but the licensing 
 aspect is not clear to me http://www.moqui.org/#model.

With Moqui it's no secret that I chose the code over community route which is 
certainly different from the ASF emphasis on community (and my emphasis on 
community and collaboration from the beginning in OFBiz). 

Moqui Framework is now pretty mature and I have sent out a couple of 
solicitations (in the LinkedIn group) for more contributors, but I'm in no 
hurry to bring on other committers/moderators... better to wait until clearly 
interested and capable people come along. The infrastructure is in place for 
this on GitHub, ie the main repo is under the moqui group and not my personal 
account any more so it is easy to add others to that group with permission for 
particular repositories (ie moqui vs mantle, HiveMind, etc).

Part of the reason I'm less worried about this is the different model for 
source management that Git makes possible and GitHub makes easy. In other 
words, the magic of distributed source management. Distributed source 
management and the moderator model make it possible for forks to exist that 
have variations on the main code base that are available for all and pulled 
into the main code base by moderators. You don't have to be a moderator to 
contribute, or even share your code with the world.

The whole distributed source and moderator model is very different from the 
community model in OFBiz, and overall better for some things and worse for 
others. Many big projects use this model, including the Linux kernel which is 
probably the biggest and the use of this model for the Linux kernel is exactly 
where git came from.

My guess is that if OFBiz started using Moqui Framework one or more current 
OFBiz committers would become moderators with commit access to the main Moqui 
Framework repository.

 2. It repeats a lot of mistakes that have been made in OFBiz, so those 
 things will need to be fixed again in Moqui after we bring it on board.
 
 Indeed, a lot of fixes have been done recently in OFBiz which is battle 
 tested for years. Moqui though certainly well done, is still young and we 
 would need to compare them, point by point.

I'd love to hear more detail on this. I know one criticism in the past from 
Adrian is Moqui's approach to object type conversions, especially in the Entity 
Facade (the part of Moqui similar to the OFBiz Entity Engine). In some parts of 
Moqui, like for service parameters, it uses the Groovy type conversion which is 
pretty good but isn't a pluggable type conversion framework as I'm sure Adrian 
would like to see... but that honestly I still have yet to find a need for.

On the entity level I prefer the current approach, mostly for performance 
reasons. In recent changes to the framework for performance improvements (which 
were significant... Moqui now getting around 15,000 entity ops per second as 
opposed to 3,000 before the latest changes, and close to 300 in the original 
version of Moqui though that was on an older laptop/etc and before ANY 
optimizations where done). This does limit the types available for entity 
fields, but is that really an issue? You're going to a database through JDBC, 
and really just the least common denominator of types available in databases to 
cleanly run on various ones, so there aren't many options in the first place! 
We can take advantage of that for simpler code and better performance.

 Neither one is a show-stopper for me.
 
 Same here, just cautious.

Caution is good in this case... to be honest I'm not sure using Moqui Framework 
in OFBiz is a good idea (as I've mentioned before), will write more on that in 
another reply.

-David

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[David E. Jones]

Not to muddy the waters... but Gradle might be a good alternative. There is a 
lot more in it than Ant that just works without needing to be explicit, 
especially when you follow Maven conventions for layout of src directories.

One big upside of Gradle is that all build files are Groovy scripts and you can 
do pretty much anything in them. One downside is the learning curve... there is 
an extensive DSL with pretty good documentation, but some things that would 
seem simple are non-obvious (to put it generously). On the other hand, there is 
fairly wide use so I still have yet to run anything where I couldn't find a 
solution quickly with a google search.

-David


 On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com wrote:
 
 We should seriously consider the comments from Adam and move to maven.
 
 Regards,
 Hans
 antwebsystems.com
 
 
 On 18/04/15 00:41, Adam Heath wrote:
 
 On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
 Thanks for your detailed heads-up Martin, notably your last point!
 
 I mostly agree, and indeed I also think Maven might not be so bad when you 
 start anew (or are forced to use it ;) ) but for OFBiz, really NO!
 
 Jacques
 
 Le 17/04/2015 16:27, Martin Becker a écrit :
 +1 for lack of benefit (and for fear ;-))
 
 The commit I did last night took me 45 minutes.  Full stop.  I started at 
 12:03am.  And I did it while drinking a second beer. Maven was that simple.  
 I had resisted for years.  Years!  But when I actually sat down to do it, I 
 realized that I did *not* have to change what I was doing.  Maven could be 
 configured to work with the existing design.
 
 The benefits are:
 
 * not having to write our own build system; ant is not a build system.
 
 * full external dependency management.  This can be done very incrementally. 
  I just got framework/base to compile, by reusing the previously downloaded 
 jars in framework/base/lib.  Then, when all dependencies are *properly* 
 listed, we can switch to the download mechanism, and suddenly, the checkout 
 becomes smaller.
 
 * full internal dependency support.  As part of framework/base now having a 
 working pom.xml, it has a dep on framework/start.  This can allow for 
 end-users wanting to just install applications/party, and having just what 
 is required get downloaded.
 
 * Each ofbiz component could be moved to separate repos, and development can 
 progress on its own.  All that specialpurpose/* stuff no longer needs to be 
 carried along with the rest of the codebase.
 
 * continuous integration becomes so much simpler; the standard mvn package 
 call does command-line unit tests, *by default*.
 
 * these poms do not break anything.  Nothing calls them.  Everyone can 
 continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.  
 So, having them in trunk won't cause issue for anyone else.  This is the way 
 linux-kernel functions.  Completely new, isolated features, that affect no 
 one else, are added to master/linux-next, so that they can get pushed out to 
 more users, for more testing.  If something is done in a separate branch, 
 they have discovered it doesn't recieve enough widespread testing.
 
 
 
 My first thoughts:
 
 = If a change is desired, than Gradle would surely be a good choice as it 
 is the next generation build tool witch tries to combine the advantages 
 from tools like ant, maven and others…
 
 Sure, why not?
 
 
 Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and 
 common.xml, but really, lets not go there.
 
 
 = I think the stability of Gradle is not a question as it is used by 
 projects like Spring, Hibernate, Grails, Groovy and others…
 
 = With the ability to use ant tasks and whole ant build scripts within 
 Gradle, a smooth migration could be an option
 
 
 Maven can call ant.  I'm even doing so in the 2 poms that I added.
 
 = Maven rely on it’s convention over configuration pattern, so it is 
 never a good idea to NOT follow it’s conventions by configuring it for a 
 different project structure for example. So there may be the need for 
 massive changes to the OFBiz project structure and so on.
 
 
 I just got framework/base to compile with maven.  This includes *NO* changes 
 to ofbiz layout.  framework/base/lib still exists. Nothing is being 
 downloaded(except maven plugins, of course).
 
 = Also the ability to only produce one artifact per project in maven 
 would perhaps end up in configuring sub projects for each application and 
 module in OFBiz with a frustrating handling of multi module configurations 
 with version-/release-tags, dependency handling and so on...
 
 
 This is wrong.  You can produce multiple artifacts.  I've seen it done in 
 other projects.
 
 = I used maven in multi module project setups before and it has it’s nice 
 features, although it is sometimes hard to understand details and effects 
 of the build lifecycle or single plugins. But the main fact is, that this 
 were green-field projects, so things in terms 

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

 On 19 Apr 2015, at 22:31, Hans Bakker mailingl...@antwebsystems.com wrote:
 
 Again, as discussed at the ApacheCon in Austin we should start setting up a 
 plan how to best move the ERP application to the Moqui framework. Moqui 
 should not be part of the Apache foundation however the ERP application 
 should remain there.
 
 Not only will it improve development of the ERP system but also will 
 establish a clean separation between application and frameworks and hopefully 
 getting David Jones back into the project.
 
 Yes, I realize i open the pandora box :-) but we need to make some major 
 decisions

I'll write this general reply with my OFBiz hat on, not my Moqui one. For Moqui 
Framework being used by OFBiz would be fantastic. It would bring a lot of well 
needed use and attention to the project and get it to a level that would take 
much longer with the current pace of growth. The growth is increasing, but it's 
nothing like the early years of OFBiz when the marketplace was so different... 
at that time OFBiz was unique as there weren't many feature-rich open source 
ecommerce or ERP systems, especially not in Java! I still find it amazing that 
OFBiz took off as much as it did... I was 23 years old when I started it, and 
only had 2 years of full-time development work behind me, and only 1 year of 
that was on ecommerce and ERP systems. Andrew had more experience with custom 
ecommerce development, but mostly in Perl IIRC.

Anyway, enough nostalgia, back to the present.

Using Moqui Framework in OFBiz would involve some really significant changes. 
The Moqui API is much cleaner (and everything is available through the single 
ExecutionContext class), but much different from the scattered static classes 
of the OFBiz framework. It may be possible to refactor much of the code with 
some regex search/replace wizardry, but there is a LOT of code in OFBiz to 
change.

The data model and to some extent service definitions would be easy. I have 
some FTL templates for transforming those that I'd be happy to share (they are 
in a private repo right now). I used these to create the little Moqui component 
that has the OFBiz data model from version 10.04 which I used with a client to 
run a sort of OFBiz/Moqui hybrid. On that note... if anyone wants to experiment 
with this that might be a good place to start: get the latest data model 
definitions in a Moqui component, deploy the Moqui WAR in the same servlet 
container as OFBiz (just drop it in an OFBiz component) and then run them in 
parallel accessing the same DB and play with migrating a few screens/etc.

IMO the biggest questions/concerns should be:

1. the significant effort required to do the migration
2. the impact on current users and applications

OFBiz would end up as a very different beast after such changes, there is no 
way around it. For example screen hierarchies, nesting, and URLs are handled 
totally different in Moqui. There are some very cool newer open source tools 
used in Moqui, and some cool features in Moqui that don't (yet) exist in OFBiz, 
and many of the more advanced and recent ones aren't mentioned here, but this 
is a basic list of fundamental differences between the two frameworks (see the 
OFBiz: How does it compare to Moqui? section near the bottom):

http://www.moqui.org/framework/index.html

OFBiz could do a custom set of FTL macros to transform screens and forms into 
HMTL/etc, but OOTB the UI is very different. This isn't just look and feel but 
also the approach to UI design. For example there are no lookup windows, other 
widgets and approaches are used instead (though those could be added... I just 
haven't found the need compared with other approaches that are often cleaner 
and easier for users). Looking at the demo server you'll see the big 
differences pretty quickly:

http://demo.moqui.org/

To go a deeper the Moqui book covers most of the framework and is available 
here:

http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf

Is it a good idea? I'm not sure about that. Both concerns 1 and 2 above are a 
big deal. It would be a huge change for OFBiz users and not in any way 
backwards compatible. Not only the code in OFBiz but also all custom code built 
on OFBiz would have to be changed to update to the newest versions. Given the 
community and user driven reality of OFBiz, my guess is that the current 
architecture would never be fully abandoned and would live on into the 
foreseeable future with both bug fixes and new features going into it.

On the other hand the growth potential is pretty substantial. Code in OFBiz 
would end up being much cleaner and smaller. Security (especially authz) could 
be ripped out of thousands of places and put in simple database configuration. 
There would be better ability to handle custom and generic RESTful and other 
web services. Elasticsearch is there ready to use for both full text search and 
analytics (ie using Elasticsearch as a distributed and efficient OLAP data 

Re: Discussion: Replace framework by Moqui.

[David E. Jones]

 On 20 Apr 2015, at 11:35, Ron Wheeler rwhee...@artifact-software.com wrote:
 
 Would Moqui become a sub-project of OFBiz with distinct deliverable with an 
 Apache license?
 Or is that too much community?

IMO they are better as distinct projects. There is a chance Moqui Framework 
could become a separate ASF project, though the name Apache Moqui is oddly 
contradictory (I chose the name based on Moqui Marbles, but it is also another 
name for the Hopi tribe). More seriously, these days I like the distributed and 
moderated approaches used in the Linux kernel more than the community approach 
mandated by the ASF.

As for community, regardless of the structure the various Moqui projects are 
now in a good place for a bigger community and it is needed for more 
significant growth in the projects. There are parallels to OFBiz which was 
mostly two people until around 2004-2005 when the project exploded (we had 
other contributors before then, but most not so involved or enduring). Jacopo 
was the first really strong contributor in 2003, and remains to this day! I'm 
still looking for a Jacopo for Moqui... heck, maybe it'll be Jacopo. ;) (No 
pressure Jacopo: I know you're a busy man and doing fantastic and important 
work elsewhere including OFBiz, Hotwax, and other projects you contribute to.)

As for licensing: the public domain license is even less restrictive than the 
Apache 2 license. The one thing that bothers me about the licensing approach, 
that I'll freely admit but that I'm not sure how to handle better, is the 
explicit patent grant that is in the Apache 2 license (which made it 
incompatible with GPL2, though GPL3 has it too so it is compatible, ie no 
additional restrictions). In theory this shouldn't be a legal issue because 
releasing it as public domain means giving up most IP rights, and there is the 
prior art aspect of it too, but patent courts these days (at least in the USA) 
are awful and they don't seem to care about prior art unless you pay a few 
million USD to lawyers along with substantial court fees to get that 
recognized. In theory it shouldn't be an issue, not sure if it ever has been 
even for Apache 2 licensed code, but it could be and in theory the terms in the 
Apache 2 license make it cheaper to defend against patent claims (again in 
theory... chances are there would still be significant, possibly bankrupting, 
legal fees to defend against such).

-David


 
 On 20/04/2015 1:19 PM, David E. Jones wrote:
 On 20 Apr 2015, at 02:24, Jacques Le Roux jacques.le.r...@les7arts.com 
 wrote:
 
 Le 20/04/2015 09:47, Adrian Crum a écrit :
 Generally speaking, I am in favor of using another framework. I have two 
 reservations about Moqui:
 
 1. It is controlled by a single person - so responsiveness to issues are 
 dependent on that person's availability.
 This is indeed a regression from the current community sharing. On the 
 other hand a such change would not be done in one day, so we would have a 
 long period to experiment in parallel before possibly switching to Moqui.
 I also guess in such cases David could open the Moqui to people he trusts. 
 I though wonder how this would be linked together. Nothing blocking but to 
 be seriously thought about, not only technically but legally. I know it's 
 David's will to share and he proved it already with OFBiz but the licensing 
 aspect is not clear to me http://www.moqui.org/#model.
 With Moqui it's no secret that I chose the code over community route which 
 is certainly different from the ASF emphasis on community (and my emphasis 
 on community and collaboration from the beginning in OFBiz).
 
 Moqui Framework is now pretty mature and I have sent out a couple of 
 solicitations (in the LinkedIn group) for more contributors, but I'm in no 
 hurry to bring on other committers/moderators... better to wait until 
 clearly interested and capable people come along. The infrastructure is in 
 place for this on GitHub, ie the main repo is under the moqui group and 
 not my personal account any more so it is easy to add others to that group 
 with permission for particular repositories (ie moqui vs mantle, HiveMind, 
 etc).
 
 Part of the reason I'm less worried about this is the different model for 
 source management that Git makes possible and GitHub makes easy. In other 
 words, the magic of distributed source management. Distributed source 
 management and the moderator model make it possible for forks to exist 
 that have variations on the main code base that are available for all and 
 pulled into the main code base by moderators. You don't have to be a 
 moderator to contribute, or even share your code with the world.
 
 The whole distributed source and moderator model is very different from the 
 community model in OFBiz, and overall better for some things and worse for 
 others. Many big projects use this model, including the Linux kernel which 
 is probably the biggest and the use of this model for the Linux kernel

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[David E. Jones]

Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and 
so has more affinity with OFBiz. Continuum is a different sort of animal, a 
continuous integration tool that can run a variety of build tools.

BTW, what is an expert, let alone a real expert? A little like the term true 
Scotsman and the corresponding logical fallacy IMO...

-David


 On 20 Apr 2015, at 11:58, Pierre Smits pierre.sm...@gmail.com wrote:
 
 Quoting: 'why change in the first place'. That is one of the most important
 question, perhaps even 'the most important' And it seems, that one
 isn't answered to the fullest.
 
 I like: if it aint broken, don't try to fix it'. But also 'a square peg
 doesn't fit in a round hole'. Is our current build mechanism broken? Is our
 current mechanism a square peg?
 
 But beyond that: have we fully explored the all/other paths? We currently
 have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
 solutions (at least according to their sites, but the writers of any of
 those pages could be disregarded as experts). But there are also Apache
 Buildr and Continiuum, according to this site listing options:
 http://en.wikipedia.org/wiki/List_of_build_automation_software.
 
 Should we explore inviting the real experts (those of all these tools) to
 share their insights, so that we can base the decision on real information
 than just conjecture/limited experiences?
 
 And on another and related aspect: how much effort would the benefit of
 each option require to have it fully operational for OFBiz? That should
 help determination too.
 
 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 Mon, Apr 20, 2015 at 7:00 PM, David E. Jones d...@me.com wrote:
 
 
 That gets back to the question of why change in the first place... build
 files may be smaller and easier to maintain, but there may not be a good
 reason!
 
 -David
 

Re: Entity Caching

[David E. Jones]

Stepping back a little, some history and theory of the entity cache might be 
helpful.

The original intent of the entity cache was a simple way to keep frequently 
used values/records closer to the code that uses them, ie in the application 
server. One real world example of this is the goal to be able to render 
ecommerce catalog and product pages without hitting the database.

Over time the entity caching was made more complex to handle more caching 
scenarios, but still left to the developer to determine if caching is 
appropriate for the code they are writing.

In theory is it possible to write an entity cache that can be used 100% of the 
time? IMO the answer is NO. This is almost possible for single record caching, 
with the cache ultimately becoming an in-memory relational database running on 
the app server (with full transaction support, etc)... but for List caching it 
totally kills the whole concept. The current entity cache keeps lists of 
results by the query condition used to get those results and this is very 
different from what a database does, and makes things rather messy and 
inefficient outside simple use cases.

On top of these big functional issues (which are deal killers IMO), there is 
also the performance issue. The point, or intent at least, of the entity cache 
is to improve performance. As the cache gets more complex the performance will 
suffer, and because of the whole concept of caching results by queries the 
performance will be WORSE than the DB performance for the same queries in most 
cases. Databases are quite fast and efficient, and we'll never be able to 
reproduce their ability to scale and search in something like an in-memory 
entity cache, especially not considering the massive redundancy and overhead of 
caching lists of values by condition.

As an example of this in the real world: on a large OFBiz project I worked on 
that finished last year we went into production with the entity cache turned 
OFF, completely DISABLED. Why? When doing load testing on a whim one of the 
guys decided to try it without the entity cache enabled, and the body of JMeter 
tests that exercised a few dozen of the most common user paths through the 
system actually ran FASTER. The database (MySQL in this case) was hit over the 
network, but responded quickly enough to make things work quite well for the 
various find queries, and FAR faster for updates, especially creates. This 
project was one of the higher volume projects I'm aware of for OFBiz, at peaks 
handling sustained processing of around 10 orders per second (36,000 per hour), 
with some short term peaks much higher, closer to 20-30 orders per second... 
and longer term peaks hitting over 200k orders in one day (north America only 
day time, around a 12 hour window).

I found this to be curious so looked into it a bit more and the main 
performance culprit was updates, ESPECIALLY creates on any entity that has an 
active list cache. Auto-clearing that cache requires running the condition for 
each cache entry on the record to see if it matches, and if it does then it is 
cleared. This could be made more efficient by expanding the reverse index 
concept to index all values of fields in conditions... though that would be 
fairly complex to implement because of the wide variety of conditions that CAN 
be performed on fields, and even moreso when they are combined with other 
logic... especially NOTs and ORs. This could potentially increase performance, 
but would again add yet more complexity and overhead. 

To turn this dilemma into a nightmare, consider caching view-entities. In 
general as systems scale if you ever have to iterate over stuff your 
performance is going to get hit REALLY hard compared to indexed and other less 
than n operations.

The main lesson from the story: caching, especially list caching, should ONLY 
be done in limited cases when the ratio of reads to write is VERY high, and 
more particularly the ratio of reads to creates. When considering whether to 
use a cache this should be considered carefully, because records are sometimes 
updated from places that developers are unaware, sometimes at surprising 
volumes. For example, it might seem great (and help a lot in dev and lower 
scale testing) to cache inventory information for viewing on a category screen, 
but always go to the DB to avoid stale data on a product detail screen and when 
adding to cart. The problem is that with high order volumes the inventory data 
is pretty much constantly being updated, so the caches are constantly... 
SLOWLY... being cleared as InventoryDetail records are created for reservations 
and issuances.

To turn this nightmare into a deal killer, consider multiple application 
servers and the need for either a (SLOW) distributed cache or (SLOW) 
distributed cache clearing. These have to go over the network anyway, so might 
as well go to the database!

In the case above where we decided to NOT use the entity cache at all 

Re: OFBiz and OHLOH (OpenHub.net

[David E. Jones]

A couple of corrections:

1. during that time without data available OFBiz was hosted as a java.net 
project (not on Undersun infrastructure); looking there I can't find any sign 
of it though... unlike SourceForce maybe they clean out projects and get rid of 
data

2. I did not create an OFBiz project on Openhub and have no admin access to 
either of the OFBiz listings there; they both show on my profile because my 
account is linked to the committer accounts for both

It would be great to have this history, but not sure if the data is available. 
I may have an archive somewhere (just looked on my laptop and couldn't find it, 
so would have to search old disks), but to get it into Openhub/Ohloh it would 
probably need to be hosted somewhere. The reason I say I might have an archive 
is that IIRC when we moved from java.net to the ASF we got a full dump of the 
SVN repo from java.net. That may still exist somewhere...

-David


On Sep 16, 2014, at 1:16 PM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:

 I found that David certainly created the OFBiz duplicate on Openhub 
 https://www.openhub.net/accounts/jonesde/positions
 He has commits almost from the start there, but with a hole between mid 2003 
 and the Apache Era (mid 2006)
 
 It would be good if we could merge the duplicate and add the missing commits 
 in between
 
 Jacques
 
 Le 16/09/2014 18:32, Jacques Le Roux a écrit :
 You might find interesting stuff here 
 https://web.archive.org/web/20060701213529/http://www.ofbiz.org/
 
 Jacques
 
 Le 16/09/2014 17:03, Pierre Smits a écrit :
 Yes they can.
 
 Actually there is a duplicate that has a sourceforge repository referenced
 as well. That duplicate has commit data prior to aug 2003.
 
 See: https://www.openhub.net/p/ofbiz
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 On Tue, Sep 16, 2014 at 4:42 PM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 Also, I wonder if openhub is able to concatenate (time ordered) the
 content of 2 svn repos?
 
 Jacques
 
 Le 16/09/2014 13:58, Jacques Le Roux a écrit :
 
  I remember BJ had a copy, not sure he is still listening...
 Jacques
 
 Le 16/09/2014 13:14, Pierre Smits a écrit :
 
 It would be good to have a complete and accurate history.
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 On Tue, Sep 16, 2014 at 1:13 PM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
  I fear the pre Apache era svn server (Undersun consulting) is no longer
 available.
 But maybe someone has a copy and could set a svn server?
 
 Jacques
 
 Le 16/09/2014 13:05, Pierre Smits a écrit :
 
  The openhub maintainers have informed me that commit data between
 2003-8-31
 and  2006-07-01 is missing.
 
 Does anybody know what was used to commit changes to and is that
 resource
 still available to be included in the OHLOH (openhub) page of OFBiz?
 
 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 Sat, Sep 13, 2014 at 11:25 AM, Pierre Smits pierre.sm...@gmail.com
 wrote:
 
   Hi all,
 
 The OFBiz page at OHLOH had gotten outdated since the OHLOH
 organisation
 moved to openhub.net.
 
 The stats have been updated, and can be found here:
 https://www.openhub.net/p/Apache-OFBiz
 
 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
 
 
 
 
 
 
 

Re: Removing the CachedClassLoader

[David E. Jones]

It may be fine to remove this, but I'd still recommend doing some performance 
tests with and without to make sure the impact isn't significant.

JVMs are much better these days about class loading, but 10 years ago that was 
not the case. The caching classloader alone resulted in something like a 20x 
performance increase for various things in OFBiz, mostly because OFBiz uses 
Java reflection so much to do things like run Java object methods for services 
and request events. 

In modern JVMs the performance different may be insignificant, but I'm not sure 
about that... some testing a couple years ago I still found a difference, 
though it wasn't as dramatic.

-David


On Sep 11, 2014, at 9:56 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:

 The CachedClassLoader was another performance improvement introduced by 
 David. I have always suspected (but never investigated thoroughly) that the 
 system class loader does some class caching on its own.
 
 I agree that class loading could be handled better - to solve jar version 
 conflicts for example. If I have a newer/older jar in my application, the 
 class loader should find it first, before looking in the OFBiz OOTB jar files.
 
 Anything that can be done to improve the class loader arrangement will be 
 wonderful.
 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com
 
 On 9/11/2014 5:46 PM, Jacopo Cappellato wrote:
 Hi all,
 
 after I spent a good amount of time studying how Java class loaders works 
 and are setup in OFBiz I realized that there was room for improving some old 
 code and simplify it a lot by removing the old and custom CachedClassLoader 
 that is created for each of the OFBiz web applications.
 
 I am pretty confident that this change will work well and that will make the 
 framework code that manages classloaders easier to read and maintain, and 
 will also be a small step in the direction of making OFBiz easier to deploy 
 on external application servers, with no penalties for performance.
 My preference would be to commit the code in the trunk (no API changes or 
 other impact for the applications and external configuration) and then let 
 you review my work.
 If, on the other hand, you prefer I submit a patch to Jira, I will be happy 
 too.
 
 Please let me know.
 
 Jacopo
 

Re: Discussion: migrating from Ant to Gradle

[David E. Jones]

With Moqui Framework I started using Ant and then migrated to Gradle. In doing 
so there are some things to be aware of:

1. because of the convention over configuration goal (defaults can generally be 
overridden, but it's a bit painful) it is a good idea to restructure things 
like the src directories to use the Maven style, ie things like src/main/java 
instead of plain src, and then along with that it's nice to split out things 
like src/main/groovy for groovy classes that are built (not scripts 
interpreted/compiled at runtime, those are best elsewhere), and 
src/main/resources instead of the various config directories and other 
classpath resources

2. jar files can still be kept locally (using a local repository), and lib 
directories with jars can even be included with a wildcard, but it is also 
possible to use Maven repositories to get the jar files by specifying each jar 
explicitly in the gradle build file; for Moqui I went with a combination of 
these, using a local directory repository but also listing all jar files 
explicitly in anticipation of maybe using a remote repository in the future 
(for various reasons I like to have all jar files in the source repo instead of 
downloading at build time; and this way you have more control over dependency 
creep that sometimes happens when you pull jars plus all their dependencies 
from a remote repo)

3. there are various API details to get used to with Gradle, much like learning 
the XML elements supported in Ant, but the documentation for Gradle is really 
pretty good and especially these days examples are plentiful

Overall using Gradle resulted in much simpler build files, it just takes care 
of a lot of things automagically that are pretty manual with Ant. OFBiz has 
some impressively complex build files that could perhaps be simplified a lot 
with Gradle (and/or made more flexible with support for Groovy scripting and 
the Gradle DSL).

On a side note, using Spock for testing is very easy with Gradle... though not 
sure how it compares to using it with Ant as I've never tried it.

Hope that helps...

-David



On Aug 21, 2014, at 6:48 AM, Al Byers bye...@automationgroups.com wrote:

 As a pro it should stated that migrating to gradle would - wait for it -
 help in the migration to and/or from moqui.org, as it is one its many
 advanced built-in tools. I appreciate the groovy-everywhere consistency of
 moqui and believe that it would be a good direction for OFBiz to head.
 
 
 On Thu, Aug 21, 2014 at 7:17 AM, Jacopo Cappellato 
 jacopo.cappell...@hotwaxmedia.com wrote:
 
 
 On Aug 21, 2014, at 12:40 PM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 I think you did not get me right. Like I have explained to Ron, branches
 are not only to get stabilised releases. So my idea would be to have a new
 feature branch where we can make the desired changes before merging them in
 the trunk, when happy with them.
 
 This is for instance what I did for the jQuery move. What I did also for
 the missed Tom Burn's new help (now a Neogia addon I have been told). And
 what I'm doing for the SEO branch I created for OFBIZ-5312 which I want to
 merge back in trunk before we freeze a branch for the next release.
 
 So yes it's a bit a burden, but it's a way to (more) safely integrate
 new features in the trunk.
 
 Jacques
 
 Experimental branches are useful for running experiments that impact a
 large amount of code or require several commits (and committers) to be
 completed; especially when the community is divided about the opportunity
 to integrate them. The examples you provided belongs to this group... the
 ant-gradle switch I am not sure because we could easily implement the
 gradle scripts while leaving the ant scripts in place and then remove the
 ant scripts only when we will have enough confidence.
 But really it is too early to talk about how to do this work... at the
 moment we can just focus on the pros/cons of this switch.
 
 Jacopo
 
 

Re: The future of OFBiz - Open Discussion

[David E. Jones]

 more difficult to do within the OFBiz software and community. 
That doesn't mean OFBiz or its governance model is bad in any way, just not 
what I was personally looking for. Consider that I made that decision even in 
the position some seem to with they had and are complaining loudly in some 
seeming sort of hope to get into without going through the years of effort 
required in the established governance model. It leaves me wondering what the 
hell certain people are trying to do. I don't get it. I asked in some of my 
other recent posts and still see no answer, and still don't get what the goal 
of all of this is or how in any way something good might come of it. 

Maybe starting with an explanation of one's own motive might be more effective 
that straw-man attacks against the motives of others...

-David



On Mar 18, 2014, at 4:03 PM, Ean Schuessler e...@brainfood.com wrote:

 - Paul Piper p...@ilscipio.com wrote:
 
 I am not biased against HWM, but what I question is the objectivity
 that is
 currently used within this project. As an open source software, you
 would
 assume that this project is run by the community - as often claimed
 by
 anybody within the PMC. If you look at the current list of members and
 there
 personal relations, I would argue that there is at least a
 conflicting
 perspective: 
 
 
 PMC Members with HWM background
 * Jacopo Cappellato (V.P. Technology - Hotwax Media)
 * Scott Gray (Developer - Hotwax Media)
 * Bilgin Ibryam (Former Hotwax Developer)
 * David E. Jones (Former CTO Hotwax Media)
 * Anil Patel (COO Hotwax Media)
 * Ashish Vijaywargiya (Vice President of Operations at HotWax Media)
 * Andrew Zeneski (former CIO Hotwax Media)
 
 ---
 Other PMC members
 * Adrian Crum
 * Hans Bakker
 * Jacques le Roux
 * Erwan de Ferrieres
 * Adam Heath
 * David Welton
 
 I suppose the conspiracy at work here is the same flavor of conspiracy
 that dominates the development of the GCC compiler or the Linux kernel.
 One might look at these efforts and conclude that there is a conspiracy
 on Red Hat's part to control these software systems. It is true that 
 Red Hat has conspired to create a vast organization with influence in 
 many corners of the globe, however, I believe that a more suitable label 
 for this conspiracy is commercial success.
 
 A protracted discussion about why the most visibly successful implementer
 of the project's software holds unfair sway doesn't strike me as 
 productive. If you want to change that, go back to building your business
 and hire more firepower than they have. All of us will benefit.
 
 As David Jones readily demonstrates, if you have new ideas you can
 always write new code. Moqui is a more powerful statement than anything you
 can say on a conference call.
 
 -- 
 Ean Schuessler, CTO
 e...@brainfood.com
 214-720-0700 x 315
 Brainfood, Inc.
 http://www.brainfood.com

Re: The future of OFBiz - Open Discussion

[David E. Jones]

Thank you Scott. This is an inspiring reminder of how things actually work in 
the ASF. Apache OFBiz is not managed top-down, it is managed bottom-up based on 
actual effort and merit. Discussions really only matter if they lead up to an 
effort that results in actual code/doc/etc changes.

Pierre's message to the Board is a great example of misunderstanding this 
guiding principle, so I responded in more detail in that thread, but just 
wanted to throw in my +1 for what you wrote here.

-David


On Mar 12, 2014, at 11:52 PM, Scott Gray scott.g...@hotwaxmedia.com wrote:

 
 I won't be attending simply because it is organized by Pierre (and because 
 the genesis of this meeting seems to have come from a very negative 
 perspective). Those of you who are new to the community or who he is polite 
 to may not be aware of how rude Pierre can be.  While he does do some good 
 work from time to time I believe his presence in the community causes more 
 harm than good.  He has almost continuously attacked or worked against the 
 PMC for the last year or two and I simply have no interest in hearing 
 anything he has to say any longer.  Almost no one seems to remember that he 
 told the ASF he would chair an OFBiz presence at an ApacheCon a year or so 
 ago, it was advertised, calls for papers/talks were made and submitted and 
 then not long before the conference... he disappeared with no explanation to 
 anyone.  PMC members were forced to attend the conference (that he organized 
 without consulting the PMC at all) and chair in his place on short notice to 
 maintain the credibility of the project.  As far as I know he has never 
 apologized to or thanked those who took his place and never offered an 
 explanation, he simply reappeared 6 months later and carried on causing 
 trouble as usual.  I have a hard time believing Pierre will ever be a 
 committer or core contributor to this project so long as he continues to 
 spectacularly fail at working well with others (this is just my opinion, I'm 
 only one voice of many in the community).  While I believe he is a 
 destructive force in the community, there is nothing I can do about that, 
 everyone is pretty much free to do as they please.  It's up to each and every 
 one of you to decide what he brings to the table and interact with him 
 accordingly.
 
 People talk about PMC hidden agendas and other conspiracy theories but 
 often the reality is that it can be difficult to find motivation to work on a 
 project that is constantly critical of the work you do.  When I joined this 
 project there was very little infighting and contributing was a rewarding 
 experience that earned you respect and praise from your peers.  It's a warm 
 fuzzy feeling that keeps you active at nights and on weekends working on 
 something you're passionate about.  For me, that passion is fast disappearing 
 because of people like Pierre (he is certainly not the first but he is 
 particularly vocal).  It feels like I'm regularly reading critical emails 
 from various community members, either of the way the project is run or the 
 way the project is progressing.  What I very rarely see is any action behind 
 the talk; people suggest major changes and then carry on with their day.  No 
 one actually gets anything done.  I'm sure some of you would replace the 
 entire PMC given half the chance and that may seem like some great 
 achievement, but eventually...  you're going to have to actually do something 
 tangible to keep the community happy and achieve the goals you speak of.  If 
 you're not doing anything tangible now, then you're as much a part of the 
 problem as anyone else, take pause before you throw those stones.  You're 
 being critical of those who have stayed when others have come and gone, those 
 who have contributed more unpaid hours than most.
 
 How many of you can claim that you do the work in project that would match 
 what you'd like to see from a committer or PMC member?  There is absolutely 
 nothing stopping you from making that type of contribution right now, so what 
 is the issue?
 
 For those of you who have an opinion but aren't actually doing anything 
 tangible (commit reviews, patch reviews, ticket research, contributing 
 designs and documentation), the brighter future of OFBiz starts with you.  Be 
 the change that you want to see, go and do something productive for the 
 project instead of complaining about what others are not doing.  Just to be 
 clear, contributing to general discussions isn't much of a contribution, it's 
 extremely rare that they result in anything positive actually happening.
 
 Regards
 Scott
 
 
 On 7/03/2014, at 9:00 PM, Pierre Smits wrote:
 
 Hi All,
 
 I invite you to join me and participate in an open discussion on the
 functioning and future of OFbiz via a teleconference on March 13, 2014.
 
 Share your thoughts and insights on how you feel it going and what you
 would like to see addressed in the project. Plus, it is a 

Re: OFBiz JSON Classes

[David E. Jones]

Why have our own stuff at all? There are good JSON parsers and generators 
around, one of the best for automatic type conversions and such being the one 
built into Groovy (JsonSlurper, JsonBuilder, JsonOutput, etc).

-David


On Oct 20, 2013, at 8:28 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:

 Does anyone know why we are using a JJ compiler to generate the JSON classes 
 in framework/base? It seems to me we could start off with compiler-generated 
 code, then improve it by hand.
 
 -- 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com

Re: OFBiz In 2014

[David E. Jones]

On Jan 6, 2014, at 5:09 AM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:

 On Monday, January 06, 2014 10:03 AM, jacopo.cappell...@hotwaxmedia.com wrote
 Then, here is my personal wish list:
 
 * integrate Atomikos Transaction Manager (to replace the existing old and 
 incomplete Geronimo Transaction Manager); I did most
 of the work some time ago and also Scott helped me; but the effort is not 
 completed (but we are close); this is on hold at the
 moment and it would be great to give it a final push
 
 Just as a note: it seems David experienced some issue with Atomikos in Moqui 
 OOTB http://tinyurl.com/pwefeoo
 And you have sometimes to use workaround config (Postgres needs it for 
 instance, reported David)

Related to this I've been testing more with Bitronix BTM recently and it seems 
to be doing much better than Atomikos in various scenarios. Part of my 
frustration with Atomikos is the lack of bug fixes going into open source 
releases. They put them in the subscriber-only releases for a few months to 
over a year before putting them in the open source releases, meaning the lag 
time for bug fixes and support for open source users (including open source 
projects that may be used commercially) is significant.

-David

Re: OFBiz In 2014

[David E. Jones]

One way to make the OFBiz Form/Screen/etc widgets more useful and extensible 
would be to take another step beyond what Jacopo did a number of years ago with 
the FTL macros to produce HTML/CSV/XML/etc.

The current implementation in OFBiz parses the XML file into Java classes and 
then when rendering generates macro calls to pass the parameters (XML attribute 
values, etc) to the FTL macros. A more flexible and extensible approach is to 
use the FTL XML processing features directly instead of going through Java 
classes. With this approach adding an attribute or support for a whole new 
element in the widget XML files is just a matter of adding it to the FTL macros 
that process XML elements.

This is the approach that Moqui Framework uses and it makes it much easier to 
improve the supported elements in the framework itself, and for users to add 
their own elements without touching any framework code or templates (using a 
FTL macros file that includes and then overrides and/or expands the XML 
processing macros). For example the FTL macro for processing the text-area 
element for a form field looks like this (from the DefaultScreenMacros.html.ftl 
file; this of course has some Moqui-specific stuff in it, but the general 
pattern would be the same in OFBiz):

#macro text-area
textarea name=@fieldName .node/ cols=${.node[@cols]!60} 
rows=${.node[@rows]!3}#if .node[@read-only]!false == true 
readonly=readonly/#if#if .node[@maxlength]?has_content 
maxlength=${.node[@maxlength]}/#if id=@fieldId .node/#if 
.node?parent[@tooltip]?has_content 
title=${.node?parent[@tooltip]}/#if${sri.getFieldValueString(.node?parent?parent,
 .node[@default-value]!, null)?html}/textarea
/#macro

As you can see there are no parameters to the FTL macro, it just uses the 
built-in .node variable that FTL makes available when processing XML elements 
to get attributes, child elements, parent elements, etc.

This is still server-side HTML generation, but would make the tool more 
flexible. The current approach in OFBiz supports users changing the text output 
and could actually be used to drive files that are used for client-side HTML 
generation, this just makes it a bit easier to do so and to use the widget XML 
files for more instead of having to revert to plain FTL files or some other 
tool for the UI (and doing so for the entire screen/form/etc as opposed to just 
doing so for certain complex parts of it).

Another enhancement is some simple tags to drop in HTML in various places (FTL 
templates or whatever). This can currently be done in OFBiz in various parts of 
screen widgets, but for form widget fields and other places it would be useful.

-David


On Jan 6, 2014, at 10:09 AM, Ean Schuessler e...@brainfood.com wrote:

 I agree that we should migrate FTL templates to ofbiz widgets for the sake
 of consistency throughout the interfaces. However, I do have to say that
 I would not use form widgets to develop a customer facing site. At this
 point, Brainfood is pretty much at a consensus that we do not want to do
 page template oriented development in the server at all. When you look at
 applications like Google Maps it becomes clear that the send post, alter
 state, regenerate and send page workflow is incredibly limited. The future
 seems to look a lot more like applications written in Javascript that
 generate HTML directly in the browser.
 
 So, for us, the important feature is the JSON-RPC interface for this remote
 applications. It would be genuinely interesting if we could write a client
 side form widget interpreter that would delegate generation of the interface
 to the client side and then supply the action interface via AJAX. That is
 something we would be very interested in.
 
 Refactoring the widget generation code to support greater modularity in the 
 HTML
 could be another target of such an effort. I made some modest efforts towards
 a Bootstrap based OFBiz theme and I found it difficult to make progress with 
 the
 current setup.
 
 - Gavin Mabie kwikst...@gmail.com wrote:
 
 It appears that the citing of Drupal/WordPress/Magento solicited quite
 a
 lot of comment.  It's a side issue really and whether some houses
 prefer to
 integrate existing solutions is besides the point.  More importantly,
 most
 commentators would agree that theme developement in Ofbiz does require
 more
 attention.  The vast majority of threads on this ML focuss on backend
 business rules and processes.  That in itself is not a problem - if
 you
 regard Ofbiz as a Framework only.  It only means that, as far as
 frameworks
 go, we need a better framework for theming as well.  This will
 encourage
 more participation from developers who have more of a front-end
 orientation.  I would support a drive towards better themeability
 in
 2014.  In this regard I would like to suggest that we take a look at
 the
 VisualThemeResource entity which currently is currently poorly
 defined.
 
 Gavin
 
 -- 
 Ean Schuessler, CTO
 

Re: OFBiz In 2014

[David E. Jones]

One of my top annoyances with OFBiz coding is the inconsistency of tools, 
especially the scripts and expressions within widgets and simple-methods.

A first step would be to make all expressions, conditions, etc use Groovy 
instead of JUEL and the bits of BeanShell that are still used. Groovy has a lot 
of convenient stuff that JUEL and BeanShell do not, and when coding I find it 
takes so much more work to understand and work with the differences and the 
more cumbersome syntax that I (and I've noticed many others) hacking around 
this limitation with the ${groovy: ...} expressions, which are fine but then 
have type conversion issues as this is really a string expansion syntax. The 
whole FlexibleStringExpander could just call into Groovy for evaluation instead 
of the various things plus calling into JUEL that it currently does.

A bigger step would be to change the simple-method processing to be just a FTL 
template that creates a Groovy script from the XML, and then compile/cache/run 
the Groovy script. This has the added benefits of dramatically simplifying the 
framework code (no need for a Java class for each XML element), and makes it 
easy to do inline Groovy scripts in simple-methods.

With either approach it would be nice to make the simple-method and 
screen/form/etc actions blocks use the same XSD and be processed the same way 
for better consistency (fewer surprises during dev and testing, more general 
flexibility too).

As I do development with both Moqui and OFBiz I find this to be one of the 
biggest differences that makes working with Moqui Framework faster and less 
frustrating than with OFBiz. There are many differences between the two 
frameworks, but this one stands out to me as perhaps the most significant when 
working day-to-day, and should be one of the easier ones to incorporate. Most 
existing expressions written for JUEL should evaluate fine in Groovy, but some 
would have to change... that would be the biggest impact of this change on 
existing code.

-David


On Dec 31, 2013, at 4:55 AM, Adrian Crum adrian.c...@sandglass-software.com 
wrote:

 Maybe we can use the start of the new year as an opportunity to consider the 
 future of OFBiz and update our road map:
 
 https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
 
 
 -- 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com

Re: OFBiz In 2014

[David E. Jones]

On Jan 6, 2014, at 12:26 PM, adrian.c...@sandglass-software.com wrote:

 There are two problems with using DOM trees in OFBiz:
 
 1. They consume a lot of memory. Keep in mind the entire XML file is kept in 
 memory, not just the bits you are interested in.

The parsed version is kept in memory, that is true, but for each 
screen/form/etc you just keep the node object for the top-level element. Under 
that element the only stuff it would keep around by default that you don't 
need/want (but could be eliminated with a little code) is comment elements.

 2. They are not thread-safe.

They should be used read-only, so unless someone does something funny thread 
safety isn't an issue. On that note, the same is true for the shared objects in 
the current OFBiz widget implementations.

-David


 I did some refactoring a while ago where I replaced that approach with a 
 thread-safe approach. But that was done in other parts of the framework, not 
 in the screen widgets.
 
 -Adrian
 
 Quoting David E. Jones d...@me.com:
 
 
 One way to make the OFBiz Form/Screen/etc widgets more useful and extensible 
 would be to take another step beyond what Jacopo did a number of years ago 
 with the FTL macros to produce HTML/CSV/XML/etc.
 
 The current implementation in OFBiz parses the XML file into Java classes 
 and then when rendering generates macro calls to pass the parameters (XML 
 attribute values, etc) to the FTL macros. A more flexible and extensible 
 approach is to use the FTL XML processing features directly instead of going 
 through Java classes. With this approach adding an attribute or support for 
 a whole new element in the widget XML files is just a matter of adding it to 
 the FTL macros that process XML elements.
 
 This is the approach that Moqui Framework uses and it makes it much easier 
 to improve the supported elements in the framework itself, and for users to 
 add their own elements without touching any framework code or templates 
 (using a FTL macros file that includes and then overrides and/or expands the 
 XML processing macros). For example the FTL macro for processing the 
 text-area element for a form field looks like this (from the 
 DefaultScreenMacros.html.ftl file; this of course has some Moqui-specific 
 stuff in it, but the general pattern would be the same in OFBiz):
 
 #macro text-area
textarea name=@fieldName .node/ cols=${.node[@cols]!60} 
 rows=${.node[@rows]!3}#if .node[@read-only]!false == true 
 readonly=readonly/#if#if .node[@maxlength]?has_content 
 maxlength=${.node[@maxlength]}/#if id=@fieldId .node/#if 
 .node?parent[@tooltip]?has_content 
 title=${.node?parent[@tooltip]}/#if${sri.getFieldValueString(.node?parent?parent,
  .node[@default-value]!, null)?html}/textarea
 /#macro
 
 As you can see there are no parameters to the FTL macro, it just uses the 
 built-in .node variable that FTL makes available when processing XML 
 elements to get attributes, child elements, parent elements, etc.
 
 This is still server-side HTML generation, but would make the tool more 
 flexible. The current approach in OFBiz supports users changing the text 
 output and could actually be used to drive files that are used for 
 client-side HTML generation, this just makes it a bit easier to do so and to 
 use the widget XML files for more instead of having to revert to plain FTL 
 files or some other tool for the UI (and doing so for the entire 
 screen/form/etc as opposed to just doing so for certain complex parts of it).
 
 Another enhancement is some simple tags to drop in HTML in various places 
 (FTL templates or whatever). This can currently be done in OFBiz in various 
 parts of screen widgets, but for form widget fields and other places it 
 would be useful.
 
 -David
 
 
 On Jan 6, 2014, at 10:09 AM, Ean Schuessler e...@brainfood.com wrote:
 
 I agree that we should migrate FTL templates to ofbiz widgets for the sake
 of consistency throughout the interfaces. However, I do have to say that
 I would not use form widgets to develop a customer facing site. At this
 point, Brainfood is pretty much at a consensus that we do not want to do
 page template oriented development in the server at all. When you look at
 applications like Google Maps it becomes clear that the send post, alter
 state, regenerate and send page workflow is incredibly limited. The future
 seems to look a lot more like applications written in Javascript that
 generate HTML directly in the browser.
 
 So, for us, the important feature is the JSON-RPC interface for this remote
 applications. It would be genuinely interesting if we could write a client
 side form widget interpreter that would delegate generation of the interface
 to the client side and then supply the action interface via AJAX. That is
 something we would be very interested in.
 
 Refactoring the widget generation code to support greater modularity in the 
 HTML
 could be another target of such an effort. I made some modest efforts 
 towards

Re: OFBiz In 2014

[David E. Jones]

I can't think of any reason to do it different from how it is now, ie the 
parsed version of the files are cached by their filename which is independent 
of the tenant. You can have files that are used by only one tenant, but any 
files that are used by more than one would be shared.

-David


On Jan 6, 2014, at 12:58 PM, Pierre Smits pierre.sm...@gmail.com wrote:

 Re: parsed version is kept in memory.
 Would that be per tenant in a multi tenant setup or only once per running
 Ofbiz instance?
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

Re: OFBiz In 2014

[David E. Jones]

On Jan 6, 2014, at 12:58 PM, adrian.c...@sandglass-software.com wrote:

 Quoting David E. Jones d...@me.com:
 
 
 On Jan 6, 2014, at 12:26 PM, adrian.c...@sandglass-software.com wrote:
 
 There are two problems with using DOM trees in OFBiz:
 
 1. They consume a lot of memory. Keep in mind the entire XML file is kept 
 in memory, not just the bits you are interested in.
 
 The parsed version is kept in memory, that is true, but for each 
 screen/form/etc you just keep the node object for the top-level element. 
 Under that element the only stuff it would keep around by default that you 
 don't need/want (but could be eliminated with a little code) is comment 
 elements.
 
 2. They are not thread-safe.
 
 They should be used read-only, so unless someone does something funny thread 
 safety isn't an issue. On that note, the same is true for the shared objects 
 in the current OFBiz widget implementations.
 
 
 And that is the problem we have now. Many contributors/committers will not 
 understand what should and shouldn't be done with DOM nodes, and consequently 
 they will do things they shouldn't. History has proven that, given the 
 opportunity, OFBiz developers will do something funny with the code.
 
 Over the last few years, the framework code-base has been moving toward 
 immutable shared objects, and I think that is the safest strategy to use. We 
 have fixed numerous bugs going that route.
 
 I understand your perspective and I appreciate it - make code thread-unsafe 
 for the sake of convenience. But that strategy exists currently in OFBiz 
 legacy code and it keeps hurting us.
 
 What I find interesting about your proposal is how similar it is to what I 
 proposed years ago - make the widgets lightweight representations of their 
 XML files. The screen widget models would contain Lists of model Elements, 
 and the model Elements would contain Maps of Element Attributes. At the time 
 you rejected that idea - you said performance would suffer by making the 
 widget models that generic. Now you're suggesting we skip the models 
 altogether and just use the DOM tree. So, what has changed your opinion?

My concerns about performance were clearly overblown. After trying the direct 
node tree and profiling performance I now know it doesn't result in much of a 
performance difference.

In other words, the direction you proposed is a good one and would simplify 
code, and letting FTL walk the node tree instead of Java code is just as fast 
and that little step eliminates a bunch more framework code and at the same 
time makes it far more flexible and extensible. IMO the minor impact on runtime 
performance is well worth the additional flexibility. It makes the tools usable 
in so many more situations where you would otherwise need to drop to plain FTL 
instead of using the form widget or certain parts of the screen widget, and 
addresses many of the concerns that push people to using other web UI 
frameworks.

BTW, from profiling work in Moqui Framework I found it was really other stuff 
that killed performance, little things you wouldn't expect sometimes like how 
long it takes to call System.currentTimeMillis(). FTL and Groovy are 
impressively fast for what they do and JVMs do so much better with Map and List 
operations (iteration, add/put, get, etc) than they did when OFBiz was young, 
especially once the JIT natively compiles that frequently used code, that the 
overhead barely shows up in profiling results.

BTW2, in early profiling a few years ago with Groovy there was noticeable 
overhead from on the fly object and method binding and such, but much of this 
changed with Groovy 2 when they incorporated features from Groovy++ to more 
quickly bind based on types declared or casted in the code, so it runs quite a 
bit faster with a little more effort in declaring types (as opposed to using 
Object or def all over the place). There is still somewhat of a performance 
difference in doing simplified method names (like foo.bar versus foo.getBar()), 
but even that doesn't show up in profilers like it used to with Groovy (so all 
the effort I put into Moqui making such changes don't matter so much any more 
:) ).

One thing about thread safety with this approach is that there is SO little 
code, the vast bulk of it is in the FTL macros. The framework code just has to 
parse the XML file, grab the desired top-level node, wrap it so FTL can use it 
(in Moqui I implemented a simple wrapper for the Groovy Node object to 
implement the FTL node interface), then pass it to FTL when rendering the 
template. That's really it. The FTL macros will also need framework code to 
call back into to do things like including forms, FTL files, other screens, 
etc... but that is also pretty small/simple code.

I was hesitant about this approach at first, in spite of the great flexibility, 
but in Moqui it has worked well... the code for that is about 3 years old now 
with hundreds of screens running on various production

Re: Proposal: convert all platform dependent scripts under tools to Groovy scripts

[David E Jones]

Moqui does use groovy for a lot more, including all expressions (no juel) and 
all string expansions. Moqui does not have any deployment scripts other than 
ant/gradle tasks because it deploys as a single war file so it uses whatever 
the server container uses, ie the Tomcat or Jetty or whatever scripts.

-David


On Aug 20, 2013, at 2:18, Jacques Le Roux jacques.le.r...@les7arts.com wrote:

 That sounds like a good idea indeed, I guess that's what Moqui already does, 
 right?
 
 Are there any restrictions/constraints compared with OS scripting languages?
 
 Jacques
 
 - Original Message - 
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 To: dev@ofbiz.apache.org
 Sent: Tuesday, August 20, 2013 9:48 AM
 Subject: Proposal: convert all platform dependent scripts under tools to 
 Groovy scripts
 
 
 Hi all,
 
 the proposal is about migrating all the *.sh and *bat scripts to *groovy 
 scripts: as you know Groovy scripts can be called from the command line and 
 executed like OS scipts.
 The only prerequisite is to have the Groovy jars in the classpath, but this 
 is easy to implement since it is already included in the OFBiz distribution.
 In this way we could have less platform dependent files and scripts written 
 in a language that is already widely used in OFBiz.
 
 What do you think?
 
 Jacopo
 
 
 

Re: svn commit: r1458429 - /ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java

[David E. Jones]

Sorry, just noticed this. Yes, it probably applies to 12.04 as well.

-David


On Mar 20, 2013, at 2:57 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 Hi David,
 
 is it ok if I backport this also to the 12.04 branch?
 
 Jacopo
 
 On Mar 19, 2013, at 6:48 PM, jone...@apache.org wrote:
 
 Author: jonesde
 Date: Tue Mar 19 17:48:28 2013
 New Revision: 1458429
 
 URL: http://svn.apache.org/r1458429
 Log:
 Fixed issue with deserialization from XML of an entity value with null fields
 
 Modified:
   ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
 
 Modified: 
 ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
 URL: 
 http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java?rev=1458429r1=1458428r2=1458429view=diff
 ==
 --- ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java 
 (original)
 +++ ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java 
 Tue Mar 19 17:48:28 2013
 @@ -2377,7 +2377,13 @@ public class GenericDelegator implements
String attr = element.getAttribute(name);
 
if (UtilValidate.isNotEmpty(attr)) {
 -value.setString(name, attr);
 +// GenericEntity.makeXmlElement() sets null values to 
 GenericEntity.NULL_FIELD.toString(), so look for
 +// that and treat it as null
 +if (GenericEntity.NULL_FIELD.toString().equals(attr)) {
 +value.set(name, null);
 +} else {
 +value.setString(name, attr);
 +}
} else {
// if no attribute try a subelement
Element subElement = UtilXml.firstChildElement(element, name);
 
 
 

Re: svn commit: r1458429 - /ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java

[David E. Jones]

It could be. Wow. That issue is a mess. If it is related it looks like this bug 
was caused by the fix for that issue.

-David


On Mar 21, 2013, at 4:56 PM, Paul Foxworthy p...@cohsoft.com.au wrote:

 Hi David and Jacopo,
 
 is this change related to Jira issue OFBIZ-4602?
 
 Thanks
 
 Paul Foxworthy
 
 
 Jacopo Cappellato-4 wrote
 Hi David,
 
 is it ok if I backport this also to the 12.04 branch?
 
 Jacopo
 
 On Mar 19, 2013, at 6:48 PM, 
 
 jonesde@
 
 wrote:
 
 Author: jonesde
 Date: Tue Mar 19 17:48:28 2013
 New Revision: 1458429
 
 URL: http://svn.apache.org/r1458429
 Log:
 Fixed issue with deserialization from XML of an entity value with null
 fields
 
 Modified:
 
 ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
 
 Modified:
 ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
 URL:
 http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java?rev=1458429r1=1458428r2=1458429view=diff
 ==
 ---
 ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
 (original)
 +++
 ofbiz/trunk/framework/entity/src/org/ofbiz/entity/GenericDelegator.java
 Tue Mar 19 17:48:28 2013
 @@ -2377,7 +2377,13 @@ public class GenericDelegator implements
String attr = element.getAttribute(name);
 
if (UtilValidate.isNotEmpty(attr)) {
 -value.setString(name, attr);
 +// GenericEntity.makeXmlElement() sets null values to
 GenericEntity.NULL_FIELD.toString(), so look for
 +// that and treat it as null
 +if (GenericEntity.NULL_FIELD.toString().equals(attr)) {
 +value.set(name, null);
 +} else {
 +value.setString(name, attr);
 +}
} else {
// if no attribute try a subelement
Element subElement = UtilXml.firstChildElement(element,
 name);
 
 
 
 
 
 
 
 -
 --
 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/Re-svn-commit-r1458429-ofbiz-trunk-framework-entity-src-org-ofbiz-entity-GenericDelegator-java-tp4639948p4639969.html
 Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Proposal: Entity Subtype Implementation

[David E Jones]

If any single entity were to be used for types instead of one per type, why not 
Enumeration? And yes, that is what I did with the Mantle data model.

Still, I agree with Jacopo... It is not worth the change repercussions for 
OFBiz. What you described is a problem with lack of research and/or experience, 
and I don't think what you described would be any more helpful.

-David


On Oct 6, 2012, at 10:19, Adrian Crum adrian.c...@sandglass-software.com 
wrote:

 So your opinion has changed...
 
 http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201103.mbox/%3c82330f5c-3938-487e-98ae-ffee0c876...@hotwaxmedia.com%3E
 
 -Adrian
 
 
 On 10/5/2012 10:23 AM, Jacopo Cappellato wrote:
 HelloAdrian,
 
 in my opinion it would be better to leave the data model as is, but improve 
 the descriptions of the types (and documentation, in the form of comments to 
 xml data) and also enhnce our utils to deal with types (the Product already 
 has something in place).
 
 Regards,
 
 Jacopo
 
 On Oct 1, 2012, at 8:14 AM, Adrian Crum wrote:
 
 I mentioned this once before as part of another discussion, but I'm 
 creating a new discussion so it can receive the attention it deserves.
 
 The Data Model Resource Book describes entity subtypes. OFBiz implements 
 entity subtypes by adding a field to the supertype that points to a *Type 
 entity that contains valid subtypes.
 
 The problem is users (and some developers) do not understand that pattern, 
 and they add invalid subtypes to the *Type entity. That can cause things to 
 break. As an example, I have a client who created additional ProductTypes 
 (that actually represented product categories) and used those added 
 ProductTypes for their products. Then they were puzzled why their order 
 fulfillment process stopped working.
 
 I think what we need is an EntitySubtype entity to store the subtype data. 
 Instead of multiple *Type entities, we would have a single EntitySubtype 
 entity, and the supertypes will point to it. The supertype field could be 
 called something like entitySubtypeId. The EntitySubtype entity will be 
 clearly documented as to its purpose and proper use.
 
 EntitySubtype
 -
 entityName*
 entitySubtypeId*
 description
 
 What do you think?
 
 -Adrian
 

Re: Removing some unnecessary synchronization for cache objects

[David E Jones]

Looks like a good pattern.

-David


On May 28, 2012, at 9:27 AM, Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com wrote:

 Please also review the following commit because it is another pattern I am 
 going to apply to other code:
 
 
 On May 28, 2012, at 5:25 PM, jaco...@apache.org wrote:
 
 Author: jacopoc
 Date: Mon May 28 15:25:46 2012
 New Revision: 1343278
 
 URL: http://svn.apache.org/viewvc?rev=1343278view=rev
 Log:
 Improved code that manages the cache:
 * protected the UtilCache object (static field) by making it private and 
 final
 * instead of using the put method, use the putIfAbsentAndGet method to 
 prevent the risk of adding the new value if another concurrent thread added 
 it in the meantime
 
 
 Modified:
   
 ofbiz/trunk/framework/base/src/org/ofbiz/base/util/template/XslTransform.java
 
 Modified: 
 ofbiz/trunk/framework/base/src/org/ofbiz/base/util/template/XslTransform.java
 URL: 
 http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/template/XslTransform.java?rev=1343278r1=1343277r2=1343278view=diff
 ==
 --- 
 ofbiz/trunk/framework/base/src/org/ofbiz/base/util/template/XslTransform.java
  (original)
 +++ 
 ofbiz/trunk/framework/base/src/org/ofbiz/base/util/template/XslTransform.java
  Mon May 28 15:25:46 2012
 @@ -56,7 +56,7 @@ import javax.xml.transform.stream.Stream
 public final class XslTransform {
 
public static final String module = XslTransform.class.getName();
 -public static UtilCacheString, Templates xslTemplatesCache = 
 UtilCache.createUtilCache(XsltTemplates, 0, 0);
 +private static final UtilCacheString, Templates xslTemplatesCache = 
 UtilCache.createUtilCache(XsltTemplates, 0, 0);
 
/**
 * @param template the content or url of the xsl template
 @@ -116,7 +116,7 @@ public final class XslTransform {
Source templateSource = getSource(templateDocument, templateUrl, 
 templateString);
translet = tFactory.newTemplates(templateSource);
if (UtilValidate.isNotEmpty(templateName)) {
 -xslTemplatesCache.put(templateName, translet);
 +translet = 
 xslTemplatesCache.putIfAbsentAndGet(templateName, translet);
}
}
if (translet != null) {
 
 
 
 Jacopo
 

Re: Move AR and AP web applications our of Accounting into Extras

[David E Jones]

When I first saw the subject I was thinking this as well.

I always wondered why those were created as separate applications,
perhaps for permission reasons I suppose. In a way they make more sense
as part of the accounting webapp instead of in separate ones.

-David



Pierre Smits wrote:
 - 1
 
 Accounts payable (AP) and accounts receivable (AP) are together with the
 ability to process accounting transactions the core ingredients of a good
 FICO solution. Without both any accountant will state that your accounting
 solution is worthless. Without both core accounting components you (as a
 company) would have no overview of money owed to you or that you owe to
 others.
 
 Regards,
 
 Pierre
 
 
 Op 7 april 2012 19:41 schreef Jacques Le Roux
 jacques.le.r...@les7arts.comhet volgende:
 
 +1
 Jacques


 Anil Patel wrote:

 Hi,
 Like lot of other stuff, I think AR and AP applications should be moved
 out of Ofbiz Accounting component. As such they are
 special purpose application, but again not core to Ofbiz application
 framework.
 I recommend we should relocate AR and AP webapplications out of Ofbiz
 Accounting to Ofbiz Extras. If we as community agree, I'll
 put efforts to complete the job.
 Thanks and Regards
 Anil Patel
 HotWax Media Inc

 

Re: Discussion: Mini-language Overhaul

[David E Jones]

Some editors, like IntelliJ IDEA, do actually support scripts embedded
in other files. I use this quite a bit for groovy scripts embedded in
XML... but it doesn't work so well for groovy expressions because it
only works when you define object types for variables and such.

-David


Adrian Crum wrote:
 https://cwiki.apache.org/confluence/display/OFBTECH/Unified+Expression+Language+%28JSR-245%29+in+OFBiz
 
 
 I don't know if there is a UEL editor with auto-completion. I don't know
 if it would work if you found one, since you are editing XML, not UEL.
 
 -Adrian
 
 On 3/15/2012 2:36 PM, Nicolas Malin wrote:
 others suggestions :
  * deprecate find-by-primary-key and find-by-and, use entity-one and
 entity-and instead.
  * field-map inherits from set attribute (except field-name)
  * change make-next-seq-id.seq-field-name by
 make-next-seq-id.seq-field (for coherence)
  * add filter-list-by-condition element
  * add sub-element condition-expr-mapping with operator, join to run
 an auto-mapping between entity and context:
  EX1 :
 entity-condition entity-name=Person
 condition-expr-mapping operator=contains combine=or
 exclude field-name=description/
 /condition-expr-mapping
 /entity-condition

  EX2 :
 entity-condition entity-name=PartyPersonView
 condition-list combine=and
 condition-expr-mapping/
 condition-expr field-name=statusId value=PARTY_ENABLED/
 /condition-list
 /entity-condition

 Just an ask on UEL,is there a completion to help young developer ?
 With mini-lang element, it' really help full when your ide list
 explicit element (as first-list-to-field
 ) I do not challenge UEL, I was just asking what it will be as
 flexible daily.

 I continue my reflexion on mini-lang
 Nicolas

 Le 06/03/2012 10:03, Nicolas Malin a écrit :
 I'm a mini-lang supporter too :)

 At the begin I used java code generation for service but with the
 time I found mini-lang more effective and simple to maintain.
 On mini-lang review, I propose to unify attribute name that have same
 purpose.
   ex : set field=field1 ...
 while
 entity-and ...
 field-map field-name=field1

 On improvement, on the great entity-condition element,
 filter-by-date attribute give the possibility to filter by
 nowTimestamp on fromDate/thruDate. If you want filter on a specific
 date orother fromDate/thruDatefield, we need recreate the condition.
 To simplify, instead of an attribute it would add an element
 condition-date

 entity-condition list=myEntites entity-name=Entity
 condition-date from=myDateField field-from=fromDate
 field-thru=thruDate ignore= /
 By default from=now, field-from=fromDate, field-thru=thruDate,
 ignore search the showHistory field (pratical to implement a generic
 history search for form)
 Finally : entity-condition list=myEntites entity-name=Entity
 filter-by-date=true/ == entity-condition list=myEntites
 entity-name=Entity/condition-date/

 for brainstorm
 
 brainstorming
 I would like to have a set operation that implements some of the
 ideas of the configure by exception concept.
 As regards the type supported, but pending the review of existing
 usage, we may consider to only support these:

 * Object
 * List
 * Map
 * BigDecimal/BigInteger (all numbers in Minilang should be treated
 as BigDecimal; no support for Integer, Float etc...)
 Why not call just Number instead of BigDecimal ?
 * String (expander i.e. the equivalent of GString in Groovy)
 * a date object

 Then we could get rid of the from-field attribute and replace it
 with a from attribute that can take as input a single field (as it
 is now) or an expression; some examples (all the following are
 evaluated using Groovy except where a different language is
 specified i.e. default scripting language):

 set field=field1 from=parameters.inputField1/  // field1 will
 have the same type of inputField1
 set field=field2 from=parameters.inputField1 +
 parameters.inputField2/  // if inputField1 and inputField2 are
 numbers then field2 will be the BigDecimal sum of the two
 set field=field3 from=parameters.inputField1 * 10/
 set field=field4 from=script:bsh parameters.inputField1 + 10/ 
 // use Beanshell
 set field=field5 from=parameters.inputField1
 type=BigDecimal/  // if inputField1 is a string representation of
 a number we can convert with the explicit definition of the type
 Interesting attribute, I'm always a little afraidby automatic
 conversion if element is not on the good type.
 I prefer to push the type :
 set field=field2 from=parameters.inputField1 +
 parameters.inputField2 type=BigDecimal/
 set field=field2 from=parameters.inputField1 +
 parameters.inputField2 type=String/
 For the constant values (I am not sure if it is a good idea, but for
 now I will throw it out):

 set field=stringField value=This is a string/
 set field=stringField value=This is a string with a ${variable}/
 // the following two are equivalent
 set field=bigDecimalField value=100/  // the system attempt to
 parse 100 as a number first 

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones]

The only library that is not friendly right now is the Redstone XMLRPC
library, which is LGPL licensed. That could be replaced by the Apache
XML-RPC project. The only reasons I used Redstone are that it is much
smaller (library bloat is a real problem), and it is a bit easier to use.

There are a couple of libraries that use CDDL (winstone servlet
container) and EPL (Mylin WikiText), but they are in binary form only so
should be fine.

If there is enough interest I'd be happy to change Moqui to use Apache
XML-RPC instead of Redstone.

-David


Jacopo Cappellato wrote:
 David,
 
 a side note (but important): is Moqui using (or there are plans to use) jars 
 or external tools whose license would prevent us from bundling Moqui in an 
 OFBiz release under the ASL 2.0? This would be a show stopper...
 
 Jacopo
 
 On Mar 15, 2012, at 6:08 AM, David E Jones wrote:
 
 This might actually be good in a separate email, but anyway...

 The Moqui Framework would be a separate project from OFBiz, and while
 some OFBiz committers could certainly become moderators for Moqui that
 would be based on their personal efforts and merits and not anything to
 do with what happens or has happened in OFBiz.

 Moqui has a lot more extension points built-in than the OFBiz Framework,
 so you can actually do quite a bit without changing the framework
 itself. For cases where changes are needed (or wanted) to Moqui itself
 they would go through the normal feature request and patch submission
 process for Moqui to be reviewed by a moderator. Initially this would be
 me, and I obviously have some skin invested in an effort like this so
 I'd try to be responsive as possible (I have been so far with Moqui, but
 most of the time it has had light traffic so I've been able to get
 things reviewed and changed/fixed within a couple of days).

 One of the easiest ways to do that is with a pull request on GitHub. In
 fact, if the OFBiz variation of the Moqui Framework was managed on
 GitHub you could customize things there as desired while still being
 able to submit changes back to Moqui and get updates from Moqui so that
 OFBiz can more easily participate in the Moqui community. In git
 terminology this would actually be a fork, and I think is what Jacopo
 was talking about.

 Still, for the most part my guess is that this would not be needed and
 I'd recommend starting with just the jar files (or even just the war
 file) and not set things up for easily changing the framework until the
 need for doing so is well established.

 For this interested in considering Moqui for use in OFBiz, the tutorial
 and framework intro docs are probably the best places to start, and the
 Run/Deploy doc is also helpful (BTW, the moqui.org site is actually
 running on Moqui, and the tutorial and run/deploy docs are actually
 cwiki documents (confluence-style wiki text)):

 http://www.moqui.org/framework/docs/Tutorial.html

 http://sourceforge.net/projects/moqui/files/IntroductionToMoquiFramework-1.0.1.pdf/download

 http://www.moqui.org/framework/docs/RunDeploy.html

 Anyway, sorry for the delay in responding to this. I'm still a bit busy
 on contracts and I only catch up on the OFBiz mailing lists every week
 or so.

 -David
 

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones]

NOTE: replying to this in multiple messages for better digestibility. :)

Jacopo Cappellato wrote:
 Thank you David,
 
 please see inline:
 
 On Mar 15, 2012, at 6:08 AM, David E Jones wrote:
 
 I think the Moqui Framework is already to a point where migration
 of OFBiz business-level artifacts could begin immediately.
 
 Of course I would be happy to see (and help with) an effort to create
 a relatively complex proof of concepts for the migration. Then we
 will have a better ground to evaluate pros and cons of the two
 frameworks.

There is an example application in Moqui that is similar to the one in
OFBiz, though focusing on the main screens and not including all of the
JS and other feature demo screens.

The online demo (running on Amazon Elastic Beanstalk) is here:

http://demo.moqui.org/apps/example/Example

The source code can be viewed through GitHub here:

https://github.com/jonesde/moqui/tree/master/runtime/component/example

-David

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones]

Jacopo Cappellato wrote:
 Doing a migration like this would bring up other issues...
 including whether or not to clean up the data model and services
 while at it, especially rewriting messier parts of OFBiz like the
 ShoppingCart* objects and order processing stuff in general.
 
 
 It will be very difficult to rewrite existing stuff, and doing this
 before or after the migration wouldn't change its complexity. For
 this reason I think we can keep this topic out of this thread for
 now. However, instead of rewriting, we could clean up what we have in
 OFBiz before the migration... especially if this could simplify the
 migration or make the existing code better organized. For example, in
 another thread I was proposing to merge the existing application
 components into one, with possibly one webapp and less (and more
 consolidated) files: this may seem a huge effort but it may not be,
 because it could be done in baby steps with a lot of string
 replacements, moving/renaming files around etc... we could even
 create some scripts to simplify the effort. But again, also this
 could be done before/after the migration (or never).

Some of it could certainly be improved with a rewrite, or perhaps more
of a serious refactor. For example, using the database for shopping cart
data instead of an object in the session would be far more flexible for
a variety of order processing apps, especially outside of the normal
ecommerce submit-all-at-once flow.

But yes, this introduces another whole big set of issues and
discussions. Actually, frankly I'm surprised there is consideration of
any major framework changes, let alone moving to a new framework,
because so much effort is required to update or migrate all of the
existing business artifacts. That has killed a lot of framework
enhancement efforts over the years.

The main trick I'd see with combining webapps in the current
ofbiz/applications components is the request-map uri and view-map name
namespaces, ie the issue with duplicate names pointing to different
events and screens and such.

In Moqui these controller files would go away and the request-map and
view-map data goes into the screen definitions, but I can't think of any
changes that could be made now and supported by OFBiz to help move
toward this.

 If you want to stick with everything as-is and just do a migration,
 that should actually be much less work than you might think. I have
 some FTL templates to transform entity and service definitions, and
 a partial template for simple-methods. Similar templates could be
 made for screens and forms, though they are more complicated and
 may require more manual work. Things like groovy scripts and Java
 classes will also require a bit more work, but many patterns are
 similar so it would be much less work than moving to an
 object-relational sort of framework (ie Hibernate/JPA type of
 thing).

 This doesn't help much to make me comfortable :-) David, it may help
 if you could list a series of tasks (if any) we could perform in one
 of the OFBiz application components to make it more ready to be
 migrated: the tasks should ideally be doable in steps, and after each
 step the component should be usable in the existing OFBiz framework;
 but the code should be more compliant with the future layout of Moqui
 (or with what the migration scripts will expect); for example we
 could: * merge/split service, entity, screen/forms definitions in
 one/more files * merge Groovy scripts into one file with several
 methods (one per data preparation script) * merge/split Java classes
 for services * merge/split xml files with services * etc. etc..

As for what can be done in advance to prepare for it, I don't think that
splitting or combining files is too big a deal because that can be done
by a tool more easily than by a human.

The main area where Moqui differs from OFBiz Framework in terms of
artifacts per file is the screens. In Moqui there is one screen per file
as opposed to multiple screens per file, and they are hierarchical as
opposed to flat (or more of a network for decoration/inclusion/etc).
This could be done manually, but it could also be done by a tool and
perhaps more easily.

-David

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones]

Jacopo Cappellato wrote:
 3. running in a single webapp: while this isn't necessary with
 Moqui, the Moqui Screens are a combination of the controller.xml
 entries for the particular screen and the OFBiz Screen Widget, and
 are hierarchical instead of being flat like the request-map URIs in
 OFBiz; this allows apps to plug into a screen hierarchy from
 separate places (by explicit inclusion, a database record, or
 implicitly by directory structure)
 
 The existing OFBiz screen/form widget is an area where OFBiz should
 be greatly improved in my opinion. Some of the things I don't like: *
 the configuration by exception patter should be used more
 extensively (most common screen definitions, controller entries
 etc... should not be required) * it is difficult to build complex
 Ajax screens * I don't like the xml code for screen/form actions: it
 is limited and it is an additional programming language to learn * in
 simpler screen it is an overkill to maintain in separate files the
 data preparation script, the form definition and the screen
 definition * the html code that is produced by the widgets is ugly
 and difficult to maintain
 
 It seems that some of the points above have been addressed by Moqui;
 David, did you ever consider to integrate other ui frameworks in
 Moqui? I know that in Moqui there is a more powerful mechanism to
 automatically render ui elements (e.g. submenu items for subscreens
 etc...) but frankly speaking I am less interested in them because I
 have learned that these tools are great to cover the 80% of the
 requirements of a ui but the work on the remaining 20% still has to
 be done in each and every screen to make it really usable. But I
 would be really interested to see a rather complex Moqui screen that
 uses Ajax and calls events: this would help me to evaluate the
 advantages of the new solution.

I don't know of any magic formulas for web-based UI stuff. Even a lot of
the desktop UI stuff is quite a pain and only elaborate visual-design
tools make it easier... and when those aren't adequate for what you want
to build life gets hard in a hurry.

One thing that the Moqui screens have that help with this is that it is
easier to extend the form and screen definitions by just adding macros
to an FTL template that extends and/or overrides the default templates.
You can add your new tags to an XSD file if you want so that things will
validate properly in your IDE, but that is not necessary for the new
tags to function.

This still isn't a silver bullet, but at least it makes it easier to
incorporate consistent UI widgets based on jQuery plugins or your own
hand-rolled stuff or whatever so that it is not necessary to have HTML
and/or JavaScript snippets to use each of these on each screen/page that
needs them.

It is also easier to inline HTML and JavaScript in a screen definition,
so that doesn't have to be maintained in a separate file... and have
have HTML inline in a form field and such. In other words, you can drop
it just about anywhere, making it much easier to do crazy stuff with the
screen and form XML files so you don't have to drop to FTL templates so
often.

OOTB the Moqui XML Screens and XML Forms use more JavaScript and dynamic
stuff than the OFBiz ones, but there is still a LOT of room for
improvement and it is something I'd like to do more of, or work with
other who do it to get it into the project (any takers? :) ).

If you have other ideas about what an artifact might look like that
would be easier for UI stuff, I would be very interested in discussing
it more. You have a lot of good ideas Jacopo, and I appreciate them a
great deal.

-David

Re: Framework refactor (Moqui-/Mantle-specific)

[David E Jones]

I think the Moqui Framework is already to a point where migration of
OFBiz business-level artifacts could begin immediately.

Doing a migration like this would bring up other issues... including
whether or not to clean up the data model and services while at it,
especially rewriting messier parts of OFBiz like the ShoppingCart*
objects and order processing stuff in general.

If you want to stick with everything as-is and just do a migration, that
should actually be much less work than you might think. I have some FTL
templates to transform entity and service definitions, and a partial
template for simple-methods. Similar templates could be made for screens
and forms, though they are more complicated and may require more manual
work. Things like groovy scripts and Java classes will also require a
bit more work, but many patterns are similar so it would be much less
work than moving to an object-relational sort of framework (ie
Hibernate/JPA type of thing).

While on the topic, some notes about things I saw in some related threads:

1. the DSL/Helper class effort is in principle just an improved API for
framework tools; the OFBiz framework tools were originally implemented
independently, and based on a LOT of static methods and static
initialization, resulting in an API that is made up of a bunch of
independent objects that I've found are opaque even to developers with
years of OFBiz experience (ie they are not aware of functionality
because it is so hard to find); the Moqui API takes care of this problem
with an API designed to actually be an API as opposed to a bunch of
independent classes that evolved; for more info on that, see:

http://www.moqui.org/apiJavadoc/index.html

... and the central object of the API (that also has contextual details
for the current request/user/etc):

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

Here are some quick examples of how this looks in actual use (from the
sendEmailTemplate.groovy script; sorry for the wrapping):

def emailTemplate =
ec.entity.makeFind(moqui.basic.email.EmailTemplate).condition(emailTemplateId,
emailTemplateId).one()

String bodyText =
ec.screen.makeRender().rootScreen(emailTemplate.bodyScreenLocation).renderMode(text).render()

Map cemParms = [sentDate:ec.user.nowTimestamp, subject:subject,
body:bodyHtml, fromAddress:emailTemplate.fromAddress,
toAddresses:toAddresses, ccAddresses:emailTemplate.ccAddresses,
bccAddresses:emailTemplate.bccAddresses, contentType:text/html,
emailTemplateId:emailTemplateId,fromUserId:ec.user.userId]
ec.service.sync().name(create,
moqui.basic.email.EmailMessage).parameters(cemParms).call()

2. consolidating OFBiz data model and services into a single component:
this is the way the Mantle UDM and USL are currently organized, though
they are restricted to very generic stuff and application-specific
extensions would live in the corresponding application

3. running in a single webapp: while this isn't necessary with Moqui,
the Moqui Screens are a combination of the controller.xml entries for
the particular screen and the OFBiz Screen Widget, and are hierarchical
instead of being flat like the request-map URIs in OFBiz; this allows
apps to plug into a screen hierarchy from separate places (by explicit
inclusion, a database record, or implicitly by directory structure)



This might actually be good in a separate email, but anyway...

The Moqui Framework would be a separate project from OFBiz, and while
some OFBiz committers could certainly become moderators for Moqui that
would be based on their personal efforts and merits and not anything to
do with what happens or has happened in OFBiz.

Moqui has a lot more extension points built-in than the OFBiz Framework,
so you can actually do quite a bit without changing the framework
itself. For cases where changes are needed (or wanted) to Moqui itself
they would go through the normal feature request and patch submission
process for Moqui to be reviewed by a moderator. Initially this would be
me, and I obviously have some skin invested in an effort like this so
I'd try to be responsive as possible (I have been so far with Moqui, but
most of the time it has had light traffic so I've been able to get
things reviewed and changed/fixed within a couple of days).

One of the easiest ways to do that is with a pull request on GitHub. In
fact, if the OFBiz variation of the Moqui Framework was managed on
GitHub you could customize things there as desired while still being
able to submit changes back to Moqui and get updates from Moqui so that
OFBiz can more easily participate in the Moqui community. In git
terminology this would actually be a fork, and I think is what Jacopo
was talking about.

Still, for the most part my guess is that this would not be needed and
I'd recommend starting with just the jar files (or even just the war
file) and not set things up for easily changing the framework until the
need for doing so is well 

Re: Discussion: Mini-language Overhaul

[David E Jones]

If you translate the entire simple-method into a groovy script (perhaps
using an FTL file) and then compile/cache/run that groovy script you can
avoid these overhead problems... and also trim the size of the code to
execute simple-methods by a LOT (ie all those Java objects per
simple-method operation would go away).

As an example the template in Moqui that does just this is available here:

https://github.com/jonesde/moqui/blob/master/framework/template/XmlActions.groovy.ftl

One nice thing about this is that everything is groovy by default so you
can inline it anywhere.

For debugging whenever there is an error just log the generated groovy
script (with lines numbers) along with the error message so you can
easily see where the problem happened and why.

-David


Adrian Crum wrote:
 Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so
 that it is very lightweight and fast. I also optimized the UEL
 integration so there is very little overhead in the evaluation process.
 Switching everything to Groovy will slow things down and increase memory
 usage. Also keep in mind that Groovy creates a class for every script,
 so we will run out of permgen space again.
 
 I think a wiser strategy would be to make mini-lang as feature complete
 as possible, and include a from-script attribute for any feature gaps.
 In other words, use from-script as a last resort - because it is costly.
 
 -Adrian
 
 On 3/6/2012 8:53 AM, Jacopo Cappellato wrote:
 On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:

 I don't understand what you mean by supporting a limited number of
 types. Currently, mini-lang supports any type - thanks to the
 conversion framework.
 The conversion framework is fine; I was thinking that we could
 implicitly (by default) treat in Minilang all the numbers as
 BigDecimals, all the strings as GStrings/Expandable Strings; where
 special conversions are required than the type can be specified.

 I like the idea of changing the from-field attribute to from. I would
 like to see a from-script attribute added:

 set field=field4 from-script=groovy: parameters.inputField1 +
 10/!-- Use Groovy --

 and why not:

 set field=field4 from=parameters.inputField1/!-- Use Groovy
 internally: refactor OFBiz custom code to delegate on Groovy the
 evaluation of simple assignments; this could potentially replace
 FlexibleStringExpander related code --
 set field=field4 from=groovy: parameters.inputField1 + 10/!--
 Use Groovy explicitly to evaluate the expression (use the same from
 attribute instead of a separate from-script)--
 set field=field4 from=parameters.inputField1 + 10/!-- Use
 Groovy (by default, configurable) to evaluate the expression--
 set field=field4 from=beanshell: parameters.inputField1 +
 10/!-- Use Beanshell to evaluate the expression--

 ?

 Then we can remove script support from expressions, which will
 eliminate ugly hacks like:

 set field=field4 value=${groovy: parameters.inputField1 + 10}/

 +1

 Jacopo

 -Adrian


 On 3/6/2012 7:31 AM, Jacopo Cappellato wrote:
 I am a big fan of Minilang too.
 The evolution strategy that I would like to see implemented for
 Minilang is actually the same one I would liketo see applied to
 OFBiz framework in general: review the current usage of the tool,
 fix existing usage for consistency (upgrade old code to use newer
 mechanisms offered by the tool), get rid of unused or old mechanisms
 in the attempt to slim down the size of the framework code,
 unify/simplify mechanisms based on lesson learned; all of this could
 be useful even to prepare the future migration to a different tool
 (e.g. Groovy).

 I know that it is very vague and doesn't add much to this thread but
 I like the approach suggested by Adrian.
 In my opinion, a good way to define a new version of the set
 operation could be that of analyzing how we are currently using the
 operation in OFBiz: as a starting point we could start by searching
 all occurrences of set  string in OFBiz, then review them and see
 different patterns; discuss and define the few ones that we like
 more, convert all code to use them consistently, then (or in the
 same phase) define the new element to better implement the patterns
 that we like.

 And now I am switching to the brainstorming mode :-)

 Kind regards,

 Jacopo

 
 brainstorming
 I would like to have a set operation that implements some of the
 ideas of the configure by exception concept.
 As regards the type supported, but pending the review of existing
 usage, we may consider to only support these:

 * Object
 * List
 * Map
 * BigDecimal/BigInteger (all numbers in Minilang should be treated
 as BigDecimal; no support for Integer, Float etc...)
 * String (expander i.e. the equivalent of GString in Groovy)
 * a date object

 Then we could get rid of the from-field attribute and replace it
 with a from attribute that can take as input a single field (as it
 is now) or an expression; some examples (all the following are
 

Re: Discussion: Handling Security In Nested Services

[David E Jones]

What might be helpful for this is the allow, deny, always-allow pattern.
Normally you'd just give users an inheritable allow permission, but if
the code called/used anything with a deny permission associated with
it, the user would be denied in spite of the inheritable allow permission.

For admin/special users you'd get around this by using the always-allow
permission which ignores deny settings.

-David


Nicolas Malin wrote:
 Le 23/11/2011 22:19, Adrian Crum a écrit :
 Why would you need to force another permission check?
 As example : To sure that a other application will not call a service
 with admin permission by a service with only update permission. Normally
 this situation will not existed, but if it's really important that we
 use admin permission prefer force the authorization check instead of a
 risk to create a security break.
 
 Maybe I am little paranoid,
 but in my age is difficult to change ;)
 
 Nicolas

 -Adrian

 On 11/23/2011 8:54 PM, Nicolas Malin wrote:
 Hi adrian,

 If a explain in my words, (if I really understand you solution) :
 On your first service, you declare permissions and force the inherit
 authorization on sub services called.

 On many case, your solution works fine, but for some service, I will
 keep the possibility to force permission analyze. Exclude this last
 point, I agree with you.

 Nicolas

 Le 23/11/2011 09:14, Adrian Crum a écrit :
 I am running into that familiar problem of handling authorization in
 nested services. Example:

 Application A
   Invoke Service A
 Authorized with permissions A
 Invokes Service C in Application C
   Authorized with permissions C

 In order for a user to run Service A, I have to give them
 permission to run Service A and Service C. This might not be
 desirable because granting permission C to the user could give
 them access to other things I didn't intend to give them access to.

 So far, we have handled that permission issue with permission
 service SECAs - where a second permission service is invoked if the
 first one fails. SECA Example:

 Invoke permission service for permissions C
   If permission service fails, invoke permission service for
 permissions A
 Return results of permission service A
   Else
 Return results of permission service C

 This solves the problem (an example can be found in the Asset Maint
 application), but it is cumbersome to implement.

 There are other places in the project where the problem is solved by
 invoking Service C with system or admin user credentials -
 which looks hackish to me.

 It seems to me this could be made a lot simpler by having the
 service dispatcher keep track of previous authorizations. In other
 words, move the authorization tracking (which is currently handled
 outside the service dispatcher) into the service dispatcher. Example:

 Service invoked
   If user previously authorized
 Execute service
   Else
 Execute permission service
 If user authorized
   Set previously authorized to true
   Execute service
   Set previously authorized to false

 With this change, giving the user permission to run Service A will
 automatically authorize them to run any services called by the service.

 Naturally, this approach does not solve the problem if permission
 checks are embedded in service code - it depends on the use of
 permission services.

 So, what do you think?

 -Adrian



 
 

Re: Discussion: Handling Security In Nested Services

[David E Jones]

Adrian,

It sounds like you're starting to get the point of the run-time
inheritable permission approach that I was trying to introduce into the
project a while back. The general idea being the permission inheritance
is based on screens/services/etc calling other artifacts, ie you keep
track of a stack of artifacts and permissions at run-time, as opposed to
doing it somehow based on inheritance based on location, or even worse
explicit permission checking in services and screens.

BTW, this is already implemented in Moqui.

-David



Adrian Crum wrote:
 I am running into that familiar problem of handling authorization in
 nested services. Example:
 
 Application A
   Invoke Service A
 Authorized with permissions A
 Invokes Service C in Application C
   Authorized with permissions C
 
 In order for a user to run Service A, I have to give them permission
 to run Service A and Service C. This might not be desirable because
 granting permission C to the user could give them access to other
 things I didn't intend to give them access to.
 
 So far, we have handled that permission issue with permission service
 SECAs - where a second permission service is invoked if the first one
 fails. SECA Example:
 
 Invoke permission service for permissions C
   If permission service fails, invoke permission service for permissions
 A
 Return results of permission service A
   Else
 Return results of permission service C
 
 This solves the problem (an example can be found in the Asset Maint
 application), but it is cumbersome to implement.
 
 There are other places in the project where the problem is solved by
 invoking Service C with system or admin user credentials - which
 looks hackish to me.
 
 It seems to me this could be made a lot simpler by having the service
 dispatcher keep track of previous authorizations. In other words, move
 the authorization tracking (which is currently handled outside the
 service dispatcher) into the service dispatcher. Example:
 
 Service invoked
   If user previously authorized
 Execute service
   Else
 Execute permission service
 If user authorized
   Set previously authorized to true
   Execute service
   Set previously authorized to false
 
 With this change, giving the user permission to run Service A will
 automatically authorize them to run any services called by the service.
 
 Naturally, this approach does not solve the problem if permission checks
 are embedded in service code - it depends on the use of permission
 services.
 
 So, what do you think?
 
 -Adrian
 

Moqui/Mantle Update

[David E Jones]

The first production-ready/stable release of Moqui Framework (version
1.0.0) is now available through SourceForge:

https://sourceforge.net/projects/moqui/files/

There is a download there that includes a preview of the Mantle project.
Mantle is basically a data model and service library. The data model is
basically complete at this point (much thanks to Jacopo and others who
have provided feedback and ideas about improvements and general ideas
for the data model).

I also spent a little time porting to entity definitions from OFBiz
10.04 to Moqui so that you can run the Moqui tools against an OFBiz
10.04 data. This includes some handy things that never made it into
OFBiz itself, including:

- Auto Screens with tabs for each master entity, much like the OOTB
screens in OFBiz but automatically generated on the fly
- A simple Data View (and export) tool to select fields from a master
entity and all of its related entities, specify functions, and view the
results (or export as CSV)
- Export tools that support exporting a specific record plus its related
records (limited to the number of relationship hops specified); this can
be used for things like exporting a Product or OrderHeader with all of
their related records

The port of these OFBiz artifacts to run on Moqui is available on GitHub
here:

https://github.com/jonesde/moqui_ofbiz_10_04

In short, Moqui is to the point where a port of OFBiz including services
and screens could be done as well... bringing up the conversation from a
few months ago. If anyone is interested in that, please let me know. If
there is enough interest in that I'd be happy to help out.

The approach I'm planning for an ERP/etc based on Moqui is to clean up
every layer as we go. The initial cleaned up version of the data model
is available in the Mantle project (the UDM part of it). The service
layer of Mantle (USL) is coming along, with some basic services needed
for an ecommerce site. Building a simple ecommerce site to flesh out
that part of the Mantle service library is one of the projects I'm
working on right now (called POP Commerce, also available on GitHub).

Comments, etc, etc welcome...

-David

Re: svn commit: r1177789 - /ofbiz/branches/release10.04/framework/webapp/src/org/ofbiz/webapp/stats/ServerHitBin.java

[David E Jones]

Also, this introduces a bug: a hard-coded dependence on the default 
delegator. The delegator name for this should always comes from the 
webapp, which is configured in the web.xml file.


-David


Scott Gray wrote:

What bug?

On 1/10/2011, at 8:25 AM, jler...@apache.org wrote:


Author: jleroux
Date: Fri Sep 30 19:25:16 2011
New Revision: 1177789

URL: http://svn.apache.org/viewvc?rev=1177789view=rev
Log:
Fix a bug reported by Martin Sanchez Vivo on user ML

Modified:
ofbiz/branches/release10.04/framework/webapp/src/org/ofbiz/webapp/stats/ServerHitBin.java


Modified:
ofbiz/branches/release10.04/framework/webapp/src/org/ofbiz/webapp/stats/ServerHitBin.java

URL:
http://svn.apache.org/viewvc/ofbiz/branches/release10.04/framework/webapp/src/org/ofbiz/webapp/stats/ServerHitBin.java?rev=1177789r1=1177788r2=1177789view=diff

==

---
ofbiz/branches/release10.04/framework/webapp/src/org/ofbiz/webapp/stats/ServerHitBin.java
(original)
+++
ofbiz/branches/release10.04/framework/webapp/src/org/ofbiz/webapp/stats/ServerHitBin.java
Fri Sep 30 19:25:16 2011
@@ -111,10 +111,9 @@ public class ServerHitBin {
}

protected static void countHit(String baseId, int type,
HttpServletRequest request, long startTime, long runningTime,
GenericValue userLogin, boolean isOriginal) {
- String delegatorName = (String)
request.getSession().getAttribute(delegatorName);
- Delegator delegator = null;
- if (UtilValidate.isNotEmpty(delegatorName)) {
- delegator = DelegatorFactory.getDelegator(delegatorName);
+ Delegator delegator = (Delegator)request.getAttribute(delegator);
+ if (delegator == null){
+ delegator = DelegatorFactory.getDelegator(default);
}
if (delegator == null) {
throw new IllegalArgumentException(In countHit could not find a
delegator or delegatorName to work from);

JavaOne, anyone going?

[David E Jones]

Is anyone going to JavaOne next week?

I won't be attending, but I am in the Bay Area (San Jose) on a contract right 
now. If anyone would like to meet up in the evenings during the week, or 
anytime this weekend or next, please let me know. It would be great to chat 
more with whoever is around about OFBiz, Moqui/Mantle, the state of the Java 
world, or whatever happens to invade our mind-space.

Also, if anyone is throwing one of those fancy JavaOne parties, I wouldn't be 
at all offended by an invitation. ;)

-David

Re: widgetVerbose

[David E Jones]

No one agrees with which approach? The approach that if you pass a 
widgetVerbose=true HTTP parameter that it should override the widget.properties 
setting? I agree with that approach… 

-David


On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:

 That's the problem - no one agrees with that approach.
 
 -Adrian
 
 On 9/12/2011 1:53 PM, Jacques Le Roux wrote:
 I think I forgot to forward Hans's answer
 
 Jacques
 
 Hans Bakker wrote:
 On Wed, 2011-08-31 at 05:15 +0200, Jacques Le Roux wrote:
 widget.properties's widget.verbose setting has precedence over web.xml's 
 widgetVerbose setting. So you can't use
 parameters.widgetVerbose to override widget.verbose to false. Is 
 ModelWidget.widgetBoundaryCommentsEnabled() written this way for
 some reasons?
 
 there was a lengthly discussion of this. As long as by default the
 properties file is not overridden in web.xml is fine either way.
 
 
 
 Another issue is that these HTML boundary comments get outputted even 
 though the view handler is set to screencsv. In the
 widget-screen.xsd, the only way to invoke a template to produce CSV is 
 using htmlhtml-template /, but this always adds HTML
 comments even if the output is CSV (see HtmlWidget class). Maybe we could 
 introduce a csv element or something like that?
 
 Anyway, both of those problems combined mean that there are no apparent 
 clean ways to remove the HTML template begin/end
 boundary comments from the CSV output if you try to draw it with an *.ftl 
 template. A workaround  kludge for now is to invoke
 the FTL manually through a Groovy script.
 
 Thanks
 
 Jacques 
 
 

Re: svn commit: r1169790 - in /ofbiz/trunk/framework/common/data: GeoData_CA.xml GeoData_US.xml

[David E Jones]

Did you consider that changing this seed data will make ALL current production 
data that depends on this data suddenly break?

In fact for existing systems, by this change alone, you'll be adding new 
records and not modifying the existing records because the PK (geoId) is being 
changed.

That's gonna screw up a lot of stuff. Please revert this and any commits done 
based on these changes.

-David


On Sep 12, 2011, at 8:50 AM, Jacques Le Roux wrote:

 I have to take care about data for test and demo also...
 
 Jacques
 
 From: jler...@apache.org
 Author: jleroux
 Date: Mon Sep 12 15:11:00 2011
 New Revision: 1169790
 
 URL: http://svn.apache.org/viewvc?rev=1169790view=rev
 Log:
 Normalizes
 * Canada GeoId for Province prefixed with CA- as it should be (following ISO 
 3166-2:CA, http://en.wikipedia.org/wiki/ISO_3166-2:CA)
 
 * USA GeoId for Province prefixed with US- as it should be (following ISO 
 3166-2:US,  http://en.wikipedia.org/wiki/ISO_3166-2:US). I did not see any 
 reasons to no use the same scheme for US Armed Forces provinces
 
 No other countries had the same problem
 
 Modified:
   ofbiz/trunk/framework/common/data/GeoData_CA.xml
   ofbiz/trunk/framework/common/data/GeoData_US.xml
 
 Modified: ofbiz/trunk/framework/common/data/GeoData_CA.xml
 URL: 
 http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/data/GeoData_CA.xml?rev=1169790r1=1169789r2=1169790view=diff
 ==
 --- ofbiz/trunk/framework/common/data/GeoData_CA.xml (original)
 +++ ofbiz/trunk/framework/common/data/GeoData_CA.xml Mon Sep 12 15:11:00 2011
 @@ -19,33 +19,33 @@ under the License.
 --
 
 entity-engine-xml
 -Geo abbreviation=AB geoCode=AB geoId=AB geoName=Alberta 
 geoTypeId=PROVINCE/
 -Geo abbreviation=BC geoCode=BC geoId=BC geoName=British 
 Columbia geoTypeId=PROVINCE/
 -Geo abbreviation=MB geoCode=MB geoId=MB geoName=Manitoba 
 geoTypeId=PROVINCE/
 -Geo abbreviation=NB geoCode=NB geoId=NB geoName=New Brunswick 
 geoTypeId=PROVINCE/
 -Geo abbreviation=NL geoCode=NL geoId=NL geoName=Newfoundland 
 and Labrador geoTypeId=PROVINCE/
 -Geo abbreviation=NS geoCode=NS geoId=NS geoName=Nova Scotia 
 geoTypeId=PROVINCE/
 -Geo abbreviation=NT geoCode=NT geoId=NT geoName=Northwest 
 Territories geoTypeId=PROVINCE/
 -Geo abbreviation=NU geoCode=NU geoId=NU geoName=Nunavut 
 geoTypeId=PROVINCE/
 -Geo abbreviation=ON geoCode=ON geoId=ON geoName=Ontario 
 geoTypeId=PROVINCE/
 -Geo abbreviation=PE geoCode=PE geoId=PE geoName=Prince Edward 
 Island geoTypeId=PROVINCE/
 -Geo abbreviation=QC geoCode=QC geoId=QC geoName=Quebec 
 geoTypeId=PROVINCE/
 -Geo abbreviation=SK geoCode=SK geoId=SK geoName=Saskatchewan 
 geoTypeId=PROVINCE/
 -Geo abbreviation=YT geoCode=YT geoId=YT geoName=Yukon 
 geoTypeId=PROVINCE/
 +Geo abbreviation=AB geoCode=AB geoId=CA-AB geoName=Alberta 
 geoTypeId=PROVINCE/
 +Geo abbreviation=BC geoCode=BC geoId=CA-BC geoName=British 
 Columbia geoTypeId=PROVINCE/
 +Geo abbreviation=MB geoCode=MB geoId=CA-MB geoName=Manitoba 
 geoTypeId=PROVINCE/
 +Geo abbreviation=NB geoCode=NB geoId=CA-NB geoName=New 
 Brunswick geoTypeId=PROVINCE/
 +Geo abbreviation=NL geoCode=NL geoId=CA-NL geoName=Newfoundland 
 and Labrador geoTypeId=PROVINCE/
 +Geo abbreviation=NS geoCode=NS geoId=CA-NS geoName=Nova Scotia 
 geoTypeId=PROVINCE/
 +Geo abbreviation=NT geoCode=NT geoId=CA-NT geoName=Northwest 
 Territories geoTypeId=PROVINCE/
 +Geo abbreviation=NU geoCode=NU geoId=CA-NU geoName=Nunavut 
 geoTypeId=PROVINCE/
 +Geo abbreviation=ON geoCode=ON geoId=CA-ON geoName=Ontario 
 geoTypeId=PROVINCE/
 +Geo abbreviation=PE geoCode=PE geoId=CA-PE geoName=Prince 
 Edward Island geoTypeId=PROVINCE/
 +Geo abbreviation=QC geoCode=QC geoId=CA-QC geoName=Quebec 
 geoTypeId=PROVINCE/
 +Geo abbreviation=SK geoCode=SK geoId=CA-SK 
 geoName=Saskatchewan geoTypeId=PROVINCE/
 +Geo abbreviation=YT geoCode=YT geoId=CA-YT geoName=Yukon 
 geoTypeId=PROVINCE/
 
 -GeoAssoc geoId=CAN geoIdTo=AB geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=BC geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=MB geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=NB geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=NL geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=NS geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=NT geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=NU geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=ON geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=PE geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=QC geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=SK geoAssocTypeId=REGIONS/
 -GeoAssoc geoId=CAN geoIdTo=YT geoAssocTypeId=REGIONS/
 +GeoAssoc geoId=CA-CAN geoIdTo=AB geoAssocTypeId=REGIONS/
 +GeoAssoc geoId=CA-CAN geoIdTo=BC geoAssocTypeId=REGIONS/
 +GeoAssoc geoId=CA-CAN 

Re: widgetVerbose

[David E Jones]

Thanks Adrian, I understand what you're getting at exactly now.

Yes, this is frustrating isn't it, and this pattern seems to come up over and 
over. That's why I like the moderated community approach better (as opposed to 
the Apache way), and I guess you know my thoughts and approach on that based on 
my recent efforts…

Still, I suppose that by the Apache way we should vote on this and consider the 
results binding, and make the corresponding changes. If someone goes against 
that vote result, then I'm not sure what the Apache way is… i.e. what do you do 
about a commit war?

I don't know.

-David



On Sep 12, 2011, at 12:02 PM, Adrian Crum wrote:

 David,
 
 Keep in mind that the original design is one that you participated in. The 
 agreement on the setting precedence in the original Jira issue was this:
 
 widget.properties - web.xml - URL parameters
 
 where widget.properties is the global default, which can be overridden by a 
 setting in web.xml, which can be overridden by screen widgets or scripts or 
 whatever (via the current context Map).
 
 The design worked great. Then Hans changed it due to a misunderstanding of 
 how the design works. Despite repeated explanations of how the design works, 
 and requests from three PMC members to revert his change, he refused to 
 change it and threatened the community with a commit war. Since then we have 
 had a number of issues reported on the mailing list describing how his change 
 makes the setting unusable.
 
 It amazes me that a single -1 vote vetoes a change in the Apache community, 
 but three -1 votes from PMC members can't revert this obvious break in 
 software design.
 
 -Adrian
 
 On 9/12/2011 7:24 PM, Adrian Crum wrote:
 No. The approach suggested by (and committed by) Hans is that the setting in 
 the widget.properties file overrides any other setting.
 
 -Adrian
 
 On 9/12/2011 6:19 PM, David E Jones wrote:
 No one agrees with which approach? The approach that if you pass a 
 widgetVerbose=true HTTP parameter that it should override the 
 widget.properties setting? I agree with that approach…
 
 -David
 
 
 On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:
 
 That's the problem - no one agrees with that approach.
 
 -Adrian
 
 On 9/12/2011 1:53 PM, Jacques Le Roux wrote:
 I think I forgot to forward Hans's answer
 
 Jacques
 
 Hans Bakker wrote:
 On Wed, 2011-08-31 at 05:15 +0200, Jacques Le Roux wrote:
 widget.properties's widget.verbose setting has precedence over 
 web.xml's widgetVerbose setting. So you can't use
 parameters.widgetVerbose to override widget.verbose to false. Is 
 ModelWidget.widgetBoundaryCommentsEnabled() written this way for
 some reasons?
 there was a lengthly discussion of this. As long as by default the
 properties file is not overridden in web.xml is fine either way.
 
 
 Another issue is that these HTML boundary comments get outputted even 
 though the view handler is set to screencsv. In the
 widget-screen.xsd, the only way to invoke a template to produce CSV is 
 usinghtmlhtml-template /, but this always adds HTML
 comments even if the output is CSV (see HtmlWidget class). Maybe we 
 could introduce acsv  element or something like that?
 
 Anyway, both of those problems combined mean that there are no apparent 
 clean ways to remove the HTML template begin/end
 boundary comments from the CSV output if you try to draw it with an 
 *.ftl template. A workaround  kludge for now is to invoke
 the FTL manually through a Groovy script.
 
 Thanks
 
 Jacques
 

Re: svn commit: r1169790 - in /ofbiz/trunk/framework/common/data: GeoData_CA.xml GeoData_US.xml

[David E Jones]

Yes, there is no conflict currently because countries are using the 3-letter 
ISO code, and the USA states (the first states we had data for, way back in 
2001, had just the 2-letter state abbreviation; later states had a country 
prefix and then a state abbreviation as the US states really should have 
originally). So anyway yes, Canada is geoId=CAN and California is geoId=CA.

So yes, I'm even more for reverting this change.

-David


On Sep 12, 2011, at 2:03 PM, Jacques Le Roux wrote:

 I'm still waiting before reverting, I'd like to have other opinions on this
 
 Thanks
 
 Jacques
 
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 Oops, an assumption was wrong in my previous emaim, there are no conflicts 
 with California and Canada geoId (how could it be since it's the PK, idiot 
 I'm)
 So yes maybe it's simpler to revert all and forget about that forever?
 
 Jacques
 
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 I could provide a SQL script which removes the wrong entities, but it's the 
 users responsability to update or not their own data. It
 seems impossible to envision all possible cases
 
 Jacques
 
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 So we are forever stuck with wrong data? Consider Canada and California 
 geoId, it's CA for both.
 Actually this was more an effort for future systems to be consistent with 
 ISO 3166-2 and sound (CA case).
 
 This said I'm ready to revert r1169822 + r1169790, but I wonder then if we 
 will never find a window to fix this data...
 Should not better concerned systems update and fix data? Then maybe we 
 could provide a mean for that?
 
 Jacques
 
 From: David E Jones d...@me.com
 Did you consider that changing this seed data will make ALL current 
 production data that depends on this data suddenly break?
 
 In fact for existing systems, by this change alone, you'll be adding new 
 records and not modifying the existing records because
 the PK (geoId) is being changed.
 
 That's gonna screw up a lot of stuff. Please revert this and any commits 
 done based on these changes.
 
 -David
 
 
 On Sep 12, 2011, at 8:50 AM, Jacques Le Roux wrote:
 
 I have to take care about data for test and demo also...
 
 Jacques
 
 From: jler...@apache.org
 Author: jleroux
 Date: Mon Sep 12 15:11:00 2011
 New Revision: 1169790
 
 URL: http://svn.apache.org/viewvc?rev=1169790view=rev
 Log:
 Normalizes
 * Canada GeoId for Province prefixed with CA- as it should be 
 (following ISO 3166-2:CA,
 http://en.wikipedia.org/wiki/ISO_3166-2:CA)
 
 * USA GeoId for Province prefixed with US- as it should be (following 
 ISO 3166-2:US,
 http://en.wikipedia.org/wiki/ISO_3166-2:US). I did not see any reasons 
 to no use the same scheme for US Armed Forces
 provinces
 
 No other countries had the same problem
 
 Modified:
  ofbiz/trunk/framework/common/data/GeoData_CA.xml
  ofbiz/trunk/framework/common/data/GeoData_US.xml
 
 Modified: ofbiz/trunk/framework/common/data/GeoData_CA.xml
 URL: 
 http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/data/GeoData_CA.xml?rev=1169790r1=1169789r2=1169790view=diff
 ==
 --- ofbiz/trunk/framework/common/data/GeoData_CA.xml (original)
 +++ ofbiz/trunk/framework/common/data/GeoData_CA.xml Mon Sep 12 
 15:11:00 2011
 @@ -19,33 +19,33 @@ under the License.
 --
 
 entity-engine-xml
 -Geo abbreviation=AB geoCode=AB geoId=AB geoName=Alberta 
 geoTypeId=PROVINCE/
 -Geo abbreviation=BC geoCode=BC geoId=BC geoName=British 
 Columbia geoTypeId=PROVINCE/
 -Geo abbreviation=MB geoCode=MB geoId=MB geoName=Manitoba 
 geoTypeId=PROVINCE/
 -Geo abbreviation=NB geoCode=NB geoId=NB geoName=New 
 Brunswick geoTypeId=PROVINCE/
 -Geo abbreviation=NL geoCode=NL geoId=NL 
 geoName=Newfoundland and Labrador geoTypeId=PROVINCE/
 -Geo abbreviation=NS geoCode=NS geoId=NS geoName=Nova 
 Scotia geoTypeId=PROVINCE/
 -Geo abbreviation=NT geoCode=NT geoId=NT geoName=Northwest 
 Territories geoTypeId=PROVINCE/
 -Geo abbreviation=NU geoCode=NU geoId=NU geoName=Nunavut 
 geoTypeId=PROVINCE/
 -Geo abbreviation=ON geoCode=ON geoId=ON geoName=Ontario 
 geoTypeId=PROVINCE/
 -Geo abbreviation=PE geoCode=PE geoId=PE geoName=Prince 
 Edward Island geoTypeId=PROVINCE/
 -Geo abbreviation=QC geoCode=QC geoId=QC geoName=Quebec 
 geoTypeId=PROVINCE/
 -Geo abbreviation=SK geoCode=SK geoId=SK 
 geoName=Saskatchewan geoTypeId=PROVINCE/
 -Geo abbreviation=YT geoCode=YT geoId=YT geoName=Yukon 
 geoTypeId=PROVINCE/
 +Geo abbreviation=AB geoCode=AB geoId=CA-AB 
 geoName=Alberta geoTypeId=PROVINCE/
 +Geo abbreviation=BC geoCode=BC geoId=CA-BC geoName=British 
 Columbia geoTypeId=PROVINCE/
 +Geo abbreviation=MB geoCode=MB geoId=CA-MB 
 geoName=Manitoba geoTypeId=PROVINCE/
 +Geo abbreviation=NB geoCode=NB geoId=CA-NB geoName=New 
 Brunswick geoTypeId=PROVINCE/
 +Geo abbreviation=NL geoCode=NL geoId=CA-NL 
 geoName=Newfoundland and Labrador

Re: widgetVerbose

[David E Jones]

Based on this I'm actually reconsidering my position, however the current 
implementation is still not adequate.

It sounds like the goal for the widget.properties is to make it easy to go into 
production and make sure that no boundary comments/etc are added anywhere in 
the system. To do that effectively you need a single setting for the whole 
system, and that setting should override everything else (i.e. not even allow 
for a parameter to be manually added which may expose implementation details 
that you want to keep hidden).

For that purpose a property would make sense, but the logic has to be carefully 
done (not the shallow logic that has been discussed so far). It would need to 
be something like: if (widgetVerbose property == false) then don't show else if 
(widgetVerbose parameter (using default OFBiz parameters Map, takes into 
account both URL parameters and web.xml context parameters) == true) then show 
else don't show.

In other words, if the widget.properties setting is false, then never show 
boundary comments. Otherwise, ignore it and use the parameters value if true, 
and overall default to false.

Wow, is this really that hard?

-David



On Sep 12, 2011, at 5:03 PM, Hans Bakker wrote:

 As i wrote before i am fine with this if in the trunk the setting of
 widget.properties is not overridden by default in web.xml for some
 component what was the case originally.
 
 Regards,
 Hans
 
 On Mon, 2011-09-12 at 20:02 +0100, Adrian Crum wrote:
 David,
 
 Keep in mind that the original design is one that you participated in. 
 The agreement on the setting precedence in the original Jira issue was this:
 
 widget.properties - web.xml - URL parameters
 
 where widget.properties is the global default, which can be overridden 
 by a setting in web.xml, which can be overridden by screen widgets or 
 scripts or whatever (via the current context Map).
 
 The design worked great. Then Hans changed it due to a misunderstanding 
 of how the design works. Despite repeated explanations of how the design 
 works, and requests from three PMC members to revert his change, he 
 refused to change it and threatened the community with a commit war. 
 Since then we have had a number of issues reported on the mailing list 
 describing how his change makes the setting unusable.
 
 It amazes me that a single -1 vote vetoes a change in the Apache 
 community, but three -1 votes from PMC members can't revert this obvious 
 break in software design.
 
 -Adrian
 
 On 9/12/2011 7:24 PM, Adrian Crum wrote:
 No. The approach suggested by (and committed by) Hans is that the 
 setting in the widget.properties file overrides any other setting.
 
 -Adrian
 
 On 9/12/2011 6:19 PM, David E Jones wrote:
 No one agrees with which approach? The approach that if you pass a 
 widgetVerbose=true HTTP parameter that it should override the 
 widget.properties setting? I agree with that approach…
 
 -David
 
 
 On Sep 12, 2011, at 6:59 AM, Adrian Crum wrote:
 
 That's the problem - no one agrees with that approach.
 
 -Adrian
 
 On 9/12/2011 1:53 PM, Jacques Le Roux wrote:
 I think I forgot to forward Hans's answer
 
 Jacques
 
 Hans Bakker wrote:
 On Wed, 2011-08-31 at 05:15 +0200, Jacques Le Roux wrote:
 widget.properties's widget.verbose setting has precedence over 
 web.xml's widgetVerbose setting. So you can't use
 parameters.widgetVerbose to override widget.verbose to false. Is 
 ModelWidget.widgetBoundaryCommentsEnabled() written this way for
 some reasons?
 there was a lengthly discussion of this. As long as by default the
 properties file is not overridden in web.xml is fine either way.
 
 
 Another issue is that these HTML boundary comments get outputted 
 even though the view handler is set to screencsv. In the
 widget-screen.xsd, the only way to invoke a template to produce 
 CSV is usinghtmlhtml-template /, but this always adds HTML
 comments even if the output is CSV (see HtmlWidget class). Maybe 
 we could introduce acsv  element or something like that?
 
 Anyway, both of those problems combined mean that there are no 
 apparent clean ways to remove the HTML template begin/end
 boundary comments from the CSV output if you try to draw it with 
 an *.ftl template. A workaround  kludge for now is to invoke
 the FTL manually through a Groovy script.
 
 Thanks
 
 Jacques
 
 
 -- 
 Ofbiz on twitter: http://twitter.com/apache_ofbiz
 Alternative ofbiz website: http://www.ofbiz.info
 http://www.antwebsystems.com : Quality services for competitive rates.
 

Re: svn commit: r1169790 - in /ofbiz/trunk/framework/common/data: GeoData_CA.xml GeoData_US.xml

[David E Jones]

Anne,

Yes, you're right that the PK is effectively arbitrary and the only reason to 
keep the current values is because they've been in use for a decade in hundreds 
of different systems.

-David


On Sep 12, 2011, at 5:25 PM, Anne wrote:

 I don't understand why it matters what the geoId is. Surely they could
 be 1, 10001 etc and it wouldn't matter, *as long as they never
 change* (because they are PK).
 
 In the UI it *should* be the geoCode or the abbreviation or the
 geoName that is displayed, depending on context. I know in some places
 in the UI the geoId is currently displayed, but I consider this a
 strange choice by the coder of the UI code, and nothing to do with the
 data in the Geo. In our local UI, we've changed that to display either
 the abbreviation or geoName or geoCode instead.
 
 So -1 for this change.
 
 Cheers,
 Anne.
 
 On 13 September 2011 08:30, David E Jones d...@me.com wrote:
 
 Yes, there is no conflict currently because countries are using the 3-letter 
 ISO code, and the USA states (the first states we had data for, way back in 
 2001, had just the 2-letter state abbreviation; later states had a country 
 prefix and then a state abbreviation as the US states really should have 
 originally). So anyway yes, Canada is geoId=CAN and California is 
 geoId=CA.
 
 So yes, I'm even more for reverting this change.
 
 -David
 
 
 On Sep 12, 2011, at 2:03 PM, Jacques Le Roux wrote:
 
 I'm still waiting before reverting, I'd like to have other opinions on this
 
 Thanks
 
 Jacques
 
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 Oops, an assumption was wrong in my previous emaim, there are no conflicts 
 with California and Canada geoId (how could it be since it's the PK, idiot 
 I'm)
 So yes maybe it's simpler to revert all and forget about that forever?
 
 Jacques
 
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 I could provide a SQL script which removes the wrong entities, but it's 
 the users responsability to update or not their own data. It
 seems impossible to envision all possible cases
 
 Jacques
 
 From: Jacques Le Roux jacques.le.r...@les7arts.com
 So we are forever stuck with wrong data? Consider Canada and California 
 geoId, it's CA for both.
 Actually this was more an effort for future systems to be consistent 
 with ISO 3166-2 and sound (CA case).
 
 This said I'm ready to revert r1169822 + r1169790, but I wonder then if 
 we will never find a window to fix this data...
 Should not better concerned systems update and fix data? Then maybe we 
 could provide a mean for that?
 
 Jacques
 
 From: David E Jones d...@me.com
 Did you consider that changing this seed data will make ALL current 
 production data that depends on this data suddenly break?
 
 In fact for existing systems, by this change alone, you'll be adding 
 new records and not modifying the existing records because
 the PK (geoId) is being changed.
 
 That's gonna screw up a lot of stuff. Please revert this and any 
 commits done based on these changes.
 
 -David
 
 
 On Sep 12, 2011, at 8:50 AM, Jacques Le Roux wrote:
 
 I have to take care about data for test and demo also...
 
 Jacques
 
 From: jler...@apache.org
 Author: jleroux
 Date: Mon Sep 12 15:11:00 2011
 New Revision: 1169790
 
 URL: http://svn.apache.org/viewvc?rev=1169790view=rev
 Log:
 Normalizes
 * Canada GeoId for Province prefixed with CA- as it should be 
 (following ISO 3166-2:CA,
 http://en.wikipedia.org/wiki/ISO_3166-2:CA)
 
 * USA GeoId for Province prefixed with US- as it should be (following 
 ISO 3166-2:US,
 http://en.wikipedia.org/wiki/ISO_3166-2:US). I did not see any 
 reasons to no use the same scheme for US Armed Forces
 provinces
 
 No other countries had the same problem
 
 Modified:
  ofbiz/trunk/framework/common/data/GeoData_CA.xml
  ofbiz/trunk/framework/common/data/GeoData_US.xml
 
 Modified: ofbiz/trunk/framework/common/data/GeoData_CA.xml
 URL: 
 http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/data/GeoData_CA.xml?rev=1169790r1=1169789r2=1169790view=diff
 ==
 --- ofbiz/trunk/framework/common/data/GeoData_CA.xml (original)
 +++ ofbiz/trunk/framework/common/data/GeoData_CA.xml Mon Sep 12 
 15:11:00 2011
 @@ -19,33 +19,33 @@ under the License.
 --
 
 entity-engine-xml
 -Geo abbreviation=AB geoCode=AB geoId=AB geoName=Alberta 
 geoTypeId=PROVINCE/
 -Geo abbreviation=BC geoCode=BC geoId=BC geoName=British 
 Columbia geoTypeId=PROVINCE/
 -Geo abbreviation=MB geoCode=MB geoId=MB 
 geoName=Manitoba geoTypeId=PROVINCE/
 -Geo abbreviation=NB geoCode=NB geoId=NB geoName=New 
 Brunswick geoTypeId=PROVINCE/
 -Geo abbreviation=NL geoCode=NL geoId=NL 
 geoName=Newfoundland and Labrador geoTypeId=PROVINCE/
 -Geo abbreviation=NS geoCode=NS geoId=NS geoName=Nova 
 Scotia geoTypeId=PROVINCE/
 -Geo abbreviation=NT geoCode=NT geoId=NT 
 geoName=Northwest Territories geoTypeId=PROVINCE/
 -Geo abbreviation=NU

Re: svn commit: r1165122 - in /ofbiz/branches/release10.04: ./ applications/party/servicedef/services.xml

[David E Jones]

My favorite is the FishEye UI, provided by Atlassian:

https://fisheye6.atlassian.com/browse/ofbiz

-David


On Sep 11, 2011, at 5:19 PM, Scott Gray wrote:

 As a side note, if anything seems in the least bit strange to me the first 
 thing I ALWAYS do is to check the revision history for the code in question.  
 It can give a lot of insight into why things are the way they are, who made 
 it that way and provides the context for a discussion about making changes.  
 It also avoids a situation like this where committers end up playing tag 
 without ever noticing that it's even happening.
 
 Committers and devs, please bookmark and use these links:
 http://svn.apache.org/viewvc/ofbiz/trunk/ - Apache SVN
 http://svn.ofbiz.org/viewcvs/trunk/ - Pre-Apache SVN
 
 Regards
 Scott
 
 On 12/09/2011, at 11:14 AM, Adrian Crum wrote:
 
 Thanks for noticing that Scott. Actually, the change in the trunk is not a 
 good one either - for the same reason.
 
 -Adrian
 
 On 9/11/2011 11:50 PM, Scott Gray wrote:
 Hi Jacques,
 
 This is not a good backport, changing the service definition could break 
 deployments that have come to depend on the firstName and lastName being 
 optional.  It's also worth noting that they were made optional 
 intentionally: 
 http://svn.apache.org/viewvc?diff_format=lview=revisionrevision=888986
 
 Regards
 Scott
 
 On 5/09/2011, at 10:07 AM, jler...@apache.org wrote:
 
 Author: jleroux
 Date: Sun Sep  4 22:07:12 2011
 New Revision: 1165122
 
 URL: http://svn.apache.org/viewvc?rev=1165122view=rev
 Log:
 Applied fix from trunk for revision: 1094007
 
 r1094007 | sascharodekamp | 2011-04-16 17:15:27 +0200 (sam., 16 avr. 2011) 
 | 20 lines
 
 Bug - Fixed a bug reported by Ravindra Mandre. When creating a party the 
 first and last name were decalred as mandatory field but this was not 
 checked in the service definition.
 I extended the service definition, now first name and last name are not 
 optional anymore.
 
 Orig Msg:
 
 
 Hi list,
 
 In partymgr when I am creating a person then on the form first name and
 last
 name are required fields but If I submit the form without passing the 
 first
 name and last name , form gets submitted , it means required validations
 are
 not working. so I am curious to know Is there any problem with Validations
 ?
 I tried for the following url
 
 
 https://demo-trunk.ofbiz.apache.org/partymgr/control/editperson?create_new=Y
 
 
 
 Modified:
   ofbiz/branches/release10.04/   (props changed)
   ofbiz/branches/release10.04/applications/party/servicedef/services.xml
 
 Propchange: ofbiz/branches/release10.04/
 --
 --- svn:mergeinfo (original)
 +++ svn:mergeinfo Sun Sep  4 22:07:12 2011
 @@ -1,3 +1,3 @@
 /ofbiz/branches/addbirt:831210-885099,885686-886087
 /ofbiz/branches/multitenant20100310:921280-927264
 -/ofbiz/trunk:939988,939990,93,940025,940053,940234,940248,940309,940401,940410,940425,940779,940815,940849,940851,941007,941047,941109,941177,941199,941261,941440,941600,941999,942084,942406,942414,942671,942883-942884,943168,943271-943272,943843,944614,944621,944623,944647,944669,944797,944895,945010,945018,945026,945118,945573,945578,945580,945582,945610,945619,945848,945852,945857,946061,946066,946073,946075,946080,946309,946313,946320,946322,946596,947004-947005,947392,947424,947679,947988,948017,948694,949174,949710,949844,950866,950870,950893,951005,951062,951098,951251,951367,951381,951672,952232,952249,952270,953294,953671,954135,954583,954733,954956,955568,956022,956206,956340,957160,958343,958514,958521,958752,958758,958769,958953,959456,960143,960491,960997,963610,964558,965470,965916,966525,966785,967098,978806,978893,978939,979104,980641-980642,980935,981051,981104,981123,981288,983920,983930,985163,985298,985473,985718,985856,985902,987841,989166,99012
 7,990
 339,990539,991485,993344,993387,995384,995686,996069,996078-996079,996563,997418-997420,997423-997425,997431,997440,997526,997990,998061,998412,998557,1000621,1000725,1000998,1001099,1001131,1001185,1001574,1001849,1001962,1002963,1003434,1003450,1003829,1004139,1027756,1027960,1028053,1028625,1028627,1029600,1030016,1030385,1030390,1033928,1033953,1034138,1034179,1035080,1035084,1036426,1036669,1037507,1037559-1037560,1037567,1037883,1038228,1038990,1039256,1040044,1040091,1042009,1042034,1042038,1042132,1042188,104,1042317,1042348,1042396,1042411,1042950,1043861,1043996-1043998,1044047,1044084,1044912,1049031,1050602,105,1051450,1051812,1052195,1053285,1053289,1053722,1054565,1055057,1056072,1056305,1056803,1057519,1058028,1058056,1058488,1059180,1060236,1060261,1060368,1060933,1061167,1061307,1061346,1061886,1061939,1062138,1062144,1062152,1063273,1064090,1064953,1064993,1065550,1066048,1067097,1067942,1069597,1069965,1070193,1070229,1072017,1072378,1074624,10
 

Re: Policy about supported releases

[David E Jones]

Do we even have a policy about supporting releases, let alone a policy about 
which releases to support?

In other words, what can a user of Apache OFBiz expect to get as part of this 
official support?

-David


On Sep 6, 2011, at 9:28 AM, Jacques Le Roux wrote:

 Thanks Hans,
 
 Yes of course this is only Apache OFBiz policy...
 
 Jacques
 
 From: Hans Bakker mailingl...@antwebsystems.com
 When you do not get a response in a reasonable time. I would suggest to
 ahead with the subject as you proposed.
 
 In general this is a fair statement, in practice providers will support
 the customers independent of the version they use?
 
 Regards,
 Hans
 
 On Tue, 2011-09-06 at 06:41 +0200, Jacques Le Roux wrote:
 I can't believe nobody is interested in this?
 
 Jacques
 
 From: Jacques Le Roux jacques.le.r...@les7arts.com
  I'd simply suggest to not support releases older than 4 years... This 
  would be a perfect timing for R4.0 (was in 2007) that we
  can't reasonnably no longer support and is a simple policy anybody can 
  remember easily
 
  So we could annonce that officialy has did Tomcat team below, opinions?
 
  Jacques
 
  From: Jacques Le Roux jacques.le.r...@les7arts.com
  Hi,
 
  I'd suggest that we define a simple official policy about supported 
  releases. There are still people asking for support on  4.0.
  But this version is more than 4 years old and I think any of the 
  commiters still use it regularly and want to support it. For
  instance it's now hard to backport things there.
 
  We could take Tomcat policy as an example:
 
  The Apache Tomcat team announces that support for Apache Tomcat 5.5.x
  will end on 30 September 2012.
 
  This means that after 30 September 2012:
  - releases from the 5.5.x branch are highly unlikely
  - bugs affecting only the 5.5.x branch will not be addressed
  - security vulnerability reports will not be checked against the 5.5.x
  branch
 
  Three months later (i.e. after 31 December 2012)
  - the 5.5.x download pages will be removed
  - the latest 5.5.x release will be removed from the mirror system
  - the 5.5.x branch in svn will move from /tomcat/tc5.5.x to
  /tomcat/archive/tc5.5.x
  - the links to the 5.5.x documentation will be removed from
  tomcat.apache.org
  - The bugzilla project for 5.5.x will be made read-only
 
  Note that all 5.5.x releases will always be available from the archive.
 
  It is anticipated that the final 5.5.x release will be made shortly
  before 30 September 2012.
 
  Thoughts?
 
  Jacques
 
 
 
 
 -- 
 Ofbiz on twitter: http://twitter.com/apache_ofbiz
 Alternative ofbiz website: http://www.ofbiz.info
 http://www.antwebsystems.com : Quality services for competitive rates.
 
 

Re: Party Classification Data Modeling

[David E Jones]

The second one should be a PartyClassificataionGroup and not a type.

-David


On Sep 4, 2011, at 12:04 PM, BJ Freeman wrote:

PartyClassificationType description=Minority hasTable=N
 parentTypeId= partyClassificationTypeId=MINORITY_CLASSIFICAT/
PartyClassificationType description=Hispanic hasTable=N
 parentTypeId=MINORITY_CLASSIFICA
 partyClassificationTypeId=HISPANIC_CLASSIFICAT/
 
 
 Adrian Crum sent the following on 1/10/2011 4:27 PM:
 I spent some time in Party Manager trying to make sense of the Party 
 Classification feature, and I can't seem to make it do anything meaningful. 
 Maybe I'm not understanding something, so I'll provide an example and see if 
 anyone knows how to implement it in the current code.
 
 In table 2.3 of the Data Model Resource Book, there is a party named Marc 
 Martinez who has been classified as Hispanic. I will use him for my example.
 
 In Party Manager I create a person named Marc Martinez and I want to 
 classify him as Hispanic. I would also like to include the Hispanic 
 classification in two classification groups: US Minorities and Non-White. I 
 go to the Classifications tab - where I can create classification groups 
 from a list of pre-defined group types. I choose the Minority type, type US 
 Minorities in the Description field, and save the group. I want to add the 
 Hispanic classification to this group, but I don't see any way to add 
 classifications. I go to Marc's profile page and try to assign him a 
 classification, but I can only assign him to a classification group. If I 
 assign him to the US Minorities group that still doesn't classify him as 
 Hispanic. 
 
 As far as I can tell, Party Classification doesn't work.
 
 Any ideas?
 
 -Adrian
 
 
 --- On Mon, 1/3/11, Adrian Crum adrian.c...@yahoo.com wrote:
 Understood. If we wanted to create
 entities to avoid the sub-types mentioned in the book
 (Organization Classification, Person Classisfication, etc)
 then I think we could have done that in a simpler way and
 still keep the book's model:
 
 PartyClassificationGroupType
 
 *groupTypeId
 description
 parentGroupTypeId
 
 PartyClassificationGroup
 
 *groupTypeId
 *partyTypeId
 
 Anyways, I have come up with a workaround. I'll just use
 the existing PartyClassificationGroup the way the book uses
 PartyType.
 
 -Adrian
 
 
 --- On Mon, 1/3/11, David E Jones d...@me.com
 wrote:
 Every single *Type entity in OFBiz is a deviation from
 the
 book (ie the *Type entities are an OFBiz pattern to
 avoid
 redundant entities and keep track of entity extensions
 like
 the Party - PartyGroup,Person thingy), as are
 dozens of
 other entities and hundreds of fields. That book is
 valuable
 for general concepts and patterns, and is not an
 actual data
 model to be used as-is.
 
 -David
 
 
 On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote:
 
 I don't think I'm generalizing anything. The book
 is
 pretty specific and clear: Party Classification is an
 intersection entity that sets up a many-to-many
 relationship
 between the Party entity and the Party Type entity.
 
 I understand OFBiz deviates from the book here
 and
 there, and if this is one of those cases, then I'll
 ask
 again: Why was it done that way?
 
 I'm trying to make sense of the OFBiz Party
 Classification model, and so far it doesn't make
 sense. The
 way it is set up, I can't give a party a
 classification
 without first creating a classification group, assign
 a
 classification type to it, and then assign the party
 to the
 classification group using party classification.
 
 In the book it's much simpler - I just assign a
 party
 type to a party using a party classification.
 Classification
 groups are Party Classification sub-types and they
 aren't
 necessary unless I want to group things a certain
 way.
 
 -Adrian
 
 --- On Mon, 1/3/11, David E Jones d...@me.com
 wrote:
 I think you may be taking the specific term
 type
 and
 generalizing it. Consider that *Type entities
 in
 OFBiz mean
 something very specific, and it is different
 from
 the more
 general use of the term in the book.
 
 -David
 
 
 On Jan 3, 2011, at 3:24 PM, Adrian Crum
 wrote:
 
 That's not what the book shows. There is
 a
 simple
 relationship:
 
 Party - PartyClassification -
 PartyType
 
 If you want to group classifications,
 give
 them
 parent/child relationships, etc then you do
 it
 with
 PartyType, not PartyClassification. Look at
 table
 2.3 on
 page 32.
 
 -Adrian
 
 --- On Mon, 1/3/11, BJ Freeman bjf...@free-man.net
 wrote:
 how about a pattern of parent child
 for PartyClassification of supertype
 
and the sub types then use a
 table for the
 attributess of the subtype.
 this would allow walking the parnent
 child
 relationships.
 PartyClassification 
 
 
 
 ---organizationClassificationminorityClassification
 
 
 
 
 
 
   industryclassification
 
 =
 BJ Freeman
 Strategic Power Office with Supplier
 Automation 
 http

Re: widgetVerbose

[David E Jones]

There was an old thread about this with a few complaints, but it looks like it 
stands.

Maybe more discussion and/or a commit war is in order? ;)

-David


On Aug 30, 2011, at 9:15 PM, Jacques Le Roux wrote:

 widget.properties's widget.verbose setting has precedence over web.xml's 
 widgetVerbose setting. So you can't use
 parameters.widgetVerbose to override widget.verbose to false. Is 
 ModelWidget.widgetBoundaryCommentsEnabled() written this way for
 some reasons?
 
 Another issue is that these HTML boundary comments get outputted even though 
 the view handler is set to screencsv. In the
 widget-screen.xsd, the only way to invoke a template to produce CSV is using 
 htmlhtml-template /, but this always adds HTML
 comments even if the output is CSV (see HtmlWidget class). Maybe we could 
 introduce a csv element or something like that?
 
 Anyway, both of those problems combined mean that there are no apparent clean 
 ways to remove the HTML template begin/end boundary
 comments from the CSV output if you try to draw it with an *.ftl template. A 
 workaround  kludge for now is to invoke the FTL manually through a Groovy 
 script.
 
 Thanks
 
 Jacques
 
 

[jira] [Commented] (OFBIZ-4379) Get first from list tag in screen's and form's action tag.

[David E. Jones (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092927#comment-13092927
 ] 

David E. Jones commented on OFBIZ-4379:
---

Why not just use the [] syntax to get the first element? In other words, 
something like:

set field=websiteContent from-field=websiteContentList[0]/

 Get first from list tag in screen's and form's action tag.
 --

 Key: OFBIZ-4379
 URL: https://issues.apache.org/jira/browse/OFBIZ-4379
 Project: OFBiz
  Issue Type: New Feature
  Components: framework
Affects Versions: Release 10.04, SVN trunk
Reporter: Ankit Jain
Priority: Minor
 Fix For: Release Branch 10.04, SVN trunk


 In most of the cases we need to get first record from a list in screen and 
 form widgets then we have to do something like this: 
 for eg:
 set field=websiteContent value=${groovy: 
 org.ofbiz.entity.util.EntityUtil.getFirst(websiteContentList);}/
 Instead of using like this my idea is to add a tag like first-from-list/ in 
 Screen  Form widget's action tag, so one can easily get first record from a 
 list.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Party Classification

[David E Jones]

On Aug 21, 2011, at 2:56 AM, Adrian Crum wrote:

 I know we have discussed this before, but I'm trying to use the OFBiz party 
 classification entities for another client and I'm running into the same 
 problem I've had before - the current party classification data model just 
 doesn't work.
 
 The party classification data model presented in the The Data Model Resource 
 Book is simple and flexible. My preference would be to use that model, but in 
 previous discussions there was some resistance to using the OFBiz PartyType 
 entity in the way the book describes. So, I have come up with a compromise 
 solution: Use the OFBiz PartyClassificationType entity as a replacement for 
 the DMRB PartyType entity, and implement the DMRB Party Classification 
 subtypes by grouping PartyClassificationTypes.
 
 This is what it would look like:
 
 PartyClassification
 ---
 partyId*, id-ne
 partyClassificationTypeId*, id-ne
 fromDate*, date-time
 thruDate, date-time
 
 PartyClassificationType
 ---
 partyClassificationTypeId*, id-ne
 description, description
 
 PartyClassificationGroup
 
 partyClassificationTypeId*, id-ne
 partyClassificationGroupTypeId*, id-ne
 
 PartyClassificationGroupType
 
 partyClassificationGroupTypeId*, id-ne
 description, description
 
 If the data currently stored in PartyClassificationType is moved to 
 PartyClassificationGroupType, then the proposed model will be capable of 
 supporting the party classification scheme illustrated in Table 2.3 of the 
 DMRB.
 
 What do you think?

Without an idea of what you're trying to model - nothing.

-David

Re: cdyne

[David E Jones]

We have a general precedence for not removing things people might be using, 
which is anything in the project, especially without reasonable notice (like 
waiting a while for comment).

On the other hand, if the company behind these services no longer existed or 
something like that (I don't know if this is the case), then yes might as well 
remove them right away.

-David


On Aug 8, 2011, at 12:37 PM, Jacques Le Roux wrote:

 Everybody agree?
 
 Jacques
 
 From: Tim Ruppert tim.rupp...@hotwaxmedia.com
 It's a likely out of date old web services API - my guess is we could drop 
 it all together.
 Cheers,
 Ruppert
 --
 Tim Ruppert
 HotWax Media
 http://www.hotwaxmedia.com
 o:801.649.6594
 f:801.649.6595
 On Aug 5, 2011, at 8:11 AM, Jacques Le Roux wrote:
 Hi,
 I really wonder if CdyneServices.java should be in commons or rather in 
 commonext. It looks like an application util to me.
 Jacques
 
 

[jira] [Commented] (OFBIZ-4346) Support MySQL and Postgres's LIMIT and OFFSET options

[David E. Jones (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068828#comment-13068828
 ] 

David E. Jones commented on OFBIZ-4346:
---

Adding a class per database is not the preferred way to handle SQL variations 
(you'll notice that OOTB there are no such things for the entity engine).

The better approach is to change the existing code to support the different 
syntax variations, and add an attribute to the datasource element in the 
entityengine.xml file so that the proper variation can be chosen for each 
database. That is how all current syntax variations are configured and coded.

 Support MySQL and Postgres's LIMIT and OFFSET options
 -

 Key: OFBIZ-4346
 URL: https://issues.apache.org/jira/browse/OFBIZ-4346
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Shi Jinghai
Priority: Minor
 Attachments: mysql_postgres_limit_offset_trunk.patch


 Two helper classes are added for MySQL and Postgres to support LIMIT and 
 OFFSET options.
 These classes can be configured in entityengine.xml:
 helper-class=org.ofbiz.entity.datasource.postgres.PostgresHelperDAO for 
 Postgres
 and
 helper-class=org.ofbiz.entity.datasource.mysql.MysqlHelperDAO for MySQL.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4346) Support MySQL and Postgres's LIMIT and OFFSET options

[David E. Jones (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068996#comment-13068996
 ] 

David E. Jones commented on OFBIZ-4346:
---

The concern of the attribute is not so much if limit/offset are allowed, if 
they are not supported the JDBC driver will eventually throw an exception.

The attribute would be used to configure the SQL syntax variation for the 
offset/limit concept. The attribute might look something like:

{code}
xs:attribute name=offset-style default=fetch
xs:simpleTypexs:restriction base=xs:token
xs:enumeration value=fetch/
xs:enumeration value=limit/
/xs:restriction/xs:simpleType
/xs:attribute
{code}

The code for the SQL syntax options might look like:

{code}
if (databaseNode.@offset-style == limit) {
// use the LIMIT/OFFSET style
this.sqlTopLevel.append( LIMIT ).append(limit ?: ALL)
this.sqlTopLevel.append( OFFSET ).append(offset ?: 0)
} else {
// use SQL2008 OFFSET/FETCH style by default
if (offset != null) this.sqlTopLevel.append( OFFSET 
).append(offset).append( ROWS)
if (limit != null) this.sqlTopLevel.append( FETCH FIRST 
).append(limit).append( ROWS ONLY)
}
{code}

This is how I would have implemented it in OFBiz, demonstrated by the fact that 
this is how I implemented it Moqui.


 Support MySQL and Postgres's LIMIT and OFFSET options
 -

 Key: OFBIZ-4346
 URL: https://issues.apache.org/jira/browse/OFBIZ-4346
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Shi Jinghai
Priority: Minor
 Attachments: mysql_postgres_limit_offset_trunk.patch


 Two helper classes are added for MySQL and Postgres to support LIMIT and 
 OFFSET options.
 These classes can be configured in entityengine.xml:
 helper-class=org.ofbiz.entity.datasource.postgres.PostgresHelperDAO for 
 Postgres
 and
 helper-class=org.ofbiz.entity.datasource.mysql.MysqlHelperDAO for MySQL.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Maven-esque directory structures (was Re: GSoC Project update: Code and Test separation of Ofbiz and Implementing pure webdriver)

[David E Jones]

I've been doing a little more research on Maven, and I'm guessing that the 
pattern that Ganath is proposing is at least partly based on the convention for 
src directories in Maven (which appears to be required for use of Maven, BTW... 
ie with their convention over configuration approach, which is certainly nice 
for various reasons even if it does impose certain constraints).

If we wanted our src directories to be Maven-friendly, it would look like:

component/src/main/java
component/src/test/java

In other words, if we're going to make a change, perhaps we should change to 
that as the Maven conventions seem to be turning into industry standards 
(perhaps because the Maven conventions are some of the few that exist and are 
even remotely widely used).

Along that vein, we might also consider moving the files under 
component/script and even component/config to:

component/src/main/resources

BTW, just as a side note if we ever had Maven POM files, their location in each 
component would just be component/pom.xml

-David


On Jul 13, 2011, at 11:09 PM, Ganath Rathnayaka wrote:

 Hi David,
 Since we have the current structure of the code,
 component/src/main
 component/src/test
 which contains separated test and code. We can do the code transformation
 to,
 component/src
 component/src-test
 easily. But to build the project, it may need some work to change the build,
 commons and macros xml files. Since I need to finish the project before 16th
 August, I and Erwan need to change the scope of the project if this change
 need to be done because we have another part (implementing a webdriver) of
 the project to be done.
 Here I am expecting all your final decision before I make my next movement.
 
 thanks
 Ganath

Re: GSoC Project update: Code and Test separation of Ofbiz and Implementing pure webdriver

[David E Jones]

There was actually a discussion about this on this mailing list.

The consensus seemed to be in favour of what Ganath proposed. I though that was 
unfortunate because have non-source directories under an src directory is an 
annoying practice IMO, and I HATE to see that going into the project. I voiced 
that concern but no one else seemed to think it was a big deal.

-David


On Jul 13, 2011, at 10:06 PM, Adam Heath wrote:

 On 07/13/2011 02:49 PM, Erwan de FERRIERES wrote:
 Le 13/07/2011 20:59, Adam Heath a écrit :
 On 07/11/2011 12:59 PM, Ganath Rathnayaka wrote:
 Hi all,
 I need all of you to know what I did up to now in my Google summer of
 code
 project, separating test/code of Ofbiz [1] and implementing a pure
 webdriver[2].
 I the first iteration of the summer I worked on separating test/code of
 Ofbiz. In this we were separate the three main modules,
 
 1. applications
 2. specialpurpose
 3. framework
 
 
 In those modules there were submodules and some modules does not include
 java files which does not needed to do the separation. Here are the
 submodules I separated the test and code.
 
 application sub-modules
 
 accounting manufacturing party workeffort
 content marketing product commonext
 humanres order securityext
 
 specialpurpose sub-modules
 
 assetmaint crowd googlebase myportal projectmgr
 ebay googlecheckout oagis shark
 cmssite ebaystore hhfacility ofbizwebsite
 webpos ecommerce ldap pos workflow
 
 framework sub-modules
 
 appserver catalina entity guiapp security webapp
 base common entityext images service webslinger
 bi example jetty sql webtools
 birt datafile exampleext minilang start widget
 documents geronimo resources testtools
 
 After separate tests and code I had to put them as separate modules,
 
 - src/main/java
 - src/test/java
 
 Er, no, do not do this. Bad. Stop.
 
 Leave it as src/. I already have stuff in ofbiz that creates
 build/lib/ofbiz-base.jar and build/lib/ofbiz-base-test.jar. There is no
 reason to split the test java files out.
 
 Adam,
 thanks for your comment. But why didn't you told this before ? Ganath
 has been working on this theme for more than a month now...
 
 Because I wasn't aware of it?  We are all busy.
 
 And as a GSoC person, he should have investigated what the system already did 
 before changing a bunch of stuff.
 
 I added the test-jar macro to common.xml last April.  It's been there for 
 quite a while.
 
 As for splitting any entitymodel/servicemodel/seed-data stuff, there is no 
 reason to move any files around.  All the loaders need to be modified to 
 support test type loading(some already support this). Then, downstream 
 distributors that don't want to include example or test stuff can just parse 
 the same set of files(or we can include a tool to do it for them).
 

Re: GSoC Project update: Code and Test separation of Ofbiz and Implementing pure webdriver

[David E Jones]

On Jul 13, 2011, at 10:23 PM, Adam Heath wrote:

 On 07/13/2011 03:17 PM, David E Jones wrote:
 
 There was actually a discussion about this on this mailing list.
 
 The consensus seemed to be in favour of what Ganath proposed.
  I though that was unfortunate because have non-source
  directories under an src directory is an annoying practice
  IMO, and I HATE to see that going into the project. I voiced
  that concern but no one else seemed to think it was a big deal.
 
 I agree with David.  I could possibly see a src/java src/c src/python layout, 
 but that is as far as I'm willing to go.
 
 But anyways, ofbiz already *does* split out */test/* stuff into a separate 
 jar, which is the whole point of the src/ splitting that was proposed.  And I 
 did it without having to change the way anyone did ofbiz source development.  
 Which is the better thing.
 
 And my suggestions about adding the correct 'spline' stuff to any loader, is 
 the correct approach as well.  Esp. considering that most loaders already 
 *do* have spline type support.

I wouldn't mind so much having the tests split out into a separate directory 
(through as I think you're getting at they already ARE in separate directories, 
just deeper under the src directory), but I'd much rather have something like:

component/src
component/src-test

instead of:

component/src/main
component/src/test

-David

[jira] [Commented] (OFBIZ-4326) VAT Correction for ProductPrice that has priceWithTax =N is not correct (with patch)

[David E. Jones (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056577#comment-13056577
 ] 

David E. Jones commented on OFBIZ-4326:
---

Stéphane,

What is it you are trying to accomplish? I can tell you for sure that there is 
no reliable way to get an even number as desired when the ProductPrice amount 
does not include tax (ie it is stored in the database with tax excluded). I 
worked on this over the course of a few weeks last year for a client making 
little tweaks here and there to improve the accuracy and precision of the 
numbers, but there are ALWAYS edge cases, and we came up with a few that were 
simply not possible to accommodate when the ProductPrice did not have taxes 
included, it's simply not possible when working with only 3 decimal digits.

The only solution is to store price with tax included, and calculate the tax 
based on the amount with tax included. In other words, the only way it will be 
mathematically correct is to follow the formulas dictated by most VAT/IVA/etc 
law.

This is a REAL pain, but does work. OFBiz supports this OOTB in the trunk and 
the 11.04 release branch. The tax adjustments have an amountAlreadyIncluded of 
the tax amount, and the normal adjustment amount is always 0 so that you know 
how much the tax is, but you don't mess up the total by adding it in again.

 VAT Correction for ProductPrice that has priceWithTax =N is not correct (with 
 patch)
 

 Key: OFBIZ-4326
 URL: https://issues.apache.org/jira/browse/OFBIZ-4326
 Project: OFBiz
  Issue Type: Bug
  Components: accounting
Affects Versions: SVN trunk
Reporter: Stéphane DUCAS
Priority: Minor
 Attachments: OFBIZ-4326_round_price_in_cart.patch, 
 vatCorrection.patch, vatCorrection_2.patch, vatCorrection_2.patch


 The VAT correction adjustment is not correct because it's based on the price 
 not rounded (while tax adjustment is calculated from the rounded price).
 I provide the patch for that.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4316) Widget $() escapes HTML. StringUtil.wrapString(contentText) throw an error

[David E. Jones (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13050907#comment-13050907
 ] 

David E. Jones commented on OFBIZ-4316:
---

When FreeMarker says that an expression is undefined if often means that the 
expression evaluated to null.

If you don't want FreeMarker to blow up like this for null values, add the 
?if_exists built-in.

In general I highly recommend the documentation for FTL at: www.freemarker.org

 Widget $() escapes HTML. StringUtil.wrapString(contentText) throw an error
 --

 Key: OFBIZ-4316
 URL: https://issues.apache.org/jira/browse/OFBIZ-4316
 Project: OFBiz
  Issue Type: Bug
  Components: content, framework, specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: BJ Freeman
  Labels: html, rendering, widget
 Fix For: SVN trunk


 from the ForumScreens.xml#ViewForumMessage
 {code}
 container style=forumtext
label${contentText}/label
 {code}
 show escaped html
 {code}
 * Data Sourcebr / * Marketing Campaignbr / * Tracking Affiliate 
 programsbr / * Segmentbr / * Contact Listbr / * Reportsbr / a 
 class=postlink 
 href=https://demo-trunk.ofbiz.apache.org/marketing/control/mainUSERNAME=flexadminPASSWORD=ofbizJavaScriptEnabled=Y;Demo
  Marketing/a 
 {code}
 replacing 
 {code}label${contentText}/label{code}
 with
 {code}${StringUtil.wrapString(contentText).toString()}{code}
 give this error
 2011-06-15 18:16:43,200 (TP-Processor13) [ UtilXml.java:1043:ERROR]
 XmlFileLoader: File
 file:specialpurpose/ecommerce/widget/ForumScreens.xml
 process error. Line: 151. Error message: cvc-complex-type.2.3: Element
 'condition' cannot have character [children], because the type's content
 type is element-only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations

[David E. Jones (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037656#comment-13037656
 ] 

David E. Jones commented on OFBIZ-4282:
---

*** For #1: 

I did a little more research, and it looks like you're right Philippe, the 
synchronized is no longer needed. It was there originally because before JTA 
1.1 the setTransactionTimeout method was defined like this:

Modify the timeout value that is associated with transactions started by 
subsequent invocations of the begin method.

In JTA 1.1 the definition was changed to fix just this issue and now reads like 
this:

Modify the timeout value that is associated with transactions started by 
subsequent invocations of the begin method by the current thread.

As long as the JTA implementation used follows this rule, then leaving the 
method unsynchronized should be fine.

*** For #2:

I didn't say I'm against a configurable setting, like a properties file 
setting. I said I'm against changing the default in the code for all of OFBiz 
without making it configurable.

On the topic of configuration: I'm against business-level configuration in 
properties files (that should go in the DB), I'm not against technical or 
system configuration in properties files, in fact that's just where it belongs.


 TransactionUtil performance optimisations
 -

 Key: OFBIZ-4282
 URL: https://issues.apache.org/jira/browse/OFBIZ-4282
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Philippe Mouawad
  Labels: PERFORMANCE
 Attachments: patch-OFBIZ-4282.patch


 Hello,
 Reviewing TransactionUtil code, I have seen 2 problems:
 - internalBegin is uselessly synchronized , since it is a static method it is 
 a very big useless Contention Point since not unthread safe instance variable 
 is used 
 - debugResources is true which creates a DebugXAResource (that creates an 
 Exception) , it should be false and made an option for debuging
 These 2 modifications have been in our production for a while and we noticed 
 CPU reduction and no more contention on TransactionUtil#begin
 Regards
 Philippe Mouawad
 http://www.ubik-ingenierie.com

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4282) TransactionUtil performance optimisations

[David E. Jones (JIRA)]

[ 
https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13037454#comment-13037454
 ] 

David E. Jones commented on OFBIZ-4282:
---

Philippe: did you consider the down-sides to these changes? It's fine if you 
want to make these changes locally, but consider undesirable behavior if they 
were the default:

1. If internalBegin is not synchronized the timeout for a transaction would 
bleed over into other transactions; unfortunately this is a major weakness with 
the JTA API: you can only change timeout for the entire transaction manager, 
you can't set it for a single transaction.

2. If the debug stack is not maintained it makes it harder to track down 
transaction and various database-related issues, even in production. If you 
haven't found it to be useful, then again, it's fine to change locally but it 
is valuable information to have when tracking down bad code or certain 
lower-level problems. Also, have you done performance measurements with and 
without to see how much of a change there is?

About the synchronization problem, that is a significant performance issue that 
I have seen while working with clients. However, the real cause of the problem 
is higher up because by default all screens are run within a transaction, and 
really it's pretty rare that a screen needs to be run in a transaction, so that 
is where a change should be made.

Either way, performance improvements without metrics and tracking down the 
main cause of problems is likely to produce as many problems as it solves.

Based on that, I'd say these changes should NOT be committed.

 TransactionUtil performance optimisations
 -

 Key: OFBIZ-4282
 URL: https://issues.apache.org/jira/browse/OFBIZ-4282
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: SVN trunk
Reporter: Philippe Mouawad
  Labels: PERFORMANCE
 Attachments: patch-OFBIZ-4282.patch


 Hello,
 Reviewing TransactionUtil code, I have seen 2 problems:
 - internalBegin is uselessly synchronized , since it is a static method it is 
 a very big useless Contention Point since not unthread safe instance variable 
 is used 
 - debugResources is true which creates a DebugXAResource (that creates an 
 Exception) , it should be false and made an option for debuging
 These 2 modifications have been in our production for a while and we noticed 
 CPU reduction and no more contention on TransactionUtil#begin
 Regards
 Philippe Mouawad
 http://www.ubik-ingenierie.com

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Code and test separation for Apache OFBiz

[David E Jones]

To avoid disrupting the current directory structure, it would be better to 
avoid:

move: component/src - component/src/main/java
result: component/src/main/java, component/src/text/java

and instead not move component/src at all and have:

component/src
component/test-src

... or something along those lines.

-David


On May 17, 2011, at 10:12 PM, Ganath Rathnayaka wrote:

 Hi devs,
 According to my project I suggested some changes to be done to separate the
 test classes from the code itself. Please let me know your ideas about the
 suggested structure.
 Also I came up with the structure for module securityext. Can I separate the
 code as follows? Please let me know your ideas.
 
 current structure
 .
 |-- src
 |   `-- org
 |   `-- ofbiz
 |   `-- securityext
 |   |-- test
 |   |   |-- AuthorizationTests.java
 |   `-- DaTest2.groovy
 
 
 after test/code separation
 .
 |-- src
 ||--main
 ||`--java
 || `-- //rest of the code
 ||--test
 |  `--java
 |  `-- org
 |`-- ofbiz
 |   `-- securityext
 | |-- AuthorizationTests.java
 | `-- DaTest2.groovy
 
 
 
 -- 
 thanks
 Ganath

Re: CustRequestParty entity

[David E Jones]

On May 13, 2011, at 1:28 PM, Adrian Crum wrote:

 The CustRequestParty entity seems to be an implementation of the Request Role 
 Type entity in The Data Model Resource Book. Besides the name difference, the 
 only other difference is using Role Type instead of Request Role Type. 
 Reusing Role Type in this way is okay from my perspective. The problem is, 
 the CustRequestParty entity isn't related to Role Type, instead it is related 
 to PartyRole - which requires a PartyRole entry.
 
 That is an extremely limiting relationship - a party can't be related to a 
 Request in a particular role unless they are already a member of that role.

Pretty much all *Role and *Party entities are setup this way, and in fact 
nearly all entities that have pairs of partyId and roleTypeId have a type one 
relationship to PartyRole. This is a pattern that goes back to the beginning of 
OFBiz and is used throughout the project.

I agree with making the change so that all of these have fks to Party and 
RoleType separately, so not requiring an entry in PartyRole, but keep in mind 
that's a big change. I've actually done this in the Mantle UDM, but that was 
easy because there aren't any dependencies on that data model yet... for OFBiz 
it's a bit more work.

BTW, this goes back to the original pattern for party roles where the concept 
was that a party being in a role (ie with a PartyRole record) means nothing, 
and roles should just be used to define how parties are related to other 
records in the system. However, no one seems to want to follow that pattern so 
by de facto practice it's a moot point, and IMO ideally we would get rid of 
PartyRole altogether, or use it for specific and limited circumstances. The 
reason is that 99% of the time someone comes up with a constraint like Party X 
is in Role Y they are forgetting other important details, like in Role Y for 
Record Z.

-David

Re: CustRequestParty entity

[David E Jones]

On May 13, 2011, at 1:47 PM, Adrian Crum wrote:

 On 5/13/2011 1:36 PM, David E Jones wrote:
 On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
 
 The CustRequestParty entity seems to be an implementation of the Request 
 Role Type entity in The Data Model Resource Book. Besides the name 
 difference, the only other difference is using Role Type instead of Request 
 Role Type. Reusing Role Type in this way is okay from my perspective. The 
 problem is, the CustRequestParty entity isn't related to Role Type, instead 
 it is related to PartyRole - which requires a PartyRole entry.
 
 That is an extremely limiting relationship - a party can't be related to a 
 Request in a particular role unless they are already a member of that role.
 Pretty much all *Role and *Party entities are setup this way, and in fact 
 nearly all entities that have pairs of partyId and roleTypeId have a type 
 one relationship to PartyRole. This is a pattern that goes back to the 
 beginning of OFBiz and is used throughout the project.
 
 I agree with making the change so that all of these have fks to Party and 
 RoleType separately, so not requiring an entry in PartyRole, but keep in 
 mind that's a big change. I've actually done this in the Mantle UDM, but 
 that was easy because there aren't any dependencies on that data model 
 yet... for OFBiz it's a bit more work.
 
 BTW, this goes back to the original pattern for party roles where the 
 concept was that a party being in a role (ie with a PartyRole record) means 
 nothing, and roles should just be used to define how parties are related to 
 other records in the system. However, no one seems to want to follow that 
 pattern so by de facto practice it's a moot point, and IMO ideally we would 
 get rid of PartyRole altogether, or use it for specific and limited 
 circumstances. The reason is that 99% of the time someone comes up with a 
 constraint like Party X is in Role Y they are forgetting other important 
 details, like in Role Y for Record Z.
 
 
 Thanks for the reply!
 
 I don't think this particular change is a big one. I suspect the relationship 
 can be changed without much fuss, but I will check into it further.
 
 There shouldn't be any confusion about Party Role if we follow the author's 
 reasoning for it: It is intended to describe the party's role in the 
 enterprise or organization. In Request Role, the relationship being described 
 is a party's role in the request, not the party's role in the enterprise. 
 That's why Request Role is related directly to a Role Type and not a Party 
 Role.

Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote 
It is intended to describe the party's role in the enterprise or organization 
and not the party's role in the enterprise. That's why Request Role is related 
directly to a Role Type and not a Party Role.

However, a record in PartyRole is NOT meant to represent a Party's role within 
the enterprise or organization, if you want to model that you should have a 
PartyRelationship record going between the Party record for the enterprise or 
organization... not a PartyRole that just ties a partyId to a roleTypeId 
without any consideration of the enterprise or organization. It's inflexible 
and generally bad modeling, and if something in The Data Model Resource Book 
seems to describe it this way I'd be surprised, chances are whatever you think 
means this really means something else.

-David

Re: CustRequestParty entity

[David E Jones]

On May 13, 2011, at 2:02 PM, Adrian Crum wrote:

 On 5/13/2011 1:53 PM, David E Jones wrote:
 On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
 
 On 5/13/2011 1:36 PM, David E Jones wrote:
 On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
 
 The CustRequestParty entity seems to be an implementation of the Request 
 Role Type entity in The Data Model Resource Book. Besides the name 
 difference, the only other difference is using Role Type instead of 
 Request Role Type. Reusing Role Type in this way is okay from my 
 perspective. The problem is, the CustRequestParty entity isn't related to 
 Role Type, instead it is related to PartyRole - which requires a 
 PartyRole entry.
 
 That is an extremely limiting relationship - a party can't be related to 
 a Request in a particular role unless they are already a member of that 
 role.
 Pretty much all *Role and *Party entities are setup this way, and in fact 
 nearly all entities that have pairs of partyId and roleTypeId have a type 
 one relationship to PartyRole. This is a pattern that goes back to the 
 beginning of OFBiz and is used throughout the project.
 
 I agree with making the change so that all of these have fks to Party and 
 RoleType separately, so not requiring an entry in PartyRole, but keep in 
 mind that's a big change. I've actually done this in the Mantle UDM, but 
 that was easy because there aren't any dependencies on that data model 
 yet... for OFBiz it's a bit more work.
 
 BTW, this goes back to the original pattern for party roles where the 
 concept was that a party being in a role (ie with a PartyRole record) 
 means nothing, and roles should just be used to define how parties are 
 related to other records in the system. However, no one seems to want to 
 follow that pattern so by de facto practice it's a moot point, and IMO 
 ideally we would get rid of PartyRole altogether, or use it for specific 
 and limited circumstances. The reason is that 99% of the time someone 
 comes up with a constraint like Party X is in Role Y they are forgetting 
 other important details, like in Role Y for Record Z.
 
 Thanks for the reply!
 
 I don't think this particular change is a big one. I suspect the 
 relationship can be changed without much fuss, but I will check into it 
 further.
 
 There shouldn't be any confusion about Party Role if we follow the author's 
 reasoning for it: It is intended to describe the party's role in the 
 enterprise or organization. In Request Role, the relationship being 
 described is a party's role in the request, not the party's role in the 
 enterprise. That's why Request Role is related directly to a Role Type and 
 not a Party Role.
 Yeah, this is exactly the sort of misunderstanding I'm referring to. You 
 wrote It is intended to describe the party's role in the enterprise or 
 organization and not the party's role in the enterprise. That's why 
 Request Role is related directly to a Role Type and not a Party Role.
 
 However, a record in PartyRole is NOT meant to represent a Party's role 
 within the enterprise or organization, if you want to model that you should 
 have a PartyRelationship record going between the Party record for the 
 enterprise or organization... not a PartyRole that just ties a partyId to a 
 roleTypeId without any consideration of the enterprise or organization. It's 
 inflexible and generally bad modeling, and if something in The Data Model 
 Resource Book seems to describe it this way I'd be surprised, chances are 
 whatever you think means this really means something else.
 
 
 
 Right. I over-simplified the meaning of Party Role to demonstrate the 
 differences in this case. Thank you for the clarification.
 
 Semantics aside, we agree that the existing entity relationship I described 
 is incorrect, right?

Good question, I don't know that it's incorrect... but it is certainly 
cumbersome, and the initial point of that constraint (to help avoid the use of 
PartyRole without any context) is totally lost on probably every single person 
who uses OFBiz, with maybe just a couple of exceptions, so the pattern has 
failed in its intent.

The main point of my first response is that the pattern is used in dozens of 
places, to see a list look at the WebTools Entity Reference for the PartyRole 
entity and look at all of the type many relationships. Every one of those 
follows the pattern you described for CustRequestParty.

It's a good point that it is cumbersome and is of little use, and so we might 
as well get rid of those everywhere...

-David

Re: ports in test-containers.xml

[David E Jones]

As long as it is just for the test-containers.xml file.

I would be against changing this for the ofbiz-containers.xml file, too many 
people are used to it and too much documentation points to it, so changing it 
there would require a significant effort to change docs and communicate the 
difference, and deal with questions on the mailing lists about the change...

-David


On May 13, 2011, at 8:02 AM, Jacques Le Roux wrote:

 +1, I can't see any issues changing default OOTB
 
 Jacques
 
 From: Erwan de FERRIERES erwan.de-ferrie...@nereide.biz
 Hi all,
 I'm planning on changing the ports for the http and https test containers. 
 This way, tests can be runned on the Apache jenkins instance (8080 is 
 already used).
 Is there anyone against these ?
 Cheers,
 -- 
 Erwan de FERRIERES
 www.nereide.biz
 

Re: CustRequestParty entity

[David E Jones]

On May 13, 2011, at 2:21 PM, Adrian Crum wrote:

 On 5/13/2011 2:07 PM, David E Jones wrote:
 On May 13, 2011, at 2:02 PM, Adrian Crum wrote:
 
 On 5/13/2011 1:53 PM, David E Jones wrote:
 On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
 
 On 5/13/2011 1:36 PM, David E Jones wrote:
 On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
 
 The CustRequestParty entity seems to be an implementation of the 
 Request Role Type entity in The Data Model Resource Book. Besides the 
 name difference, the only other difference is using Role Type instead 
 of Request Role Type. Reusing Role Type in this way is okay from my 
 perspective. The problem is, the CustRequestParty entity isn't related 
 to Role Type, instead it is related to PartyRole - which requires a 
 PartyRole entry.
 
 That is an extremely limiting relationship - a party can't be related 
 to a Request in a particular role unless they are already a member of 
 that role.
 Pretty much all *Role and *Party entities are setup this way, and in 
 fact nearly all entities that have pairs of partyId and roleTypeId have 
 a type one relationship to PartyRole. This is a pattern that goes back 
 to the beginning of OFBiz and is used throughout the project.
 
 I agree with making the change so that all of these have fks to Party 
 and RoleType separately, so not requiring an entry in PartyRole, but 
 keep in mind that's a big change. I've actually done this in the Mantle 
 UDM, but that was easy because there aren't any dependencies on that 
 data model yet... for OFBiz it's a bit more work.
 
 BTW, this goes back to the original pattern for party roles where the 
 concept was that a party being in a role (ie with a PartyRole record) 
 means nothing, and roles should just be used to define how parties are 
 related to other records in the system. However, no one seems to want to 
 follow that pattern so by de facto practice it's a moot point, and IMO 
 ideally we would get rid of PartyRole altogether, or use it for specific 
 and limited circumstances. The reason is that 99% of the time someone 
 comes up with a constraint like Party X is in Role Y they are 
 forgetting other important details, like in Role Y for Record Z.
 
 Thanks for the reply!
 
 I don't think this particular change is a big one. I suspect the 
 relationship can be changed without much fuss, but I will check into it 
 further.
 
 There shouldn't be any confusion about Party Role if we follow the 
 author's reasoning for it: It is intended to describe the party's role in 
 the enterprise or organization. In Request Role, the relationship being 
 described is a party's role in the request, not the party's role in the 
 enterprise. That's why Request Role is related directly to a Role Type 
 and not a Party Role.
 Yeah, this is exactly the sort of misunderstanding I'm referring to. You 
 wrote It is intended to describe the party's role in the enterprise or 
 organization and not the party's role in the enterprise. That's why 
 Request Role is related directly to a Role Type and not a Party Role.
 
 However, a record in PartyRole is NOT meant to represent a Party's role 
 within the enterprise or organization, if you want to model that you 
 should have a PartyRelationship record going between the Party record for 
 the enterprise or organization... not a PartyRole that just ties a partyId 
 to a roleTypeId without any consideration of the enterprise or 
 organization. It's inflexible and generally bad modeling, and if something 
 in The Data Model Resource Book seems to describe it this way I'd be 
 surprised, chances are whatever you think means this really means 
 something else.
 
 
 Right. I over-simplified the meaning of Party Role to demonstrate the 
 differences in this case. Thank you for the clarification.
 
 Semantics aside, we agree that the existing entity relationship I described 
 is incorrect, right?
 Good question, I don't know that it's incorrect... but it is certainly 
 cumbersome, and the initial point of that constraint (to help avoid the use 
 of PartyRole without any context) is totally lost on probably every single 
 person who uses OFBiz, with maybe just a couple of exceptions, so the 
 pattern has failed in its intent.
 
 The main point of my first response is that the pattern is used in dozens of 
 places, to see a list look at the WebTools Entity Reference for the 
 PartyRole entity and look at all of the type many relationships. Every one 
 of those follows the pattern you described for CustRequestParty.
 
 It's a good point that it is cumbersome and is of little use, and so we 
 might as well get rid of those everywhere...
 
 
 The point I made earlier is that The Data Model Resource Book does not put 
 that constraint on the Request Role entity. The defacto OFBiz pattern of 
 enforcing that constraint everywhere a Role Type is used is what seems 
 incorrect to me. I suppose we could debate if the book is incorrect, but I 
 need to move on to other things...  ;-)

I

Re: Discussion: REST support in OFBiz

[David E Jones]

One bit of documentation I like that shows clearly how the RESTful services are 
defined and what the messages look like is the Adility API docs, such as this 
one:

http://apidoc.adility.com/submission-api

The nice thing (and actually many RESTful API docs do this) is that they list 
each service for that service they tell you which HTTP method is used, and 
what the path to the resource is. The point of this style of mapping is because 
the HTTP methods (GET, PUT, POST, DELETE) don't really map naturally to, well, 
to anything. They don't even map well to CrUD operations because PUT and POST 
are really meant for submitting resources and both could technically result in 
a create or update, though they have different intended uses and semantics that 
confuse the matter further.

So, it's generally necessary to define service locations (and mappings to the 
actual service) not just as a URL, but with a HTTP method and URL pair.

On a side note, to handle all HTTP methods we'll need to either modify the 
ControlServlet, or (maybe preferable, and what I've done on other projects) 
just use a totally separate servlet that is meant for the RESTful API. In other 
words, because RESTful stuff relies more on lower level HTTP stuff it is quite 
different from the more generic approach the ControlServlet uses.

-David


On May 6, 2011, at 9:39 AM, Adrian Crum wrote:

 Here is the Amazon REST API - it could be a good source of ideas for 
 implementation:
 
 http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAPI.html
 
 -Adrian
 
 On 5/6/2011 7:33 AM, Jacques Le Roux wrote:
 After having read the response hyperlinks article I tend to agree with 
 Adrian. HATEOAS seems to me a really important feature of
 REST
 I have still to read completly the 1st article Adrian mentionned though. I 
 mean http://www.infoq.com/articles/rest-introduction
 
 And yes I also prefer response-hyperlink instead of hateoas-attributes
 
 Jacques
 
 From: Adrian Crum adrian.c...@sandglass-software.com
 I don't like the idea of adding attributes to the existing service element 
 because we still need a way to specify response
 hyperlinks (HATEOAS), plus I imagine other sub-elements and additional 
 attributes will be needed as we build it out more.
 
 I prefer to keep the attribute names similar to the names used in the 
 specification - so they will make sense to developers who
 are familiar with REST. I came up with a better name for the 
 hateoas-attributes element: response-hyperlink.
 
 -Adrian
 
 On 5/6/2011 2:23 AM, Jacopo Cappellato wrote:
 What about adding the noun and verb attributes to the service 
 element?
 BTW in order to write a good application I suspect that a lot of services 
 should be refactored to better fit into a REST based
 application.
 A good candidate for a prototype could be the Webtools' Entity Data 
 Maintenance application: we could rewrite it to work with
 RESTful URIs like
 
 webtools/entities/
 webtools/entities/orderheaders/
 webtools/entities/orderheaders?orderTypeId=SALES_ORDER
 webtools/entities/orderheaders/10010 (CRUD using GET/POST/DELETE)
 webtools/entityrelations/orderheader (this will return URLs of related 
 entities)
 
 We could provide different representations for the responses (and this 
 could also serve to reimplement the XML data export
 part).
 
 Kind regards,
 
 Jacopo
 
 On May 5, 2011, at 5:06 PM, Adrian Crum wrote:
 
 I'm thinking we could have a new element for the service definition:
 
 service name=createExample default-entity-name=Example 
 engine=entity-auto invoke=create auth=true
  ...
 rest-attributes resource=example method=POST/
  ...
 /service
 
 The presence of the rest-attributes element implies the service can be 
 exported via REST.
 
 So, a new Example can be created by sending an HTTP POST request to
 
 https://mydomain.com/rest/example
 
 HATEOAS can be implemented with child elements:
 
 service name=createExample default-entity-name=Example 
 engine=entity-auto invoke=create auth=true
  ...
 rest-attributes resource=example method=POST
 hateoas-attributes resource=exampleItem .../
...
 /rest-attributes
  ...
 /service
 
 service name=createExampleItem default-entity-name=ExampleItem 
 engine=entity-auto invoke=create auth=true
  ...
 rest-attributes resource=exampleItem method=POST
 hateoas-attributes resource=example .../
...
 /rest-attributes
  ...
 /service
 
 The REST servlet will use the hateoas-attributes elements to construct 
 URLs for the REST response.
 
 What do you think?
 
 -Adrian
 
 On 5/4/2011 6:24 PM, Adrian Crum wrote:
 Thanks Scott!
 
 I agree - the REST URLs (or URIs) should represent resources and the 
 HTTP commands should represent actions taken on those
 resources. I guess I was trying to take a shortcut by having REST URLs 
 point directly to OFBiz services.
 
 So we need a way to map REST URLs to the appropriate services. Maybe the 
 service definitions could include a REST resource
 identifier. That should be 

Re: Discussion: REST support in OFBiz

[David E Jones]

Yes, POST semantics are more flexible in some ways in that it implies that the 
resource in the message is added (created) under the location specified, and 
because of this it supports sending multiple resources to be added there. In 
theory there could already be something under the location with the same name, 
causing an update or replacement, but that seems to be ignored, making POST 
seem slightly more natural as a create instead of an update.

PUT is for placing the data at the location and I believe does not support 
multiple resources in the message, and would either create if nothing was at 
the location or update if something was there, and I suppose that's why people 
consider it more for update instead of create.

Either way, it's messed up IMO... but that goes back to my bias against RESTful 
services as it seems to be using a protocol for something that it what was not 
intended or designed for, and it turns into repeated efforts to put round pegs 
in square holes (or do I have that backwards?).

-David


On May 6, 2011, at 1:52 PM, Adrian Crum wrote:

 Thanks David!
 
 I was thinking we would need a servlet for this - because some of the REST 
 semantics are in the HTTP headers as well as in the HTTP method. From what 
 I've read, the generally accepted convention is that POST is a create 
 operation, and PUT is an update operation. But I agree with you that we need 
 to have the method meaning clearly documented.
 
 -Adrian
 
 On 5/6/2011 10:40 AM, David E Jones wrote:
 One bit of documentation I like that shows clearly how the RESTful services 
 are defined and what the messages look like is the Adility API docs, such as 
 this one:
 
 http://apidoc.adility.com/submission-api
 
 The nice thing (and actually many RESTful API docs do this) is that they 
 list each service for that service they tell you which HTTP method is 
 used, and what the path to the resource is. The point of this style of 
 mapping is because the HTTP methods (GET, PUT, POST, DELETE) don't really 
 map naturally to, well, to anything. They don't even map well to CrUD 
 operations because PUT and POST are really meant for submitting resources 
 and both could technically result in a create or update, though they have 
 different intended uses and semantics that confuse the matter further.
 
 So, it's generally necessary to define service locations (and mappings to 
 the actual service) not just as a URL, but with a HTTP method and URL pair.
 
 On a side note, to handle all HTTP methods we'll need to either modify the 
 ControlServlet, or (maybe preferable, and what I've done on other projects) 
 just use a totally separate servlet that is meant for the RESTful API. In 
 other words, because RESTful stuff relies more on lower level HTTP stuff it 
 is quite different from the more generic approach the ControlServlet uses.
 
 -David
 
 
 On May 6, 2011, at 9:39 AM, Adrian Crum wrote:
 
 Here is the Amazon REST API - it could be a good source of ideas for 
 implementation:
 
 http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAPI.html
 
 -Adrian
 
 On 5/6/2011 7:33 AM, Jacques Le Roux wrote:
 After having read the response hyperlinks article I tend to agree with 
 Adrian. HATEOAS seems to me a really important feature of
 REST
 I have still to read completly the 1st article Adrian mentionned though. I 
 mean http://www.infoq.com/articles/rest-introduction
 
 And yes I also prefer response-hyperlink instead of hateoas-attributes
 
 Jacques
 
 From: Adrian Crumadrian.c...@sandglass-software.com
 I don't like the idea of adding attributes to the existing service 
 element because we still need a way to specify response
 hyperlinks (HATEOAS), plus I imagine other sub-elements and additional 
 attributes will be needed as we build it out more.
 
 I prefer to keep the attribute names similar to the names used in the 
 specification - so they will make sense to developers who
 are familiar with REST. I came up with a better name for the 
 hateoas-attributes element: response-hyperlink.
 
 -Adrian
 
 On 5/6/2011 2:23 AM, Jacopo Cappellato wrote:
 What about adding the noun and verb attributes to the service 
 element?
 BTW in order to write a good application I suspect that a lot of 
 services should be refactored to better fit into a REST based
 application.
 A good candidate for a prototype could be the Webtools' Entity Data 
 Maintenance application: we could rewrite it to work with
 RESTful URIs like
 
 webtools/entities/
 webtools/entities/orderheaders/
 webtools/entities/orderheaders?orderTypeId=SALES_ORDER
 webtools/entities/orderheaders/10010 (CRUD using GET/POST/DELETE)
 webtools/entityrelations/orderheader (this will return URLs of related 
 entities)
 
 We could provide different representations for the responses (and this 
 could also serve to reimplement the XML data export
 part).
 
 Kind regards,
 
 Jacopo
 
 On May 5, 2011, at 5:06 PM, Adrian Crum wrote:
 
 I'm thinking we could have a new

Re: Please move Ofbiz books page from OFBADMIN to OFBIZ wiki

[David E Jones]

Jacques,

Why do you recommend requesting changes in comments? There is no way to track 
them there, and a good chance fewer people (or no one) will notice them. We 
also have a license granting issue which is better through Jira, though 
technically not required (ie for legal something over a mailing list, and 
perhaps in a comment, is okay but Jira has an explicit contribution thingy).

I'm not sure what you meant by what you wrote here, but it is very different 
from what I wrote and it sounded like you were saying it was the same as what I 
wrote.

Paul: I apologize for the confusion, quite frankly there aren't many 
contributions for the restricted spaces in Confluence, and as you can see there 
is not a consensus or even a meeting of the minds about how to handle it. I'd 
still recommend a Jira issue if you want to make sure your changes get tracked 
and don't slip through the cracks. Email and comments get lost a lot easier, 
and don't get seen by as many committers (especially if sent directly to a 
couple of people instead of to the mailing list). Comments are the same way, I 
don't know how many (if any) committers have notifications setup for all 
comments, I certainly don't.

-David


On May 4, 2011, at 1:16 AM, Jacques Le Roux wrote:

 Though it has already been explained recently but shortly by David (I think 
 it's explained in the wiki somewhere also), the
 established practise for Confluence (we call Wiki the open pages) is to 
 suggest your changes in a comment at bottom of the page to
 change. You can even use Confluence formatting there. It's not more work for 
 you and sligthly for us (we would have to review
 changes anyway).
 
 Jacques
 PS: Paul, I have just received your documents, please follow the procedure 
 above rather. Note that I want to keep the same structure, ie have you an 
 image for Sharan's book?
 
 From: David E Jones d...@me.com
 
 The best procedure to submit contributions is the same as for code, ie 
 create a Jira issue.
 
 Also, note that the same process as for code is used for Confluence. If 
 someone starts contributing a lot of content they will be
 invited to have permissions to do it directly.
 
 -David
 
 
 On May 3, 2011, at 10:03 PM, Paul Foxworthy wrote:
 
 OK, I've sent what I'm thinking of to David and Jacques.
 
 I can see that project policy and planning needs governance and while
 everyone can contribute their own opinions on the mailing list, the project
 administration wiki should represent consensus and conclusions.
 
 I suggest this is not in that category. Code needs to be 100% right or we
 have a broken system that nobody can use. A wiki page only needs to be 90%
 right, and if it exists and it is 90% right, people will quickly correct the
 last 10%. That is, if they have access to it.
 
 Isn't the books page an example of something that core contributors should
 be able to ignore?
 
 If nobody agrees with me, please give a clear statement of what the
 procedure is to submit proposed changes to the OFBADMIN wiki.
 
 Cheers
 
 Paul Foxworthy
 
 
 David E Jones-4 wrote:
 
 The point of having that page in a restricted space is to reduce quantity
 and increase quality, just like having a limited group of committers for
 the OFBiz source code instead of allowing anyone and everyone to commit.
 Whether or not that is the result is another questions, but here we are...
 
 The better approach would be for Paul to send over proposed changes and
 someone with permission can update the page.
 
 -David
 
 
 On Apr 27, 2011, at 2:26 AM, Jacques Le Roux wrote:
 
 Hi Paul,
 
 Though I agree it could be done, since I'm anyway monitoring and checking
 all changes in the wiki, this is not a decision I should take on my own.
 So I forward on dev ML to ask the same... I think we will get a
 consensus...
 
 Thanks
 
 Jacques
 - Original Message - From: Paul Foxworthy
 To: jacques.le.r...@les7arts.com
 Sent: Tuesday, April 26, 2011 10:05 AM
 Subject: Please move Ofbiz books page from OFBADMIN to OFBIZ wiki
 
 
 Hi Jacques,
 
 I see Ruth Hofffman has published an e-book on Ofbiz accounting. I
 wanted to put it on the wiki, but I can't edit pages in the OFBADMIN
 wiki. Please move
 https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Related+Books
 and its images to the general OFBIZ wiki. Then people like me will be
 able to work on it.
 
 Thanks
 
 Paul Foxworthy
 
 -- 
 Coherent Software Australia Pty Ltd
 PO Box 2773
 Cheltenham Vic 3192
 Phone: (03) 9585 6788
 Fax: (03) 9585 1086
 Web: http://www.cohsoft.com.au/
 Email: sa...@cohsoft.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/Re-Please-move-Ofbiz-books-page-from-OFBADMIN-to-OFBIZ-wiki-tp3477620p3494531.html
 Sent from the OFBiz - Dev mailing list archive at Nabble.com.
 
 
 

Re: Another Framework Vision

[David E Jones]

Back to the original purpose of this thread, does anyone have any feedback on 
Adrian's framework ideas?

-David

Re: Another Framework Vision

[David E Jones]

Could you be more specific? Are you saying that you agree with every part of 
what Adrian proposed in his document?

For a reminder, it is this document I'm referring to (and that this thread was 
originally about):

https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision

-David


On May 4, 2011, at 11:26 AM, Shi Jinghai wrote:

 +1 to Adrian.
 
 On Wed, 2011-05-04 at 10:46 -0700, David E Jones wrote:
 Back to the original purpose of this thread, does anyone have any feedback 
 on Adrian's framework ideas?
 
 -David
 
 

Re: Please move Ofbiz books page from OFBADMIN to OFBIZ wiki

[David E Jones]

On May 4, 2011, at 12:23 PM, Jacques Le Roux wrote:

 From: David E Jones d...@me.com
 Jacques,
 
 Why do you recommend requesting changes in comments?
 
 http://markmail.org/message/iadu3l57gkb22lkf :p

Yeah, that was nearly 5 years ago. I would hope we could make progress in that 
time, especially for this sort of low frequency thing that is easily lost.

 There is no way to track them there, and a good chance fewer people (or no 
 one) will notice them.
 
 You may use Confluence for that see 
 https://cwiki.apache.org/confluence/users/viewnotifications.action

Yes, but how many committers have Confluence notifications setup, and how many 
want them?

 We also have a license granting issue which is better through Jira, though 
 technically not required (ie for legal something over a
 mailing list, and perhaps in a comment, is okay but Jira has an explicit 
 contribution thingy).
 
 I'm not sure what you meant by what you wrote here, but it is very different 
 from what I wrote and it sounded like you were saying
 it was the same as what I wrote.
 
 Paul: I apologize for the confusion, quite frankly there aren't many 
 contributions for the restricted spaces in Confluence, and as
 you can see there is not a consensus or even a meeting of the minds about 
 how to handle it. I'd still recommend a Jira issue if
 you want to make sure your changes get tracked and don't slip through the 
 cracks. Email and comments get lost a lot easier, and
 don't get seen by as many committers (especially if sent directly to a 
 couple of people instead of to the mailing list). Comments
 are the same way, I don't know how many (if any) committers have 
 notifications setup for all comments, I certainly don't.
 
 I have :o) And I follow it closely from the moment you gave me the rights for 
 that (some years ago). Actually I act as a sort of
 Confluence moderator, and I do it seriously. Conflucen comments advantage: 
 Confluence formatting, a simple C/P and voilà. Still the
 delegate and KISS way: as you said  license granting is not required .

If it works, fine. If I were contributing something to Confluence I would use a 
Jira issue to do it and keep track of it, and that's what I was trying to 
communicate to Paul. Otherwise I, as a contributor, would have to monitor and 
keep track of it instead of having a system to help with that.

Just an FYI: Jira comments also support Confluence style formatting.

-David



 On May 4, 2011, at 1:16 AM, Jacques Le Roux wrote:
 
 Though it has already been explained recently but shortly by David (I think 
 it's explained in the wiki somewhere also), the
 established practise for Confluence (we call Wiki the open pages) is to 
 suggest your changes in a comment at bottom of the page
 to
 change. You can even use Confluence formatting there. It's not more work 
 for you and sligthly for us (we would have to review
 changes anyway).
 
 Jacques
 PS: Paul, I have just received your documents, please follow the procedure 
 above rather. Note that I want to keep the same
 structure, ie have you an image for Sharan's book?
 
 From: David E Jones d...@me.com
 
 The best procedure to submit contributions is the same as for code, ie 
 create a Jira issue.
 
 Also, note that the same process as for code is used for Confluence. If 
 someone starts contributing a lot of content they will
 be
 invited to have permissions to do it directly.
 
 -David
 
 
 On May 3, 2011, at 10:03 PM, Paul Foxworthy wrote:
 
 OK, I've sent what I'm thinking of to David and Jacques.
 
 I can see that project policy and planning needs governance and while
 everyone can contribute their own opinions on the mailing list, the 
 project
 administration wiki should represent consensus and conclusions.
 
 I suggest this is not in that category. Code needs to be 100% right or we
 have a broken system that nobody can use. A wiki page only needs to be 90%
 right, and if it exists and it is 90% right, people will quickly correct 
 the
 last 10%. That is, if they have access to it.
 
 Isn't the books page an example of something that core contributors should
 be able to ignore?
 
 If nobody agrees with me, please give a clear statement of what the
 procedure is to submit proposed changes to the OFBADMIN wiki.
 
 Cheers
 
 Paul Foxworthy
 
 
 David E Jones-4 wrote:
 
 The point of having that page in a restricted space is to reduce quantity
 and increase quality, just like having a limited group of committers for
 the OFBiz source code instead of allowing anyone and everyone to commit.
 Whether or not that is the result is another questions, but here we 
 are...
 
 The better approach would be for Paul to send over proposed changes and
 someone with permission can update the page.
 
 -David
 
 
 On Apr 27, 2011, at 2:26 AM, Jacques Le Roux wrote:
 
 Hi Paul,
 
 Though I agree it could be done, since I'm anyway monitoring and 
 checking
 all changes in the wiki, this is not a decision I should take on my own.
 So I forward on dev