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

+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

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

+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"

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

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 >

Re: Why A Framework Rewrite Is Necessary

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 reas

Re: Why A Framework Rewrite Is Necessary

> 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 >

Re: Why A Framework Rewrite Is Necessary

> 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

Re: Why A Framework Rewrite Is Necessary

> 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

Re: Discussion: Replace framework by Moqui.

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

Re: Discussion: Replace framework by Moqui.

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

Re: Discussion: Replace framework by Moqui.

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

Re: VOTE RESULT: Begin Replacing OFBiz Framework With Moqui

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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

+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

Re: move to git.

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

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

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

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

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

Re: move to git.

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

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

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

Re: move to git.

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

Re: move to git.

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

Re: Discussion: Replace framework by Moqui.

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

Re: move to git.

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

Re: Discussion: Replace framework by Moqui.

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

Re: Discussion: Replace framework by Moqui.

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

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

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

Re: Discussion: Replace framework by Moqui.

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

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

'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

Re: Discussion: Replace framework by Moqui.

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

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

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

Re: Discussion: Replace framework by Moqui.

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

Re: Discussion: Replace framework by Moqui.

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

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

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

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

Re: OFBiz and OHLOH (OpenHub.net

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

Re: Removing the CachedClassLoader

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

Re: Discussion: migrating from Ant to Gradle

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

Re: The future of OFBiz - Open Discussion

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

Re: The future of OFBiz - Open Discussion

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.

Re: OFBiz JSON Classes

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

Re: OFBiz In 2014

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

Re: OFBiz In 2014

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

Re: OFBiz In 2014

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

Re: OFBiz In 2014

. 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

Re: OFBiz In 2014

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

Re: OFBiz In 2014

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

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

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

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

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

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

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

Re: Proposal: Entity Subtype Implementation

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

Re: Removing some unnecessary synchronization for cache objects

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:

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

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

Re: Discussion: Mini-language Overhaul

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

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

(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

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

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

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

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

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

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

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

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

Re: Discussion: Mini-language Overhaul

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

Re: Discussion: Handling Security In Nested Services

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

Re: Discussion: Handling Security In Nested Services

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

Moqui/Mantle Update

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

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

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:

JavaOne, anyone going?

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

Re: widgetVerbose

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

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

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.

Re: widgetVerbose

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

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

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

Re: widgetVerbose

/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

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

, 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

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

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

Re: Policy about supported releases

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

Re: Party Classification Data Modeling

, 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

Re: widgetVerbose

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

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

[ 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

Re: Party Classification

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.

Re: cdyne

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

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

[ 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

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

[ 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

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

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

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

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

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

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

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

[ 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

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

[ 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

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

[ 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

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

[ 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

Re: Code and test separation for Apache OFBiz

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

Re: CustRequestParty entity

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

Re: CustRequestParty entity

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

Re: CustRequestParty entity

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

Re: ports in test-containers.xml

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

Re: CustRequestParty entity

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

Re: Discussion: REST support in OFBiz

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

Re: Discussion: REST support in OFBiz

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

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

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

Re: Another Framework Vision

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

Re: 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

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

  1   2   3   4   5   6   7   8   9   10   >