Re: Welcome Deepak Dixit as a new PMC member

[Deepak Dixit]

Thanks all for your warm welcome.
Its my great pleasure to be part of such a wonderful community.



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

On Mon, Feb 27, 2017 at 8:19 PM, akash jain  wrote:

> Many Congratulations Deepak!
>
> Thanks and Regards
> --
> Akash Jain
>
> On Fri, Feb 24, 2017 at 6:38 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > The OFBiz PMC has invited Deepak Dixit to become a new member of the
> > committee; and the committee members are happy to announce that he has
> > accepted.
> >
> > Deepak has been involved in OFBiz for a long time now, and is a respected
> > committer for 2 years.
> >
> > We are sure Deepak will help us to take good decisions in favour of a
> > bright future for OFBiz!
> >
> > Please join me in welcoming and congratulating Deepak.
> >
> > Thanks
> >
> > Jacques
> > PS: Deepak, I let you change your status on the wiki PMC page :)
> >
> >
>

Re: Git for commiters

[Scott Gray]

I couldn't say sorry, I set it up once 5+ years ago and I've never had to
set it up again since.  The instructions don't look clear to me at first
glance (I don't know what some of them do), but I'm not in a position to
improve upon them.  Surely someone is using this setup who put it in place
more recently?

Regards
Scott

On 19 February 2017 at 22:22, Jacques Le Roux 
wrote:

> OK thanks, so would you say that the steps in the document are too much
> and you could change them or it's OK and up to date as is?
>
> Jacques
>
>
>
> Le 19/02/2017 à 09:29, Scott Gray a écrit :
>
>> Well it's been a while since I worked on the trunk but yes, I would still
>> use git svn for the work.
>>
>> Regards
>> Scott
>>
>> On 19/02/2017 21:18, "Jacques Le Roux" 
>> wrote:
>>
>> Thanks Scott,
>>
>> Do you mean you are still using it, or?
>>
>> Jacques
>>
>>
>>
>> Le 18/02/2017 à 23:03, Scott Gray a écrit :
>>
>> I've been using git-svn for years, I don't think my setup involved as many
>>> steps as that document shows though.  I think I just started from git svn
>>> init.
>>>
>>> The main advantages for me was to be able to stash works in progress and
>>> to
>>> make multiple local commits before pushing to svn.
>>>
>>> Regards
>>> Scott
>>>
>>> On 19 February 2017 at 01:41, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com>
>>> wrote:
>>>
>>> Er, I want to know if some committers are using "Git for commiters" as
>>>
 described at https://cwiki.apache.org/confluence/display/OFBIZ/Git+for+
 committers ?

 How could I say that differently?

 This page is linked from http://ofbiz.apache.org/source
 -repositories.html

 I have no intentions yet, just curious.

 Jacques



 Le 18/02/2017 à 11:19, Michael Brohl a écrit :

 Hi Jacques,

> what do you mean with "using"? What's the intention of your question?
>
> Regards,
>
> Michael
>
>
> Am 18.02.17 um 10:14 schrieb Jacques Le Roux:
>
> Hi,
>
>> Is someone using "Git for commiters" as explained at
>> https://cwiki.apache.org/confluence/display/OFBIZ/Git+for+committers
>> ?
>>
>> Thanks
>>
>> Jacques
>>
>>
>>
>>
>>
>

Re: buildbot failure in on ofbiz-branch15

[Jacques Le Roux]

OK this works locally on Windows, not an issue

Jacques

Le 28/02/2017 à 12:32, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbiz-branch15 while 
building . Full details are available at:
 https://ci.apache.org/builders/ofbiz-branch15/builds/309

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz15-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release15.12] 1784721
Blamelist: jleroux

BUILD FAILED: failed compile_1

Sincerely,
  -The Buildbot

Re: Should not catch Exception in EntityUtilProperties.getSystemPropertyValue()

[Rishi Solanki]

+1 for using the GenericEntityException, we did similar effort in
OFBIZ-7539.

Also agree on Jacques concern that, we should also fix the NPE for
delegator coming from HtmlFormMacroLibrary.ftl. So I think for now the fix
provided in the mentioned ticket is fine OFBIZ-9230 and we should also use
the GenericEntityException. Later we should try to figure out why and when
system lose the delegator which causes the NPE. Once we would fix the
reason we should remove the fix added in the EntityUtilProperties class
method.

New fix proposal:

Change method WidgetWorker.getDelegator with following code;

public static Delegator getDelegator(Map context) {
Delegator delegator = (Delegator) context.get("delegator");
if (delegator == null) {
delegator = DelegatorFactory.getDelegator(delegatorName);
}
return delegator;
}


Please see if this proposal looks fine then we could try and see if it
works to fix the original issue reported in the ticket.

Thanks!


Rishi Solanki
Sr. Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Tue, Feb 28, 2017 at 1:49 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Thanks Wei,
>
> Please All, refer to OFBIZ-9230 to see how I temporarily handled the issue.
>
> I also agree that using GenericEntityException is better than just a
> permissive Exception
>
> But I believe we should rather fix the underlying issue I reported there.
> So I was hesitant to agree with Wei though it's maybe a better way to get
> to really fix the issue because it shows it at the UI level and non only in
> logs.
>
> Jacques
>
>
>
> Le 28/02/2017 à 03:35, Wei Zhang a écrit :
>
>> Hi,
>>
>> I found there is a try/catch block to catch Exception in
>> EntityUtilProperties.getSystemPropertyValue(). Which will catche a NPE
>> (delegator is null) when this method is called in
>> framework/widget/templates/HtmlFormMacroLibrary.ftl but we only get a
>> waring
>> message in the log file.
>>
>> So I think we should catch GenericEntityException rather than Exception
>> here
>> to expose NPE or other runtime exceptions.
>>
>> Thanks,
>>
>> Wei
>>
>>
>>
>> -
>> 程序羊
>> --
>> View this message in context: http://ofbiz.135035.n4.nabble.
>> com/Should-not-catch-Exception-in-EntityUtilProperties-getSy
>> stemPropertyValue-tp4702833.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>>
>>
>

buildbot failure in on ofbiz-branch15

[buildbot]

The Buildbot has detected a new failure on builder ofbiz-branch15 while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-branch15/builds/309

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz15-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release15.12] 1784721
Blamelist: jleroux

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot

Re: [PROPOSAL] deprecate mini lang

[Rishi Solanki]

+1


Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Tue, Feb 28, 2017 at 2:53 PM, Julien NICOLAS 
wrote:

> +1
>
>
>
> On 27/02/2017 13:44, Nicolas Malin wrote:
>
>> +1
>>
>> I also agree to replace the minilang by groovy dsl for service.
>>
>> For screen a prefer wait a good equivalent solution for simple case.
>>
>> Nicolas
>>
>>
>> Le 18/02/2017 à 10:17, Michael Brohl a écrit :
>>
>>> Hi everyone,
>>>
>>> we are currently working hard to make OFBiz a modern, quality, robust
>>> and easy to use framework.
>>> There are several ongoing initiatives like refactoring the core, UX,
>>> changing the build and plugin system and cleaning up the javadocs, only to
>>> mention a few.
>>>
>>> In mini lang I see another part of our project which needs a
>>> refactoring/change. Here are some reasons:
>>>
>>> - Programming in XML is hard to deal with when it comes to refactoring.
>>>
>>> - The "code" cannot be debugged and is hard to review and maintain.
>>>
>>> - It is slower because of the overhead of parsing and processing XML
>>> documents
>>>
>>> - It is highly verbose, even so more than Java!
>>>
>>> - It is difficult to reason about because everything appears as a string
>>> (variables, maps, objects, etc ...) which makes it very difficult to know
>>> where something was declared or modified
>>>
>>> - It is highly error prone and brittle (again due to string declarations)
>>>
>>> - It is not a full programming language (unlike groovy, or any other
>>> language that supports a DSL). Thus it has many limitations that forces the
>>> developer to write many more lines of code to achieve the same result.
>>>
>>> - The code is not reusable (limitation of the DSL)
>>>
>>> - The code is not composable (limitation of the DSL)
>>>
>>> - Minilang depends on a lot of Java constructs (implementations, not
>>> interfaces) that require refactoring, making any improvements to the core
>>> API more challenging
>>>
>>> - Minilang is used inconsistently (different DSL in widgets, services
>>> and entities). Hence, we need to keep only a minimal DSL to declare things
>>> only.
>>>
>>>
>>> We already have Java based implementations for services and events and
>>> there are ideas to implement a Groovy DSL which can be used as easy (or
>>> easier) as mini lang and does not have the above mentioned flaws.
>>>
>>> I therefore like to propose to deprecate the mini lang implementation
>>> which means:
>>>
>>> 1. there will be no new implementations based on mini lang accepted to
>>> go into the code base.
>>>
>>> 2. mini lang and mini lang code will be maintained with bug and security
>>> fixes for backwards compatibility and to support existing adopters relying
>>> on mini lang.
>>>There will be no new features though.
>>>
>>> 3. we will continously replace the mini lang implementations with Java
>>> and/or Groovy code. This will be another good opportunity for contributors
>>> to engage in the project.
>>>
>>>
>>> This will certainly be a longer process and we will not stop support for
>>> mini lang but I think we should avoid to add more mini lang implementations
>>> to the project.
>>>
>>> What do you think?
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>
>>
>

The ecommerce webapp is broken in R14/15

[Jacques Le Roux]

Hi,

While working on OFBIZ-9234 I noticed that, when coming from catalog/product or 
not, the ecommerce webapp is  broken in R14/15

I created OFBIZ-9235 for that

Jacques

Re: [PROPOSAL] Allow Blog Posts from Community Members on Official OFBiz Blog

[Julien NICOLAS]

+1


On 28/02/2017 04:23, Taher Alkhateeb wrote:

Hi Sharan,

You folks are doing a great job with the blog, so thank you. I would like
to make a distinction like you hinted between two categories of information:

1- News / success stories / community and project promotion
2- Advertisement / forks promotion / vendor promotion

Naturally I think we should be careful not to slip over time into the
second category.

With that being said I think it's a good idea

+1

On Feb 27, 2017 2:21 PM, "Sharan Foga"  wrote:


Hi All

Generally Michael, Jacques and I put together our monthly project blog
news updates. Our official blog also tends to include information about our
releases.

I've recently been sent a general blog post from Pranay, promoting OFBiz
that I think would be nice to post on our blog so this is the reason behind
the proposal.

I think that it could be a good thing to let the community know that if
they want to publish an article about the way they use OFBiz or anything
that could promote using it then it could be posted on the blog.

We could also perhaps include announcements from companies going live with
an OFBiz implementation. One thing we might want to be careful about though
is keeping things neutral and project focussed.

What do people think?

Thanks
Sharan

Re: [PROPOSAL] deprecate mini lang

[Julien NICOLAS]

+1


On 27/02/2017 13:44, Nicolas Malin wrote:

+1

I also agree to replace the minilang by groovy dsl for service.

For screen a prefer wait a good equivalent solution for simple case.

Nicolas


Le 18/02/2017 à 10:17, Michael Brohl a écrit :

Hi everyone,

we are currently working hard to make OFBiz a modern, quality, robust 
and easy to use framework.
There are several ongoing initiatives like refactoring the core, UX, 
changing the build and plugin system and cleaning up the javadocs, 
only to mention a few.


In mini lang I see another part of our project which needs a 
refactoring/change. Here are some reasons:


- Programming in XML is hard to deal with when it comes to refactoring.

- The "code" cannot be debugged and is hard to review and maintain.

- It is slower because of the overhead of parsing and processing XML 
documents


- It is highly verbose, even so more than Java!

- It is difficult to reason about because everything appears as a 
string (variables, maps, objects, etc ...) which makes it very 
difficult to know where something was declared or modified


- It is highly error prone and brittle (again due to string 
declarations)


- It is not a full programming language (unlike groovy, or any other 
language that supports a DSL). Thus it has many limitations that 
forces the developer to write many more lines of code to achieve the 
same result.


- The code is not reusable (limitation of the DSL)

- The code is not composable (limitation of the DSL)

- Minilang depends on a lot of Java constructs (implementations, not 
interfaces) that require refactoring, making any improvements to the 
core API more challenging


- Minilang is used inconsistently (different DSL in widgets, services 
and entities). Hence, we need to keep only a minimal DSL to declare 
things only.



We already have Java based implementations for services and events 
and there are ideas to implement a Groovy DSL which can be used as 
easy (or easier) as mini lang and does not have the above mentioned 
flaws.


I therefore like to propose to deprecate the mini lang implementation 
which means:


1. there will be no new implementations based on mini lang accepted 
to go into the code base.


2. mini lang and mini lang code will be maintained with bug and 
security fixes for backwards compatibility and to support existing 
adopters relying on mini lang.

   There will be no new features though.

3. we will continously replace the mini lang implementations with 
Java and/or Groovy code. This will be another good opportunity for 
contributors to engage in the project.



This will certainly be a longer process and we will not stop support 
for mini lang but I think we should avoid to add more mini lang 
implementations to the project.


What do you think?

Regards,

Michael

Re: OFBIZ-3972

[Rishi Solanki]

Interesting related blog - LINK

One more conversation -
http://stackoverflow.com/questions/5989539/when-to-use-datetime-or-timestamp

It says it depends on the context of the field for which it is used.
DATETIME seems to be good choice as we will be updating field type, and it
may applicable to many places.

Thanks!


Rishi Solanki
Sr. Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Fri, Feb 24, 2017 at 3:37 PM, Taher Alkhateeb  wrote:

> I think I would prefer DATETIME. Some reasons are found here ->
> http://stackoverflow.com/questions/409286/should-i-use-
> field-datetime-or-timestamp.
> Given that OFBiz takes care of conversions, DATETIME seems like a more
> appropriate choice
>
> On Fri, Feb 24, 2017 at 12:13 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi,
> >
> > At OFBIZ-3972 Deepak suggested
> >
> > < > As we have only DATETIME set as sql type and this does not support
> > Milliseconds, we need to use DATETIME(3) or DATETIME(6).>>
> >
> > I suggested
> >
> >  refman/5.6/en/datetime.html
> > >>
> >
> > Deepak rightly mentioned that in both cases we need to create an entry in
> > "data migration" wiki page
> >
> > << we need to run alter query manually (if someone want to upgrade custom
> > solution to latest)>>
> >
> > Please let know your thoughts and suggestions if any
> >
> > Jacques
> >
> >
>

Re: Should not catch Exception in EntityUtilProperties.getSystemPropertyValue()

[Jacques Le Roux]

Thanks Wei,

Please All, refer to OFBIZ-9230 to see how I temporarily handled the issue.

I also agree that using GenericEntityException is better than just a permissive 
Exception

But I believe we should rather fix the underlying issue I reported there. So I was hesitant to agree with Wei though it's maybe a better way to get to 
really fix the issue because it shows it at the UI level and non only in logs.


Jacques


Le 28/02/2017 à 03:35, Wei Zhang a écrit :

Hi,

I found there is a try/catch block to catch Exception in
EntityUtilProperties.getSystemPropertyValue(). Which will catche a NPE
(delegator is null) when this method is called in
framework/widget/templates/HtmlFormMacroLibrary.ftl but we only get a waring
message in the log file.

So I think we should catch GenericEntityException rather than Exception here
to expose NPE or other runtime exceptions.

Thanks,

Wei



-
程序羊
--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Should-not-catch-Exception-in-EntityUtilProperties-getSystemPropertyValue-tp4702833.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: [PROPOSAL] deprecate mini lang

[Pranay Pandey]

+1

Thanks for the well thought proposal.

Best regards,

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

On Sat, Feb 18, 2017 at 2:47 PM, Michael Brohl 
wrote:

> Hi everyone,
>
> we are currently working hard to make OFBiz a modern, quality, robust and
> easy to use framework.
> There are several ongoing initiatives like refactoring the core, UX,
> changing the build and plugin system and cleaning up the javadocs, only to
> mention a few.
>
> In mini lang I see another part of our project which needs a
> refactoring/change. Here are some reasons:
>
> - Programming in XML is hard to deal with when it comes to refactoring.
>
> - The "code" cannot be debugged and is hard to review and maintain.
>
> - It is slower because of the overhead of parsing and processing XML
> documents
>
> - It is highly verbose, even so more than Java!
>
> - It is difficult to reason about because everything appears as a string
> (variables, maps, objects, etc ...) which makes it very difficult to know
> where something was declared or modified
>
> - It is highly error prone and brittle (again due to string declarations)
>
> - It is not a full programming language (unlike groovy, or any other
> language that supports a DSL). Thus it has many limitations that forces the
> developer to write many more lines of code to achieve the same result.
>
> - The code is not reusable (limitation of the DSL)
>
> - The code is not composable (limitation of the DSL)
>
> - Minilang depends on a lot of Java constructs (implementations, not
> interfaces) that require refactoring, making any improvements to the core
> API more challenging
>
> - Minilang is used inconsistently (different DSL in widgets, services and
> entities). Hence, we need to keep only a minimal DSL to declare things only.
>
>
> We already have Java based implementations for services and events and
> there are ideas to implement a Groovy DSL which can be used as easy (or
> easier) as mini lang and does not have the above mentioned flaws.
>
> I therefore like to propose to deprecate the mini lang implementation
> which means:
>
> 1. there will be no new implementations based on mini lang accepted to go
> into the code base.
>
> 2. mini lang and mini lang code will be maintained with bug and security
> fixes for backwards compatibility and to support existing adopters relying
> on mini lang.
>There will be no new features though.
>
> 3. we will continously replace the mini lang implementations with Java
> and/or Groovy code. This will be another good opportunity for contributors
> to engage in the project.
>
>
> This will certainly be a longer process and we will not stop support for
> mini lang but I think we should avoid to add more mini lang implementations
> to the project.
>
> What do you think?
>
> Regards,
>
> Michael
>
>
>
>