Re: Removing debug task

to console.log > > The ofbiz pattern by itself makes sense since it's used with the start > options, that's why I created the lazy start and stop cover tasks > > Opinions, before I commit my tiny changes (including "debug task" revert)? > > Jacques > > > Le 12/

Re: Removing debug task

Also another note Jacques, if things are a WIP, I suggest not to commit before testing functionality. I know we are in trunk, but at least committing working code is better than fixing it after a commit. On Fri, Aug 12, 2016 at 2:25 PM, Taher Alkhateeb wrote: > I see no problem in this renam

Re: system property not define

Hi Mridul, I'm assuming you want to split the methods, not copy-paste into a new file right? If yes then yeah I think It's a good idea. Taher Alkhateeb On Thu, Aug 11, 2016 at 5:37 PM, Mridul Pathak < mridul.pat...@hotwaxsystems.com> wrote: > The other area that I believe ne

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, I created OFBIZ-7951 to remove ofbizSecure and ofbizBackgroundSecure. However, I understand you want to rename the tasks so I do not want to cross wires with you. Are you going to start your task anytime soon? Taher Alkhateeb On Fri, Aug 12, 2016 at 1:27 PM, Jacques Le Roux

Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, Ok so I'm a little confused now. If the whitelist is incomplete and we did not exhaust the investigation, then why are we running the demo on ofbizSecure? Or actually, let me ask you in another why ... When should we prefer _not_ to have ofbizSecure and why? Taher Alkhateeb O

Re: Taking a decision on remaining Jars in OFBiz

on intersecting work? Would you mind helping out in switching buildbot to ofbiz instead of ofbizSecure? Taher Alkhateeb On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 12/08/2016 à 20:51, Taher Alkhateeb a écrit : > >> Hi Jacques,

Re: Removing debug task

hat is why many times I get very afraid when touching code because I just don't know what am I going to break next. Taher Alkhateeb On Saturday, 13 August 2016, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > On Fri, Aug 12, 2016 at 1:58 PM, Jacques Le Roux <

Re: Taking a decision on remaining Jars in OFBiz

plugins that we might introduce in the future. I'm stating this here in case we face such an issue in the future to be aware of it and fix it. Taher Alkhateeb On Sat, Aug 13, 2016 at 1:23 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi Taher, > > I agree,

Re: Removing debug task

xactly because of simple things like this one. Imagine this >> small tangling of code happening thousands of times everywhere in the code >> base, what do you get? you get the complexity we are suffering from right >> now. That is why many times I get very afraid when touchin

Re: Taking a decision on remaining Jars in OFBiz

they do work. Taher Alkhateeb On Aug 14, 2016 11:29 AM, "Jacques Le Roux" wrote: > Hi Taher, > > Inline > > Le 14/08/2016 à 09:31, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> I removed ofbizSecure and ofbizBackgroundSecure in OFBIZ-7951 at

Re: system property not define

ystems.com > > > On Aug 12, 2016, at 7:49 PM, Taher Alkhateeb > wrote: > > > > Hi Mridul, > > > > I'm assuming you want to split the methods, not copy-paste into a new > file right? If yes then yeah I think It's a good idea. > > > > Tahe

Re: Commits causing conflicts

Hi Pierre, We will try to minimize these issues, however this is trunk, which is by default unstable. Having your CIs always catching the latest commit might not be the best idea if you are trying to build solutions. On Aug 15, 2016 8:32 PM, "Pierre Smits" wrote: > HI all, > > Over the past few

Gradle version 3 released

think the auto-complete feature specifically is nice, so I wanted to share this info for heads up. Perhaps we can upgrade after making a release? Regards, Taher Alkhateeb

Re: Gradle version 3 released

sing, looking forward > > If there are not too much functional changes why not trying it already? > > Maybe we could at least use it in IDEs and still use v2 for building? > > Jacques > > > Le 15/08/2016 à 22:49, Taher Alkhateeb a écrit : > >> Hey everyone, >> &

Re: Commits causing conflicts

Also in addition to what Jacopo suggested, depending on the context of what you are trying to do you can simply include an external script right at the end of build.gradle and externalize all your work in there. For example "echo apply from: 'my-script.gradle' >> build.gradle" or something like tha

Re: Realistic lean Roadmap [was Ofbiz Cookbook]

vy integration (because of Gradle integration), Complete the > support for VAT(WIP was removed) > Achieved: Solr integration > > It simple and lean, what do you think? > > Jacques > > > Le 13/08/2016 à 10:19, Taher Alkhateeb a écrit : > >> +1 >> >> On

Re: Commits causing conflicts

Hi Pierre, I would also like to add that CD vs CI is irrelevant to my point. You would still have an unstable trunk in both situations. The point emphasis is that trunk is stable, not whether you're publishing or not. Taher Alkhateeb On Mon, Aug 15, 2016 at 9:38 PM, Pierre Smits wrote:

Re: Refactoring our Wiki spaces

Agreed, the whole purpose of a wiki is to provide and organize information. If we are going to worry about comments and "history" then we are using the wrong tool for that. History is the last thing I would care about, instead we should focus on having clean updated information. On Aug 18, 2016 7:

Re: Wiki documentation update with respect to Gradle

n. - The syntax for java -jar is more complex So my recommendation is to replace every occurence of java -jar with ./gradlew "ofbiz --whatever-commands-here". Taher Alkhateeb On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi, >

Re: Wiki documentation update with respect to Gradle

Hi Jacques, I think there should be an added value beyond "because it used to be there". What is the purpose of keeping it with disclaimers in your opinion? Regards, Taher Alkhateeb On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi

Re: Wiki documentation update with respect to Gradle

he corner cases away. What you are mentioning is less common scenarios that are rather rare in this age where cloud computing is the norm. This way, you keep things easy for our new users while providing more information for those with special deployment needs. Regards, Taher Alkhateeb On Fri, A

Re: Wiki documentation update with respect to Gradle

, Taher Alkhateeb < slidingfilame...@gmail.com> wrote: > Hi Jacques, > > Okay based on your feedback I would suggest to create a special page / > section in the documentation that has the title "Deploying OFBiz on offline > servers" or something like that. I would ra

Re: Taking a decision on remaining Jars in OFBiz

Well done you Gil & Nicolas, great work. The framework is finally clean. Jacques I think requesting publishing in jcenter is a good idea. Worst case scenario might not be pretty (download and compile the jar ourselves as a subproject).

Re: Sharing the burden of maintaining documentation

n the README.md can be generated from them automatically. With DITA one powerful advantage is the ability to reuse content in different documents so you abide with DRY principle. WDYT? Taher Alkhateeb On Aug 20, 2016 8:29 AM, "jler...@apache.org" wrote: > Hi, > > Not so long ago

Re: Sharing the burden of maintaining documentation

s or maybe just mirroring the reference documentation. This in my opinion would be a simpler solution as I find it just so hard to keep the wiki and the code base in sync. Taher Alkhateeb On Aug 20, 2016 8:41 PM, "Jacques Le Roux" wrote: > Taher, > > Inline > > > Le

Re: Sharing the burden of maintaining documentation

gs and how to organize them. On Sat, Aug 20, 2016 at 10:15 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 20/08/2016 à 20:16, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> Thank you for the feedback, based on your input I would summarize as >>

Re: Sharing the burden of maintaining documentation

we have it / need it) I hope I got things right. I think all solutions above are good and I lean slightly towards dita because of the modularity aspect. Taher Alkhateeb On Aug 21, 2016 9:03 AM, "Jacques Le Roux" wrote: > Le 20/08/2016 à 21:15, Jacques Le Roux a écrit : > >&

Re: svn commit: r1757360 - /ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/Ofbi zStartupUnitTests.java

I don't know, do you change some code while OFBiz is up? If yes then probably that is the reason. If not then it could be something else. On Tue, Aug 23, 2016 at 2:51 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Could it be the reason I had to switch to terminateOFBiz at some poin

Re: svn commit: r1757360 - /ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/Ofbi zStartupUnitTests.java

rts.com> wrote: > > > Thanks, no I did not change "some code" (I guess you mean Java) > > > > A worry less, I guess it was something else, and terminateOFBiz does the > > job! > > > > Jacques > > > > > > > > Le 23/08/2016 à 1

Re: Feedback on Committer Mentoring and HipChat

and it is the basis for all decisions. But we DO have a gap in communication that I think instant messaging applications like hipchat can fill. Taher Alkhateeb On Aug 24, 2016 8:50 AM, "Scott Gray" wrote: > I'm in two minds about it. > > On one hand it's nice to

Re: notsoserial on jcenter repo?

cript, build time, dependencies, etc ... Taher Alkhateeb On Aug 24, 2016 10:04 AM, "Jacques Le Roux" wrote: > We did not get an answer yet, but Taher suggested another possibility: > gradle-repositories-plugin on GitHub. It's not yet evaluated but could be a > workaround, my

Re: Should we do binary releases?

recompiled form. In other words we cannot include the dependencies in the binary releases anyway. So people must use Gradle to download the dependencies, and so the whole purpose of the binary release becomes unnecessary as you must have gradle and java installed on your computer. Taher Alkhateeb O

Re: Should we do binary releases?

uch sense to me. Taher Alkhateeb On Wed, Aug 24, 2016 at 11:54 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Taher, > > Wait, either Tomcat, Ant and JMeter are doing it wrong or we don't > understand this sentence (I agree with you) or it's incomplete

Re: Should we do binary releases?

ad? Regards, Taher Alkhateeb On Thu, Aug 25, 2016 at 7:32 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 24/08/2016 à 23:15, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> I'm not sure how am I supposed to understand it? To me it seems clear .. &

Re: Should we do binary releases?

n your own. Gradle makes it very easy as is proven by your patch in OFBIZ-7783 in which you copied the libs in 3 lines of code! Regards, Taher Alkhateeb On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 25/08/2016 à 11:33, Taher Alkhateeb a écri

Re: Should we do binary releases?

etwork settings On Thu, Aug 25, 2016 at 2:03 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 25/08/2016 à 12:32, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> Ok great thank you for clarifying. >> >> It is hard to find modern systems t

Some questions on plugin system

m and implement it in a later stage. Thank you in advance for your help and feedback. Taher Alkhateeb

Re: Should we do binary releases?

story is different, this is a complex ERP system that does not just work OOTB (see my comments above). If anything, the only thing I would do with each release is to perhaps zip or tar the source and that's it. Then every user would download it, unzip, ./gradlew loadDefault ofbiz ... Done!

Re: Offer of Snoot Analytic Services for OFBiz

sounds great, +1 On Fri, Aug 26, 2016 at 8:24 AM, Jacopo Cappellato < jacopo.cappell...@hotwaxsystems.com> wrote: > +1 > > Jacopo > > On Tue, Aug 23, 2016 at 1:57 PM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > > > Sure, +1! > > > > Jacques > > > > > > > > Le 23/08/2016 à 11:34, Sh

Re: svn commit: r1757822 - in /ofbiz/trunk/applications/workeffort: config/WorkEffortUiLabels.xml webapp/workeffort/WEB-INF/controller.xml widget/WorkEffortForms.xml widget/WorkEffortMenus.xml widget/

Good advice Nicolas, would you mind also taking another look at everything and committing your recommendations against OFBIZ-7973? On Fri, Aug 26, 2016 at 2:57 PM, Nicolas Malin wrote: > Taher, > Le 26/08/2016 à 13:37, ta...@apache.org a écrit : > >> > title="${uiLabelMap.CommonCreate}"

Re: svn commit: r1757822 - in /ofbiz/trunk/applications/workeffort: config/WorkEffortUiLabels.xml webapp/workeffort/WEB-INF/controller.xml widget/WorkEffortForms.xml widget/WorkEffortMenus.xml widget/

of commit on your commit, source of > frustration raise :) > > Nicolas > > > Le 26/08/2016 à 14:17, Taher Alkhateeb a écrit : > >> Good advice Nicolas, would you mind also taking another look at everything >> and committing your recommendations against OFBIZ-7

Re: Some questions on plugin system

, but I think the above provides a good starting point. Ideas? Feedback? Should I go ahead and fine-tune / share the PoC on JIRA? Regards, Taher Alkhateeb On Fri, Aug 26, 2016 at 6:17 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 25/08/2016 à 16:39, Taher Alkhatee

Re: Some questions on plugin system

ution that works and tested in code. The implementation is not big because of utilizing established standards like maven and gradle embedded plugins. Taher Alkhateeb On Aug 29, 2016 9:37 AM, "Pierre Smits" wrote: > This solutions must be able to work with: > >- zip fi

Re: Some questions on plugin system

your solution as a patch to the issue you created earlier? > > Best regards, > > Pierre Smits > > ORRTIZ.COM <http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Mon, Aug 29,

Re: Using Steve for OFBiz votes

I agree with Jacopo, I prefer not to use solutions to problems that do not exist. If / when voting becomes a problem because of volume or other reasons then we can give it a try. On Mon, Aug 29, 2016 at 2:21 PM, Pierre Smits wrote: > Steve is a great tool for various kinds of votes, not only com

Re: Should we do binary releases?

task. >> >> I understand the mostly reason for QA and no internet access (and I'm >> concerned :)) but if an administrator team have the skill to block >> internet, they have also the skill to create a proxy cache for gradle (or >> something like that). >&g

Re: How to deploy OFBiz without Gradle

o conclude, if we succumb to every deployment scenario for every person, we would indeed have a very big code base. I suggest to keep things lean and clean, and to avoid adding anything to the code base for the specific exceptional deployment requirements of some individuals. Regards, Taher Alkhateeb.

Re: How to deploy OFBiz without Gradle

tains the classpath for all the dependencies (sitting in the gradle cache) so when you switch to a new computer with a different user name, it does not work immediately. So a simple rebuild command would do the trick. Regards, Taher Alkhateeb On Tue, Aug 30, 2016 at 10:56 AM, Montalbano Fl

Re: How to deploy OFBiz without Gradle

others to have their say. Regards, Taher Alkhateeb On Aug 30, 2016 11:50 AM, "Jacques Le Roux" wrote: > Le 30/08/2016 à 09:21, Taher Alkhateeb a écrit : > >> Hi Jacques, All, >> >> Okay just to put things into context, the reason that kick-started this >

Re: How to deploy OFBiz without Gradle

Hi Jacques, I think to get the absolute minimum cache size you do the following: - delete .gradle - ./gradlew cleanAll build (do not run eclipse so that you do not download the source dependencies) This would give you the minimum cache needed for OFBiz to run. Taher Alkhateeb On Tue, Aug 30

Re: How to deploy OFBiz without Gradle

Hmmm, not sure if Intellij or eclipse would make a difference in the cache size? It is gradle that is downloading, not eclipse nor intellij. On Tue, Aug 30, 2016 at 2:02 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 30/08/2016 à 12:43, Taher Alkhateeb a écrit : > &

Re: How to deploy OFBiz without Gradle

320 MB of dependencies related to only OFBiz > > Jacques > > > > Le 30/08/2016 à 13:18, Taher Alkhateeb a écrit : > >> Hmmm, not sure if Intellij or eclipse would make a difference in the cache >> size? It is gradle that is downloading, not eclipse nor

Re: How to deploy OFBiz without Gradle

tion, and we have effectively 350MB of dependencies instead > of 150MB before. > > Jacques > > > > Le 30/08/2016 à 13:36, Taher Alkhateeb a écrit : > >> Be careful, those could be just regular OFBiz requirements. For example, >> take a look at the below outputs from ./

Re: How to deploy OFBiz without Gradle

above solutions then we can start exploring it in more depth and enhancing it, or if you have other suggestions and ideas please fire away. Regards, Taher Alkhateeb On Tuesday, 30 August 2016, Scott Gray wrote: > I just want to add that I don't think it is an uncommon scenario to desire &

Re: How to deploy OFBiz without Gradle

it's a big deal and not something I'm > going to complain about. > > Regards > Scott > > On 31 August 2016 at 17:28, Taher Alkhateeb > wrote: > > > Hi Scott,. > > > > I will explain the build process to analyze the problem to try and come > up

Re: How to deploy OFBiz without Gradle

exclude this transitive dependency and so on and so forth. On Aug 31, 2016 2:03 PM, "Jacques Le Roux" wrote: > Le 31/08/2016 à 07:28, Taher Alkhateeb a écrit : > >> - And for completeness my original proposal, just let Gradle handle it >> because: >>- You

Re: Michael Brohl joins OFBiz PMC

Michael is an added value to OFBiz. Congratulations On Sep 2, 2016 1:37 PM, "Pierre Smits" wrote: > Congratulations Michael! > > Best regards, > > Pierre Smits > > ORRTIZ.COM > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-

Re: svn commit: r1758927 - in /ofbiz/trunk: applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdpart y/gosoftware/ applications/content/src/main/java/org/apache/ofbiz/content/survey

Jacques this is still problematic, you are closing the streams upon exceptions! now all kinds of memory leaks and side effects could take place because you are not ensuring closing all streams properly. This needs a revert and a full review to make things tight in terms of memory. On Fri, Sep 2,

Re: svn commit: r1758927 - in /ofbiz/trunk: applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdpart y/gosoftware/ applications/content/src/main/java/org/apache/ofbiz/content/survey

to Java 7, but it would take time to explain, and it is your initiative so I leave it up to you to fix it. Regards, Taher Alkhateeb On Fri, Sep 2, 2016 at 8:37 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Why should I not close the Socket once the DataInputStream derive

Taking action on problems with using JIRA

in so many JIRAs many of which are hindering rather than helping. What do you think? Taher Alkhateeb

Re: svn commit: r1758927 - in /ofbiz/trunk: applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdpart y/gosoftware/ applications/content/src/main/java/org/apache/ofbiz/content/survey

if you don't use a lot of calls to PcChargeApi.send() > during the JVM session, since the JVM will clear it when finished. > But it seems to me that it's better to avoid crossing this issue. > > And last but not least, this is in a peripheral thirdparty\gosoftware, so > there

Re: svn commit: r1758927 - in /ofbiz/trunk: applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdpart y/gosoftware/ applications/content/src/main/java/org/apache/ofbiz/content/survey

Hi Jacques, I don't see anything wrong with Oracle's documentation. It is very much correct that closing a socket closes its streams. The problem is with closing the higher chained streams. Taher Alkhateeb On Sep 3, 2016 3:16 PM, "Jacques Le Roux" wrote: > Thanks Tahe

Re: Question about transitive dependencies on different version of the same library

thing to note is that the special purpose components especially birt pull a lot of libraries that override some of the libraries in core system. Taher Alkhateeb On Sep 3, 2016 4:57 PM, "Jacopo Cappellato" < jacopo.cappell...@hotwaxsystems.com> wrote: > Hi all, > > I have

Re: Question about transitive dependencies on different version of the same library

Hi Jacopo, also adding that you can override any transitive dependencies by explicitly declaring them (compile, runtime, etc ..) in build.gradle. I'm not sure if this is what you're after but I thought I'd mention it here just in case. On Sat, Sep 3, 2016 at 5:04 PM, Taher Alkhatee

Re: svn commit: r1759155 - /ofbiz/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/DatabaseUtil.java

a bit odd. Taher Alkhateeb On Sun, Sep 4, 2016 at 11:57 AM, wrote: > Author: shijh > Date: Sun Sep 4 08:57:44 2016 > New Revision: 1759155 > > URL: http://svn.apache.org/viewvc?rev=1759155&view=rev > Log: > OFBIZ-8137 Entityname starts with schema name causes error in P

Re: svn commit: r1759155 - /ofbiz/trunk/framework/entity/src/main/java/org/apache/ofbiz/entity/jdbc/DatabaseUtil.java

ote: > Hi Taher, > > Yes, it's for OFBIZ-8137. > > Good questions on why adding a dot. Honest, I don't think it's in our > entity name conventions, maybe it's safe to use it here. > > Kind Regards, > > Shi Jinghai > > > -邮件原件- > 发

Introducing OWASP plugin in Gradle

going to use it). The purpose of this plugin is to produce CVE security report by examining the jar dependencies in OFBiz. I will wait for any feedback for a few days before committing work Regards Taher Alkhateeb

Re: OFBiz logo files in repo?

I think the wiki is okay, maybe the website repo is okay, but not in trunk unless it serves a purpose (used somewhere in some screen) On Mon, Sep 5, 2016 at 11:40 AM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi, > > Previously we had some OFBiz logo files in repo, should we put th

Re: svn commit: r1759250 - /ofbiz/trunk/build.gradle

Hi Jacques, I don't understand your concern described below? What is the problem of having jars not related to OFBiz in gradle's cache? What is the problem? Regards, Taher Alkhateeb On Sep 5, 2016 3:24 PM, wrote: > Author: jleroux > Date: Mon Sep 5 12:24:21 2016 > Ne

Re: Proposal for a more unified commit message format

+1 I also suggest to have maximum width of 80 characters. This makes things nicer and cleaner for svn log On Tue, Sep 6, 2016 at 11:31 AM, gil portenseigne < gil.portensei...@nereide.fr> wrote: > Hi Michael, > > I like the idea to have unified commit message format. > > +1 > > Thanks for the pro

Re: Proposal for a more unified commit message format

Can you include some samples Michael, just for clarity? On Tue, Sep 6, 2016 at 12:25 PM, Taher Alkhateeb wrote: > +1 > > I also suggest to have maximum width of 80 characters. This makes things > nicer and cleaner for svn log > > On Tue, Sep 6, 2016 at 11:31 AM

Re: Proposal for a more unified commit message format

would not put a general limit on the length of the commit message. There > are sometimes valuable informations in longer messages I'd like not to miss. > > > Am 06.09.16 um 11:25 schrieb Taher Alkhateeb: > > +1 >> >> I also suggest to have maximum width of 80 charac

Re: Taking action on problems with using JIRA

k for adherence to our requirements? Or do we need to finalize it first? Cheers, Taher Alkhateeb On 2016-09-05 14:06 ( 0300), "Sharan fo...@gmail.com> wrote: > Hi Taher> > > 1 > > > You have raised some good actionable points here. I think you are right that the J

Re: Proposal for a more unified commit message format

ke it as a guideline but at command line and e.g. >> Eclipse you don't have a character count when committing so that could be a >> hurdle. >> >> >> Am 06.09.16 um 12:00 schrieb Taher Alkhateeb: >> >>> Hi Michael, >>> >>> I meant a n

Re: [Supplier-Product] - How can apply more than one price for a product and a supplier.

Hello Thang, There are probably multiple ways to achieve this. I think perhaps for your situation you can use price rules -> https://cwiki.apache.org/confluence/display/OFBENDUSER/Price+Rules Taher Alkhateeb On Sep 7, 2016 4:47 AM, "thang nguyen" wrote: > Hi everyone! >

Re: [Supplier-Product] - How can apply more than one price for a product and a supplier.

price rules, that should do the job no? Taher Alkhateeb On Wed, Sep 7, 2016 at 7:46 AM, thang nguyen wrote: > Thanks Taher! > If we use product_price_rule it will not map that rules with suppliers. Do > you have other ways ? > > On Wed, Sep 7, 2016 at 10:48 AM, Taher Alkhate

Re: [Supplier-Product] - How can apply more than one price for a product and a supplier.

, nothing too difficult. Anyway, if you do decide to go with new entities make sure of fixing the order screens appropriately for the price retrieval logic. Taher Alkhateeb On Sep 7, 2016 8:33 AM, "thang nguyen" wrote: > That right, If made that way too complex. I thinks i should genera

Re: Creating a new release branch in preparation for the new release

+1 On Wed, Sep 7, 2016 at 2:07 PM, Sharan Foga wrote: > That's great news ! +1 > > Thanks > Sharan > > > On 07/09/16 12:06, Jacopo Cappellato wrote: > >> Hi all, >> >> I think it is the right time to create a new release branch out of the >> trunk. >> >> According to our naming conventions the

Re: Taking a decision on remaining Jars in OFBiz

ng happens because it will just ignore it as missing from the classpath. Taher Alkhateeb On Sep 7, 2016 5:48 PM, "Jacques Le Roux" wrote: > Huho, I was too fast on this. Currently the Gradle "ofbizSecure" tasks > depends on the notsoserial-1.0-SNAPSHOT.jar > > So this

Re: Taking a decision on remaining Jars in OFBiz

cques Le Roux < jacques.le.r...@les7arts.com> wrote: > OK Cool, if the JVM arguments are simply ignored, then I will proceed with > an addition in the readme and remove the jar, simple > > Jacques > > > > Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : > >>

Re: Taking a decision on remaining Jars in OFBiz

serial.dryrun=${rootDir}/tools/security/notsoserial/ >>> is-deserialized.txt", >>> - >>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>> deserialize-trace.txt"] >>> +def jvmArguments = ['-Xms128M', '-Xmx10

Re: Taking a decision on remaining Jars in OFBiz

').toLowerCase() >>>>> >>>>>// java settings >>>>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>>>> - >>>>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>>>&g

Re: Taking a decision on remaining Jars in OFBiz

security\notsoserial folder and its content. > > I ask you the same question than I asked to Jacopo: "How do you expect to > warn users about deserialization driven attacks?" > > Jacques > > > Le 08/09/2016 à 12:12, Taher Alkhateeb a écrit : > >> I have a q

Re: Taking a decision on remaining Jars in OFBiz

> > Also, I wonder why both you and Jacopo reject my proposed solution, any > technical or other reasons? > > We decided to use notsoserial by default, I don't see why we should change > now. I'd have a reassured mind if we committed my proposed change. I see no > rea

Re: Some questions on plugin system

ntain anything and can be hosted everywhere (localhost, jcenter, maven central, private maven, etc). So not only is it not compatible with OFBiz components but also more complex to use as described above. Taher Alkhateeb On Sep 9, 2016 12:31 AM, "Jacques Le Roux" wrote: > Hi Taher,

Re: Taking a decision on remaining Jars in OFBiz

win-win situation and the reason why I was pushing hard for code refactoring. WDYT? If you agree then we can work on a good well documented page all about security and get help from everyone to have good well documented material. Taher Alkhateeb On Sep 9, 2016 7:08 AM, "Jacques Le Roux"

Re: Some questions on plugin system

ublished in any maven repo (like jcenter or mavencentral, etc...) Taher Alkhateeb On Sep 9, 2016 8:36 AM, "Jacques Le Roux" wrote: > Taher, inline... > > Le 09/09/2016 à 05:40, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> JitPack is indeed a nice service an

Re: Proposal for a more unified commit message format

, not because of fear of consequences. Taher Alkhateeb On Sep 10, 2016 12:19 PM, "Pierre Smits" wrote: > A rule - in general - implies, that, when not adhered to, there will be > consequences. What will those consequences be? > Will the rule police then bitch at the contributo

Re: Proposal for a more unified commit message format

lt;http://www.orrtiz.com> > OFBiz based solutions & services > > OFBiz Extensions Marketplace > http://oem.ofbizci.net/oci-2/ > > On Sat, Sep 10, 2016 at 12:56 PM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > > > I totally agree with you Taher! >

Re: svn commit: r1759945 - /ofbiz/trunk/

I think that it doesn't make much of a difference whether it's past or present or whatever as long as it remains consistent. Consistency will make us all familiar with the process and it's easy to understand what everybody's doing and you can automate things. So Jacques since you already casted y

Re: Proposal for a more unified commit message format

message is triggered by the above method when a delegator can't be created; added a TODO comment to remind that the code should be refactored to throw the exception instead. = commit message ends = p.s. Jacopo I botched your commit message for the above sample :) Cheers, Taher Alkh

Re: Proposal for a more unified commit message format

lank > lines as separators and the max. width of 80 characters in the rules > section below the template. > > I have adjusted the examples to be max. 80 chars wide. > > Thanks, > > Michael > > > Am 11.09.16 um 14:29 schrieb Taher Alkhateeb: > > Looks good Michael,

Re: svn commit: r1760325 - /ofbiz/trunk/applications/party/widget/partymgr/ProfileScreens.xml

We write long emails, we write a lot of code, we write wiki pages, we write documentation, we write comments in Jiras and in fact what we do every day is write. Writing a few parentheses is hardly work especially since more than 90% of the time a commit is related to a single Jira. The effort we a

Re: Groovy and semicolon at EOL

Agreed, I think it is better to remove semicolons for groovy files. In fact our gradle scripts do not have semicolons. Perhaps people put them there out of habit. On Sep 12, 2016 7:56 PM, "Jacques Le Roux" wrote: > Hi > > While committing r1760406 I wondered if I should really put semicolons at

Re: svn commit: r1760435 - in /ofbiz/trunk/applications: accounting/servicedef/services_finaccount.xml product/servicedef/services_facility.xml

ur feedback. Regards, Taher Alkhateeb On Mon, Sep 12, 2016 at 9:54 PM, wrote: > Author: arunpatidar > Date: Mon Sep 12 18:54:23 2016 > New Revision: 1760435 > > URL: http://svn.apache.org/viewvc?rev=1760435&view=rev > Log: > Applied patch for "Added CRUD services for F

Re: Groovy and semicolon at EOL

Okay I missed the historical context. Like Jacopo I also do not have a strong opinion, if it is easier and faster to keep them, then keep them. The important thing is to take a direction and stay with it. On Sep 13, 2016 9:40 AM, "Jacques Le Roux" wrote: Hi, Wait, I did not ask to remove them.

Re: Groovy and semicolon at EOL

thanks for clarifying Michael! Better to > have consistent lines (with respect to semicolons) by file indeed. > > Jacques > > >> Am 13.09.16 um 08:49 schrieb Taher Alkhateeb: >> >>> Okay I missed the historical context. >>> >>> Like Jacopo I also do not have a strong opinion, if it is easier and >>> faster >>> to keep them, then keep them. The important thing is to take a direction >>> and stay with it. >>> >>> >>> >> >> >

Re: Groovy and semicolon at EOL

gt; can try to assign single dev as volunteer to provide patch for all the > > files. > > > > Thanks! > > > > Best Regards, > > -- > > > > Rishi Solanki > > Manager, Enterprise Software Development > > HotWax Systems Pvt. Ltd. > > Direct

Re: Some questions on plugin system

I appreciate your help in feedback, ideas, testing and sharing whatever is on your mind. You will find the patch in https://issues.apache.org/jira/browse/OFBIZ-7972 Cheers, Taher Alkhateeb On Fri, Sep 9, 2016 at 12:55 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 0

Re: Some questions on plugin system

ier for all contributors to start playing with > this new plugin api. > > Jacopo > > > On Tue, Sep 13, 2016 at 7:20 PM, Taher Alkhateeb < > slidingfilame...@gmail.com > > wrote: > > > Hello Folks, > > > > After quite a bit of work, I have

<    5   6   7   8   9   10   11   12   13   14   >