Re: svn commit: r1828233 - /ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java

[Michael Brohl]

Hi all,

thanks for the feedbacks. I created a Jira at 
https://issues.apache.org/jira/browse/OFBIZ-11341


I noticed that this is also present in the 16.11 release branch. Should 
it be backported there also?


If not, do we have a standard way to provide fixes for old releases 
which might not be released anymore? One way could be to provide the 
patch in Jira.


Thanks,

Michael


Am 04.02.20 um 20:32 schrieb Gil Portenseigne:

+1 for the fix.

On Tue, Feb 04, 2020 at 12:22:48PM +0100, Michael Brohl wrote:

During a migration I found that this bugfix was not backported to the 17.12
release branch.

Should I do it now?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 03.04.18 um 15:06 schrieb mbr...@apache.org:

Author: mbrohl
Date: Tue Apr  3 13:06:28 2018
New Revision: 1828233

URL: http://svn.apache.org/viewvc?rev=1828233=rev
Log:
Fixed: Prevent possible NullPointerException.

Modified:
  
ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java

Modified: 
ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
URL: 
http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java?rev=1828233=1828232=1828233=diff
==
--- 
ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
 (original)
+++ 
ofbiz/ofbiz-framework/trunk/applications/accounting/src/main/java/org/apache/ofbiz/accounting/finaccount/FinAccountServices.java
 Tue Apr  3 13:06:28 2018
@@ -210,8 +210,11 @@ public class FinAccountServices {
   Timestamp now = UtilDateTime.nowTimestamp();
   // now use our values
-String finAccountCode = 
FinAccountHelper.getNewFinAccountCode(accountCodeLength.intValue(), delegator);
-inContext.put("finAccountCode", finAccountCode);
+String finAccountCode = null;
+if (UtilValidate.isNotEmpty(accountCodeLength)) {
+finAccountCode = 
FinAccountHelper.getNewFinAccountCode(accountCodeLength.intValue(), delegator);
+inContext.put("finAccountCode", finAccountCode);
+}
   // with pin codes, the account code becomes the ID and the pin 
becomes the code
   if ("Y".equalsIgnoreCase(requirePinCode)) {








smime.p7s
Description: S/MIME Cryptographic Signature

Re: Removing “base/config/component-load.xml”

[Mathieu Lirzin]

Hello Taher,

Taher Alkhateeb  writes:

> I can sense frustration from Mathieu regarding getting things moving
> forward.

You are correct.

> I would just like to note that it's really not _that_ bad!  You've
> already gotten a lot of commits rolling into the code base (which is
> fantastic) and you didn't get objections on most of them. In fact many
> commits that you made were just fine, including things you did to the
> core components and gradle scripts and whatnot.

Yes I am glad about that. However such achievement has been possible
only because I chosed to move fast for changes I considered as implicit
implementation details. Apparently such practice do not follow the
recommended guidelines which require a code change proposal to be slowly
reviewed first even for trivial stuff because we can never know if it
might break user code or not.

> So I want to encourage you to trust that things would work themselves
> out, and there is no need to be frustrated. Take a deep breath and
> just consider more of a long-term initiative than a short term one.
> Doing the jar architecture is not the only thing that can be improved.
> There is a whole heap of areas in the framework that can be improved.
> For example REST (which you worked on partially if I'm not mistaken).

The global goal is not just to improve various areas for the sake of
improving them. The objective is to end up with a piece of software that
is useable, extensible and works reliably.

I tried my best to implement the REST stuff (and Artemiy after me)
without going as far as I intended because I faced the immense
complexity of ‘RequestHandler#doRequest’ which involves complex
mechanisms like “override view URI”, ad-hoc redirection, messy error
handling, HTTP query parameter passed in the path with a ‘~’ prefix
which are used in templated links inside Freemarker code... all that
paired with the unbearable complexity of the screen DSL to implement a
JSON view handler...  Clearly I am not convinced that following that
approach will eventually turn into something useable and reliable in the
long run.

Thank you anyway Taher for trying to find something positive within a
failure. :-)

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Removing “base/config/component-load.xml”

[Mathieu Lirzin]

Michael Brohl  writes:

> I think depends-on is a point we already have discussed and this was
> not my topic in the latest emails. My proposal to write up a concept
> is adressed to the "big picture" you have described in [1], which
> contains your statement:
>
> "Here is a *big* change that I am considering for OFBiz to fixes those
> issues by leveraging the Java platform which already provides
> everything that we need to fix those issues: ..."
>
> I was talking about this big change and the plan behind it. In the
> initial discussion you gave a brief vision, which should be worked out
> by the community to move forward. A vision is far from a concept the
> community can decide on, which is my main point I expressed earlier.

If we failed to understand each other on the small picture, I doubt
bringing the “big picture” will be lead to better result. The bigger the
scope is the more likely it will end up in a “what if” tar pit.

>> I don't see the point of continuing this unproductive discussion neither
>> to proceed with a formal vote regarding the deprecation of
>> “component-load.xml”, because whatever the result I have lost my faith
>> in the capability of this community to succeed at handling the technical
>> challenges that will enable OFBiz to stay relevant in the future.
>>
>> But this is fine.
>
> As I've sorted out the "depends-on" topic as the reason for the wish
> for a concept/plan: do you also think that a discussion about the *big
> change* is unproductive and is not necessary?

Maybe a few month ago I would have been more patient and open to get
into the requirement analysis details, but now that I have already spent
all my energy into related heated debates without having any time left
on realizing what I intended to work on initially, I am basically done.

It could have been productive but in an alternate reality.

> How do you do conceptual work with clients or colleagues? I believe
> there is some kind of written documentation and clear decision points
> involved at least for non trivial features/changes.

Usually such discussion involves a whiteboard and a face-to-face
discussion. Nereide has not a strong culture of written specifications
and work in a very agile way.

> I sincerely hope that we can sort out the resentments and find a way
> to collaborate on the challenges that lay ahead.

I am afraid that I am out of fuel here.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [ofbiz-plugins] branch trunk updated: Implemented: Have a Country Dimension (OFBIZ-10954)

[Pierre Smits]

Nicolas,

A ticket regarding the service to populate the dimension is available in
JIRA. See OFBIZ-10954. In that ticket I suggested a solution approach for
the assignee (or anyone else) to evaluate before I submit a pull request.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Wed, Feb 5, 2020 at 7:00 PM Nicolas Malin 
wrote:

> Hi,
>
> On 30/01/2020 16:51, Michael Brohl wrote:
> > Hi Pawan, all,
> >
> > I really don't see any reason to introduce tables into the codebase
> > which are not used anywhere in the current functionality.
> >
> > I would recommend to wait until there is substantial functioanality
> > which use these table. As Piere stated in some of the *Dimension
> > Jiras: "The component would benefit from a ... dimension for future
> > fact tables and star schema view entities".
> >
> > What do others think?
>
> I'm not opposed to introduce some new dimension, if we have service to
> populate them, as bi api.
>
> Otherwise the added valuable would be small because not really easy to use.
>
> After use a dimension with fact element are, for me, just an example how
> we can use this dimension
>
> Nicolas
>
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 30.01.20 um 10:15 schrieb pa...@apache.org:
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> pawan pushed a commit to branch trunk
> >> in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/trunk by this push:
> >>   new ccb6219  Implemented: Have a Country Dimension (OFBIZ-10954)
> >> ccb6219 is described below
> >>
> >> commit ccb6219954a0b523b8ff854da5954af2feaab8d0
> >> Author: Pawan Verma 
> >> AuthorDate: Thu Jan 30 14:45:25 2020 +0530
> >>
> >>  Implemented: Have a Country Dimension
> >>  (OFBIZ-10954)
> >>   Added new CountryDimension entity in olap.
> >>   Thanks: Pierre Smits for your contribution.
> >> ---
> >>   bi/entitydef/entitygroup.xml |  1 +
> >>   bi/entitydef/entitymodel.xml | 25 +
> >>   2 files changed, 26 insertions(+)
> >>
> >> diff --git a/bi/entitydef/entitygroup.xml b/bi/entitydef/entitygroup.xml
> >> index 2d34fe7..670405c 100644
> >> --- a/bi/entitydef/entitygroup.xml
> >> +++ b/bi/entitydef/entitygroup.xml
> >> @@ -24,6 +24,7 @@ under the License.
> >>   
> >>   
> >>   
> >> + >> entity="CountryDimension"/>
> >>>> entity="CurrencyDimension"/>
> >>>> entity="DateDimension"/>
> >>>> entity="ProductDimension"/>
> >> diff --git a/bi/entitydef/entitymodel.xml b/bi/entitydef/entitymodel.xml
> >> index 57c0868..7bdfe25 100644
> >> --- a/bi/entitydef/entitymodel.xml
> >> +++ b/bi/entitydef/entitymodel.xml
> >> @@ -29,6 +29,31 @@ under the License.
> >>   
> >>   
> >>   
> >> + >> package-name="org.apache.ofbiz.bi.dimension" title="Country Dimension">
> >> +Country dimension. Based on ISO 3166-1. The
> >> natural key is [geoId]
> >> +
> >> +Unique identifier of the Date dimension
> >> record
> >> +
> >> +
> >> +The natural key, based on ISO 3166-1
> >> alpha-3
> >> +
> >> +
> >> +The name of the country, based on ISO
> >> 3166
> >> +
> >> +
> >> +The ISO 3166-1 alpha-2 code of the
> >> country
> >> +
> >> +
> >> +Based on the ISO 3166-1 alpha-3 code of the
> >> country
> >> +
> >> +
> >> +The telephone country code. Based on
> >> ITU.E123 and ITU.164
> >> +
> >> +
> >> +The country code top-level domain for the
> >> country. Base on IANA rfc1591
> >> +
> >> +
> >> +
> >>>> package-name="org.apache.ofbiz.bi.dimension" title="Date Dimension">
> >>   Date (days) dimension. The natural key is
> >> [dateValue]
> >>   
> >>
> >
>

Re: Removing “base/config/component-load.xml”

[Taher Alkhateeb]

Hello Folks,

I can sense frustration from Mathieu regarding getting things moving
forward. I would just like to note that it's really not _that_ bad!
You've already gotten a lot of commits rolling into the code base
(which is fantastic) and you didn't get objections on most of them. In
fact many commits that you made were just fine, including things you
did to the core components and gradle scripts and whatnot.

So I want to encourage you to trust that things would work themselves
out, and there is no need to be frustrated. Take a deep breath and
just consider more of a long-term initiative than a short term one.
Doing the jar architecture is not the only thing that can be improved.
There is a whole heap of areas in the framework that can be improved.
For example REST (which you worked on partially if I'm not mistaken).

Disagreements are usually a positive rather than a negative one,
because it allows us all to learn something new by looking at things
from different points of view. All in all,  I am appreciative of your
efforts and hope that you don't drop the ball.

Cheers,

Taher Alkhateeb

On Wed, Feb 5, 2020 at 8:29 PM Michael Brohl  wrote:
>
> Hi Mathieu,
>
> I'm not sure if we understand each other correctly and maybe talk at
> cross-puposes.
>
> Hope you are open to read my comments inline...
>
>
> Am 05.02.20 um 15:34 schrieb Mathieu Lirzin:
> > Hello,
> >
> > Michael Brohl  writes:
> >
> >> Am 31.01.20 um 13:15 schrieb Jacques Le Roux:
> >>> We could continue the discussion in this thread or at
> >>> https://issues.apache.org/jira/browse/OFBIZ-11296
> >>
> >> This issue shows exactly the same pattern in the process like the
> >> component-load approach. The Jira was created and *on the same day*
> >> the first patches were committed without further discussion within the
> >> Jira. The Jiras contains a link to a discussion with the statement
> >> "this has been discusses on Development mailing list".
> >>
> >> In fact, the thread also started on the same day in dev but has not
> >> many reactions and in no way any decision to go in that
> >> direction. This is by no means the correct way to introduce
> >> fundamental changes to the project.
> > This description is dishonest, I have always opened discussions on this
> > mailing-list and waited for feedback when considering a *big/breaking
> > change*. I have only moved fast when I considered that what I was
> > working on was an implementation detail and that the improvement was
> > obvious.
>
> My latest emails were not adressed at the depends-on topic but the
> changes proposed in [1]. See below also.
>
> >
> > The actual issue is not that I did not follow the rules. The fact that I
> > ended up opening/closing a JIRA the same day I commit things that I
> > consider trivial was precisely to conform to the policy of “every change
> > needs to have a JIRA associated” which is bureaucratic non-sense.
>
> I think it helps to keep track of the many issues we have to work on.
>
> A good example is my own fault to not create a Jira for [3]: I fixed a
> bug but forgot to backport.
>
> If I had created a Jira, other might have spotted it and reacted or I
> may have thought about backporting myself. It was sheer luck that I
> stumbled upon it again.
>
> >> As much as I appreciate the initiative to move things forward I am
> >> also strictly against the approach and process to put fundamental
> >> changes into the codebase without through conceptual work and
> >> planning.
> > I am glad that you appreciate the initiative, but as far as I am
> > concerned I am certainly not enjoying my time in this community anymore.
>
> For which I feel truly sorry and I apologize if I caused frustration and
> did not find the right words to express my concerns in a more motivating
> way.
>
> >>> https://issues.apache.org/jira/browse/OFBIZ-11161 is also related
> >>>
> >>> Maybe better to create a new thread?
> >> We already have a thread for it, started on 22. August 2019. I would
> >> very much appreciate if experienced users/developers would join this
> >> discussion (which I have missed being on vacation at the time and,
> >> having not much response, did not get my attention until now).
> > Basically you are acknowledging that nobody cares deeply about the idea
> > I proposed in previous thread (which is probably true) but at the same
>
> I did not say that nobody cares, I said that the thread does not get
> many responses. The reasons can be manifold.
>
> The reason why *I* have not responded is that I was on vacation and had
> an immense workload of projects until the end of the year afterwards. I
> was more or less off as you can see at my engagement in the dev list
> after June.
>
> Others may have had same issues. Sometimes a topic needs patience or
> reminders for the community to pick up.
>
> I care a lot for this topic, which is why I expressed my wish to the
> community to join the discussion on several occasions. We simply have
> different perspectives, 

Re: [ofbiz-plugins] branch trunk updated: Implemented: Have a Country Dimension (OFBIZ-10954)

[Nicolas Malin]

Hi,

On 30/01/2020 16:51, Michael Brohl wrote:
> Hi Pawan, all,
>
> I really don't see any reason to introduce tables into the codebase
> which are not used anywhere in the current functionality.
>
> I would recommend to wait until there is substantial functioanality
> which use these table. As Piere stated in some of the *Dimension
> Jiras: "The component would benefit from a ... dimension for future
> fact tables and star schema view entities".
>
> What do others think?

I'm not opposed to introduce some new dimension, if we have service to
populate them, as bi api.

Otherwise the added valuable would be small because not really easy to use.

After use a dimension with fact element are, for me, just an example how
we can use this dimension

Nicolas

>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 30.01.20 um 10:15 schrieb pa...@apache.org:
>> This is an automated email from the ASF dual-hosted git repository.
>>
>> pawan pushed a commit to branch trunk
>> in repository https://gitbox.apache.org/repos/asf/ofbiz-plugins.git
>>
>>
>> The following commit(s) were added to refs/heads/trunk by this push:
>>   new ccb6219  Implemented: Have a Country Dimension (OFBIZ-10954)
>> ccb6219 is described below
>>
>> commit ccb6219954a0b523b8ff854da5954af2feaab8d0
>> Author: Pawan Verma 
>> AuthorDate: Thu Jan 30 14:45:25 2020 +0530
>>
>>  Implemented: Have a Country Dimension
>>  (OFBIZ-10954)
>>   Added new CountryDimension entity in olap.
>>   Thanks: Pierre Smits for your contribution.
>> ---
>>   bi/entitydef/entitygroup.xml |  1 +
>>   bi/entitydef/entitymodel.xml | 25 +
>>   2 files changed, 26 insertions(+)
>>
>> diff --git a/bi/entitydef/entitygroup.xml b/bi/entitydef/entitygroup.xml
>> index 2d34fe7..670405c 100644
>> --- a/bi/entitydef/entitygroup.xml
>> +++ b/bi/entitydef/entitygroup.xml
>> @@ -24,6 +24,7 @@ under the License.
>>   
>>   
>>   
>> +    > entity="CountryDimension"/>
>>   > entity="CurrencyDimension"/>
>>   > entity="DateDimension"/>
>>   > entity="ProductDimension"/>
>> diff --git a/bi/entitydef/entitymodel.xml b/bi/entitydef/entitymodel.xml
>> index 57c0868..7bdfe25 100644
>> --- a/bi/entitydef/entitymodel.xml
>> +++ b/bi/entitydef/entitymodel.xml
>> @@ -29,6 +29,31 @@ under the License.
>>   
>>   
>>   
>> +    > package-name="org.apache.ofbiz.bi.dimension" title="Country Dimension">
>> +    Country dimension. Based on ISO 3166-1. The
>> natural key is [geoId]
>> +    
>> +    Unique identifier of the Date dimension
>> record
>> +    
>> +    
>> +    The natural key, based on ISO 3166-1
>> alpha-3
>> +    
>> +    
>> +    The name of the country, based on ISO
>> 3166
>> +    
>> +    
>> +    The ISO 3166-1 alpha-2 code of the
>> country
>> +    
>> +    
>> +    Based on the ISO 3166-1 alpha-3 code of the
>> country
>> +    
>> +    
>> +    The telephone country code. Based on
>> ITU.E123 and ITU.164
>> +    
>> +    
>> +    The country code top-level domain for the
>> country. Base on IANA rfc1591
>> +    
>> +    
>> +    
>>   > package-name="org.apache.ofbiz.bi.dimension" title="Date Dimension">
>>   Date (days) dimension. The natural key is
>> [dateValue]
>>   
>>
>


pEpkey.asc
Description: application/pgp-keys

Re: Removing “base/config/component-load.xml”

[Michael Brohl]

Hi Mathieu,

I'm not sure if we understand each other correctly and maybe talk at 
cross-puposes.


Hope you are open to read my comments inline...


Am 05.02.20 um 15:34 schrieb Mathieu Lirzin:

Hello,

Michael Brohl  writes:


Am 31.01.20 um 13:15 schrieb Jacques Le Roux:

We could continue the discussion in this thread or at
https://issues.apache.org/jira/browse/OFBIZ-11296


This issue shows exactly the same pattern in the process like the
component-load approach. The Jira was created and *on the same day*
the first patches were committed without further discussion within the
Jira. The Jiras contains a link to a discussion with the statement
"this has been discusses on Development mailing list".

In fact, the thread also started on the same day in dev but has not
many reactions and in no way any decision to go in that
direction. This is by no means the correct way to introduce
fundamental changes to the project.

This description is dishonest, I have always opened discussions on this
mailing-list and waited for feedback when considering a *big/breaking
change*. I have only moved fast when I considered that what I was
working on was an implementation detail and that the improvement was
obvious.


My latest emails were not adressed at the depends-on topic but the 
changes proposed in [1]. See below also.




The actual issue is not that I did not follow the rules. The fact that I
ended up opening/closing a JIRA the same day I commit things that I
consider trivial was precisely to conform to the policy of “every change
needs to have a JIRA associated” which is bureaucratic non-sense.


I think it helps to keep track of the many issues we have to work on.

A good example is my own fault to not create a Jira for [3]: I fixed a 
bug but forgot to backport.


If I had created a Jira, other might have spotted it and reacted or I 
may have thought about backporting myself. It was sheer luck that I 
stumbled upon it again.



As much as I appreciate the initiative to move things forward I am
also strictly against the approach and process to put fundamental
changes into the codebase without through conceptual work and
planning.

I am glad that you appreciate the initiative, but as far as I am
concerned I am certainly not enjoying my time in this community anymore.


For which I feel truly sorry and I apologize if I caused frustration and 
did not find the right words to express my concerns in a more motivating 
way.



https://issues.apache.org/jira/browse/OFBIZ-11161 is also related

Maybe better to create a new thread?

We already have a thread for it, started on 22. August 2019. I would
very much appreciate if experienced users/developers would join this
discussion (which I have missed being on vacation at the time and,
having not much response, did not get my attention until now).

Basically you are acknowledging that nobody cares deeply about the idea
I proposed in previous thread (which is probably true) but at the same


I did not say that nobody cares, I said that the thread does not get 
many responses. The reasons can be manifold.


The reason why *I* have not responded is that I was on vacation and had 
an immense workload of projects until the end of the year afterwards. I 
was more or less off as you can see at my engagement in the dev list 
after June.


Others may have had same issues. Sometimes a topic needs patience or 
reminders for the community to pick up.


I care a lot for this topic, which is why I expressed my wish to the 
community to join the discussion on several occasions. We simply have 
different perspectives, which is good IMO. Together with more 
perspectives from others, we will be able to build a clearer picture of 
the vision and an actionable plan to reach its realization.


And I really think that a more detailed roadmap will help to engage more 
people in the collaboration (which would be more fun also).




time you are suggesting me to write a lengthy design/architectural
document that will rephrase what as already been said in that thread.


I have suggested to write down and discuss important details and the 
pros/cons of different approaches and ideas. IMO it's the only way to 
engage the community in actionable work items and collaboration. It does 
not necessarily mean that it needs lengthy documents. A simple Wiki page 
would do for a start.



Sorry but no, I will not write such document, I have already explained
multiple times the design principles leading to the proposal of enabling
the distribution of OFBiz inside a Jar:

- Extensible dependency management is better than having to define a
   arbitrary global ordering

- Location independent loading/configuration mechanism is the only sane
   way to provide true extensibility.

- Adopting the stable mechanism provided by the Java platform that we
   already depend on is better than implementing our own specific
   mechanism

If people are not convinced by the benefits of this vision which imply
deprecating the 

Please add me as an Apache OFBiz Contributor

[Wiebke Pätzold]

Hello everyone,

I would like to ask you to add me as an Apache OFBiz Contributor.
My Confluence username is: wpaetzold

Thanks and kind regards,
Wiebke

Re: Removing “base/config/component-load.xml”

[Mathieu Lirzin]

Hello,

Michael Brohl  writes:

> Am 31.01.20 um 13:15 schrieb Jacques Le Roux:
>>
>> We could continue the discussion in this thread or at
>> https://issues.apache.org/jira/browse/OFBIZ-11296
>
>
> This issue shows exactly the same pattern in the process like the
> component-load approach. The Jira was created and *on the same day*
> the first patches were committed without further discussion within the
> Jira. The Jiras contains a link to a discussion with the statement
> "this has been discusses on Development mailing list".
>
> In fact, the thread also started on the same day in dev but has not
> many reactions and in no way any decision to go in that
> direction. This is by no means the correct way to introduce
> fundamental changes to the project.

This description is dishonest, I have always opened discussions on this
mailing-list and waited for feedback when considering a *big/breaking
change*. I have only moved fast when I considered that what I was
working on was an implementation detail and that the improvement was
obvious.

The actual issue is not that I did not follow the rules. The fact that I
ended up opening/closing a JIRA the same day I commit things that I
consider trivial was precisely to conform to the policy of “every change
needs to have a JIRA associated” which is bureaucratic non-sense.

The actual issue is that in the case of
“{framework,applications}/component-load.xml” we disagreed on the
trivial aspect of this change.  This disagreement is an expected thing
because nobody in this community can tell the difference between an
*implementation detail* and a *breaking change* because we don't have
(and don't want) a public API. This simply means that every code change
is a breaking change and that it should follow a slow process of review
to let evaluate the trade-offs between potential downstream breakage
(that we might not be aware of) and the actual benefits of the proposed
change.

> I'm also pretty sure that, if the community decides to go that way
> after a thorough exchange of arguments and real life practical
> experience, the implementation will be a long-running project
> itself. This cannot be undertaken on the trunk but will need a feature
> branch, which has to be discussed when the time is right.
>
> As much as I appreciate the initiative to move things forward I am
> also strictly against the approach and process to put fundamental
> changes into the codebase without through conceptual work and
> planning.

I am glad that you appreciate the initiative, but as far as I am
concerned I am certainly not enjoying my time in this community anymore.

>> https://issues.apache.org/jira/browse/OFBIZ-11161 is also related
>>
>> Maybe better to create a new thread?
>
> We already have a thread for it, started on 22. August 2019. I would
> very much appreciate if experienced users/developers would join this
> discussion (which I have missed being on vacation at the time and,
> having not much response, did not get my attention until now).

Basically you are acknowledging that nobody cares deeply about the idea
I proposed in previous thread (which is probably true) but at the same
time you are suggesting me to write a lengthy design/architectural
document that will rephrase what as already been said in that thread.

Sorry but no, I will not write such document, I have already explained
multiple times the design principles leading to the proposal of enabling
the distribution of OFBiz inside a Jar:

- Extensible dependency management is better than having to define a
  arbitrary global ordering

- Location independent loading/configuration mechanism is the only sane
  way to provide true extensibility.

- Adopting the stable mechanism provided by the Java platform that we
  already depend on is better than implementing our own specific
  mechanism

If people are not convinced by the benefits of this vision which imply
deprecating the “component-load.xml” mechanism and use “depends-on”
instead (which I did not introduced in the first place) then providing a
precise design/implementation plan will not help moving forward, it will
just lead to more time waste on my side.

I don't see the point of continuing this unproductive discussion neither
to proceed with a formal vote regarding the deprecation of
“component-load.xml”, because whatever the result I have lost my faith
in the capability of this community to succeed at handling the technical
challenges that will enable OFBiz to stay relevant in the future.

But this is fine.


-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: [DISCUSSION] bi/birt component integration

[Taher Alkhateeb]

I think Jacopo got it just right!

BI to me means a collection of complex queries and services that give
insightful information (not necessarily even visual). Birt on the
other hand is a specific tool that makes it possible to design and
create reports interactively using a drag-and-drop behavior and it is
one of multiple options available. Hence BI is a generic thing while
BIRT is a specific tool. Furthermore, BIRT has lots and lots of
dependencies which might not be appealing to everyone using it.

So I think the two represent entirely different concepts. And the only
relationship might / should be that birt depends on some things in BI
but not the opposite.


On Wed, Feb 5, 2020 at 2:20 PM Jacopo Cappellato
 wrote:
>
> My main concern about this proposal is that the BI component is intended to
> provide a "universal data model" (of dimensions, facts and star schemas)
> for OLAP that is independent from the specific tools adopted to actually
> perform the analysis (reporting tools, user interfaces etc...); its role
> for OLAP is similar to the role of the OFBiz "universal data model" (of
> entities and views) for OLTP that we all know and love.
> On the other hand the Birt component is intended to integrate one specific
> technology platform (Birt from Eclipse) to create data visualizations and
> reports.
> If we merge the two components, an adopter that would like to use a
> different technology on our "universal data model" of dimensions/facts/star
> schemas would have to deal with more unneeded code and dependencies (on
> Birt).
> I agree with Pierre that the BI component would need more attention to be
> appealing to users; in its current form it is just a Proof Of Concepts
> (POC) of some of the great ideas of "The Data Warehouse Toolkit"; but in my
> opinion we should focus on improving and completing
> the dimensions/facts/star schemas and the scripts that populate them; I am
> fine with the idea of moving the definitions of dimensions/facts/star
> schemas to the BI component (similarly to what was done with the entity
> definitions in the "datamodel" component).
> On the other hand, the Birt component can be improved by using and
> leveraging more the data model provided by the BI component.
>
> Jacopo
>
>
> On Sat, Feb 1, 2020 at 2:05 PM Michael Brohl 
> wrote:
>
> > Hi Pierre,
> >
> > +1 for the initiative as a whole.
> >
> > One remark though to the current approach: you are creating al lot of
> > singe Jira issues for new tables, services to load data etc. I currently
> > do not find the functional part, for example UI elements and
> > functionality to view the informations loaded into the datastore.
> >
> >  From my perspective, it does not make sense to add tables to the
> > datamodel and services to the codebase without having a functional part
> > depending on it.
> >
> > I think it would help to maybe pick a single aspect (e.g. sales channel
> > dimension) of the overall approch and implement all of the needed parts
> > (database mode, service, UI and example data) for it to show what the
> > desired outcome would be. I'm sure it would help to get the work
> > accepted and into the codebase.
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 27.04.19 um 13:22 schrieb Pierre Smits:
> > > Hi All,
> > > Currently the various business intelligence (BI) functionalities are
> > > scattered in various components (consider all the overviews regarding
> > > inventory positions, orders/deliveries per customer/supplier) in the
> > > applications folder.
> > >
> > > And on the other hand we have the BI component and the Birt component in
> > > the plugins repo. Both of those components have minimal functionality
> > > regarding the business intelligence aspect. But both components are
> > > complimentary:
> > >
> > > 1. the bi (short for: Business Intelligence) component initialised
> > the
> > > OFBiz DWH and has secas and services for copying data from the ofbiz
> > > database to the ofbizolap database, and
> > > 2. the birt (short for Business Intelligence Report Tool) component
> > is
> > > intended to deliver on  functionalities to display data overviews in
> > > various forms (tables, charts, in PDFs, UI widgets, etc)...
> > >
> > > Unfortunately, both components lack of love from our community. But a bit
> > > more love would significantly enhances the appeal of OFBiz for
> > (potential)
> > > adopters!
> > >
> > > As a result from a customer project, I recently have been working a bit
> > > more on the business intelligence aspect (see recent tickets in [1] and
> > > [2]).
> > >
> > > I believe it would be in the best interest of the project to integrate
> > the
> > > functionalities in the Birt component into the BI component. It will
> > send a
> > > clear message to both (potential) adopters and OFBiz developers (both our
> > > contributors, and those not participating here but working on
> > > implementations of adopters), being:
> > >
> > > *everything related with 

Re: [DISCUSSION] bi/birt component integration

[Jacopo Cappellato]

My main concern about this proposal is that the BI component is intended to
provide a "universal data model" (of dimensions, facts and star schemas)
for OLAP that is independent from the specific tools adopted to actually
perform the analysis (reporting tools, user interfaces etc...); its role
for OLAP is similar to the role of the OFBiz "universal data model" (of
entities and views) for OLTP that we all know and love.
On the other hand the Birt component is intended to integrate one specific
technology platform (Birt from Eclipse) to create data visualizations and
reports.
If we merge the two components, an adopter that would like to use a
different technology on our "universal data model" of dimensions/facts/star
schemas would have to deal with more unneeded code and dependencies (on
Birt).
I agree with Pierre that the BI component would need more attention to be
appealing to users; in its current form it is just a Proof Of Concepts
(POC) of some of the great ideas of "The Data Warehouse Toolkit"; but in my
opinion we should focus on improving and completing
the dimensions/facts/star schemas and the scripts that populate them; I am
fine with the idea of moving the definitions of dimensions/facts/star
schemas to the BI component (similarly to what was done with the entity
definitions in the "datamodel" component).
On the other hand, the Birt component can be improved by using and
leveraging more the data model provided by the BI component.

Jacopo


On Sat, Feb 1, 2020 at 2:05 PM Michael Brohl 
wrote:

> Hi Pierre,
>
> +1 for the initiative as a whole.
>
> One remark though to the current approach: you are creating al lot of
> singe Jira issues for new tables, services to load data etc. I currently
> do not find the functional part, for example UI elements and
> functionality to view the informations loaded into the datastore.
>
>  From my perspective, it does not make sense to add tables to the
> datamodel and services to the codebase without having a functional part
> depending on it.
>
> I think it would help to maybe pick a single aspect (e.g. sales channel
> dimension) of the overall approch and implement all of the needed parts
> (database mode, service, UI and example data) for it to show what the
> desired outcome would be. I'm sure it would help to get the work
> accepted and into the codebase.
>
> Thanks,
>
> Michael
>
>
> Am 27.04.19 um 13:22 schrieb Pierre Smits:
> > Hi All,
> > Currently the various business intelligence (BI) functionalities are
> > scattered in various components (consider all the overviews regarding
> > inventory positions, orders/deliveries per customer/supplier) in the
> > applications folder.
> >
> > And on the other hand we have the BI component and the Birt component in
> > the plugins repo. Both of those components have minimal functionality
> > regarding the business intelligence aspect. But both components are
> > complimentary:
> >
> > 1. the bi (short for: Business Intelligence) component initialised
> the
> > OFBiz DWH and has secas and services for copying data from the ofbiz
> > database to the ofbizolap database, and
> > 2. the birt (short for Business Intelligence Report Tool) component
> is
> > intended to deliver on  functionalities to display data overviews in
> > various forms (tables, charts, in PDFs, UI widgets, etc)...
> >
> > Unfortunately, both components lack of love from our community. But a bit
> > more love would significantly enhances the appeal of OFBiz for
> (potential)
> > adopters!
> >
> > As a result from a customer project, I recently have been working a bit
> > more on the business intelligence aspect (see recent tickets in [1] and
> > [2]).
> >
> > I believe it would be in the best interest of the project to integrate
> the
> > functionalities in the Birt component into the BI component. It will
> send a
> > clear message to both (potential) adopters and OFBiz developers (both our
> > contributors, and those not participating here but working on
> > implementations of adopters), being:
> >
> > *everything related with business intelligence happens in and comes from
> > the bi component*.
> >
> >
> > What do you think?
> >
> > When we have this, the community can start working on enhancing the
> single
> > component to increase its (and inherently OFBiz) appeal:
> >
> >
> > 1. more entitiy definitions for dimension and fact tables (per [3],
> from
> > the OFBiz related books),
> > 2. more scheduled services that move data from various ofbiz tables
> into
> > ofbizolap tables,
> > 3. more UI widgets for displaying data aggregations (tables, charts)
> in
> > the form of portal pages widgets. These portal page widgets can then
> be
> > integrated by our adopters dynamically anywhere in the components of
> the
> > applications folder, e.g through starting/main pages.
> >
> > [1]
> >
>