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 may be useful because it could > provid

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" email (similar to the "commits" mailing

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 > > and Initial Framew

Re: Why A Framework Rewrite Is Necessary

we start with the pages that Adrian wrote way back then, as a basic > outline of the components of a framework? > https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision > > > Ron > > > On 17/10/2015 2:07 PM, David E. Jones wrote: >> This me

Re: Why A Framework Rewrite Is Necessary

mage, > > 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 &g

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 > Moqui-Mantle-HiveMindPM-PopCommerce s

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 some of the problems I listed - so b

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 would be > easier for the Moqui com

Re: Discussion: Replace framework by Moqui.

> On 22 May 2015, at 11:29, David E. Jones wrote: > > >> On 21 May 2015, at 06:28, Ron Wheeler 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 do

Re: Discussion: Replace framework by Moqui.

> On 21 May 2015, at 06:28, Ron Wheeler 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

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: Begin Replacing OFBiz Framework With Moqui

> On 30 Apr 2015, at 05:31, Ron Wheeler 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 re

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 abou

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

> On 29 Apr 2015, at 08:01, Ron Wheeler 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.

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

> On 29 Apr 2015, at 00:41, Jacques Le Roux > 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 < implies a PoC effort in a branch>>) I sort of changed my mi

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

> On 28 Apr 2015, at 07:42, Adam Heath 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

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-.jar file and all dependent jars to a c

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

> On 21 Jan 2015, at 09:24, Jacques Le Roux > 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

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 I

Re: move to git.

> On 22 Apr 2015, at 16:14, Pierre Smits 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

Re: move to git.

> On 22 Apr 2015, at 16:49, Adam Heath wrote: > > > On 04/22/2015 06:13 PM, Jacopo Cappellato wrote: >> On Apr 22, 2015, at 11:41 PM, Adam Heath wrote: >> >>> When this happened, we had to relicense the entire project from GPL to >>> Apache 2.0. >> Gr It was not GPL! :-) > > It

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

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

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: Discussion: Replace framework by Moqui.

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:

Re: move to git.

> On 20 Apr 2015, at 23:21, Pierre Smits 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 t

Re: Discussion: Replace framework by Moqui.

> On 20 Apr 2015, at 12:48, Ron Wheeler wrote: > > On 20/04/2015 3:11 PM, David E. Jones wrote: >>> On 20 Apr 2015, at 11:35, Ron Wheeler >>> wrote: >>> >>> Would Moqui become a sub-project of OFBiz with distinct deliverable with an >>

Re: Discussion: Replace framework by Moqui.

> On 20 Apr 2015, at 13:21, Adrian Crum > 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 >>

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

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

t; 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 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: Discussion: Replace framework by Moqui.

ry... 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 >>> wrote: >>> >>> Le 20/04/2015

Re: Discussion: Replace framework by Moqui.

> On 19 Apr 2015, at 22:31, 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 th

Re: Discussion: Replace framework by Moqui.

> On 20 Apr 2015, at 02:24, Jacques Le Roux > 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 >> depen

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

ut '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 het volgende > geschreven: > >> >>

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 th

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

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 a

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 pr

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 direc

Re: The future of OFBiz - Open Discussion

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

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

Re: Discussion: Potential Data Model Improvements

Doing significant data model cleanups and changes is a LOT of work with a large code base and user community. All code that uses the data structure needs to be changes, and accommodations are needed for deprecating the old entity or fields and migrating data to the new ones. So yes, to the poin

Re: OFBiz In 2014

On Jan 6, 2014, at 12:58 PM, adrian.c...@sandglass-software.com wrote: > Quoting "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: >&g

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 O

Re: OFBiz In 2014

proach 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" : > >> >> One way to make the OFBiz Form/Screen/etc widgets more useful and extensible >&g

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 has

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 rende

Re: OFBiz In 2014

On Jan 6, 2014, at 5:09 AM, Jacques Le Roux 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

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 wrote: > Does anyone know w

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 s

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 wrote: > Hi David and Jacopo, > > is this change related to Jira issue OFBIZ-4602? > > Thanks > > Paul Foxworthy > >

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

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 exp

Re: Removing some unnecessary synchronization for cache objects

Looks like a good pattern. -David On May 28, 2012, at 9:27 AM, Jacopo Cappellato 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:

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

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

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

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

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

Re: Discussion: Mini-language Overhaul

m having an > hard time to find the real need for these Minilang/xml-actions: in my opinion > Groovy supported by a simple DSL (or call it how you want) would cover all > the needs (in screens, events, services etc...) with the same consistent > language. > > Jacopo > > On

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 wr

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 opera

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

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 data

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

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 a

Re: widgetVerbose

d add a parameter to see them, or I would have > to modify the application's web.xml file and restart the server. > > -Adrian > > On 9/13/2011 2:22 AM, David E Jones wrote: >> Based on this I'm actually reconsidering my position, however the current >> implem

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

r this change. > > Cheers, > Anne. > > On 13 September 2011 08:30, David E Jones 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 >> 20

Re: widgetVerbose

eak 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 >&g

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

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

Re: widgetVerbose

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

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. That's

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 appro

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 co

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 cour

Re: Party Classification Data Modeling

roupType >>> -------- >>> *groupTypeId >>> description >>> parentGroupTypeId >>> >>> PartyClassificationGroup >>> >>> *groupTypeId >>> *partyTypeId >>> >>> Anyways, I hav

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

[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13068996#comment-13068996 ] David E. Jones commented on OFBIZ-4346: --- The concern of the attribute is no

[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-tabpanel&focusedCommentId=13068828#comment-13068828 ] David E. Jones commented on OFBIZ-4346: --- Adding a class per database is not

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

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 un

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 v

[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-tabpanel&focusedCommentId=13056577#comment-13056577 ] David E. Jones commented on OFBIZ-4326: --- Stéphane, What is it you are tryin

[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-tabpanel&focusedCommentId=13050907#comment-13050907 ] David E. Jones commented on OFBIZ-4316: --- When FreeMarker says that an expres

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

[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037656#comment-13037656 ] David E. Jones commented on OFBIZ-4282: --- *** For #1: I did a little more rese

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

[ https://issues.apache.org/jira/browse/OFBIZ-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037454#comment-13037454 ] David E. Jones commented on OFBIZ-4282: --- Philippe: did you consider the down-s

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

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 differe

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

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 Mode

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 Rol

Re: Discussion: REST support in OFBiz

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

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

  1   2   3   4   5   6   7   8   9   10   >