Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Taher Alkhateeb]

+1

If it helps with saving the valuable time of our community volunteers, then it 
makes perfect sense.

On Saturday, February 11, 2023 14:32 +03, Michael Brohl 
 wrote:
 See also https://issues.apache.org/jira/browse/INFRA-24152 for the infra
migration Jira issue.

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 07.02.23 um 19:06 schrieb Michael Brohl:
> Dear community,
>
> In the course of getting Wiebke to be able to help with our blog, it
> turned out that Apache Roller will be discontinued as the platform for
> blogs by infra [1].
>
> There is an offer and already a pull request [2] to export the
> existing blog posts for a migration to Hugo [3].
> Hugo is a static site generator which will generate individual pages
> from every markdown blog posts file which is provided in the PR.
>
> That means we need to (at least)
>
> - setup a Hugo project
> - build up templates for the blog posts which also include header and
> footer for full page rendering
>   (hence, we have to take over some of the templates/html
> code/javascrip/CSS to Hugo as well)
> - generate the post pages and include them in the website under /blog.
>
> These are quite some steps we have to take anyway and I ask myself if
> we should not switch over to Hugo for the whole website as well.
> That should be not too difficult because we already have some kind of
> templates (in php) and there is already some sectioning with header,
> content, footer etc.
>
> The advantages would be
>
> - to truly separate content from the templates (it is now mixed
> php/content)
> - blog posts can be generated from OFBiz commits and, together with
> page content, be send in by pull requests
> - content automation (no need to change the copyright year manually,
> automated taxonimies for the blog etc.)
> - easy process for a git supported writing process for pages and blog
> posts and a fast and automatable publishing process (git hooks or
> GitHub integration).
>
> Coincidence: I am on a journey to migrate the ecomify websites to Hugo
> we have at least some knowledge there (maybe others as well?).
>
> To sum up, I propose to migrate our blog and also the Apache OFBiz
> website to be an integrated, Hugo based website.
>
> Opinions?
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
> [1] https://issues.apache.org/jira/browse/INFRA-22461
> [2] https://github.com/apache/ofbiz-site/pull/8/files
> [3] https://gohugo.io/
>

Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Taher Alkhateeb]

Yeah seems very fast and lean indeed. Might be worth the switch



On Wednesday, February 08, 2023 14:17 +03, Michael Brohl 
 wrote:
 Hi Taher,

while this sounds like an interesting approach, I personally want to
avoid to face things more complex than they have to be.

At ecomify, we are shifting to Hugo to get rid of things like Wordpress
/ database maintenance, possible security issues etc.. We have limited
ressources in our project here so I'm interested to keep things simple
and effortless as much as we can.

Hugo is an infra supported solution, it seems to be the official
migration target away from Roller so it seems to be the given way for
the blog.

The question is if we also want to shift to Hugo for the website with a
- then integrated - blog.

Thanks for your input and greetings,

Michael


Am 08.02.23 um 11:13 schrieb Taher Alkhateeb:
> Hello, just throwing another idea in the pile, which I used in the past.
>
> It is possible is to deploy a headless CMS. A headless CMS gives you admin 
> user interface to control content, but the website is just a regular website 
> (can be the existing one) that communicates with that headless CMS. What you 
> can do with that is be able to deploy whatever exists and just replace the 
> dynamic parts with calls to the headless CMS. And you control the content 
> from there. So you don't even need to commit code, build and deploy, you just 
> login to the admin section and edit things.
>
> ​​​Maybe the advantage of this approach is that you build on what exists 
> instead of re-writing. This disadvantage might be that you have more pieces 
> (website, CMS-admin, CMS-database) that should all be deployed and 
> maintained. Thank you for all the efforts on maintaining all this content 
> either way.
>
> On Wednesday, February 08, 2023 12:55 +03, Daniel Watford  
> wrote:
>  Hi Michael,
>
> This sounds very interesting.
>
> I have gone back and forth over the years between CMS driven (WordPress)
> and statically generated sites (Jekyll) depending on the users that
> would be responsible for authoring content. Mixing the two with tools like
> Next.js was also interesting.
>
> WordPress suited non-technical better, whereas technical users benefited
> from being able to generate the exact site they wanted. Plus the static
> sites have the benefit of fast load times without having to implement
> caches (although caching at CDNs is still useful)
>
> Since we are a techy bunch I would support building the website using a
> static generation tool. I've heard good things about Hugo, and since there
> is existing experience on this tool within our community it would seem a
> reasonable direction to take.
>
> I'm also interested to see if adding more data-driven pages to the site
> would be easier with Hugo. I quite like the idea of a few utility pages to
> help generate seed data for users, such as:
> - Custom time period generator
> - Chart of accounts generator
>
> My only concern with changing the site is the amount of work involved since
> we have limited resources, but since we are being forced to take action in
> order to get the blog operational, perhaps widening the scope to the site
> is reasonable. I expect we can keep the existing HTML pages, and replace
> them with Hugo generated pages as and when needed.
>
> +1 from me.
>
> Dan.
>
>
> On Tue, 7 Feb 2023 at 18:07, Michael Brohl  wrote:
>
>> Dear community,
>>
>> In the course of getting Wiebke to be able to help with our blog, it
>> turned out that Apache Roller will be discontinued as the platform for
>> blogs by infra [1].
>>
>> There is an offer and already a pull request [2] to export the existing
>> blog posts for a migration to Hugo [3].
>> Hugo is a static site generator which will generate individual pages
>> from every markdown blog posts file which is provided in the PR.
>>
>> That means we need to (at least)
>>
>> - setup a Hugo project
>> - build up templates for the blog posts which also include header and
>> footer for full page rendering
>> (hence, we have to take over some of the templates/html
>> code/javascrip/CSS to Hugo as well)
>> - generate the post pages and include them in the website under /blog.
>>
>> These are quite some steps we have to take anyway and I ask myself if we
>> should not switch over to Hugo for the whole website as well.
>> That should be not too difficult because we already have some kind of
>> templates (in php) and there is already some sectioning with header,
>> content, footer etc.
>>
>> The advantages would be
>>
>> - to truly separate content from the templates (it is now mixed
>> php/content)
>> - blog posts

Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Taher Alkhateeb]

Hello, just throwing another idea in the pile, which I used in the past.

It is possible is to deploy a headless CMS. A headless CMS gives you admin user 
interface to control content, but the website is just a regular website (can be 
the existing one) that communicates with that headless CMS. What you can do 
with that is be able to deploy whatever exists and just replace the dynamic 
parts with calls to the headless CMS. And you control the content from there. 
So you don't even need to commit code, build and deploy, you just login to the 
admin section and edit things.

​​​Maybe the advantage of this approach is that you build on what exists 
instead of re-writing. This disadvantage might be that you have more pieces 
(website, CMS-admin, CMS-database) that should all be deployed and maintained. 
Thank you for all the efforts on maintaining all this content either way.

On Wednesday, February 08, 2023 12:55 +03, Daniel Watford  
wrote:
 Hi Michael,

This sounds very interesting.

I have gone back and forth over the years between CMS driven (WordPress)
and statically generated sites (Jekyll) depending on the users that
would be responsible for authoring content. Mixing the two with tools like
Next.js was also interesting.

WordPress suited non-technical better, whereas technical users benefited
from being able to generate the exact site they wanted. Plus the static
sites have the benefit of fast load times without having to implement
caches (although caching at CDNs is still useful)

Since we are a techy bunch I would support building the website using a
static generation tool. I've heard good things about Hugo, and since there
is existing experience on this tool within our community it would seem a
reasonable direction to take.

I'm also interested to see if adding more data-driven pages to the site
would be easier with Hugo. I quite like the idea of a few utility pages to
help generate seed data for users, such as:
- Custom time period generator
- Chart of accounts generator

My only concern with changing the site is the amount of work involved since
we have limited resources, but since we are being forced to take action in
order to get the blog operational, perhaps widening the scope to the site
is reasonable. I expect we can keep the existing HTML pages, and replace
them with Hugo generated pages as and when needed.

+1 from me.

Dan.


On Tue, 7 Feb 2023 at 18:07, Michael Brohl  wrote:

> Dear community,
>
> In the course of getting Wiebke to be able to help with our blog, it
> turned out that Apache Roller will be discontinued as the platform for
> blogs by infra [1].
>
> There is an offer and already a pull request [2] to export the existing
> blog posts for a migration to Hugo [3].
> Hugo is a static site generator which will generate individual pages
> from every markdown blog posts file which is provided in the PR.
>
> That means we need to (at least)
>
> - setup a Hugo project
> - build up templates for the blog posts which also include header and
> footer for full page rendering
> (hence, we have to take over some of the templates/html
> code/javascrip/CSS to Hugo as well)
> - generate the post pages and include them in the website under /blog.
>
> These are quite some steps we have to take anyway and I ask myself if we
> should not switch over to Hugo for the whole website as well.
> That should be not too difficult because we already have some kind of
> templates (in php) and there is already some sectioning with header,
> content, footer etc.
>
> The advantages would be
>
> - to truly separate content from the templates (it is now mixed
> php/content)
> - blog posts can be generated from OFBiz commits and, together with page
> content, be send in by pull requests
> - content automation (no need to change the copyright year manually,
> automated taxonimies for the blog etc.)
> - easy process for a git supported writing process for pages and blog
> posts and a fast and automatable publishing process (git hooks or GitHub
> integration).
>
> Coincidence: I am on a journey to migrate the ecomify websites to Hugo
> we have at least some knowledge there (maybe others as well?).
>
> To sum up, I propose to migrate our blog and also the Apache OFBiz
> website to be an integrated, Hugo based website.
>
> Opinions?
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
> [1] https://issues.apache.org/jira/browse/INFRA-22461
> [2] https://github.com/apache/ofbiz-site/pull/8/files
> [3] https://gohugo.io/
>
>

--
Daniel Watford

Re: Welcome to Daniel Watford as new PMC member

[Taher Alkhateeb]

Congratulations!



On Saturday, January 28, 2023 13:57 +03, Jacopo Cappellato 
 wrote:
 The OFBiz PMC has invited Daniel Watford as a new PMC member and we
are glad to announce that Daniel has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: How committers should handle old Jira Issues (and patches)

[Taher Alkhateeb]

I think I would be in favor of always closing tickets instead of letting them 
hang indefinitely. In my experience old and stale tickets are really never 
handled, they eventually get outdated and irrelevant, and after enough 
accumulation everyone stops caring to attend to them. On the other hand, having 
very few but really active and really happening tickets encourages everyone to 
try and get everything done because it is "possible" as opposed to having 
mountains of those things around which just leads to overwhelm and chaos.

I find many of the tickets difficult to understand, missing repeat steps, 
vague, or simply not too necessary or critical. Closing these off would 
probably bring relief to the project.

my 2 cents

Taher Alkhateeb

On Saturday, October 29, 2022 16:34 +03, Michael Brohl 
 wrote:
 Hi Giulio,

thanks for taking care of the Jira issues and bringing this up.

As to my knowledge, there is no strict rule on how to handle this. We
are a community of volunteers and sometimes contributors come and go so
it is common that you will get late or no responses to an issue comment.

Personally, I ask 1-3 times and then decide for myself on how to proceed
with the issue. The action taken depends on the issue (working on it,
closing it because of no response, ...).

So I encourage you to decide what you think would be the best for the
project and go on. If there is an objection, it will be raised.

Regarding the mentioned OFBIT-9362, your comment is only 4 days old. You
should give people at least 1-2 weeks to respond.  What you can also do
is to mention how you will proceed with the issue if there is no
response within xx days/weeks.

Hope this helps,

best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 28.10.22 um 19:14 schrieb Giulio Speri - MpStyle Srl:
> Hello devs,
>
> I hope you're doing great.
> I recently started to give a check to the old ofbiz issues in Jira with the
> status "patch available", both to increase my contribution as (new)
> committer and also to try to reduce the bug list.
> To warm up I started with the "trivia" issues and then I'll proceed. :)
>
> I came across some (quite) old issues and I tried to gather informations by
> contacting the original reporter or the assignee of that task (ie:
> OFBIZ-9362).
> What if nobody replies for some time (maybe the original reporter/assignee
> is no more involved in the project so not able to respond), as for the case
> of the issue OFBIZ-9362 ? Are there some community guidelines for this kind
> of situation? Should I keep waiting for a response or should I re-analyze
> the issue, assign it to me and then work on it?
>
>
> Thank you in advance,
>
> Giulio
>
>
>
>

Re: Welcome to Leila Mekika as new committer

[Taher Alkhateeb]

Congrats

On 10/4/22 08:38, Devanshu Vyas wrote:

Many congratulations and welcome aboard Leila!!

Thanks & Regards,
Devanshu Vyas.


On Mon, Oct 3, 2022 at 6:27 PM Nicolas Malin 
wrote:


The OFBiz PMC has invited Leila Mekika as new
committer and we are glad to announce that she have accepted the
nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: OFBiz re-architecture thoughts

[Taher Alkhateeb]

st / all agrees that change is needed in OFBiz but I guess we
have different ideas on how to proceed.

I don't think I can add a lot to what was already said.

I do think keeping the current number of git repositories is good.
More will add overhead.
I do believe that ofbiz should provide stable extension points so 
people

can deploy their own plugins and functionality.

I'm also working on some ideas around OFBiz - I believe I can
re-implement OFBiz entity engine on top of relational algebra using
Calcite.

More on this soon on the mailing list.

Looking forward to seeing a PoC from you.
I hope we do get to improve OFBiz and make it even more appealing.


On 25.01.2022 16:29, Taher Alkhateeb wrote:

Thank you everyone for your kind feedback and sharing your thoughts on
this initiative.

I didn't get enough feedback or momentum to give me the impression 
that

this can be a community initiative. I think I made the discussion too
early before coming up with a PoC. So I will attempt something 
privately

and come back perhaps when it is in a more ready state and see if it
garners any momentum. IF people are interested in collaborating, then
perhaps you can approach me and we can team up.

Thank you again.

Regards,

--
Eugen Stan

+40770 941 271  /https://www.netdava.com

Re: "New commiter first steps" wiki page proposal

[Taher Alkhateeb]

Hello Guilio,

I think that's a good idea. It would be helpful to complement whatever 
ASF steps are needed to complete the on-boarding process.


On 4/2/22 15:07, Giulio Speri - MpStyle Srl wrote:

Hello devs,

I hope you're all doing well.

Few days ago me and Nicola became committers of this project and we are
really happy to be part of it.

We read the wiki pages related to committers Roles And Responsibilities and
we started to set up all things to be ready to work with GitHub repos: in
this process we struggled for couple of days before everything was
correctly set up and gain the rights to push into the repos, because the
various steps wasn't so clear, at least for us (create a github account,
then go back to your apache account and put in it the GitHub username to
link both together to correctly use GitBox,...).

We noted down the various actions taken to be fully ready to work with
online repository and we thought that, writing a specific wiki page that
describes the very first steps to perform after a contributor becomes a new
committer, could be helpful to future new committers to get easily involved
in the project.

We could take this task and write it.

What do you think about this?

Thank you in advance for your feedback and suggestions,

Giulio

Re: Welcome to Nicola Mazzoni and Giulio Speri as new committers

[Taher Alkhateeb]

Congratulations and welcome aboard

On 3/21/22 23:26, Jacopo Cappellato wrote:

The OFBiz PMC has invited Nicola Mazzoni and Giulio Speri as new
committers and we are glad to announce that they have accepted the
nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: OFBiz re-architecture thoughts

[Taher Alkhateeb]

Thank you everyone for your kind feedback and sharing your thoughts on 
this initiative.


I didn't get enough feedback or momentum to give me the impression that 
this can be a community initiative. I think I made the discussion too 
early before coming up with a PoC. So I will attempt something privately 
and come back perhaps when it is in a more ready state and see if it 
garners any momentum. IF people are interested in collaborating, then 
perhaps you can approach me and we can team up.


Thank you again.

On 1/9/22 11:16, Jacques Le Roux wrote:

Hi,

If we want to improve OFBiz w/o changing too much the current OFBiz 
why not create an official OFBiz2 fork and work to this goal there?


Disclaimer: I don't think of doing something like that, if people are 
ready for it, why not?


Jacques

Le 28/12/2021 à 18:18, Sakthivel Vellingiri a écrit :
Thanks Taher and Michael for detailed insights and Sathish for 
sharing your

thoughts on upgrades.

Just to introduce myself, we are using OFBiz for little over 7 years 
for a

Life Sciences Product, and we consider ourselves as end user and haven't
inclined to make hardcore changes to the framework as yet.

1. Lack of Code Isolation_:::
  Our approach has been as outlined by Michael, we have custom 
plugins
for each application and in some cases custom application plugins for 
each
customer which are overrides and extensions of the OOTB OFBiz 
application
plugins and we more or less leave the framework untouched except for 
a few

issues we have discovered, and we are guilty of not contributing the fix
back to OFBIZ and hence maintaining in our own branch, but without 
taking
an inventory now, my recollection is that the changes to the 
framework is
minimal. we merge the changes from our customer application plugin 
branch
to *our* common application plugin branch that way *our* common 
application
plugin branch at a given point in time has most of *our* custom 
application

plugin changes.

2. Rest Interface:::
 We are currently using HTML based web UI and relying on
widget/freemarker templating for the changes. We are inclined to client
rendering using Vue Js, and having Rest API integrated in the core
framework would be a huge plus. but we are open to using Rest API as a
plugin to begin with, I know there has been some communication around 
Rest

based webservice api in the email thread, I have to admit, we haven't
explored that all that much yet. But if a Rest API plugin is made
available, we will be happy to utilize that and share feedback.

3. UI Screens:::
 As experienced by new users and outlined in this thread, we end up
customizing the UI to minimize the field display to our user needs 
either
by making changes in minilang or ftl, Perhaps it might be good idea 
to have
database tables to control what is rendered in the UI and perhaps 
rendering

based on database configuration can include support for role/permission
based rendering to show different fields for different
roles/SecurityPermission.

4. Webapps :::
    As of right now, we switch off the webapps that we do not need
currently, At less frequent times we see application logouts when 
switching
from one webapp to another, i'm not sure if this caused by having 
different
plugins as different webapps and passing the session id between them 
and if

this be solved by having single webapp, but i do not understand enough
about the merits of having a single webapp at this time to comment 
more on

this.

I do not have strong opinions about the other points other than what is
discussed already and i will skip responding to them,

In my opinion replacing OFBiz framework code with established open 
source

which is  purpose-built for a specific use case like Apache Shiro for
Security, eHCache for caching could  bring down OFBiz framework code and
thereby maintenance of OFBiz, framework however i also recognize and
reflect the thoughts outlined in this thread that we need to be very
careful about bringing such hardcore changes with careful planning &
quality control not to disrupt the existing implementations.

Thanks to everyone sharing their view points and starting a 
conversation in

lieu of the future of OFBiz.

just my 2 cents from the end user perspective.

regards
Sakthi


On Mon, Dec 27, 2021 at 1:09 PM Taher Alkhateeb 


wrote:


Hi Michael,

Thank you so much for spending your time reading and sifting through
everything, I really appreciate and value your feedback.

I need to highlight that we deployed mixed and somewhat crazy solutions
including multiple mobile apps, live video / chat streaming systems and
other projects that are booming in Kuwait and exploding both in user
bases and technical requirements which is why we cannot operate some of
these projects the way we used to in the past.

Anyway I think I'm not going to elaborate too much as we wait for more
opinions from the community to see if this is worth pushing. However, I
want to reply to a few points you ra

Re: OFBiz re-architecture thoughts

[Taher Alkhateeb]

rstand why you might not agree with some of the points. In a 
way it's kind of hard to imagine a different way of doing things when 
we're used to working a certain way, but once we get exposed we realize 
that OH .. I've been torturing myself :). However, I do so your 
very-good point on being conservative because there is substantial risk 
in doing everything that I suggest.


Anyway opening this to the rest of the community and thank you in 
advance for sharing your thoughts.


Cheers,

Taher Alkhateeb

On 12/27/21 17:20, Michael Brohl wrote:

Hi Taher,

thanks for bringing this up! I will try to briefly explain my views on 
the raised topics.


My perspective is from nearly 20 years of intensive work with OFBiz, 
both for internal and external projects. Those projects have/had a 
volume reaching from about 50 to over 1000  project days and we have 
active customer projects which are running for almost 20 years now, 
still being developed further with the business. OFBiz often became a 
crucial part of the business ecosystem of those users. It is also the 
central toolbox for our services around development of web based 
software solutions and system integration in our own company since 7 
years now. I consider myself both a user of OFBiz and a service 
provider/integrator.


After so many years of working with OFBiz if have learned that - from 
a business users perspective - the functionality and integration 
aspects along with the powerful datamodel, services etc. as well as 
flexibility, performance and scalability is way more important than 
detailed technical aspects (in the sense of “modern” or “newest 
technology”).


As a service provider for OFBiz, we are feeling responsible to provide 
a reliable, constant and upgradeable software ecosystem which is why 
we are on a more "conservative" path regarding big or long running 
changes in the project. I have seen several new, ambititious 
contributors who wanted to change everything, using the newest 
frameworks and tools around etc., but often did not have an extensive 
background of real world projects or who are not able to explain why 
they want to use other tools and mechanisms and which user problems 
they really want to solve.


Most of these people are not active anymore or unfinished solutions 
are put into the codebase  which is another reason why I am really 
careful when it comes to massive changes. I think the project needs 
good planning, a good migration path and constant support when those 
changes are decided to take place.


All in all, I do not feel such a great pain as you seem to feel but 
there is definetely much room for improvement, for sure.


I will try to give my views on the different topics inline. They are 
brief and need/deserve more in-depth preparation from my side which I 
cannot spare at the moment.


For further discussions I recommend to split those topics in different 
threads because they would become unreadable soon with more 
participants. Also writing up the outcome of the discussions and the 
further roadmap in the wiki might help.


Let's see how it works.

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 22.12.21 um 18:23 schrieb Taher Alkhateeb:

Problems

...
_1. Lack of Code Isolation_:It is unlikely to do anything substantial 
in OFBiz without touching the core repositories. Compare this with 
moqui or some other web frameworks like say Ruby-On-Rails or django 
and you will see that you can work independently of the development 
path in these frameworks. This makes upgrades quite painfulwith 
patches and manual interventions. Some in the community even 
introduced a whole patching framework in the past.


We do not have this experience, at least not as much as you seem to 
have. Customer projects are developed completely in plugins, using the 
framework and avoiding changes there. There ARE some changes tagged as 
mods but not too much to be a real pain during a vendor update. Some 
mods are also contributed back to OFBiz so these mods disappear during 
the next vendor import.


We are not directly using the original framework but rather use the 
original as an upstream branch for our own projects. This makes it 
easy to track changes and merge them into our codebase.


It would be helpful to have some specific examples on where you are 
having those painful changes.




_2. All or nothing:_In OFBiz, if you want to use the system, either 
take the whole thing or take nothing. What if I don't want any user 
interface for example, and just want to utilize the entities and 
services?


We are running projects which do not use the original user interface 
or are being headless / just REST interfaces. You are not forced to 
use the UI and you can switch off the web apps, do we really have a 
problem there?




_3. Limited Re-usability:_Because of the way current components are 
designed, it's difficult to take advantage of components in other 
components. Sharing artifacts is pretty much

OFBiz re-architecture thoughts

[Taher Alkhateeb]

 of effort. That's why I hesitated in starting this 
thread, but I thought maybe showing the tradeoffs would make it easier 
to weigh things out and decide on a direction to push.



 Pros

- Pretty much most of the above mentioned problems will be resolved.
- The framework would be resilient and future proof.
- We will have more options and capabilities in the future, it would be 
easier to incorporate new technologies as they emerge

- Development would go faster
- Technical Debt will be reduced


 Cons

- Huge (maybe too huge) upfront costs in time and effort to make the switch
- Extra effort needed to ensure a smooth upgrade path for existing users 
/ adopters / system integrators. A whole layer of code needs to be 
written to ensure the ability to upgrade without massive rewrites.

- Risk of failure, exhaustion, inability to push through to the end
- Inconvenience to those with existing systems / solutions


   Summary

Change is the only constant. Inability to adapt to the future means not 
surviving. I'm not confident what is the best change possible or at what 
pace, but I do know that lack of change is a death sentence to any 
project. Maybe it's time to reflect and think of where we'd like to go 
and this thread is sort of a brain-dump of possible ideas.


I look forward to hearing your thoughts.

Cheers,

Taher Alkhateeb


[1] Example mixed XML actions and groovy from moqui








<![CDATA[
try {

ec.service.sync().name(serviceRegister.serviceName).parameters(context).softValidate(true).disableAuthz().call()
if (ec.message.hasError()) return
} catch (Throwable t) {
ec.logger.log(300, "Error calling auto order payments service for 
SettlementTerm ${settlementTermId}", t)
}
]]>






[2] https://ci.apache.org/projects/ofbiz/site/trunk/javadocs/

Re: Logical dependency tree for ofbiz components OFBIZ-12309

[Taher Alkhateeb]

Hello,

I may be misunderstanding your point, but ofbiz is already broken down 
to sub-projects and the sub-projects are defined from the framework 
itself (check common.gradle). And it is possible to publish ofbiz parts 
separately, and also possible to isolate dependencies in each project 
and it is already done for some components. We also do already have a 
plugin mechanism that allows you to publish things separately.


Maybe there is little value now in working on Gradle beyond basic 
maintenance. The real hard-work that is probably badly needed is in 
breaking down the components themselves into layers that makes it easy 
to extend the framework at multiple levels. And to get rid of many 
things that piled up over the years. If you can get the system to work 
well at each of the below layers then extensibility might become an 
easier problem:


1. framework

2. data model -> framework

3. data-model services -> data -model

5. data-model UI -> data-model & data-model services

6. applications (I don't mean accounting, party, but rather a full 
application that utilizes the above layers)


7. plugins (pick and choose whatever layers needed)

My 2 cents.

Cheers,

Taher Alkhateeb

On 11/29/21 03:28, Eugen Stan wrote:

Hi,

I think I made some progress while reverse engineering how ofbiz is 
built and I decided to share this so on the issue 
https://issues.apache.org/jira/browse/OFBIZ-3500


My train of thought is to split the current setup first into 4 static 
gradle sub-projects:

* framework
* application
* themes
* plugins - we should add plugins dynamically first.

Each sub-project should have it's own dependencies {}, source-sets {} 
etc.


We can then depend these sub-projects in the main project.

Benefits we get from this change:
* we get closer to publish ofbiz parts as libraries .
* we get closer to smaller components - which are easier to maintain
* we get better dependency management - and closer into splitting the 
ofbiz monolith into smaller services



Please let me know how you feel about this.

Re: PartyRole usage in OFBiz

[Taher Alkhateeb]

Hello Everyone,

From my understanding, fromDate and thruDate are primarily used for 
historical record purposes. This is useful only if a context exists such 
as in relation to an Order, WorkEffort, Request or something like that.


The PartyRole entity on the other hand has a different purpose which I 
think is not context-bound. It is only used in other contexts to make 
sure that a certain party has access to a certain role so the context 
can be applied. We can say it's almost like a security entity and it 
serves many other entities but has no significant value on its own (e.g. 
I don't care when did we classify someone as customer, I care when was 
his / her first order)


Hence history in PartyRole does not seem to serve any logical purpose 
(unless I'm missing something) and perhaps would lead to higher 
complexity for no immediate realized value.


On 11/12/21 14:00, Michael Brohl wrote:

Hi Gil,

thanks for the summary and links to previous discussions and issues.

In my opinion, the conclusion is still valid and I agree to close the 
pending issues as "Won't do".


Thanks and best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 12.11.21 um 10:07 schrieb Gil Portenseigne:

Hello,

I'm starting a new thread to discuss with the community about an 
Improvement that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was 
conclude by a lazy consensus not to implement PartyRole lifespan into 
OFBiz.
Recently, this improvement was discussed again in Jira [3], and 
partly commited, before being reverted when big blocking side effect 
where discovered.

A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto 
PartyRole entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the 
community consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if 
we need to organize or if we need to close pending Jira with 
reference to this discussion ?


Thanks,
Gil
[1] https://issues.apache.org/jira/browse/OFBIZ-5959
[2] 
https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
[3] https://issues.apache.org/jira/browse/OFBIZ-5980 
(https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274)
[4] 
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

Re: Welcome Wiebke Pätzold as new committer!

[Taher Alkhateeb]

Congratulations!

Re: JFrog to shut down jcenter

[Taher Alkhateeb]

Hi Folks.

I need to stress something very important here. The problem is not at 
all future versions, the big problem is existing versions.


If you have a production system running and JFrog pulls the plug on May 
1st, you cannot run the server unless you have some existing gradle 
cache and you need to pass the offline flag to ignore the jcenter 
repository.


So any solution here is a painful one. Here are the solutions I can 
think of:


- create a mirror of jcenter that at least covers the requirements of 
older OFBiz versions. The problem here is that people who worked on 
older versions of trunk are going to hit a wall. It's also hard and 
costly to setup a mirrored repo.

- create a compressed archive of all cache artifacts for each major version.
- Inform users to make a backup copy of gradle cache archives if they 
are on an older version and encourage them to upgrade ASAP.
- create a patch file for each major release that alters dependencies to 
switch to mavenCentral. The patch would mostly affect build.gradle.
- Make commits directly to all release branches. However the problem 
here is that some people are running on old releases and cannot upgrade 
immediately due to merge conflicts and whatnot.


This is a very nasty move by JFrog, they hurt a lot of projects. Android 
depends on JCenter, React Native, OFBiz, and numerous other projects and 
libraries that go even beyond the java eco-system.


- Taher

On 2/6/21 1:30 PM, Jacques Le Roux wrote:

Hi Taher,

Yes, yesterday I moderated/accepted, I guess the same message you 
received, to the private ML. We received it in the private ML because 
we (PMC members) have a credential we use to upload Gradle wrappers 
version on Bintray:
https://cwiki.apache.org/confluence/display/OFBIZ/Load+new+gradle+wrapper+version+on+bintray 


So it's also a release concern...

I agree we should not procrastinate... Fortunately we have 2 months to 
decide and act...


We should try to use MavenCentral as much as possible, but IIRW maybe 
it will not be enough.


HTH

Jacques

Le 05/02/2021 à 22:04, Taher Alkhateeb a écrit :

Hello Everyone,

I received emails and checked resources [1] that seem to confirm 
JCenter from JFrog is going down and that the last day of operation 
for the repository is going to be May 1st 2021.


This is a big deal as many running instances will crash unless 
updated, so not only do future versions of OFBiz need to adapt, but 
also existing installations.


I'm not sure how to best handle this? Especially for production 
instances out there on older versions of OFBiz. Maybe one solution is 
to host the existing libraries in some temporary location or try to 
migrate them to MavenCentral ... Whatever is the solution I think we 
should make a fast move.


[1]

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter 


https://www.infoq.com/news/2021/02/jfrog-jcenter-bintray-closure

JFrog to shut down jcenter

[Taher Alkhateeb]

Hello Everyone,

I received emails and checked resources [1] that seem to confirm JCenter 
from JFrog is going down and that the last day of operation for the 
repository is going to be May 1st 2021.


This is a big deal as many running instances will crash unless updated, 
so not only do future versions of OFBiz need to adapt, but also existing 
installations.


I'm not sure how to best handle this? Especially for production 
instances out there on older versions of OFBiz. Maybe one solution is to 
host the existing libraries in some temporary location or try to migrate 
them to MavenCentral ... Whatever is the solution I think we should make 
a fast move.


[1]

https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter
https://www.infoq.com/news/2021/02/jfrog-jcenter-bintray-closure

Re: Have a README.TXT file in release package

[Taher Alkhateeb]

If I see two README files in a project, I would get confused. Conventions are 
usually that there is only one README, one LICENSE, one INSTALL and so on ...

Perhaps another approach is to slimdown the README file and refer to other 
documentation using links to the other resources. This way you can emphasize 
any point you want in the main README and leave the other less used 
documentation for elsewhere.


On Sunday, May 10, 2020 19:43 +03, Jacques Le Roux 
 wrote:
 Hi,

We often get questions from people not reading the basic documentation. Like 
not able to run Gradle because ignoring init-gradle-wrapper scripts.

I know there will always people not reading the documentation. But maybe, to 
prevent most obvious questions and tempting RTFM answers, we could add a
small README.TXT with basic information in OFBiz root.

It would ultimately refer to README.adoc. Also saying that README.adoc can be 
read with a text reader tool. And it's easy to follow
https://asciidoctor.org/docs/convert-documents/#converting-a-document-to-html

What do you think?

Jacques
 
 

Re: Clojure Repl for OFBiz - repl driven development

[Taher Alkhateeb]

Hello Eugen,

Q Are groovy scripts allowed access to all Java API (file io, network etc)?
A Yes groovy scripts can pretty much access all resources and Java APIs. But 
they are implemented in multiple places as different things (service 
implementations, events, or simply helper scripts)
 
Q Could you give me some examples as to why do you believe this is more 
important?
A First of all any contribution / work you do is a good work. I'm encouraging 
you in a certain direction but at the end it's your itch to scratch. The reason 
why I encourage the solution I propose is that you can build whatever you want 
on top of it, including your proposed APIs. I think the API layer is better 
implemented when clojure is part of the core.

Q Would you sponsor the inclusion of this component in OFBiz ?
A I didn't know there are sponsors for features. Damn it I should've asked for 
sponsoring all the stuff I put in :)
Joke aside, features are usually simply donated by willing developers for the 
benefit of everyone as enhancing the software comes back with added value to 
everyone including the original author. I think this is sort of the prominent 
way in which ASF projects generally thrive. The sponsoring is usually done as a 
code review / imporvement, guidance and collaboration.

In all cases, good luck with your work and initiative.

Cheers,

Taher Alkhateeb


On Wednesday, May 06, 2020 15:59 +03, Eugen Stan  wrote:
 Hi,

Please see my reply inline.

La 06.05.2020 14:21, Taher Alkhateeb a scris:
> For me I would forget about the services for a moment. I would focus my 
> attention on defining a container for the REPL [1]. Then I would try to 
> implement clojure as an engine implementation for the services. This involves 
> modifying a few XSD files and java files for parsing and also providing the 
> engine implementation [2]. You can look at the groovy engine as an example [3]

Interesting idea. I will look into it. It's a different direction than
my goal of providing an API on top of OFBiz but has potential by
bringing Clojure's features.

I don't know how easily it is to secure an embedded version of clojure
or if we need to.

Are groovy scripts allowed access to all Java API (file io, network etc)
? I'm asking because of security considerations.

> The ticky (and very useful) part would be to have the REPL with an open port 
> available all the time, and can intercept every single request and 
> investigate its contents. That would be a kickass feature IMHO.

I like your enthusiasm. Could you give me some examples as to why do you
believe this is more important?

Regarding the feature, it is doable but there is some work regarding
authentication and authorization. There is  [drawbridge] project forthat. I 
think an http2 or a WebSocket version should work perfect and
should not be that hard to build.

[drawbridge] https://github.com/nrepl/drawbridge .

> [1] 
> https://ci.apache.org/projects/ofbiz/site/javadocs/org/apache/ofbiz/base/container/ComponentContainer.html
> [2] 
> https://ci.apache.org/projects/ofbiz/site/javadocs/org/apache/ofbiz/service/engine/GenericEngine.html
> [3] 
> https://ci.apache.org/projects/ofbiz/site/javadocs/org/apache/ofbiz/service/engine/GroovyEngine.html

Thanks for the links. I checked them out. They are useful starting points.

Would you sponsor the inclusion of this component in OFBiz ?


Thanks,

> On Wednesday, May 06, 2020 09:42 +03, Eugen Stan  
> wrote:
>  Hello Taher,
>
> Thank you for the feedback.
> Yes, that is what I am doing at the moment. I had less than 48h of
> knowledge about ODBiz API so it was the best I could do.
>
> I believe even that can provide benefits since you have a way to call
> every service in a running OFBiz instance from code. It gives you access
> to data and the runtime behavior.
>
> It can also be used for doing operational work.
>
> You are talking about a more advanced integration and it might be
> worthwhile to do that when I know how.
>
> My short to medium term goal is to build an http API on top of OFBiz . I
> believe without an API I think the possibilities are quite limited.
>
> I have some of the pieces in place but this will take a bit of time and> 
> investigation in the inner workings of OFBiz. Mainly how to read the xml
> entity and service definitions so I can make something out of those.
>
> By the way, for building a POC API what are the first services I should> 
> target? The ones that are mostly used by end users or the ones that do
> not depend on few/no other services.
>
>
> Regards,
>
> Eugen
>
> La 04.05.2020 17:22, Taher Alkhateeb a scris:
>> Hello Eugen,
>>
>> Great initiative! Thank you for the work.
>>
>> I have a question about the implementation. It seems from reading your code 
>> [1] that you're essentially just passing the the c

Re: Clojure Repl for OFBiz - repl driven development

[Taher Alkhateeb]

For me I would forget about the services for a moment. I would focus my 
attention on defining a container for the REPL [1]. Then I would try to 
implement clojure as an engine implementation for the services. This involves 
modifying a few XSD files and java files for parsing and also providing the 
engine implementation [2]. You can look at the groovy engine as an example [3]

The ticky (and very useful) part would be to have the REPL with an open port 
available all the time, and can intercept every single request and investigate 
its contents. That would be a kickass feature IMHO.

[1] 
https://ci.apache.org/projects/ofbiz/site/javadocs/org/apache/ofbiz/base/container/ComponentContainer.html
[2] 
https://ci.apache.org/projects/ofbiz/site/javadocs/org/apache/ofbiz/service/engine/GenericEngine.html
[3] 
https://ci.apache.org/projects/ofbiz/site/javadocs/org/apache/ofbiz/service/engine/GroovyEngine.html


On Wednesday, May 06, 2020 09:42 +03, Eugen Stan  wrote:
 Hello Taher,

Thank you for the feedback.
Yes, that is what I am doing at the moment. I had less than 48h of
knowledge about ODBiz API so it was the best I could do.

I believe even that can provide benefits since you have a way to call
every service in a running OFBiz instance from code. It gives you access
to data and the runtime behavior.

It can also be used for doing operational work.

You are talking about a more advanced integration and it might be
worthwhile to do that when I know how.

My short to medium term goal is to build an http API on top of OFBiz . I
believe without an API I think the possibilities are quite limited.

I have some of the pieces in place but this will take a bit of time and
investigation in the inner workings of OFBiz. Mainly how to read the xml
entity and service definitions so I can make something out of those.

By the way, for building a POC API what are the first services I should
target? The ones that are mostly used by end users or the ones that do
not depend on few/no other services.


Regards,

Eugen

La 04.05.2020 17:22, Taher Alkhateeb a scris:
> Hello Eugen,
>
> Great initiative! Thank you for the work.
>
> I have a question about the implementation. It seems from reading your code 
> [1] that you're essentially just passing the the context object to NREPL and 
> getting it working from there.
>
> Although the idea works, you're not getting anything beyond just running the 
> clojure REPL against the context. Why not design NREPL to be part of the 
> framework from the start. Implement it as a container and fire it up and 
> fully integrate with the framework. This way not only will you be able to run 
> the REPL (which is great) but you will also have the ability to introspect 
> every request / response and even add clojure as another implementation 
> engine.
>
> [1] 
> https://github.com/netdava/ofbiz-clojure-repl/blob/master/src/main/java/com/netdava/ofbiz/clojure/ClojureReplService.java
>
>
> On Monday, May 04, 2020 03:34 +03, Eugen Stan  wrote:
>  Hello,
>
> I just wrote a simple component for that adds clojure nRepl support for> 
> OFBiz. This allows people to use clojure to interact with OFBiz and do
> all sorts of nice things.
>
> It also opens a lot of possibilities for improving the developer
> experience.
>
> Please let me know what you think about this. It would be great to have> it 
> upstream (not in this form).
>
> I would love some help on how to properly develop a plugin. I have a lot
> of ideas on how to use clojure for more productivity and interactive
> development.
>
>
> You can see a demo of the plugin here  https://youtu.be/XXxJDZRzu_E .
>
> You can see the plugin source code here:
> https://github.com/netdava/ofbiz-clojure-repl .
>
> I believe the OFBiz development experience can look like this:
>
> * https://www.youtube.com/watch?v=ZkJX9ciI5aM=1824s
> * https://www.youtube.com/watch?v=Bs44qdAX5yo
>
>
> ## About ofbiz-clojure-repl plugin
>
> Uses [jvm-breakglass](https://github.com/matlux/jvm-breakglass) library> to 
> start an instance of nRepl inside Apache OFBiz.
> Once we have a Repl inside OFBiz we can connect to it from our favorite> 
> cloujure IDE and interact with it.
>
> Some things that can be done:
>
> * Interact with a running OFBiz instance from a shell like environment
> (Repl is better then the shell)
> * Prototype functionality and experiment with instant feedback - search> for 
> Repl driven development videos
> * Develop services for OFBiz in clojure and leverage all it's wonderfull
> properties
> * Use data visualization tools like
> [Proto-repl](https://github.com/jasongilman/proto-repl) to explore and
> do interactive Business Inteligence.
> * Desing reports using real data using something like
> [Gorilla-repl](http://gorilla-repl.org/)
&

Re: [POC Vue.js] Cleaning - Screen - rest - compound

[Taher Alkhateeb]

Hi Olivier,

I think to engage the community you need to expose the code more than just 
sharing a hosted server. Perhaps posting a repo on github might do the trick. 
Either way, good luck with the initiative.


On Monday, May 04, 2020 18:02 +03, Olivier Heintz  wrote:
 Hi Community,

Some news about the POC Vue.js,
since last mails (4 month ago), some works have been done, and compared to what 
was planned as the next step, we have taken a step backwards, in order to
1. take into account the remarks of the community
2. make better progress after :-)

* First of all, the cleaning of the POCs (not yet finished), after the first 
few months where we tried a few solutions, we worked to eliminate all the
non-validated tests or workaround solutions used.
At the JsonRenderer level we try to clearly show what is used and functional, 
and which attributes / tags not yet implemented, The idea is to have
less but correctly tested.

* Some simplifications in screen "json representation", ex: field title 
attributes are now in the field attribute, to be able to have a better
presentation (title integrated in field)
** all generic template use vuetify
** a more beautiful contactMech screenlet

* All can be done with "standard" screens, (without portal - portlet), 
 with a get (so without parameters) all the examples +
=> with a post (parameters and _method="GET") examples selected by options
| Example/create | get | create form
| Example/edit/{exampleId} | get | edit form and data for the id sent
| Example/show/{exampleId} | get | show form and data for the id sent
| Example/summary/{exampleId} | get | summary form and data for the id sent
| Example/data/{exampleId} | get | just data for the id sent
| Example/change | post | create a example
| Example/change/{exampleId} | put (via post)| update example with exampleId
| Example/change/{exampleId} | delete | delete example with exampleId

each time a request need multiple parameters, a POST is used with the _method 
param to which http method should used

* Compound file by Resource name, to have more modularity and reusability 
(organize by functional Resource), all widget data are in the same file
controller / menu / form / widget

It's still a POC, so it's still a support to discuss about technical or GUI 
point.
All current choices can be challenged to find the correct or strong solution 
and quickly see the result on a user point of view.

To view/test, there are two testing environments :
* ofbiz-selenium[1] used by the continuous integration process and some debug 
process, so vue.js application is build with dev option
With this env. it's possible to see a lot of information about data store and 
component with browser vuejs tools, but application is more slow
* demo-vuejs[2], the standard POC demo build, more stable and build with prod 
option.

on menu, "Examples management" is done with Screen et Rest-uri
and "Examples management (MgmtPageFrontJs)" is done with portal-portlet

[1] 
https://ofbiz-selenium.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg
[2] 
https://demo-vuejs.ofbizextra.org/examplefjs/control/main#/screen/Example/mgmtPg

We work on a agile mode, so most of the parts are prototype which should be 
reviewed and/or optimize before finalized

For the next step: we're back on schedule (the POC-UI)
https://ofbizextra.org/ofbizextra_adocs/docs/asciidoc/developer-manual.html#_modular_and_generic_ui
 

Re: Clojure Repl for OFBiz - repl driven development

[Taher Alkhateeb]

Hello Eugen,

Great initiative! Thank you for the work.

I have a question about the implementation. It seems from reading your code [1] 
that you're essentially just passing the the context object to NREPL and 
getting it working from there.

Although the idea works, you're not getting anything beyond just running the 
clojure REPL against the context. Why not design NREPL to be part of the 
framework from the start. Implement it as a container and fire it up and fully 
integrate with the framework. This way not only will you be able to run the 
REPL (which is great) but you will also have the ability to introspect every 
request / response and even add clojure as another implementation engine.

[1] 
https://github.com/netdava/ofbiz-clojure-repl/blob/master/src/main/java/com/netdava/ofbiz/clojure/ClojureReplService.java


On Monday, May 04, 2020 03:34 +03, Eugen Stan  wrote:
 Hello,

I just wrote a simple component for that adds clojure nRepl support for
OFBiz. This allows people to use clojure to interact with OFBiz and do
all sorts of nice things.

It also opens a lot of possibilities for improving the developer
experience.

Please let me know what you think about this. It would be great to have
it upstream (not in this form).

I would love some help on how to properly develop a plugin. I have a lot
of ideas on how to use clojure for more productivity and interactive
development.


You can see a demo of the plugin here  https://youtu.be/XXxJDZRzu_E .

You can see the plugin source code here:
https://github.com/netdava/ofbiz-clojure-repl .

I believe the OFBiz development experience can look like this:

* https://www.youtube.com/watch?v=ZkJX9ciI5aM=1824s
* https://www.youtube.com/watch?v=Bs44qdAX5yo


## About ofbiz-clojure-repl plugin

Uses [jvm-breakglass](https://github.com/matlux/jvm-breakglass) library
to start an instance of nRepl inside Apache OFBiz.
Once we have a Repl inside OFBiz we can connect to it from our favorite
cloujure IDE and interact with it.

Some things that can be done:

* Interact with a running OFBiz instance from a shell like environment
(Repl is better then the shell)
* Prototype functionality and experiment with instant feedback - search
for Repl driven development videos
* Develop services for OFBiz in clojure and leverage all it's wonderfull
properties
* Use data visualization tools like
[Proto-repl](https://github.com/jasongilman/proto-repl) to explore and
do interactive Business Inteligence.
* Desing reports using real data using something like
[Gorilla-repl](http://gorilla-repl.org/)


I've heard that Clojure was fun to write code with and I did not believe
it until I tried it.

Let's have fun developing on OFBiz,

--
Eugen Stan
+40720 898 747 / netdava.com
 
 

Re: Welcome Rishi Solanki as new PMC member

[Taher Alkhateeb]

Congratulations Rishi


On Wednesday, April 29, 2020 08:21 +03, Mridul Pathak 
 wrote:
 Congratulations Rishi!!

Thanks
Mridul Pathak

> On 28-Apr-2020, at 7:52 PM, Jacopo Cappellato  
> wrote:
>
> The OFBiz PMC has invited Rishi Solanki to become member of the committee
> and we are glad to announce that he has accepted the nomination.
>
> On behalf of the OFBiz PMC, welcome on board!
 
 

Re: Welcome to Vasmatkar as new committer!

[Taher Alkhateeb]

Congratulations!


On Wednesday, April 22, 2020 12:37 +03, Jacques Le Roux 
 wrote:
 The OFBiz PMC has invited Girish to become a new committer and we are pleased  
to announce that he has accepted.

Girish is part of the community for near 2 years and has proposed several smart 
propositions notably related to security and GraphQL, but not only.

Please join me in welcoming and congratulating Girish.

Jacques

 
 

Re: Welcome James Young as new PMC member

[Taher Alkhateeb]

congratulations


On Wednesday, April 22, 2020 11:36 +03, Jacques Le Roux 
 wrote:
 The OFBiz PMC has invited James Young to become member of the committee and we 
are glad to announce that he has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board!
 
 

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.03

[Taher Alkhateeb]

+1


On Tuesday, April 21, 2020 13:02 +03, Pawan Verma  wrote:
 +1
--
Thanks & Regards
Pawan Verma
ofbiz.apache.org


On Tue, Apr 21, 2020 at 3:08 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> +1, works for me on Windows 7
>
> verify-ofbiz-release.sh OK
>
> init-gradle-wrapper OK
>
> Both UIs (back and front ends) OK
>
> Integration tests OK (no errors at all after a second test, had in 1st)
>
> Jacques
>
> Le 21/04/2020 à 10:35, Deepak Dixit a écrit :
> > +1
> >
> >
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > ofbiz.apache.org
> >
> >
> > On Tue, Apr 21, 2020 at 1:22 PM Michael Brohl 
> > wrote:
> >
> >> +1
> >>
> >> ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.03 
> >> ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.03.zip
> >> sha check of file: apache-ofbiz-17.12.03.zip
> >> Using sha file: apache-ofbiz-17.12.03.zip.sha512
> >> apache-ofbiz-17.12.03.zip: E4E49620 661FA7B0 9BA4610E DC63B0CE E849DC3A
> >> 91536311 595ECD8C 5246C2F5 5751A339 9FFCCFFE 02F06CBD DEF8A589 06483077
> >> AC172AFC E945DC8B 0BE20AEC
> >> apache-ofbiz-17.12.03.zip: E4E49620 661FA7B0 9BA4610E DC63B0CE E849DC3A
> >> 91536311 595ECD8C 5246C2F5 5751A339 9FFCCFFE 02F06CBD DEF8A589 06483077
> >> AC172AFC E945DC8B 0BE20AEC
> >> sha checksum OK
> >>
> >> GPG verification output
> >> gpg: Signature made Mon Apr 20 10:42:14 2020 CEST using RSA key ID
> 847AF9E0
> >> gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY)
> >> " [ultimate]
> >>
> >> ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.03/apache-ofbiz-17.12.03
> >>  ./gradle/init-gradle-wrapper.sh
> >> === Prepare operation ===
> >>
> /Users/mbrohl/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.03/apache-ofbiz-17.12.03/gradle/wrapper/gradle-wrapper.jar
> >>
> >> not found, we download it
> >> === Download gradle-wrapper.jar ===
> >> === Download gradle-wrapper.properties ===
> >> === Control downloaded files ===
> >> gradle/wrapper/gradle-wrapper.jar: OK
> >> gradle/wrapper/gradle-wrapper.properties: OK
> >> gradlew: OK
> >>
> >> ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.03/apache-ofbiz-17.12.03
> >>  ./gradlew loadAll testIntegration
> >>
> >> ...
> >> BUILD SUCCESSFUL
> >>
> >>
> >> Thanks,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 20.04.20 um 11:03 schrieb Jacopo Cappellato:
> >>> This is the vote thread to release a new bug fix release for the
> >>> release17.12 branch. This new release, "Apache OFBiz 17.12.03" will
> >>> supersede the previous release from the same branch.
> >>>
> >>> The release files can be downloaded from here:
> >>> https://dist.apache.org/repos/dist/dev/ofbiz/
> >>> and are:
> >>> * apache-ofbiz-17.12.03.zip
> >>> * KEYS: text file with keys
> >>> * apache-ofbiz-17.12.03.zip.asc: the detached signature file
> >>> * apache-ofbiz-17.12.03.zip.sha512: checksum file
> >>>
> >>> Please download and test the zip file and its signatures (for
> >> instructions
> >>> on testing the signatures see
> >> http://www.apache.org/info/verification.html).
> >>> Vote:
> >>> [ +1] release as Apache OFBiz 17.12.03
> >>> [ -1] do not release
> >>>
> >>> This vote will be open for 5 days.
> >>>
> >>> For more details about this process please refer to
> >>> http://www.apache.org/foundation/voting.html
> >>>
> >>> Best Regards,
> >>>
> >>> Jacopo
> >>>
> >>
>
 

Re: [VOTE] [RESULT] Apache OFBiz 17.12.02

[Taher Alkhateeb]

I would recommend options 2/3. There is no need for a vote, just a release with 
a note about 17.12.0 and archive it


On Monday, April 20, 2020 10:21 +03, Jacopo Cappellato 
 wrote:
 ouch, thank you for catching that Deepak.
Here is my proposal:
1) I prepare the new release files for 17.12.03 and we vote on it
2) we leave 17.12.02 in our records and archive (because we have formally
published it, so it is a release) but we do not announce it
3) we will announce the new 17.12.03 release only, with a notice about the
17.12.02 gap.

What do you think?

Jacopo


On Mon, Apr 20, 2020 at 8:04 AM Deepak Dixit  wrote:

> Hi Jacopo,
> I think we need to do vote release once again,
> Blocker: https://issues.apache.org/jira/browse/OFBIZ-11601
>
> We need to
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Fri, Apr 17, 2020 at 12:34 PM Jacopo Cappellato <
> jacopo.cappell...@gmail.com> wrote:
>
> > The vote to release Apache OFBiz 17.12.02 is successful with 11 positive
> > (i.e. "+1") votes, of which 5 binding votes.
> >
> > Thank you everyone for the participation. I am going to proceed with the
> > next steps and we will be announcing the release in a couple of days.
> >
> > Best regards,
> >
> > Jacopo
> >
> > On Fri, Apr 10, 2020 at 12:05 PM Jacopo Cappellato <
> > jacopo.cappell...@gmail.com> wrote:
> >
> > > This is the vote thread to release a new bug fix release for the
> > > release17.12 branch. This new release, "Apache OFBiz 17.12.02" will
> > > supersede the previous release from the same branch.
> > >
> > > The release files can be downloaded from here:
> > > https://dist.apache.org/repos/dist/dev/ofbiz/
> > > and are:
> > > * apache-ofbiz-17.12.02.zip
> > > * KEYS: text file with keys
> > > * apache-ofbiz-17.12.02.zip.asc: the detached signature file
> > > * apache-ofbiz-17.12.02.zip.sha512: checksum file
> > >
> > > Please download and test the zip file and its signatures (for
> > instructions
> > > on testing the signatures see
> > http://www.apache.org/info/verification.html
> > > ).
> > >
> > > Vote:
> > > [ +1] release as Apache OFBiz 17.12.02
> > > [ -1] do not release
> > >
> > > This vote will be open for 5 days.
> > >
> > > For more details about this process please refer to
> > > http://www.apache.org/foundation/voting.html
> > >
> > > Best Regards,
> > >
> > > Jacopo
> > >
> >
>
 

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.02

[Taher Alkhateeb]

+1


On Monday, April 13, 2020 16:10 +03, Michael Brohl  
wrote:
 +1

~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.02 
../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.02.zip
sha check of file: apache-ofbiz-17.12.02.zip
Using sha file: apache-ofbiz-17.12.02.zip.sha512
apache-ofbiz-17.12.02.zip: 0F0179E8 6C3972A7 E5825405 0D87FA15 FEA6D842
BF317151 CE6042D2 34EA88E4 B6D5AD89 B62776BE EA17331F 711CCFE8 F4084E56
813CA0EF DC599283 E97B94BD
apache-ofbiz-17.12.02.zip: 0F0179E8 6C3972A7 E5825405 0D87FA15 FEA6D842
BF317151 CE6042D2 34EA88E4 B6D5AD89 B62776BE EA17331F 711CCFE8 F4084E56
813CA0EF DC599283 E97B94BD
sha checksum OK

GPG verification output
gpg: Signature made Fri Apr 10 11:45:17 2020 CEST using RSA key ID 847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY)
" [ultimate]

~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.02/apache-ofbiz-17.12.02  
./gradle/init-gradle-wrapper.sh
 === Prepare operation ===
/Users/mbrohl/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.02/apache-ofbiz-17.12.02/gradle/wrapper/gradle-wrapper.jar
not found, we download it
 === Download gradle-wrapper.jar ===
 === Download gradle-wrapper.properties ===
 === Control downloaded files ===
gradle/wrapper/gradle-wrapper.jar: OK
gradle/wrapper/gradle-wrapper.properties: OK
gradlew: OK

~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.02/apache-ofbiz-17.12.02  
./gradlew loadAll testIntegration

BUILD SUCCESSFUL

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 10.04.20 um 12:05 schrieb Jacopo Cappellato:
> This is the vote thread to release a new bug fix release for the
> release17.12 branch. This new release, "Apache OFBiz 17.12.02" will
> supersede the previous release from the same branch.
>
> The release files can be downloaded from here:
> https://dist.apache.org/repos/dist/dev/ofbiz/
> and are:
> * apache-ofbiz-17.12.02.zip
> * KEYS: text file with keys
> * apache-ofbiz-17.12.02.zip.asc: the detached signature file
> * apache-ofbiz-17.12.02.zip.sha512: checksum file
>
> Please download and test the zip file and its signatures (for instructions
> on testing the signatures see http://www.apache.org/info/verification.html).
>
> Vote:
> [ +1] release as Apache OFBiz 17.12.02
> [ -1] do not release
>
> This vote will be open for 5 days.
>
> For more details about this process please refer to
> http://www.apache.org/foundation/voting.html
>
> Best Regards,
>
> Jacopo
>
 
 

Re: BI Component Improvements

[Taher Alkhateeb]

Hello and thank you for your work. A few review notes:

- It would be great if you can briefly explain the new dimensions and
what you're triangulating on
- Can you elaborate on the purpose for having time dimensions values
for every minute? What is the data being aggregated here?
- There is some stramge logic in DimensionServices.groovy where
essentially you're clearing the input map (effectively passing an
empty map) to a bunch of service calls. Why are you using the same map
which you keep clearing from one call to the next? Are those services
not supposed to take input parameters? If so, why not pass an empty
map instead of this logic?
- There are some files with windows EOL characters. Need to run
something like dos2unix on those
- There are also tab characters around the code base

May I also suggest breaking this work into smaller chunks to start
incorporating into the code base to make it easier to review and
integrate the work. Perhaps you can isolate the work for each new
dimension in a branch / patch / etc

On Mon, Mar 16, 2020 at 6:09 PM Pierre Smits  wrote:
>
> Following up on recent migrations from minilang to groovy regarding the
> functions in the BI component I have made various enhancements to the
> component, enabling the project to move from a Proof of Concept state to
> something that is starting to provide our (potential) adopters some
> additional arguments to use (or select) our product.
>
> BI (or Business Intelligence) is a key factor to measure the success of a
> company (and its underlying departments), whether it is regarding sales,
> purchases, inventory ageing, or employer utilisation (e.g. in
> project-oriented service orgs). BI often works against a Data Warehouse,
> which is fed from the transactions RDBMS using (more or less) sophisticated
> ETL solutions. Often these ETL tools are quite expensive to operate, and
> require - when talking about development - quite the skill set.
> Unfortunately, Small and Medium Enterprises often lack the budget to deploy
> such tools and services and make due with exports from the transaction
> RDBMS and the use of MS Excel to do their Business Intelligence analysis.
>
> Given the unique feature set of OFBiz catering to the needs of small and
> medium enterprises, an improved BI component can deliver on an easy (and
> fairly cheap) means to have a DataWarehouse populated, and - through the
> population of dimension and fact tables - get data elements combined into
> star schemas for in-component or external (through external tools as Excel)
> analysis.
>
> In order to bring the BI component up to a level of usability in a company,
> I have implemented following changes (in a feature branch in my repo)
>
>- added and updated dimension tables
>   - CustomerDimension, OrganisationDimension (internal organisations),
>   and SupplierDimension
>   - supporting: DateDimension, TimeDimension, CountryDimension,
>   CurrencyDimension
>- updated fact tables to work with the added and improved dimension
>tables
>   - SalesInvoiceItemFact
>   - InventoryItemFact
>- updated star schemas to bring data elements from dimension and fact
>tables together
>   - SalesInvoiceItemStarSchema
>   - InventoryItemStarSchema
>- made the Report Builder functionality (screens and such) mode user
>friendly, by applying ajax functionality,  to have selection of the star
>schema, the field selection and the resulting overview in one page
>
> While there are still a lot of areas (BI-wise) that can be improved, such
> as:
>
>- SalesOrderItemFact and SalesOrderItemStarSchema - to enhance the
>analysis regarding sales,
>- Purchase (Spend) analysis functionality,
>- Utilisation analysis function (assets, employee),
>
> enhancements currently available improve the BI component significantly.
>
> Rather than working alone and see contributions go stale, I would like to
> collaborate more via a feature branch in the official plugins repository.
> As you can see in JIRA, there already quite a number of improvement tickets
> (seeu [1]), and I have already many (up to the point of ready for
> incorporation into the plugins code base)  in progress. The improvements
> are currently available in my public fork on Github (see [2]). I invite you
> to fork or clone and test-drive the enhancements.
>
> And if you have any suggestions, questions, and/or remarks, feel free to
> post them here (or directly to me), or as a comment to the master ticket
> (for general aspects) or to a particular sub-task.
>
>1. https://issues.apache.org/jira/browse/OFBIZ-11414
>2.
>https://github.com/PierreSmits/plugins/tree/OFBIZ-11414_BI-Improvements
>
>
> Looking forward.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Trafodion , Vice President*
> *Apache Directory 

Re: Dockerfiles for OFBiz

[Taher Alkhateeb]

Sounds great. I would recommend a combination of docker +
docker-compose + scripts + environment files to get everything fully
automated and also parameterized

On Fri, Mar 13, 2020 at 10:00 PM Michael Brohl  wrote:
>
> Hi Taher,
>
> Am 13.03.20 um 18:21 schrieb Taher Alkhateeb:
> > Hello Michael,
> >
> > 1. Absolutely from my side. Deployment becomes drastically simpler
> > 2. Which version of what?
> > 3. Hmm, I'm not sure of the purpose / benefit of having that. No one
> > just "deploys" OFBiz without customization. And even if so, if you
> > have comfy scripts in the code base, then that would be enough.
> >
> > Ideally, the way I'd go for it is to have a Dockerfile at the top
> > level directory and a docker folder to hold everything else.
> > Deployment can be targeted to multiple different environments  such
> > that even the development environment can depend on a database engine
> > like postgres by default.
>
> I have an idea how to solve this with a more sophisticated Docker file
> together with the config mechanism we use here at ecomify. Describing
> this for a proposal to contribute is still on my agenda.
>
> This would allow configuring everything and build a docker image by just
> copying a a single (or multiple staged) files during the build process.
> This would allow to configure every single property used in OFBiz
> (database, ports, security etc.) and build targeted images from that.
>
> Let's see when I find time...
>
> Michael
>
>
>

Re: Dockerfiles for OFBiz

[Taher Alkhateeb]

Hello Michael,

1. Absolutely from my side. Deployment becomes drastically simpler
2. Which version of what?
3. Hmm, I'm not sure of the purpose / benefit of having that. No one
just "deploys" OFBiz without customization. And even if so, if you
have comfy scripts in the code base, then that would be enough.

Ideally, the way I'd go for it is to have a Dockerfile at the top
level directory and a docker folder to hold everything else.
Deployment can be targeted to multiple different environments  such
that even the development environment can depend on a database engine
like postgres by default.

On Fri, Mar 13, 2020 at 8:06 PM Michael Brohl  wrote:
>
> Hi everyone,
>
> please have a look at the solutions provided in
> https://issues.apache.org/jira/browse/OFBIZ-10407.
>
> The main questions for the mailing list:
>
> 1. do we want to add and maintain Docker files in our codebase?
>
> 2. if yes, which version should we use?
>
> 3. if yes, additionally: would it be a good idea to place OFBiz Docker
> images on docker hub and maintain them?
>
> What do you think?
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>

Re: OFBiz-Github-MultiBranch » trunk - Build # 6 - Still Failing

[Taher Alkhateeb]

The Apache OFBiz CI infrastructure is the responsibility of infra@ and
the OFBiz team. I would not touch the CI code for lucene for example
if I was contributing with them without commit access., and having
access to the repository due to engagement in other projects should
not violate that fact. This is just basic courtesy.

On Tue, Mar 10, 2020 at 10:46 AM Pierre Smits  wrote:
>
> Michael, all,
>
> Moving forward with automated recommit vetting of PRs and patch files in
> JIRA tickets I am working on a Proof of Concept.
>
> In order to conclude this PoC scenarios need to be established and tested.
> In order to get to acceptable results these scenarios need to be executed
> against repositories as close to the official repositories (albeit with
> some additions/modifications not in the official base repository) and in
> the CI infrastructure of the ASF.
> Given the unique nature of ASF's CI architecture/infrastructure and
> services (including integration with ASF's Github and JIRA setups) anything
> deviating from this would affect results and therefore conclusions and
> recommendations. Furthermore copying/mimicking such a setup to work with is
> not feasible.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Proud* *contributor** of* Apache OFBiz  since
> 2008 (without privileges)
>
> *Apache Trafodion , Vice President*
> *Apache Directory , PMC Member*
> Apache Incubator , committer
> Apache Steve , committer
>
>
> On Mon, Mar 9, 2020 at 11:51 AM Michael Brohl 
> wrote:
>
> > Hi Pierre,
> >
> > can you explain why a push to your private repository triggers a build
> > on the official ASF infrastructure builds.apache.org?
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 09.03.20 um 09:15 schrieb Pierre Smits:
> > > Good morning Michael, all,
> > >
> > > My apologies for the inconvenience caused.
> > >
> > > A minor glitch in a push to my GitHub fork of the official repository
> > > caused this to happen.
> > >
> > >
> > > Met vriendelijke groet,
> > >
> > > Pierre Smits
> > > *Proud* *contributor** of* Apache OFBiz 
> > since
> > > 2008 (without privileges)
> > >
> > >
> > > On Mon, Mar 9, 2020 at 7:19 AM Michael Brohl 
> > > wrote:
> > >
> > >> Good morning,
> > >>
> > >> I've got this mailed to my apache mail account. Does anyone know what
> > >> this is?
> > >>
> > >> Seems to be a misconfigured Jenkins but I am not aware that we have this
> > >> running.
> > >>
> > >> I also see that it is partly working against a repository from Pierre so
> > >> it might be initiated by him?
> > >>
> > >> Regards,
> > >>
> > >> Michael Brohl
> > >>
> > >> ecomify GmbH - www.ecomify.de
> > >>
> > >>
> > >>
> > >>  Weitergeleitete Nachricht 
> > >> Betreff:OFBiz-Github-MultiBranch » trunk - Build # 6 - Still
> > >> Failing
> > >> Datum:  Mon, 9 Mar 2020 02:34:47 + (UTC)
> > >> Von:Apache Jenkins Server 
> > >> An: mbr...@apache.org
> > >>
> > >>
> > >>
> > >> For more details, see
> > >> https://builds.apache.org/job/OFBiz-Github-MultiBranch/job/trunk/6/
> > >>
> > >> [Mar 8, 2020 12:13:05 AM] (mbrohl) Improved: Upgrade Freemarker from
> > >> 2.3.29 to 2.3.30.
> > >>
> > >>
> > >> HTML Version:
> > >>
> > >>
> > https://builds.apache.org/job/OFBiz-Github-MultiBranch/job/trunk/6/Yetus_20Report/
> > >>
> > >> ERROR: File 'out/brief.txt' does not exist
> > >>
> > >>
> >
> >

Re: [VOTE] [RELEASE] Apache OFBiz 17.12.01 (full version), vote #3

[Taher Alkhateeb]

+1

On Fri, Feb 28, 2020, 12:37 PM Gil Portenseigne 
wrote:

> +1
>
> On Thu, Feb 27, 2020 at 06:09:34PM +0100, Michael Brohl wrote:
> > +1
> >
> > ~/Projects/apache-ofbiz/dist-apache-ofbiz-17.12.01 
> > ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-17.12.01.zip
> > sha check of file: apache-ofbiz-17.12.01.zip
> > Using sha file: apache-ofbiz-17.12.01.zip.sha512
> > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> > 5B8A5358 36208F4A D26DEB40
> > apache-ofbiz-17.12.01.zip: 3E92DF0F 92E71B33 0FEF2B7C FBEE2E51 88F98E3B
> > 76614824 2A40C84F 922DDB08 B0760B76 8667EAF4 E35F2939 44757CD7 658C9A72
> > 5B8A5358 36208F4A D26DEB40
> > sha checksum OK
> >
> > GPG verification output
> > gpg: Signature made Thu Feb 27 10:36:12 2020 CET using RSA key ID
> 847AF9E0
> > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY)
> > " [ultimate]
> >
> >
> > ./gradlew loadAll testIntegration
> >
> > ...
> >
> > :testIntegration
> >
> > BUILD SUCCESSFUL
> >
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 27.02.20 um 10:49 schrieb Jacopo Cappellato:
> > > This is the vote thread (3nd attempt) to release "Apache OFBiz
> 17.12.01":
> > > this is the first release, containing the framework, applications and
> all
> > > the plugins from the 17.12 release branches.
> > >
> > > The release files can be downloaded from here:
> > > https://dist.apache.org/repos/dist/dev/ofbiz/
> > >
> > > and are:
> > > * apache-ofbiz-17.12.01.zip
> > > * KEYS: text file with keys
> > > * apache-ofbiz-17.12.01.zip.asc: the detached signature file
> > > * apache-ofbiz-17.12.01.zip.sha512: checksum file
> > >
> > > Please download the zip file, build and test OFBiz and verify the
> signature
> > > and checksum (for instructions on testing the signatures see
> > > http://www.apache.org/info/verification.html).
> > >
> > > Vote:
> > >
> > > [ +1] release as Apache OFBiz 17.12.01
> > > [ -1] do not release
> > >
> > > This vote will be open for 5 days.
> > > For more details about this process please read
> > > http://www.apache.org/foundation/voting.html
> > >
> >
>
>
>

Re: Allow shutdown in Gradle without building the project (Allow shutdown in Gradle without building the project)

[Taher Alkhateeb]

Hello Mathieu,

I did not know that it was you who changed it nor am I implying
"sneaking" anything. I'm just analyzing the reason for the dependency
on classes sticking in the code base and did not check who / why out
of laziness. I appreciate your understanding and hope you don't
personalize issues.

On another note, I don't have a strong opinion on whatever direction
people prefer, I'm just happy we figured out the root cause and any
solution is fine by me.

Cheers,

On Wed, Feb 26, 2020 at 9:14 PM Mathieu Lirzin
 wrote:
>
> Mathieu Lirzin  writes:
>
> > If people want to be in charge of the compilation and execution
> > lifecycles, they are free to use Gradle to build an artifact and run
> > OFBiz outside of their build tool like in the following example:
> >
> > ```
> > $ ./gradlew jar
> > $ java -jar build/libs/ofbiz &
> > $ java -jar build/libs/ofbiz --shutDown
> > ```
>
> Oups, I forgot the “.jar” extension and misspelled --shutdown. Here are
> the correct commands.
>
> ```
> $ ./gradlew jar
> $ java -jar build/libs/ofbiz.jar &
> $ java -jar build/libs/ofbiz.jar --shutdown
> ```
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Allow shutdown in Gradle without building the project (Allow shutdown in Gradle without building the project)

[Taher Alkhateeb]

or another approach is again to have another if condition to say if
the task is shutdown, then depend on the jar, else depend on the
classes although that would be messy IMO and might increase the
technical debt due to inconsistencies

On Wed, Feb 26, 2020 at 6:36 PM Taher Alkhateeb
 wrote:
>
> I think I understand the reason why this is happening. Someone changed
> the implementation of createOfbizCommandTask to depend on the classes
> directly instead of depending on the generated Jar. I'm not sure why
> but I personally do not prefer this approach.
>
> The solution is to revert to the original design where the classpath =
> files(thejarfilehere) and change dependsOn from classes to build
>
> On Wed, Feb 26, 2020 at 6:18 PM Michael Brohl  
> wrote:
> >
> > Hi Taher,
> >
> > the configuration in your patch is executed correctly, I logged it with
> > this code enhancement:
> >
> >  if (!(taskName ==~ /^ofbiz.*(--shutdown|-d).*/)) {
> >  println taskName + ' dependsOn classes'
> >  dependsOn classes
> >  } else {
> >  println taskName + ' NO dependsOn classes'
> >  }
> >
> > ./gradlew "ofbiz --shutdown" --dry-run
> >
> >  > Configure project :
> > executeLoadAdminUser dependsOn classes
> > executeLoadTenant dependsOn classes
> > loadTenantOnMasterTenantDb dependsOn classes
> > loadTenantData dependsOn classes
> > loadTenantAdminUserLogin dependsOn classes
> > ofbiz --shutdown NO dependsOn classes
> > :compileJava SKIPPED
> > :compileGroovy SKIPPED
> > :processResources SKIPPED
> > :classes SKIPPED
> > :ofbiz --shutdown SKIPPED
> >
> > but it still seems to execute the whole task dependencies:
> >
> >  > Task :compileJava UP-TO-DATE
> >  > Task :compileGroovy UP-TO-DATE
> >  > Task :processResources UP-TO-DATE
> >  > Task :classes UP-TO-DATE
> >
> >  > Task :ofbiz --shutdown
> >
> >
> > The plugin https://github.com/dorongold/gradle-task-tree shows the
> > following task dependencies:
> >
> > :ofbiz --shutdown
> > \--- :classes
> >   +--- :compileGroovy
> >   |\--- :compileJava
> >   +--- :compileJava
> >   \--- :processResources
> >
> >
> > Not sure why...
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 26.02.20 um 13:53 schrieb Taher Alkhateeb:
> > > Hi Michael,
> > >
> > > I could be mistaken, but I think perhaps you're trying to remove the
> > > dependency during the execution phase instead of the configuration
> > > phase?
> > >
> > > Would a patch like the below not work?
> > >
> > > diff --git a/build.gradle b/build.gradle
> > > index e5bfb3e9c9..96dcb53a01 100644
> > > --- a/build.gradle
> > > +++ b/build.gradle
> > > @@ -976,11 +976,14 @@ tasks.addRule('Pattern: ofbizBackground
> > > : Execute OFBiz startup comman
> > >*  */
> > >
> > >   def createOfbizCommandTask(taskName, arguments) {
> > > -task(type: JavaExec, dependsOn: classes, taskName) {
> > > +task(taskName, type: JavaExec) {
> > >   jvmArgs(application.applicationDefaultJvmArgs)
> > >   classpath = sourceSets.main.runtimeClasspath
> > >   main = application.mainClassName
> > >   args arguments
> > > +if (!(taskName ==~ /^ofbiz.*(--shutdown|-d).*/)) {
> > > +dependsOn classes
> > > +}
> > >   if (taskName ==~ /^ofbiz.*(--test|-t).*/) {
> > >   finalizedBy(createTestReports)
> > >   }
> > >
> > > On Tue, Feb 25, 2020 at 8:48 PM Michael Brohl  
> > > wrote:
> > >> Hi Taher,
> > >>
> > >> thanks for your feedback!
> > >>
> > >> It seems that removing a dependency from a task is deprecated and should
> > >> not be used:
> > >>
> > >> "Do not remove a task dependency from a Task instance. This behaviour
> > >> has been deprecated and is scheduled to be removed in Gradle 6.0."
> > >>
> > >> Given this depracation, do you think there is another way to reduce the
> > >> code added?
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> Am 25.02.20 um 12:14 schrieb Taher Alkhateeb:
> > >>> Hi Michael,
> > >>&

Re: Allow shutdown in Gradle without building the project (Allow shutdown in Gradle without building the project)

[Taher Alkhateeb]

I think I understand the reason why this is happening. Someone changed
the implementation of createOfbizCommandTask to depend on the classes
directly instead of depending on the generated Jar. I'm not sure why
but I personally do not prefer this approach.

The solution is to revert to the original design where the classpath =
files(thejarfilehere) and change dependsOn from classes to build

On Wed, Feb 26, 2020 at 6:18 PM Michael Brohl  wrote:
>
> Hi Taher,
>
> the configuration in your patch is executed correctly, I logged it with
> this code enhancement:
>
>  if (!(taskName ==~ /^ofbiz.*(--shutdown|-d).*/)) {
>  println taskName + ' dependsOn classes'
>  dependsOn classes
>  } else {
>  println taskName + ' NO dependsOn classes'
>  }
>
> ./gradlew "ofbiz --shutdown" --dry-run
>
>  > Configure project :
> executeLoadAdminUser dependsOn classes
> executeLoadTenant dependsOn classes
> loadTenantOnMasterTenantDb dependsOn classes
> loadTenantData dependsOn classes
> loadTenantAdminUserLogin dependsOn classes
> ofbiz --shutdown NO dependsOn classes
> :compileJava SKIPPED
> :compileGroovy SKIPPED
> :processResources SKIPPED
> :classes SKIPPED
> :ofbiz --shutdown SKIPPED
>
> but it still seems to execute the whole task dependencies:
>
>  > Task :compileJava UP-TO-DATE
>  > Task :compileGroovy UP-TO-DATE
>  > Task :processResources UP-TO-DATE
>  > Task :classes UP-TO-DATE
>
>  > Task :ofbiz --shutdown
>
>
> The plugin https://github.com/dorongold/gradle-task-tree shows the
> following task dependencies:
>
> :ofbiz --shutdown
> \--- :classes
>   +--- :compileGroovy
>   |    \--- :compileJava
>   +--- :compileJava
>   \--- :processResources
>
>
> Not sure why...
>
> Thanks,
>
> Michael
>
>
> Am 26.02.20 um 13:53 schrieb Taher Alkhateeb:
> > Hi Michael,
> >
> > I could be mistaken, but I think perhaps you're trying to remove the
> > dependency during the execution phase instead of the configuration
> > phase?
> >
> > Would a patch like the below not work?
> >
> > diff --git a/build.gradle b/build.gradle
> > index e5bfb3e9c9..96dcb53a01 100644
> > --- a/build.gradle
> > +++ b/build.gradle
> > @@ -976,11 +976,14 @@ tasks.addRule('Pattern: ofbizBackground
> > : Execute OFBiz startup comman
> >*  */
> >
> >   def createOfbizCommandTask(taskName, arguments) {
> > -task(type: JavaExec, dependsOn: classes, taskName) {
> > +task(taskName, type: JavaExec) {
> >   jvmArgs(application.applicationDefaultJvmArgs)
> >   classpath = sourceSets.main.runtimeClasspath
> >   main = application.mainClassName
> >   args arguments
> > +if (!(taskName ==~ /^ofbiz.*(--shutdown|-d).*/)) {
> > +dependsOn classes
> > +}
> >   if (taskName ==~ /^ofbiz.*(--test|-t).*/) {
> >   finalizedBy(createTestReports)
> >   }
> >
> > On Tue, Feb 25, 2020 at 8:48 PM Michael Brohl  
> > wrote:
> >> Hi Taher,
> >>
> >> thanks for your feedback!
> >>
> >> It seems that removing a dependency from a task is deprecated and should
> >> not be used:
> >>
> >> "Do not remove a task dependency from a Task instance. This behaviour
> >> has been deprecated and is scheduled to be removed in Gradle 6.0."
> >>
> >> Given this depracation, do you think there is another way to reduce the
> >> code added?
> >>
> >> Thanks!
> >>
> >>
> >> Am 25.02.20 um 12:14 schrieb Taher Alkhateeb:
> >>> Hi Michael,
> >>>
> >>> The idea is fine but I think we can improve the implementation. All that
> >>> you need is to remove the dependsOn declaration if it is a shutdown 
> >>> command
> >>> which would probably result in less code than in the proposed patch.
> >>>
> >>> Cheers
> >>>
> >>> On Tue, Feb 25, 2020, 1:32 PM Michael Brohl 
> >>> wrote:
> >>>
> >>>> Oops, just realized I already asked in
> >>>>
> >>>> https://lists.apache.org/thread.html/rf88ce5eb1a3842471ddb8239bb5f08b71c107c4b0d3863b3c13e54fe%40%3Cdev.ofbiz.apache.org%3E
> >>>>
> >>>> Better respond there, thanks!
> >>>>
> >>>> Michael
> >>>>
> >>>>
> >>>> Am 25.02.20 um 11:29 schrieb Michael Brohl:
> >>>>> Hi devs,
> >>>>>
> >>>>> any objections to get this into the codebase (and backporting to
> >>>>> 17.12./18.12)?
> >>>>>
> >>>>> See https://issues.apache.org/jira/browse/OFBIZ-10168
> >>>>>
> >>>>> Thanks for your feedback,
> >>>>>
> >>>>> Michael Brohl
> >>>>>
> >>>>> ecomify GmbH - www.ecomify.de
> >>>>>
> >>>>>
> >>>>>
>

Re: New Online Help, need some ideas

[Taher Alkhateeb]

Hello Olivier,

Without digging into much detail, I can say that it's a good idea to
switch the online help system to asciidoc.

The current structure of asciidoc templates is designed to be a full
manual document. To link up different pages to different sections, you
need to break the documentation down to smaller files and then combine
them. This way you can have both the "big" manual and the "per screen"
help section.

Also, gradle might not be enough for online help. A more robust
solution could involve integrating asciidoc at the framework level to
dynamically generate help. So this is another idea to consider.

On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz  wrote:
>
> Hi all,
>
> Currently OFBiz Online help work with docbook files with html generation done 
> by a ftl template.
>  Link between screen and file to show is done with some content associated 
> with key-word
>
> Decision has been done to no more used docbook format but now use asciidoc 
> format.
>
> User-manual.adoc should be the new reference for user help. How to use it for 
> online help ?
>
> I think it's important that online help is link to a internal help (which can 
> be modified) not to a Apache-OFBiz-website-Help
> but this point of view can be discuss.
>
> To be able to have OFBiz internal help, three points should be solved :
> 1) with asciidoc we have multiple documentations, it seem important to have a 
> "website" to be able to access easily all the doc.
>how to "encapsulate" each html documentation generated in a "website"
> 2) generation doc process put html and pdf files in build directory, how it's 
> possible to access them from ofbiz
> 3) For online help it's necessary to be able to create link between screen 
> and html anchor.
>In documentation generate from asciidoc, all title can be used.
>How to to say this screen should go to this documentation at this title.
>
> I suppose content application, can help to solve this points.
> I need some help from OFBiz-Content experts.
>
> For point (1) I'm using jBake but maybe it's possible to do something similar 
> with templating in Content
> Who has some idea ?
>
> For point (2) I suppose it's a "gradle configuration" and "content 
> configuration"
> Who has some idea ?
>
> For point (3) the more simple solution is to add 1 (or 2) field in context 
> which contain help_title,(help_documentation) and
> so it will be simple to build the correct help link
>

Re: Allow shutdown in Gradle without building the project (Allow shutdown in Gradle without building the project)

[Taher Alkhateeb]

Hi Michael,

I could be mistaken, but I think perhaps you're trying to remove the
dependency during the execution phase instead of the configuration
phase?

Would a patch like the below not work?

diff --git a/build.gradle b/build.gradle
index e5bfb3e9c9..96dcb53a01 100644
--- a/build.gradle
+++ b/build.gradle
@@ -976,11 +976,14 @@ tasks.addRule('Pattern: ofbizBackground
: Execute OFBiz startup comman
  *  */

 def createOfbizCommandTask(taskName, arguments) {
-task(type: JavaExec, dependsOn: classes, taskName) {
+task(taskName, type: JavaExec) {
 jvmArgs(application.applicationDefaultJvmArgs)
 classpath = sourceSets.main.runtimeClasspath
 main = application.mainClassName
 args arguments
+if (!(taskName ==~ /^ofbiz.*(--shutdown|-d).*/)) {
+dependsOn classes
+}
 if (taskName ==~ /^ofbiz.*(--test|-t).*/) {
 finalizedBy(createTestReports)
 }

On Tue, Feb 25, 2020 at 8:48 PM Michael Brohl  wrote:
>
> Hi Taher,
>
> thanks for your feedback!
>
> It seems that removing a dependency from a task is deprecated and should
> not be used:
>
> "Do not remove a task dependency from a Task instance. This behaviour
> has been deprecated and is scheduled to be removed in Gradle 6.0."
>
> Given this depracation, do you think there is another way to reduce the
> code added?
>
> Thanks!
>
>
> Am 25.02.20 um 12:14 schrieb Taher Alkhateeb:
> > Hi Michael,
> >
> > The idea is fine but I think we can improve the implementation. All that
> > you need is to remove the dependsOn declaration if it is a shutdown command
> > which would probably result in less code than in the proposed patch.
> >
> > Cheers
> >
> > On Tue, Feb 25, 2020, 1:32 PM Michael Brohl 
> > wrote:
> >
> >> Oops, just realized I already asked in
> >>
> >> https://lists.apache.org/thread.html/rf88ce5eb1a3842471ddb8239bb5f08b71c107c4b0d3863b3c13e54fe%40%3Cdev.ofbiz.apache.org%3E
> >>
> >> Better respond there, thanks!
> >>
> >> Michael
> >>
> >>
> >> Am 25.02.20 um 11:29 schrieb Michael Brohl:
> >>> Hi devs,
> >>>
> >>> any objections to get this into the codebase (and backporting to
> >>> 17.12./18.12)?
> >>>
> >>> See https://issues.apache.org/jira/browse/OFBIZ-10168
> >>>
> >>> Thanks for your feedback,
> >>>
> >>> Michael Brohl
> >>>
> >>> ecomify GmbH - www.ecomify.de
> >>>
> >>>
> >>>
> >>
>

Re: Allow shutdown in Gradle without building the project (Allow shutdown in Gradle without building the project)

[Taher Alkhateeb]

Hi Michael,

The idea is fine but I think we can improve the implementation. All that
you need is to remove the dependsOn declaration if it is a shutdown command
which would probably result in less code than in the proposed patch.

Cheers

On Tue, Feb 25, 2020, 1:32 PM Michael Brohl 
wrote:

> Oops, just realized I already asked in
>
> https://lists.apache.org/thread.html/rf88ce5eb1a3842471ddb8239bb5f08b71c107c4b0d3863b3c13e54fe%40%3Cdev.ofbiz.apache.org%3E
>
> Better respond there, thanks!
>
> Michael
>
>
> Am 25.02.20 um 11:29 schrieb Michael Brohl:
> > Hi devs,
> >
> > any objections to get this into the codebase (and backporting to
> > 17.12./18.12)?
> >
> > See https://issues.apache.org/jira/browse/OFBIZ-10168
> >
> > Thanks for your feedback,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> >
>
>

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 

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: [VOTE] [RELEASE] Apache OFBiz 16.11.07

[Taher Alkhateeb]

+1

On Tue, Feb 4, 2020 at 9:23 AM Deepak Nigam  wrote:
>
> +1
>
> Thanks & Regards
> --
> Deepak Nigam
>
> On Thu, Jan 30, 2020 at 7:43 PM Jacopo Cappellato <
> jacopo.cappell...@gmail.com> wrote:
>
> >  This is the vote thread to release a new bug fix release for the
> > release16.11 branch. This new release, "Apache OFBiz 16.11.07" will
> > supersede all the previous releases from the same branch.
> > Please consider that this may be the last release in the 16.11 series and
> > in the future releases will be published from the newer series only.
> >
> > The release files can be downloaded from here:
> > https://dist.apache.org/repos/dist/dev/ofbiz/
> >
> > and are:
> > * apache-ofbiz-16.11.07.zip
> > * KEYS: text file with keys
> > * apache-ofbiz-16.11.07.zip.asc: the detached signature file
> > * apache-ofbiz-16.11.07.zip.sha512: checksum file
> >
> > Please download and test the zip file and its signatures (for instructions
> > on testing the signatures see http://www.apache.org/info/verification.html
> > ).
> >
> > Vote:
> > [ +1] release as Apache OFBiz 16.11.07
> > [ -1] do not release
> >
> > This vote will be open for 5 days.
> > For more details about this process refer to
> > http://www.apache.org/foundation/voting.html
> >
> > Kind Regards,
> >
> > Jacopo
> >

Re: Migrate all docbook files to asciidoc ?

[Taher Alkhateeb]

It sounds like a good initiative to me. I would be careful about pure
converting without reviewing. Some of the documentation is quite outdated
and so maybe convert + review is a reasonable approach.

On Tue, Jan 28, 2020, 9:52 PM Olivier Heintz  wrote:

> Hi everyone,
>
> I wanted to make progress on the OFBiz documentation, and thus continue
> the existing tasks, at first the one on the accounting component.
>
> It's a bit painful to have to work between the old files in docbook and
> the new ones in asciidoc.
> For me it would be simpler to migrate all the docbooks first, and then
> rework the result.
>
> Does this process bother anyone ?
>
> Olivier
>
>
>
>
>
>
>

Re: [VOTE] Do not release R17 and directly publish R18 instead.

[Taher Alkhateeb]

-1

I'm not sure what is the necessity for skipping a branch.

On Fri, Jan 24, 2020, 4:19 PM Gil Portenseigne 
wrote:

> +1
>
> On Fri, Jan 24, 2020 at 11:27:15AM +0100, Jacques Le Roux wrote:
> > Hi,
> >
> > R16 is now an old distribution and has almost reached its end of
> support. We
> > can soon expect a last release but we need to think about the next to be
> > released package
> >
> > Some would prefer to release R17 before releasing R18, some would prefer
> to bypass R17 release and directly publish R18 instead.
> >
> > Vote:
> > [ +1] Do not release R17 and directly publish R18 instead.
> > [ -1]  Release R17 before releasing R18
> >
> > We had already 3 months to discuss without reaching a consensus, so this
> vote will be only open for a week.
> >
> > Note that it's not a formal vote to release R17 or R18, as that is
> another process documented at
> >
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> >
> > Thank you for your attention
> >
> > Jacques
> >
>

Re: What is OFBiz public API?

[Taher Alkhateeb]

Hello Mathieu and all,

Thank you for this interesting and engaging thread. Before I make my
input, I would like to note that Apache OFBiz and its community from
my experience is welcoming of change and improvements. In my earlier
days in the project we went through massive changes to the system that
made tremendous differences including:

- Moving from ant to gradle
- introducing unit tests
- Redesigning the startup logic and possible flags
- Changing the distribution mechanism (remote dependencies instead of
inside the code base)
- Changing folder structures in components
- many others

While working on all the above, I never faced major obstacles. But the
reason that I did not is I always made a complete, well written
argument about what I'm trying to implement. I always ask for a pair
of eyes to look at my code and give me feedback, and I always engage
with the community. In my opinion, disagreements made me do some of
the best pieces of code because I learn and grow from other people's
input.

The boundary of a public API does not necessarily need to be agreed
upon RIGHT NOW!. I don't think the best way to move forward is to
enforce agreeing on what we should done before hand.

Instead of setting rules and boundaries on what should and should not
be done, I recommend instead collaborating on all work, one piece at a
time. As I said, I've worked on very large issues indeed and had no
problem working it with others and making it eventually to the code
base.

So whenever there is a disagreement or differing points of view, why
not start a new thread specific to that topic and work it out.
Everybody wants the best for the project, and communication is the key
to moving us forward IMHO.

My 2 cents

Cheers,
Taher Alkhateeb

On Sun, Jan 12, 2020 at 4:56 AM Mathieu Lirzin
 wrote:
>
> Hello Paul, Jacopo and Olivier,
>
> Paul Foxworthy  writes:
>
> > Being clearer about it would be a good thing.  There is still the
> > potential that a change that seems simple and straightforward to one
> > contributor is disruptive to others. And if it truly is disruptive, we
> > should collaborate on what comes next. Are the benefits worth the
> > disruption? Should there be some sort of deprecation, phase-out or
> > backwards compatibility option? I can't clearly define what "big" is,
> > but I know it when I see it.
>
> IMO “We Should collaborate” is wishful thinking, because in practice
> what happens most of the time is that only one person is doing the work
> that he/she is proposing and the rest is doing +1 or -1. When someone
> objects it often just means more burden for the person doing the work
> because the person objecting will just add extra requirements.
>
> Don't get me wrong, I find that situation normal because nobody is doing
> a better job than someone who is motivated about it. Moreover people
> with “ideas” but which are not responsible for implementing those tend
> to advocate less practicable ideas.
>
> It is just that I don't think we should expect the community to work
> collectively better than the norm by relying on collaboration to be able
> to get things done.
>
> Jacopo Cappellato  writes:
>
> > There will always be a tension between guaranteeing backward compatibility
> > for the existing user base and the efforts to maintain our codebase,
> > enhance/refactor/innovate it.
> > Considering the peculiar nature of OFBiz, I don't think that trying to
> > define the areas that are part of the "public API" and then guarantee
> > backward compatibility only for them, will resolve this tension. In fact
> > there may be cases in which the "public API" should change in a
> > non-backward compatible way such as:
> > * the cost of maintaining a backward compatible feature is too high for our
> > community (or there is not enough interest in the active community in
> > maintaining it)
> > * the change is required to fix a flaw or a security vulnerability
> > * some fundamental (and important to the community) architectural change
> > may not be backward compatible
> > * etc...
>
> Specifying a public API does not mean necessarily preserving it. It just
> mean knowing when a border is being crossed:
>
> - The developer changing something that is part of that API
> - The user using an undocumented mechanism that happen to be here.
>
> > Apart from this, even the definition of "public API" for OFBiz is
> > troublesome considering for example that potentially any OFBiz service can
> > be used by "client" code and as a consequence in theory our community
> > should never change the behavior (or remove) a service.
>
> Ideally yes because the notion of services is about providing something
> to others.  To red

Welcome to Olivier Heintz as new committer!

[Taher Alkhateeb]

The OFBiz PMC has invited Olivier Heintz to become a new committer and
we are happy to announce that he has accepted this role.

Some of the reasons for inviting Olivier Heintz include:

- He is invested in the OFBiz project and has been a member for many years
- He is taking an initiative towards improving the UI part of the system
- He has functional experience in various areas of the framework
- He enjoys working with the community and collaborating with others

Please join me in welcoming and congratulating Olivier!

Cheers,
Taher Alkhateeb

Re: How to deploy Microservice developed using Spring boot to ofbiz

[Taher Alkhateeb]

I think this thread belongs to u...@ofbiz.apache.org and might be better
served there.

On Wed, Jan 15, 2020, 4:58 AM Victor Hernadez 
wrote:

> Hi Jakob,
>
> I see now, thanks for clarification, if you are going to continue working
> on
> Spring 2 / REST compatible efforts I would be interested in participate on
> them.
>
> Kind Regards,
> Victor
>
>
>
> --
> Sent from: http://ofbiz.135035.n4.nabble.com/OFBiz-Dev-f165671.html
>

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

[Taher Alkhateeb]

Also, if there are disagreements on a direction among members then it is
usually the case that a -1 from a binding vote requires a revert and
starting a discussion. Then we can either have consensus, lazy consensus or
the issue is shut down.

I'm saying what should be done, just laying out the standard rules we
usually run by.

On Thu, Dec 19, 2019, 1:59 PM Taher Alkhateeb 
wrote:

> May I suggest inquiring from the community on whether this feature is
> important to them? Pehaps on user@? This way maybe we can have a more
> informed decision on whether to adopt this change.
>
> On Thu, Dec 19, 2019, 10:13 AM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
>> Le 18/12/2019 à 21:09, Jacques Le Roux a écrit :
>> > Hi Samuel, All,
>> >
>> > Le 18/12/2019 à 14:00, Samuel Trégouët a écrit : Le 18/12/2019 à 12:09,
>> Jacques Le Roux a écrit :
>> >>>> Mathieu asks Michael to provide  an "explanation regarding why it
>> matters in production environments to be able to patch" component-load.xml
>> files
>> >> yes we are still waiting for your answer Michael ;) In my opinion we
>> >> cannot go ahead in this discussion without your answer, without your
>> >> need about component-load.xml: are you trying to avoid loading a
>> >> particular framework component? do you patch a framework component and
>> >> need another one to be loaded first to make your patch works? ...
>> >
>> > That's an interesting point indeed. Have you your own framework
>> component/s Michael ?
>>
>> Note: I include applications components here
>>
>>
>> Jacques
>>
>

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

[Taher Alkhateeb]

May I suggest inquiring from the community on whether this feature is
important to them? Pehaps on user@? This way maybe we can have a more
informed decision on whether to adopt this change.

On Thu, Dec 19, 2019, 10:13 AM Jacques Le Roux 
wrote:

> Le 18/12/2019 à 21:09, Jacques Le Roux a écrit :
> > Hi Samuel, All,
> >
> > Le 18/12/2019 à 14:00, Samuel Trégouët a écrit : Le 18/12/2019 à 12:09,
> Jacques Le Roux a écrit :
>  Mathieu asks Michael to provide  an "explanation regarding why it
> matters in production environments to be able to patch" component-load.xml
> files
> >> yes we are still waiting for your answer Michael ;) In my opinion we
> >> cannot go ahead in this discussion without your answer, without your
> >> need about component-load.xml: are you trying to avoid loading a
> >> particular framework component? do you patch a framework component and
> >> need another one to be loaded first to make your patch works? ...
> >
> > That's an interesting point indeed. Have you your own framework
> component/s Michael ?
>
> Note: I include applications components here
>
>
> Jacques
>

Re: [DISCUSSION] Make Back-Office screens dynamic

[Taher Alkhateeb]

Hello Gil,

Great research on the subject, thank you for sharing.

I could be wrong here, but at a first glance it seems you want to
essentially create a tag " wrote:
>
> Chapter One: How to manage the updating area
>
> Hello,
>
> After different discussions already listed by Taher [1-9], Leila,
> Nicolas and me tried another approach.
> Instead of analyzing how to implement different functionalities offered
> by modern js framework, we did analyzed how end user use, in general,
> OFBiz and where we, as an integrator, waste more time to create a
> screen.
>
> To help on this huge task, we set some basic rules :
> * Work only on screens supported by the theme, defined mainly in xml
> * This concerns only screens used for back-office applications,
>   oriented to manage data
> * A developer does not have to know all of js language (or other)
>   but can concentrate on the process/view with the end user to
>   manage a data
>
>
> After a first brainstorm, we have identified three major cases :
> 1. Navigation and data display
> 2. View event result (data modification, calculation service, ...)
> 3. Update an area to refresh data (after data modification)
>
> Case 1 and 2 are easy and currently managed by OFBiz (and missing stuff
> will be simple to add), we concentrate our attention on case 3.
>
> To update an area, we follow this pattern
>
> 1. We start from a context that display different information
>
> 2. That context display a submit form, use a link or another
> mechanism to call an OFBiz event
>
> 3. After receiving the event return, we refresh the desired area
> with parameters that can come from origin context or from event
> return.
>
>
> Currently with the screen widget, we can use within a form the element
> ``.
>
> The problem with this use, is that your form needs to know the origin
> context, to identify what are the areas to update and what are the
> target to use for the refresh.
>
> So your form needs to know where it comes from, what information need to
> be updated in OFBiz and what will be updated after.
>
> This increases complexity for the developer in the way that current form
> implementation manages :
>   * the data and target to communicate with the server
>   * the behaviour (refreshment) to apply when receiving server response.
>
> Example :
>  target="createPartyRole">
> 
> ...
>area-target="PartyRolesCustom">
> 
> 
> 
>
> If you want to reuse the same form, you need to create another screen
> with a new form to redefine the on-event-update-area (for instance
> create a PartyRole).
>
> We change the thinking, because since it is the starting context that
> better knows itself, it's the starting context that will realize the
> updating operation. The starting context is the screen/menu that call
> this form.
>
> In general a form is contained in a screen (classic) that is called
> through a link. So we move the idea on this link :
>
> 
>  from-field="customerParty.partyId"/>
> 
>  from-field="customerParty.partyId"/>
> 
> 
>
> And the form :
>
> 
>
>...
> 
>
> With this logic you can define a new usage of createPartyRole
> without redefining a form just :
>
> 
>  from-field="partyRelationship.partyIdTo"/>
> 
>  from-field="partyRelationship.partyIdTo"/>
>  value="IRL_LIKE"/>
> 
> 
>
> After some use we identified as pro and con feedback :
> * updating form is reusable and contains only code related to the
>   form action
> * link being in origin context, the developer knows where he is and
>   where he wants to go
> * Menu oriented management offers a quick vision on how the screen will 
> works
>
> * update-area seems to be a too technical name
> * we always have to manage area to update manually
> * too many areas to update become a headache and not only for the 
> developer
>
> We did not explain how we have done it, to try to focus the discussion
> on the principles.
>
> It would be a pleasure to have some criticism of this approach, and we
> would try, in a second chapter to introduce other concepts that appeared
> after the screens were made more dynamic and others to lowers the
> identified cons.
>
> Thanks,
>
> The Néréide Team
>
> [1] https://s.apache.org/rf94
> [2] https://s.apache.org/g5zr
> [3] https://s.apache.org/XpBO
> [4] https://s.apache.org/YIL1
> [5] https://s.apache.org/836D
> [6] https://s.apache.org/DhyB
> [7] https://s.apache.org/Lv9E
> [8] https://s.apache.org/zKIo
> [9] https://s.apache.org/D6jx
>

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

[Taher Alkhateeb]

Hello Mathieu, Michael, All

I was involved in some of the biggest changes in the framework
(gradle, unit tests, start component, core framework, etc ...) and
every time it involved a good deep discussion on the mailing list
trying to reach consensus before implementation.

So I recommend always treading carefully when doing larger changes and
getting others involved. Sometimes people surprise you with better or
simpler solutions if you give them the opportunity to express their
opinion.

Now regarding completely replacing the component-load.xml with
depends-on, I'm not sure this makes much sense at the core framework
level for a few reasons:

- First I don't think this issue is linear. It is possible for
example, to speed up the startup time of the system by running things
in parallel where possible
- Also, the multi-threaded portion of the system (some of it using the
executor framework in java.util.concurrent) needs to be studied
carefully to see how the loading sequence is best optimized
- Finally, I'm just not convinced of either approach (depends-on or
container-load) for core framework functionality. We need a better
solution that handles the core quite differently (without the need for
a component concept).

So a better refactoring IMHO on the core level involves an
architecture that does not necessarily comply with the component
concept, and we can proceed with the original plan of further breaking
down the system into a core deplorable framework, core components, and
plugins.

On Sun, Dec 8, 2019 at 5:30 PM Michael Brohl  wrote:
>
> Hi Mathieu,
>
> I was in fact asking for the discussion and review process to the
> changes already introduced and committed in the mentioned Jira.
>
> It's a good approach to let fellow committers review such work before it
> gets committed to the codebase.
>
> This change will affect existing productive installations and should not
> be made without proper documentation and clear instructions for the user
> on how to migrate their installation to the new mechanism.
>
> To me it is not clear what we are gaining with this change.  We are
> removing one tag which is used and stable for years and introduce
> another one which was not used before. Users are forced to migrate their
> installations if they had custom modifications.
>
> I did not look deeply into the changes yet but it looks strange that a
> component like "product" or "order" only depends on "humanres". In fact,
> they have more dependencies like "party". Given that "depends-on" really
> means what it says and has a real difference to the component-load.xml
> approach.
>
> The component-load.xml mechanism clearly shows the loading order of the
> components which is an advantage over the cluttered information of the
> depends-on mechanism. You will have to analyze every ofbiz-component to
> see what's going on.
>
> IMO these examples show that is in fact worth a discussion and should
> not be a lone decision of a single committer.
>
> I would like to see this being reverted and proposed for discussion and
> review before this is going to be introduced into the codebase.
>
> Thanks you,
>
> Michael
>
>
> Am 08.12.19 um 13:13 schrieb Mathieu Lirzin:
>
> > Hello Michael,
> >
> > Michael Brohl  writes:
> >
> >> can you please point me to the discussion where this important change
> >> was discussed before it was introduced?
> >>
> >> I only find the Jira https://issues.apache.org/jira/browse/OFBIZ-11296
> >> which was closed only hours after it was created.
> > If you speak about the usage of  in the “framework” and
> > “applications” directory, See my response in OFBIZ-11296 regarding what
> > has actually changed.
> >
> > Regarding what I am proposing in this email, I did not open a Jira yet
> > and did not commit anything removing the “component-load.xml” feature.
> >
> > Sorry if I was not explicit enough about the fact that this is a
> > discussion not a report of things already changed.
> >
> >> Am 08.12.19 um 02:34 schrieb Mathieu Lirzin:
> >> [...]
> >>
> >>> In order to simplify things which helps the endeavour towards
> >>> transforming OFBiz in an extensible JVM based library, I would like to
> >>> remove such configuration point and hard-code the list of component
> >>> directories inside the code.
> >>>
> >>> [...]
> >>>
> >>> If nobody step-up in a week, I will go ahead.
> >>>
> >>> Thanks.
> >>>
>

Re: Welcome Gil Portenseigne and Mathieu Lirzin as new PMC members

[Taher Alkhateeb]

Congratulations gentlemen!

On Tue, Dec 3, 2019 at 6:33 PM Rishi Solanki  wrote:
>
> Congratulations Gil and Mathieu!!
>
> Best regards,
> --
> Rishi Solanki
> *CTO, Mindpath Technology*
> Intelligent Solutions
> cell: +91-98932-87847
>
> On Tue, Dec 3, 2019 at 7:43 PM Swapnil M Mane 
> wrote:
>
> > Many congratulations Gil and Mathieu!! :)
> >
> > Best regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> >
> >
> > On Tue, Dec 3, 2019 at 3:56 PM Jacopo Cappellato <
> > jacopo.cappell...@gmail.com> wrote:
> >
> > > The OFBiz PMC has invited Gil Portenseigne and Mathieu Lirzin to become
> > > members of the committee and we are glad to announce that they have
> > > accepted the nomination.
> > >
> > > On behalf of the OFBiz PMC, welcome on board!
> > >
> >

Re: Change commit message template?

[Taher Alkhateeb]

Hi Jacques,

I'm not sure what convention over configuration has to do with what
you're saying :)

Anyway, it makes sense. Most GIT editors consider the first line to be
subject, and third line onward is the body of the message. So perhaps
we can move the (OFBIZ-) to the end of the first line or maybe
make it the last line in the body or something like that.


On Sun, Nov 17, 2019 at 7:05 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> While working in Eclipse with Git (ie using eGit which is not my favourite 
> tool). I found a warning telling me:
>
> "Second line should be empty to separate commit message header from body"
>
> It was argued that it's only a convention[1], but don't we prefer "convention 
> over configuration"?
>
> I suggest to change our template according to the convention, ie separate the 
> title from the issue number or put the number on the same line (split
> sometimes) than the title
>
> [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=475845
>
> What do you think?
>
> Jacques
>

Re: Git repo for each ofbiz plugin

[Taher Alkhateeb]

Hello Mathieu,

If you study the plugin system implementation, you will notice that it
is based on maven for dependency resolution, which already takes care
of many of the details you mentioned, especially with respect to
dependency management. The way it is designed avoids reinventing the
wheel by using something that already solves the problem. Now granted
it is incomplete, that doesn't mean it's a bad idea, It's just
incomplete. And part of the complexity by the way, is deficiencies in
the architecture of OFBiz itself. The concept of a "component" needs
to improve and better utilization of the subproject architecture would
greatly improve this.

I don't have a problem with removing whatever you feel like removing.
I only propose a more thorough assessment before shrugging it off as
"too complex" or "poor". Dependency management by design is complex.
And using Jar libraries or any other solution will not make it easier,
quite the opposite. It does not matter whether it lives in the build
system or somewhere else (although I personally prefer the build
system). The important thing is how to architect it to solve your
problems.

Anyway, I have no further input on this, please feel free to discuss
this with the rest of the folks and reach whatever decision you feel
like heading to.

On Tue, Nov 12, 2019 at 1:26 PM Mathieu Lirzin
 wrote:
>
> Taher Alkhateeb  writes:
>
> > I'm not sure I see this issue with the same perspective. Having the
> > build system automatically download (and run some code) for a certain
> > component is a convenience especially for the community components.
> > Things are even easier when using git as there are many plugins to
> > support that. I'm also not sure what is "poor" about that
>
> I agree that having the “build system” downloading things automatically
> is convenient and desirable. But IMO what we should mean by a build
> system is Gradle (or Maven, SBT, Leinigen, ...) not “OFBiz pretending to
> be a build system ontop of Gradle”.
>
> Let me clarify what I mean by “OFBiz build system doing things poorly”.
> There are a lot a important features that people would expect from a
> tool downloading/installing plugins (a.k.a package manager) that are
> missing like for example:
>
> - having a manifest listing the installed plugins with their version
> - removing unneeded dependencies when uninstalling a plugin,
> - having a way to upgrade an install plugin (automatically upgrading its 
> dependencies if needed).
> - Ensuring that the plugin is compatible with the framework version
> - Resolve plugin version mismatchs consistently (A depends on B-0.1 and C 
> depends on B-0.2 => use B-0.2)
> - Having a shared cache for already downloaded dependencies.
>
> One could then say “we just need to implement those features” to do
> things properly. But having some experience with in the domain of
> package managers, I know that things are too *complex* for us OFBiz
> developpers to mess with that.  This is why I am proposing to remove the
> push/pull/remove commands and advocate towards working on the adoption
> of existing distribution interfaces like Jar libraries (See work done in
> OFBIZ-11161 [1]).
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-11161
>
> > On Mon, Nov 11, 2019 at 10:37 PM Mathieu Lirzin
> >  wrote:
> >>
> >> Hello,
> >>
> >> Jacques Le Roux  writes:
> >>
> >> > I propose that waiting for plugins Maven repos we simply continue to
> >> > use Svn through Github as I explained elsewhere
> >>
> >> No need to wait for Maven plugins before acting responsibly. :-)
> >>
> >> A preferable solution would be to simply remove the
> >> ‘push/pull/removePlugin*’ stuff from our build system which is the
> >> reason why we are discussing keeping this “Github SVN” hack initially.
> >>
> >> IMO people can manage their plugins more conveniently by directly
> >> running the “installation” command of their choice ‘git clone’, ‘svn
> >> checkout’, ‘ln -s’, ... in their plugins directory without needing OFBiz
> >> build system to do it poorly for them.
> >>
> >> > Le 07/11/2019 à 14:00, Gil Portenseigne a écrit :
> >> >> Hello Deepak, all,
> >> >>
> >> >> I do not have a strong opinion about separating plugins into independent
> >> >> git repositories but here are my thought :
> >> >>
> >> >> Plugins integration in OFBiz is intended to be used with a maven
> >> >> repository that hosts the plugin releases for the users. See as a
> >> >> reference the ‘OFBiz Plugins tasks’ or README.adoc about ‘OFB

Re: Git repo for each ofbiz plugin

[Taher Alkhateeb]

I'm not sure I see this issue with the same perspective. Having the
build system automatically download (and run some code) for a certain
component is a convenience especially for the community components.
Things are even easier when using git as there are many plugins to
support that. I'm also not sure what is "poor" about that

On Mon, Nov 11, 2019 at 10:37 PM Mathieu Lirzin
 wrote:
>
> Hello,
>
> Jacques Le Roux  writes:
>
> > I propose that waiting for plugins Maven repos we simply continue to
> > use Svn through Github as I explained elsewhere
>
> No need to wait for Maven plugins before acting responsibly. :-)
>
> A preferable solution would be to simply remove the
> ‘push/pull/removePlugin*’ stuff from our build system which is the
> reason why we are discussing keeping this “Github SVN” hack initially.
>
> IMO people can manage their plugins more conveniently by directly
> running the “installation” command of their choice ‘git clone’, ‘svn
> checkout’, ‘ln -s’, ... in their plugins directory without needing OFBiz
> build system to do it poorly for them.
>
> > Le 07/11/2019 à 14:00, Gil Portenseigne a écrit :
> >> Hello Deepak, all,
> >>
> >> I do not have a strong opinion about separating plugins into independent
> >> git repositories but here are my thought :
> >>
> >> Plugins integration in OFBiz is intended to be used with a maven
> >> repository that hosts the plugin releases for the users. See as a
> >> reference the ‘OFBiz Plugins tasks’ or README.adoc about ‘OFBiz plugin
> >> system’.
> >>
> >> We did not implemented an official maven repository for plugin releases,
> >> so there is no simple way to install a plugin without using VCS. There
> >> might be tasks to be done to have an nice answer to how an user can
> >> install a sole plugin from a downloaded release archive.
> >>
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Toirtoisegit keeps adding "/gradle/" in .gitignore

[Taher Alkhateeb]

as a general rule I would recommend against avoiding commits as a
workaround for specific tools. perhaps you can change the tool
settings to not generate this file.

on another note, you might want to consider something like git-cola
[1]. I it manages to combine simplicity with richness.

[1] https://git-cola.github.io/

On Mon, Nov 11, 2019 at 3:50 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> As you may know I'm mostly on Windows and I use ToirtoiseGit to handle 
> things, and in a lesser way Git Bash and eGit (Eclipse plugin).
>
> There is something which is annoying me with ToirtoiseGit. I don't know why 
> but it keeps adding "/gradle/" in .gitignore.
>
> I want to push it, but before I'd like your opinions.
>
> Thanks
>
> Jacques
>

Re: Backward compatibility for Java interfaces

[Taher Alkhateeb]

I leave for the rest of the folks to pitch in. I would just say that I
think having a lot of care for the container-specific API in terms of
backwards compatibility is probably not very necessary. Very few
external components AFAIK rely on that part of the system, and this
whole piece of the architecture probably needs major re-hauling
anyway. The refactoring work that I did back in 2016 was only one step
that needs further improvement by others to keep improving the code
base.

On Sat, Oct 19, 2019 at 7:57 PM Mathieu Lirzin
 wrote:
>
> Mathieu Lirzin  writes:
>
> > However I have just discovered that in 2016 some refactoring work chose
> > a different approach by simply changing a method signature in the
> > ‘ContainerConfig’ interface [1].
> [...]
> > [1] 
> > https://github.com/apache/ofbiz-framework/commit/d44020f0d6b2af4c049722751e4586a3ae5b2d98#diff-af4722454ae770d57420936da9bd4e29L55-R56
>
> For the record I have discovered a similar approach in 2012 [2].
>
> [2] 
> https://github.com/apache/ofbiz-framework/commit/c386b7fc9a8d61923efb9bbd2e472d1cac3d8a6f#diff-6a7b97cfa75c3d5f2ec74abbb2d42316L78-R78
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Using ‘checkstyle’ linting tool

[Taher Alkhateeb]

No opinion for or against, but I'd like to mention that the majority of our
code base is xml, and the emphasis is on switching to groovy for
everything, so the return on value from linting java might not be very
high, especially since our problems in java are not primarily formatting
issues, but rather design and architectural issues.

There are many great ideas for things to improve. The question is what to
prioritize and bring to the top of your to do list.

On Mon, Oct 14, 2019, 8:13 PM Mathieu Lirzin 
wrote:

> Hello,
>
> Linting [1] is a software engineering practice which make the code more
> readable and maintainable by improving its consistency and avoiding
> potential programming mistakes.  Gradle provides a core plugin for the
> ‘checkstyle’ tool [2][3] which implement a linting facility for the Java
> language.
>
> I have opened OFBIZ-11251 [4] which proposes a patch for using this
> Gradle plugin in OFBiz.
>
> With this patch when contributors will write Java code that do not match
> the OFBiz coding convention [5] an error will be reported by ‘gradlew
> check’ target.  However when hacking running ‘gradlew’, ‘gradlew run’ or
> ‘gradlew "ofbiz ..."’ will not bother integrators or contributors with
> any linting errors.  The idea is to recommend contributors to run
> ‘gradlew check’ before sending a patch or committing one and maybe add a
> Buildbot task for running such verification and blaming the faulty
> committer.
>
> What do people think?
>
> If nobody oppose I will commit the OFBIZ-11251 patch in 3 days.
>
> [1] https://en.wikipedia.org/wiki/Lint_(software)
> [2] https://checkstyle.org/
> [3] https://docs.gradle.org/current/userguide/checkstyle_plugin.html
> [4] https://issues.apache.org/jira/browse/OFBIZ-11251
> [5] https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: Welcome Pranay Pandey as a new PMC member

[Taher Alkhateeb]

Congratulations Pranay!

On Wed, Sep 25, 2019, 9:44 AM Ankit Joshi 
wrote:

> Many Congratulations Pranay!!
>
> Thanks & Regards,
> Ankit Joshi
>
> On Tue, Sep 24, 2019 at 9:07 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > The OFBiz PMC has invited Pranay Pandey to become a new member of the
> > committee and we are glad to announce that he has accepted the
> nomination.
> >
> > Welcome on board Pranay!
> >
> > Jacques (on behalf of the OFBiz PMC)
> >
> >
>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Taher Alkhateeb]

I see, in this case I think it's a good idea to comply with
conventions. It's strange that while I was working in the beginnings
on gradle I remember the opposite suggestion happening "keep the
scripts where they are" is what I heard repeatedly. Anyway, if it is
just a matter of moving, then it's not that big of a deal.

I suggest to do that slowly and carefully though. It is quite possible
to break many scripts due to location references.

On Fri, Sep 20, 2019 at 6:40 PM Jacques Le Roux
 wrote:
>
> In a 1st time I intend to do only what I wrote in OFBIZ-10226, OFBIZ-10205 
> and this thread, ie indeed mostly "move them to src/main/groovy". That's
> enough for my need.
>
> Using @CompileStatic is out of my scope because I want to keep Groovy scripts 
> dynamic.
>
> Le 20/09/2019 à 16:27, Taher Alkhateeb a écrit :
> > I'm not sure I understand the outcome from reading the JIRA and this
> > thread. What will happen exactly? Are you going to make groovy scripts
> > part of the call stack? Are you going to use @CompileStatic? Or are
> > you just going to move them to src/main/groovy?
> >
> > On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
> >  wrote:
> >> Thanks Paul, Gil, for your suggestions,
> >>
> >> I have created OFBIZ-11205 for that
> >>
> >> Jacques
> >>
> >> Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
> >>> Hi Devs,
> >>>
> >>> While working on OFBIZ-10226 "Adds groovyScripts in the Gradle 
> >>> sourceSets" I discussed with Mathieu and we had some ideas.
> >>>
> >>> Mathieu suggested to move Groovy scripts from /groovyScripts/ 
> >>> to/src/main/groovy/.
> >>>
> >>> I was initially reluctant because I love to be able to change things on 
> >>> the fly. That's why I liked Minilang and still like widgets, Freemarker
> >>> templates and Groovy Scripts.
> >>>
> >>> We also know the advantages of compilation. But then I thought: why not 
> >>> have best of both Groovy worlds: compile and on the fly.
> >>>
> >>> I tried and it works. So here is the (simple) plan:
> >>>
> >>> 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> >>> 2. We add the necessary packages names
> >>> 3. Devs can then open "gradlew --continuous" in a terminal and let it 
> >>> like that. It will continuously build on any changes in Gradle sourcesets
> >>>
> >>> So, if you modify a Groovy scripts while running an OFBiz instance, the 
> >>> changes will be reflected in the instance and you can check possible 
> >>> syntax
> >>> or alike issues in the terminal running the continuous build. It's very 
> >>> fast since only changes have an impact on the build.
> >>>
> >>> I'm sure there are other benefits to follow "the common convention of 
> >>> putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> >>> suggested Mathieu.
> >>>
> >>> I see no disadvantages, do you? If nobody disagree with this idea, I'll 
> >>> create a Jira for that.
> >>>
> >>> Feedback welcome, thanks
> >>>
> >>> Jacques
> >>>
> >>>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Taher Alkhateeb]

I'm not sure I understand the outcome from reading the JIRA and this
thread. What will happen exactly? Are you going to make groovy scripts
part of the call stack? Are you going to use @CompileStatic? Or are
you just going to move them to src/main/groovy?

On Fri, Sep 20, 2019 at 5:14 PM Jacques Le Roux
 wrote:
>
> Thanks Paul, Gil, for your suggestions,
>
> I have created OFBIZ-11205 for that
>
> Jacques
>
> Le 16/09/2019 à 12:28, Jacques Le Roux a écrit :
> > Hi Devs,
> >
> > While working on OFBIZ-10226 "Adds groovyScripts in the Gradle sourceSets" 
> > I discussed with Mathieu and we had some ideas.
> >
> > Mathieu suggested to move Groovy scripts from /groovyScripts/ 
> > to/src/main/groovy/.
> >
> > I was initially reluctant because I love to be able to change things on the 
> > fly. That's why I liked Minilang and still like widgets, Freemarker
> > templates and Groovy Scripts.
> >
> > We also know the advantages of compilation. But then I thought: why not 
> > have best of both Groovy worlds: compile and on the fly.
> >
> > I tried and it works. So here is the (simple) plan:
> >
> > 1. We move all Groovy scripts from /groovyScripts/ to /src/main/groovy/
> > 2. We add the necessary packages names
> > 3. Devs can then open "gradlew --continuous" in a terminal and let it like 
> > that. It will continuously build on any changes in Gradle sourcesets
> >
> > So, if you modify a Groovy scripts while running an OFBiz instance, the 
> > changes will be reflected in the instance and you can check possible syntax
> > or alike issues in the terminal running the continuous build. It's very 
> > fast since only changes have an impact on the build.
> >
> > I'm sure there are other benefits to follow "the common convention of 
> > putting groovy compiled sources in ${COMPONENT}/src/main/groovy.", as
> > suggested Mathieu.
> >
> > I see no disadvantages, do you? If nobody disagree with this idea, I'll 
> > create a Jira for that.
> >
> > Feedback welcome, thanks
> >
> > Jacques
> >
> >

Re: [VOTE] [RELEASE] Apache OFBiz 16.11.06 - second attempt

[Taher Alkhateeb]

+1

On Thu, Aug 29, 2019, 8:55 AM Aditya Sharma  wrote:

> +1
>
> --
> Thanks and Regards,
> Aditya Sharma
>
> On Thu, Aug 29, 2019 at 10:52 AM Suraj Khurana  wrote:
>
> > +1
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > Technical Consultant
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Aug 28, 2019 at 1:20 PM Nicolas Malin 
> > wrote:
> >
> > > same here
> > >
> > > +1
> > >
> > > On 8/28/19 9:25 AM, Swapnil M Mane wrote:
> > > > +1, thank you Jacopo!
> > > >
> > > > Everything seems good -
> > > >
> > > > 1. Checksums and signing certificate
> > > > $  ../ofbiz-tools/verify-ofbiz-release.sh apache-ofbiz-16.11.06.zip
> > > > sha check of file: apache-ofbiz-16.11.06.zip
> > > > Using sha file: apache-ofbiz-16.11.06.zip.sha512
> > > > apache-ofbiz-16.11.06.zip: 407F03CF C0A60B0F 363E83FC 55C0D301
> DDF323DC
> > > > 016B2C96 CA624791 046E8367 AE629A38 F4CE597F AE1E1F2E C504E895
> D22E6C6A
> > > > 4FA2E958 30F1EB3F 62A81E01
> > > > apache-ofbiz-16.11.06.zip: 407F03CF C0A60B0F 363E83FC 55C0D301
> DDF323DC
> > > > 016B2C96 CA624791 046E8367 AE629A38 F4CE597F AE1E1F2E C504E895
> D22E6C6A
> > > > 4FA2E958 30F1EB3F 62A81E01
> > > > sha checksum OK
> > > >
> > > > GPG verification output
> > > > gpg: Signature made Tue Aug 27 15:05:16 2019 IST
> > > > gpg:using RSA key 7A580908847AF9E0
> > > > gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) <
> > > > jaco...@apache.org>"
> > > >
> > > > 2. Initializing gradle wrapper, build, and tests are successful, the
> > > steps
> > > > followed are as follows (using macOS Mojave OS) -
> > > > -- Unzip apache-ofbiz-16.11.06.zip
> > > > -- Executed the ./gradle/init-gradle-wrapper cmd
> > > > -- Executed load and test command
> > > > $ ./gradlew loadDefault testIntegration
> > > > BUILD SUCCESSFUL
> > > >
> > > >
> > > > Best regards,
> > > > Swapnil M Mane,
> > > > ofbiz.apache.org
> > > >
> > > >
> > > >
> > > > On Tue, Aug 27, 2019 at 3:18 PM Jacopo Cappellato <
> > > > jacopo.cappell...@gmail.com> wrote:
> > > >
> > > >> This is the second vote thread to release a new bug fix release for
> > the
> > > >> release16.11 branch.
> > > >> This new release, "Apache OFBiz 16.11.06" will supersede all the
> > > previous
> > > >> releases from the same branch.
> > > >> The release files can be downloaded from here:
> > > >>
> > > >> https://dist.apache.org/repos/dist/dev/ofbiz/
> > > >>
> > > >> and are:
> > > >>
> > > >> * apache-ofbiz-16.11.06.zip
> > > >> * KEYS: text file with keys
> > > >> * apache-ofbiz-16.11.06.zip.asc: the detached signature file
> > > >> * apache-ofbiz-16.11.06.zip.sha512: checksum file
> > > >>
> > > >> Please download and test the zip file and its signatures (for
> > > instructions
> > > >> on testing the signatures see
> > > http://www.apache.org/info/verification.html
> > > >> ).
> > > >>
> > > >> The preview of the Release Notes can be found at:
> > > >> https://ofbiz.apache.org/release-notes-16.11.06.html
> > > >>
> > > >> Vote:
> > > >> [ +1] release as Apache OFBiz 16.11.06
> > > >> [ -1] do not release
> > > >>
> > > >> In order to provide enough time to discuss and test the candidate
> > files,
> > > >> this vote will be open for at least 10 days.
> > > >>
> > > >> For more details about this process please read
> > > >> http://www.apache.org/foundation/voting.html
> > > >>
> > > >> Best Regards,
> > > >> Jacopo Cappellato
> > > >>
> > >
> >
>

Re: Improving OFBiz extensibility and distribution

[Taher Alkhateeb]

Hi Mathieu,

It could be a different objective, but it serves in the provision of
an architecture where the framework is separated from the plugins and
they can be deployed at runtime. To do so, implementing what I
mentioned previously might help.

Anyhow, all initiatives are welcomed. It's a good start.

On Thu, Aug 22, 2019 at 8:06 PM Mathieu Lirzin
 wrote:
>
> Hello Taher,
>
> Taher Alkhateeb  writes:
>
> > We have done many discussions in the past about publishing OFBiz as
> > deployable JAR and then the plugin mechanism would work as you
> > suggested and you won't need the build system anymore. I remember
> > joining our friend Adrian Crum before he passed away in an attempt to
> > do that but which did not bear fruit.
>
> Thanks for reminding that past effort,
>
> > So, I am in agreement in theory with the concept, but I think
> > realistically this makes the whole "plugin" thing a secondary topic,
> > and the main topic is how to rewrite the core OFBiz framework as an
> > independent JAR with perhaps a single comprehensive webapp, and then
> > make the components deployable (possibly even at runtime) by having
> > this truly pluggable architecture. If you look at the commit history
> > when gradle was introduced, you will notice that in the past there was
> > a little top-level jar created by the start component and then every
> > component would hold its own jars and sources which are then compiled
> > and linked through the old build system (ant) and included through the
> > custom class loader. So it was a mix between ant + class loader to get
> > things going but was still suffering from being one big monolithic
> > thing.
>
> I have used the old ant build in one of our customer project at Néréide
> and noticed the separation in multiple jars, but I didn't investigate
> the internals.
>
> > So IMHO, perhaps a good approach would have the following preliminary
> > work even before starting to worry about the plugin architecture:
> >
> > - Remove tomcat as an integral container and instead make the web
> > server independent of the framework and vice versa
> > - Delete the entire "container" architecture altogether and just keep
> > thing running in the core
> > - Make everything as a single webapp by default with possible opt-in
> > other webapps
> > - Customize the classloader to allow extending the classpath and
> > loading other components.
> > - Finally, the component concept itself should be redesigned such that
> > every component _is_ an outputted jar file.
>
> Maybe I am overlooking something but this seems like an interesting but
> different objective to me. :-)
>
> > One thing though, I think the concept of the subproject in gradle
> > would help, not hurt moving towards that goal. It's just that
> > currently, the implementation is not ideal and requires improvements.
> > I don't think ditching the entire subproject functionality is very
> > useful though.
>
> Sure I am maybe throwing the baby with the bathwater. Gradle
> multi-projet builds are indeed useful to solve the issue of coordinating
> the local build and development of multiple source repositories.
>
> My only critic is that using this Gradle facility should not be a
> requirement for extending OFBiz.
>
> Thanks for you answer.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Improving OFBiz extensibility and distribution

[Taher Alkhateeb]

We have done many discussions in the past about publishing OFBiz as
deployable JAR and then the plugin mechanism would work as you
suggested and you won't need the build system anymore. I remember
joining our friend Adrian Crum before he passed away in an attempt to
do that but which did not bear fruit.

So, I am in agreement in theory with the concept, but I think
realistically this makes the whole "plugin" thing a secondary topic,
and the main topic is how to rewrite the core OFBiz framework as an
independent JAR with perhaps a single comprehensive webapp, and then
make the components deployable (possibly even at runtime) by having
this truly pluggable architecture. If you look at the commit history
when gradle was introduced, you will notice that in the past there was
a little top-level jar created by the start component and then every
component would hold its own jars and sources which are then compiled
and linked through the old build system (ant) and included through the
custom class loader. So it was a mix between ant + class loader to get
things going but was still suffering from being one big monolithic
thing.

So IMHO, perhaps a good approach would have the following preliminary
work even before starting to worry about the plugin architecture:

- Remove tomcat as an integral container and instead make the web
server independent of the framework and vice versa
- Delete the entire "container" architecture altogether and just keep
thing running in the core
- Make everything as a single webapp by default with possible opt-in
other webapps
- Customize the classloader to allow extending the classpath and
loading other components.
- Finally, the component concept itself should be redesigned such that
every component _is_ an outputted jar file.

One thing though, I think the concept of the subproject in gradle
would help, not hurt moving towards that goal. It's just that
currently, the implementation is not ideal and requires improvements.
I don't think ditching the entire subproject functionality is very
useful though.

Needless to say, this is probably a _lot_ of work. But a good
direction to have perhaps.


On Thu, Aug 22, 2019 at 11:53 AM Mathieu Lirzin
 wrote:
>
> Hello,
>
> The plugin mechanism has various issues that make distributing and
> extending OFBiz inconvenient and complex.  Here are some examples of the
> problems I identified:
>
> 1. Binary distribution of OFBiz needs to include both the Jar and the
>‘ofbiz.home’ directory which make deployment more complex
>
> 2. Gradle multi-project feature is overly complex (try to understand
>“build.gradle”...) and proves to be limited and brittle in practice
>(ex. adding an extra Gradle plugin in a subproject can easily break
>the build with obscure errors)
>
> 3. The plugin mechanism is hardly coupled with Gradle which breaks its
>API regularly. This means that plugins cannot choose their build
>system (Maven, Leinigen, SBT) and cannot expect their plugins to work
>with various version of OFBiz reliably.
>
> 4. There is no flexibility to install plugins outside of the ‘plugins’
>directory of $OFBIZ_HOME.
>
> 5. Plugins and Framework bytecode is distributed in the same JAR when we
>would want instead to independently compile and distribute them.
>
>
> 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:
>
>  - Distributing OFBiz in a Jar with its XML files inside to fix #1 would
>allow developpers to extend the framework without compiling it which
>removes the hard dependency on Gradle which fixes #2 and #3 and make
>the build process snappier.
>
>  - the classpath can be used to compose an arbitrary list of plugins
>from various location which fixes #4.
>
>  - The ServiceLoader class [1] is a standard and stable extensibility
>mechanism based on JAR metadata which can be used to scan the
>available OFBiz components available across multiple JARs that can
>replace Gradle complex component bundling to fix #5.
>
> The biggest challenge with this solution is that we need to do a huge
> work of adapting OFBiz to to use location independant resources [3] when
> loading XML and GroovyScript files.
>
> However what this effort would would bring is a convenient and decoupled
> way to extend OFBiz by simply declaring a dependency to the framework
> and dependant reusable plugins from the project plugin build tool like
> that:
>
> // myApplicationProjectPlugin/build.gradle
> dependencies {
> implementation "org.apache.ofbiz:ofbiz-framework:18.12"
> implementation "org.example:reusable-ofbiz-plugin:0.8"
> ...
> }
>
> Would people welcome such change?
>
> Thanks.
>
> [1] https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html
> [2] https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html
>
> --
> Mathieu 

Re: [VOTE] [RELEASE] Apache OFBiz 16.11.06

[Taher Alkhateeb]

All tests are clear, smoke tests clear, SHA512 checksum matches

+1 from my side. Thank you for your efforts Jacopo

On Sat, Aug 10, 2019 at 12:17 PM Jacopo Cappellato
 wrote:
>
>  This is the vote thread to release a new bug fix release for the
> release16.11 branch.
> This new release, "Apache OFBiz 16.11.06" will supersede all the previous
> releases from the same branch.
> The release files can be downloaded from here:
>
> https://dist.apache.org/repos/dist/dev/ofbiz/
>
> and are:
>
> * apache-ofbiz-16.11.06.zip
> * KEYS: text file with keys
> * apache-ofbiz-16.11.06.zip.asc: the detached signature file
> * apache-ofbiz-16.11.06.zip.sha512: checksum file
>
> Please download and test the zip file and its signatures (for instructions
> on testing the signatures see http://www.apache.org/info/verification.html).
>
> The preview of the Release Notes can be found at:
> https://ofbiz.apache.org/release-notes-16.11.06.html
>
> Vote:
> [ +1] release as Apache OFBiz 16.11.06
> [ -1] do not release
>
> In order to provide enough time to discuss and test the candidate files,
> this vote will be open for at least 10 days.
>
> For more details about this process please read
> http://www.apache.org/foundation/voting.html
>
> Best Regards,
> Jacopo Cappellato

Possible problem in dependencies

[Taher Alkhateeb]

Hi Folks,

It could be my environment, but I suspect something might be wrong
with the dependencies because it still happens after I delete the
cache. Is anyone else facing the below warnings [1]?

[1] > Task :compileJava
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentl$
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy':
class
file for javax.annotation.concurrent.GuardedBy not found
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentl$
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentl$
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
/home/taher/.gradle/caches/modules-2/files-2.1/com.googlecode.concurrentlinkedhashmap/concurrentlinkedhashmap-lru/1.4.2/2eaf3d3c9746d526ff7e5b93931d482c3887e6ac/concurrentli
nkedhashmap-lru-1.4.2.jar(com/googlecode/concurrentlinkedhashmap/ConcurrentLinkedHashMap.class):
warning: Cannot find annotation method 'value()' in type 'GuardedBy'
12 warnings

Re: weird behavior in reply lately

[Taher Alkhateeb]

Awesome, it works again. Very cool.

On Thu, Jul 18, 2019, 10:13 PM Jacques Le Roux 
wrote:

> Thanks Aditya,
>
> Jacques
>
> Le 18/07/2019 à 14:59, Aditya Sharma a écrit :
> > Here is the Jira: https://issues.apache.org/jira/browse/INFRA-18768
> >
> > Thanks and regards,
> > Aditya Sharma
> >
> > On Wed, Jul 17, 2019 at 5:39 PM Aditya Sharma 
> > wrote:
> >
> >> I went through the post shared by Mathieu, Jacques along with this
> post[1]
> >> that shows both the sides vividly and it all makes sense.
> >> Different people may have different preferences for it but we have to
> >> choose what favors the community.
> >> I can see many instances on lists where users replied to the personal
> >> email and we cannot really restrict anyone to use reply or reply-all.
> >> I will create a Jira at infra so that previous arrangement is restored.
> >>
> >> 1. https://www.gnu.org/software/mailman/mailman-admin/node11.html
> >>
> >> Thanks and regards,
> >> Aditya Sharma
> >>
> >> On Sun, Jun 30, 2019 at 8:23 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>
> >>> Le 30/06/2019 à 16:08, Mathieu Lirzin a écrit :
>  Hello Jacques
> 
>  Jacques Le Roux  writes:
> 
> > The question is should we vote?
> >
> > So far it all depends on me and my -0.2 added to Paul's -0.8 after
> > Mathieu convinced me that it would be better do to otherwise.
> >
> > If Mathieu does not want to use his veto, I'll not apply mine. It was
> > like that for years and it seems everybody was happy, including
> > Mathieu, Paul and I, we never complained.
>  I am not familiar with Apache voting policies, However according to
> [1]
>  it seems that people are not expected to use their veto for procedural
>  issues.
> 
>  Most people in this conversation have already expressed their opinion
> in
>  favour of the ‘reply-to’ munging and have not been convinced by my
>  arguments, so I don't think we need to formally vote.
> 
>  [1] https://www.apache.org/foundation/voting.html
> >>> That's simpler indeed. We could argue that it's code and a vote could
> be
> >>> done. But it's not OFBiz code so I I guess it would be far fetched and
> most
> >>> would not agree.
> >>>
> >>> Anyway, I'll continue to use Reply-to-list, and we will not receive
> >>> unwanted copies, it's OK with me.
> >>>
> >>> Jacques
> >>>
> >>>
>

Re: OFBIZ-11103

[Taher Alkhateeb]

I'm not sure you even need to ask the community for an OK on a ticket
which is created by you with no activity or feedback from anyone :)

I don't think you need to wait either unless you want to

On Tue, Jul 2, 2019 at 6:27 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> If nobody is against I'll close OFBIZ-11103 as won't fix in a week.
>
> It seems not a problem so far.
>
> Jacques
>

Re: weird behavior in reply lately

[Taher Alkhateeb]

I don't even use a mail client. I use web interface and it does not work.
It's also annoying to have to configure mobile client, desktop client and
web. I prefer to add the headers back.

On Fri, Jun 28, 2019, 11:13 AM Mathieu Lirzin 
wrote:

> Scott Gray  writes:
>
> > I just did it as well and it's super annoying.  I don't ever want to
> > directly reply to messages on our lists, at least without some manual
> > effort on my part.  Personally I couldn't care less about whether or not
> > some idealists think setting reply-to is harmful.
>
> Should I say then that I don't care about people who don't want to make
> the effort of configuring and using an email client properly? Let us not
> go that path and be respectful to each other.
>
> This topic has nothing to do with “idealism”, it is just about adopting
> some practical and safe conventions.
>
> I acknowledge that your current habits makes things impractical for you,
> since you were expecting "reply" to mean "reply to {list,group,all}" but
> to me this is just confusing.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: [DISCUSSION] where download gradle-wrapper.jar ?

[Taher Alkhateeb]

You can go ahead and give it a try, however the main problem you might
face would perhaps be the complex logic that you need to add to
"gradlew" and "gradlew.bat" scripts to download the jar if it does not
exist. Now that wrapper jar is difficult to obtain because I think you
can only get it from inside the compressed archive of a certain
distribution.

So think about it, the logic in these two scripts (bash & windows
batch) should have the following logic in it:
1 - download the correct compressed archive binary
2 - uncompress it
3 - copy the wrapper jar to the correct location

The first two items above require installation of certain tools on the
operating system like curl, wget, zip, etc ... which means they won't
work out of the box and requirements to run ofbiz would go beyond
simply installing java. That's what I meant by difficult and complex.

Another downsize to heavy customization of these scripts is that the
upgrade process of the wrapper in the new version becomes more
involved because these scripts are auto generated by gradle, and so
merging these changes into your custom logic might be more work.

Now to reduce that complexity we might switch from a batch script to a
powershell script instead, but that would mean converting the entire
script to powershell and also means powershell is a necessity on any
Microsoft platform.

So if we bypass the wrapper script as an exceptional thing, it would
be the easiest way to move forward and I think this was discussed
elsewhere in the ASF before (perhaps LEGAL).

To summarize, I'm not objecting to doing it if you would like to push
in that direction, but it would perhaps be annoying and complex to
implement.

On Tue, Jun 25, 2019 at 12:49 PM Nicolas Malin  wrote:
>
> My vision is to have the code base near the building package as
> possible. If we keep gradle-wrapper.jar for developing comfort, it's a
> risk for me to generate an issue on release package due to not enough
> test after package creation.
>
> > Le 23/06/2019 à 17:38, Taher Alkhateeb a écrit :
> >> [...]
> >> The gradle wrapper is difficult to download and obtain, and is usually
> >> provided using a gradle command (installed gradle on the platform. So
> >> it's best to just keep it in.
>
> Taher do you show any difficulties with the trunk to resolve
> automatically and download the wrapper ?
>
>
> Otherwise, I have a problem with the resolution on gradle-wrapper based
> only on branches, with that the wrapper resolved would be always the up
> to date related to branch code base. It's nice for demo, buildbot and
> developer but open a potential problem for package.
>
> 16.05 works with gradle 3.2.1 for any reason we need to update the
> wrapper to 4.0.0, 16.06 works with it but all previous package has been
> a potential incompatibility.We can decide to say it's not own problem
> however I prefer to offer a solution more flexible like store the
> wrapper by version : ofbiz/tools/gradle/wrapper/v3.2.1/* as the gradle
> community works. Also possibility to call wrapper verion by wrapper it
> self, I really une preference to resolve direclty the wrapper on the
> good version.
>
> On second time I prefer to resolve the wrapper from the origin community
> (keep resolution near source code, have always source origin) but after
> different remarks maybe we can couple gradle community and own
> resolution form own repository as fallback.
>
> Nicolas
>
>
> >>
> >> On Sun, Jun 23, 2019 at 4:58 PM Mathieu Lirzin
> >>  wrote:
> >>> Mathieu Lirzin  writes:
> >>>
> >>>> Nicolas Malin  writes:
> >>>>
> >>>>> Jacques suggests to store the  on own tools
> >>>>> repository source[3] and download through viewvc with one wrapper by
> >>>>> stable branch.
> >>>>> I suggest to download it from gradle community on github and store
> >>>>> the
> >>>>> release to download in own code source[4]
> >>>>>
> >>>>> Your opinion ? or other idea ?
> >>>> IMO storing Gradle binary releases in our own infrastructure is too
> >>>> much
> >>>> trouble. If we don't trust Gradle binaries to continue to be available
> >>>> in the future, we maybe should use another build system instead of
> >>>> keeping trying to keep our copies of its binary releases. No?
> >>> I overlooked that we were not speaking of downloading the binary
> >>> releases, but only of the “gradle-wrapper.jar” which should already be
> >>> avaibable in our VCS branches in order to comply with Gradle wrapping
> >>> recommendations as I advocated in my previous mail.
> >>>
> >>> Given that each release archive can point to its corresponding
> >>> repository branch to find its associated “gradle-wrapper.jar”, it is
> >>> basically free in term of maintenance. Then I agree with Jacques
> >>> option.
> >>>
> >>> Sorry for the confusion.
> >>>
> >>> --
> >>> Mathieu Lirzin
> >>> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
> >
> >

weird behavior in reply lately

[Taher Alkhateeb]

Hi folks,

I'm not sure if something is wrong, but lately I keep replying to
individuals instead of the mailing list (or sometimes both). Did
something change in our mailing servers? Or could it be that gmail
changed its behavior perhaps?

Re: [DISCUSSION] where download gradle-wrapper.jar ?

[Taher Alkhateeb]

I think the gradle-wrapper.jar should be maintained inside the code
base as an exceptional thing, otherwise it would be quite painful to
administer the system.

The gradle wrapper is difficult to download and obtain, and is usually
provided using a gradle command (installed gradle on the platform. So
it's best to just keep it in.

On Sun, Jun 23, 2019 at 4:58 PM Mathieu Lirzin
 wrote:
>
> Mathieu Lirzin  writes:
>
> > Nicolas Malin  writes:
> >
> >> Jacques suggests to store the gradle-wrapper.jar on own tools
> >> repository source[3] and download through viewvc with one wrapper by
> >> stable branch.
> >> I suggest to download it from gradle community on github and store the
> >> release to download in own code source[4]
> >>
> >> Your opinion ? or other idea ?
> >
> > IMO storing Gradle binary releases in our own infrastructure is too much
> > trouble. If we don't trust Gradle binaries to continue to be available
> > in the future, we maybe should use another build system instead of
> > keeping trying to keep our copies of its binary releases. No?
>
> I overlooked that we were not speaking of downloading the binary
> releases, but only of the “gradle-wrapper.jar” which should already be
> avaibable in our VCS branches in order to comply with Gradle wrapping
> recommendations as I advocated in my previous mail.
>
> Given that each release archive can point to its corresponding
> repository branch to find its associated “gradle-wrapper.jar”, it is
> basically free in term of maintenance. Then I agree with Jacques option.
>
> Sorry for the confusion.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Welcome to Deepak Nigam as new committer!

[Taher Alkhateeb]

Congratulations Deepak, always great to see the team growing.

On Thu, Jun 13, 2019, 9:24 AM Devanshu Vyas 
wrote:

> Many Congratulations Deepak!
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Thu, Jun 13, 2019 at 11:20 AM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > The OFBiz PMC has invited Deepak to become a new committer and we are
> > pleased  to announce that he has accepted.
> >
> > Deepak  is part of the community since January 2016 and has proved to be
> > committed since.
> >
> > He notably made a great work for OFBIZ-10518 "Inventory (Supply)
> > Allocation Planning "
> >
> > He not only worked in Jira,  but also answered accurately on MLs where he
> > supported our users.
> >
> > Please join me in welcoming and congratulating Deepak.
> >
> > Jacques
> >
> >
>

Re: Welcome to Pawan Verma as new committer!

[Taher Alkhateeb]

Congratulations Pawan, looking forward to seeing you in action.

On Thu, Jun 13, 2019, 8:50 AM Jacques Le Roux 
wrote:

> The OFBiz PMC has invited Pawan to become a new committer and we are
> pleased  to announce that he has accepted.
>
> Pawan is part of the community for 2 years and has being quite active and
> proficient, notably these last times with several smart propositions.
>
> He also helps a lot of Jiras and answers properly on MLs.
>
> Please join me in welcoming and congratulating Pawan.
>
> Jacques
>
>

Re: [DISCUSSION] Committing Minilang test patches under OFBIZ-1463

[Taher Alkhateeb]

As a general rule, minilang adds to the technical debt of this project. It
is hard to understand or maintain even simple constructs in minilang.

To generalize this concept... Patch != Good patch. So I recommend that
everything goes through the funnel of good old reviews. Good code has no
shortcuts, it is blood sweat and tears both for the provider and the
reviewer of patches.

On Mon, Jun 3, 2019, 4:20 PM Michael Brohl  wrote:

> I explained my POV in the Jira [1].
>
> Why not encourage the contributors to move their minilang tests to
> Groovy code? I can see that this has already been done, e.g. here [2]
> (thanks everyone involved!).
>
> I'm sure that the remaining patches will get converted soon, no need to
> choose the "easy way" and commit the minilang versions.
>
> If we will allow more minilang commits, we will always have the
> discussion and won't ever get rid of it.
>
> Thanks,
>
> Michael
>
> [1] https://issues.apache.org/jira/projects/OFBIZ/issues/OFBIZ-1463
>
> [2] https://issues.apache.org/jira/browse/OFBIZ-9002
>
>
>
> Am 03.06.19 um 13:21 schrieb Jacques Le Roux:
> > OK if this is a veto, no need to continue the discussion.-
> >
> > Else could you explain your POV Michael, notably about missing to put
> > in some new tests that could be helpful in the meantime?
> >
> > Thanks
> >
> > Le 02/06/2019 à 21:27, Michael Brohl a écrit :
> >> -1 to introduce more minilang code to the codebase. New code should
> >> be provided in either Java or Groovy code.
> >>
> >> Thanks,
> >> Michael
> >>
> >>
> >>
> >>> Am 02.06.2019 um 12:56 schrieb Jacques Le Roux
> >>> :
> >>>
> >>> Hi All,
> >>>
> >>> We started a discussion in OFBIZ-1463 about committing or not the
> >>> Minilang test patches.
> >>>
> >>> There are already few mixed opinions there (Michael, Aditya, Suraj
> >>> and I).
> >>>
> >>> Before voting I'd like to know if we can come to a consensus.
> >>>
> >>> Please read in OFBIZ-1463 and come back with your opinion.
> >>>
> >>> I have just changed mine because I believe using the tests as soon
> >>> they are reading is a good thing.
> >>>
> >>> Waiting would be a waste of not only work done but also time for
> >>> code safety. We can still move them to Groovy later, it's not more
> >>> work, I guess it's
> >>> even less.
> >>>
> >>> Jacques
> >>>
> >>
>
>

Re: Gradle eclipse task - classpath modification

[Taher Alkhateeb]

I see, sounds good. No harm in altering the exclusions.

On Sun, May 26, 2019 at 10:01 PM Michael Brohl  wrote:
>
> Hi Taher,
>
> I find it extremely useful to start OFBiz from the IDE ;-)
>
> This way hot code replacement is supported which helps changing code at
> runtime or while debugging.
>
> We add these two classpath entries by hand in Eclipse until now. I think
> there would be no problem to remove the two exclusions which would make
> these extra steps obsolete.
>
> Thanks,
>
> Michael
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 25.05.19 um 19:15 schrieb Taher Alkhateeb:
> > It might be more useful not to launch from the IDE. Instead run gradle
> > "ofbizDebug" and hookup remotely with the debug port. This would maintain a
> > consistent environment instead of being surprised (happened to me in the
> > past). It would also make a consistent experience to development team
> > regardless of the IDE and you won't have to alter the jar file to
> > accommodate an IDE.
> >
> > With that being said I don't think it's a big deal if you wish to remove
> > those exclusions. Up to community to decide.
> >
> >
> >
> > On Sat, May 25, 2019, 6:37 PM Girish Vasmatkar <
> > girish.vasmat...@hotwaxsystems.com> wrote:
> >
> >> So every IDE provides a shortcut (certain combination of keys) to execute
> >> any java file in a project as a java application, that in turn invokes
> >> *java
> >> *command on that class file. Eclipse applies all classpath entries (list of
> >> jar files from gradle dependency) as -classpath argument.
> >>
> >> Under the hood command that gets executed is -
> >>
> >> java org.apache.ofbiz.base.start.Start -classpath 
> >>
> >> I do this because it saves a lot of time. As soon as you make any change in
> >> any file, especially java, it is compiled instantaneously as soon as you
> >> save it. All you have to do is, just run Start.java as a java application
> >> and you have OFBiz launched quickly.
> >>
> >>
> >>
> >> On Sat, May 25, 2019 at 7:23 PM Taher Alkhateeb <
> >> slidingfilame...@gmail.com>
> >> wrote:
> >>
> >>> start how? what is the command? Are you trying to start _from_ eclipse.
> >> If
> >>> yes why?
> >>>
> >>> On Sat, May 25, 2019 at 2:26 PM Girish Vasmatkar <
> >>> girish.vasmat...@hotwaxsystems.com> wrote:
> >>>
> >>>> I realised Taher's reply after I had sent my response.
> >>>>
> >>>> Following's the command.
> >>>>
> >>>> *./gradlew eclipse*
> >>>>
> >>>> This would do the job of setting up the eclipse workspace with all all
> >>>> gradle dependencies nicely set-up in the classpath.
> >>>>
> >>>> Then I would normally try to start OFBiz using Start.java. Not sure if
> >>> you
> >>>> can see the inline screenshot. Pl see below.
> >>>>
> >>>> [image: image.png]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, May 25, 2019 at 4:49 PM Girish Vasmatkar <
> >>>> girish.vasmat...@hotwaxsystems.com> wrote:
> >>>>
> >>>>> There is a bit more to it ...
> >>>>>
> >>>>> When the system can't find cache.properties (as it's no more on the
> >>>>> classpath), following happens -
> >>>>>
> >>>>> 1. Exception is thrown (which is obvious)
> >>>>> 2. Code execution halts (which is fine), so no tomcat is launched.
> >>>>> 3. Since execution stops, JVM should be terminated in my opinion. In
> >>>>> other words, JVM should not keep hanging doing nothing, better stop it
> >>> if a
> >>>>> major exception has occurred. The JVM process is never terminated in
> >>> this
> >>>>> case.
> >>>>>
> >>>>> Again, this is a very isolated scenario because it is always expected
> >>>>> that these config files and folders are always going to be on the
> >>>>> classpath. But this is one of those rare scenarios
> >>>>> where that's not the case.
> >>>>>
> >>>>> Log4j2 internal initialization logging.
> >>>>>

Re: Gradle eclipse task - classpath modification

[Taher Alkhateeb]

It might be more useful not to launch from the IDE. Instead run gradle
"ofbizDebug" and hookup remotely with the debug port. This would maintain a
consistent environment instead of being surprised (happened to me in the
past). It would also make a consistent experience to development team
regardless of the IDE and you won't have to alter the jar file to
accommodate an IDE.

With that being said I don't think it's a big deal if you wish to remove
those exclusions. Up to community to decide.



On Sat, May 25, 2019, 6:37 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> So every IDE provides a shortcut (certain combination of keys) to execute
> any java file in a project as a java application, that in turn invokes
> *java
> *command on that class file. Eclipse applies all classpath entries (list of
> jar files from gradle dependency) as -classpath argument.
>
> Under the hood command that gets executed is -
>
> java org.apache.ofbiz.base.start.Start -classpath 
>
> I do this because it saves a lot of time. As soon as you make any change in
> any file, especially java, it is compiled instantaneously as soon as you
> save it. All you have to do is, just run Start.java as a java application
> and you have OFBiz launched quickly.
>
>
>
> On Sat, May 25, 2019 at 7:23 PM Taher Alkhateeb <
> slidingfilame...@gmail.com>
> wrote:
>
> > start how? what is the command? Are you trying to start _from_ eclipse.
> If
> > yes why?
> >
> > On Sat, May 25, 2019 at 2:26 PM Girish Vasmatkar <
> > girish.vasmat...@hotwaxsystems.com> wrote:
> >
> > > I realised Taher's reply after I had sent my response.
> > >
> > > Following's the command.
> > >
> > > *./gradlew eclipse*
> > >
> > > This would do the job of setting up the eclipse workspace with all all
> > > gradle dependencies nicely set-up in the classpath.
> > >
> > > Then I would normally try to start OFBiz using Start.java. Not sure if
> > you
> > > can see the inline screenshot. Pl see below.
> > >
> > > [image: image.png]
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, May 25, 2019 at 4:49 PM Girish Vasmatkar <
> > > girish.vasmat...@hotwaxsystems.com> wrote:
> > >
> > >> There is a bit more to it ...
> > >>
> > >> When the system can't find cache.properties (as it's no more on the
> > >> classpath), following happens -
> > >>
> > >> 1. Exception is thrown (which is obvious)
> > >> 2. Code execution halts (which is fine), so no tomcat is launched.
> > >> 3. Since execution stops, JVM should be terminated in my opinion. In
> > >> other words, JVM should not keep hanging doing nothing, better stop it
> > if a
> > >> major exception has occurred. The JVM process is never terminated in
> > this
> > >> case.
> > >>
> > >> Again, this is a very isolated scenario because it is always expected
> > >> that these config files and folders are always going to be on the
> > >> classpath. But this is one of those rare scenarios
> > >> where that's not the case.
> > >>
> > >> Log4j2 internal initialization logging.
> > >>
> > >> java.util.MissingResourceException: Can't find bundle for base name
> > >> cache, locale en
> > >>
> > >> at java.util.ResourceBundle.throwMissingResourceException(
> > >> ResourceBundle.java:1573)
> > >>
> > >> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
> > >>
> > >> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> > >> UtilCache.java:191)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> > >> UtilCache.java:173)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> > >> UtilCache.java:169)
> > >>
> > >> at
> org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
> > >>
> > >> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
> > >> UtilCache.java:797)
> > >>
> > >> at org.apache.ofbiz.base.util.UtilProperties.(
> > >> UtilProperties.java:75)
> > >>
> > >> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
> > >>
> &g

Re: Gradle eclipse task - classpath modification

[Taher Alkhateeb]

start how? what is the command? Are you trying to start _from_ eclipse. If
yes why?

On Sat, May 25, 2019 at 2:26 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> I realised Taher's reply after I had sent my response.
>
> Following's the command.
>
> *./gradlew eclipse*
>
> This would do the job of setting up the eclipse workspace with all all
> gradle dependencies nicely set-up in the classpath.
>
> Then I would normally try to start OFBiz using Start.java. Not sure if you
> can see the inline screenshot. Pl see below.
>
> [image: image.png]
>
>
>
>
>
>
> On Sat, May 25, 2019 at 4:49 PM Girish Vasmatkar <
> girish.vasmat...@hotwaxsystems.com> wrote:
>
>> There is a bit more to it ...
>>
>> When the system can't find cache.properties (as it's no more on the
>> classpath), following happens -
>>
>> 1. Exception is thrown (which is obvious)
>> 2. Code execution halts (which is fine), so no tomcat is launched.
>> 3. Since execution stops, JVM should be terminated in my opinion. In
>> other words, JVM should not keep hanging doing nothing, better stop it if a
>> major exception has occurred. The JVM process is never terminated in this
>> case.
>>
>> Again, this is a very isolated scenario because it is always expected
>> that these config files and folders are always going to be on the
>> classpath. But this is one of those rare scenarios
>> where that's not the case.
>>
>> Log4j2 internal initialization logging.
>>
>> java.util.MissingResourceException: Can't find bundle for base name
>> cache, locale en
>>
>> at java.util.ResourceBundle.throwMissingResourceException(
>> ResourceBundle.java:1573)
>>
>> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
>>
>> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>> UtilCache.java:191)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>> UtilCache.java:173)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>> UtilCache.java:169)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
>>
>> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
>> UtilCache.java:797)
>>
>> at org.apache.ofbiz.base.util.UtilProperties.(
>> UtilProperties.java:75)
>>
>> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
>>
>> at org.apache.ofbiz.base.container.ContainerLoader.load(
>> ContainerLoader.java:61)
>>
>> at org.apache.ofbiz.base.start.StartupControlPanel.loadStartupLoaders(
>> StartupControlPanel.java:218)
>>
>> at org.apache.ofbiz.base.start.StartupControlPanel.start(
>> StartupControlPanel.java:71)
>>
>> at org.apache.ofbiz.base.start.Start.main(Start.java:85)
>>
>>
>> Best,
>> Girish
>>
>> On Sat, May 25, 2019 at 2:56 PM Girish Vasmatkar <
>> girish.vasmat...@hotwaxsystems.com> wrote:
>>
>>> Hi Mathieu,
>>>
>>> With those entries missing from the classpath, you'd get the following
>>> exceptions and warning -
>>>
>>> 1. For cache.properties (when /framework/base/config entry is missing)
>>>
>>> Exception in thread "main" java.lang.ExceptionInInitializerError
>>>
>>> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
>>>
>>> at org.apache.ofbiz.base.container.ContainerLoader.load(
>>> ContainerLoader.java:61)
>>>
>>> at org.apache.ofbiz.base.start.StartupControlPanel.loadStartupLoaders(
>>> StartupControlPanel.java:218)
>>>
>>> at org.apache.ofbiz.base.start.StartupControlPanel.start(
>>> StartupControlPanel.java:71)
>>>
>>> at org.apache.ofbiz.base.start.Start.main(Start.java:85)
>>>
>>> Caused by: java.util.MissingResourceException: Can't find bundle for
>>> base name cache, locale en
>>>
>>> at java.util.ResourceBundle.throwMissingResourceException(
>>> ResourceBundle.java:1573)
>>>
>>> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
>>>
>>> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>>> UtilCache.java:177)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>>> UtilCache.java:173)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
>>> UtilCache.java:169)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
>>>
>>> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
>>> UtilCache.java:779)
>>>
>>> at org.apache.ofbiz.base.util.UtilProperties.(
>>> UtilProperties.java:75)
>>>
>>> ... 5 more
>>>
>>> 2. when /framework/base/dtd entry is missing (contains all schema files)
>>>
>>> 2019-05-25 14:48:37,591 |main |ContainerLoader
>>>   |I| [Startup] Loading containers...
>>>
>>> 2019-05-25 14:48:38,431 |main |UtilXml
>>>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL
>>> DTD/Schema with publicId [null] and the file/resource is
>>> [ofbiz-containers.xsd]
>>>
>>> 2019-05-25 14:48:39,139 |main |ContainerLoader
>>>   

Re: Gradle eclipse task - classpath modification

[Taher Alkhateeb]

What is the exact command used to run?

On Sat, May 25, 2019, 12:27 PM Girish Vasmatkar <
girish.vasmat...@hotwaxsystems.com> wrote:

> Hi Mathieu,
>
> With those entries missing from the classpath, you'd get the following
> exceptions and warning -
>
> 1. For cache.properties (when /framework/base/config entry is missing)
>
> Exception in thread "main" java.lang.ExceptionInInitializerError
>
> at org.apache.ofbiz.base.util.Debug.(Debug.java:69)
>
> at org.apache.ofbiz.base.container.ContainerLoader.load(
> ContainerLoader.java:61)
>
> at org.apache.ofbiz.base.start.StartupControlPanel.loadStartupLoaders(
> StartupControlPanel.java:218)
>
> at org.apache.ofbiz.base.start.StartupControlPanel.start(
> StartupControlPanel.java:71)
>
> at org.apache.ofbiz.base.start.Start.main(Start.java:85)
>
> Caused by: java.util.MissingResourceException: Can't find bundle for base
> name cache, locale en
>
> at java.util.ResourceBundle.throwMissingResourceException(
> ResourceBundle.java:1573)
>
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
>
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:782)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> UtilCache.java:177)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> UtilCache.java:173)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.setPropertiesParams(
> UtilCache.java:169)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.(UtilCache.java:125)
>
> at org.apache.ofbiz.base.util.cache.UtilCache.createUtilCache(
> UtilCache.java:779)
>
> at
> org.apache.ofbiz.base.util.UtilProperties.(UtilProperties.java:75
> )
>
> ... 5 more
>
> 2. when /framework/base/dtd entry is missing (contains all schema files)
>
> 2019-05-25 14:48:37,591 |main |ContainerLoader
>   |I| [Startup] Loading containers...
>
> 2019-05-25 14:48:38,431 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-containers.xsd]
>
> 2019-05-25 14:48:39,139 |main |ContainerLoader
>   |I| Loading container: component-container
>
> 2019-05-25 14:48:39,244 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [component-loader.xsd]
>
> 2019-05-25 14:48:39,596 |main |ComponentContainer
>   |I| Auto-Loading component directory :
> [/Users/grv/git/clients/warbyparker/github/ofbiz/framework]
>
> 2019-05-25 14:48:39,641 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [component-loader.xsd]
>
> 2019-05-25 14:48:39,898 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:40,210 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:40,496 |main |ComponentContainer
>   |I| Added class path for component : [base]
>
> 2019-05-25 14:48:40,552 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:40,923 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:41,162 |main |ComponentContainer
>   |I| Added class path for component : [entity]
>
> 2019-05-25 14:48:41,190 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:41,491 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:42,300 |main |ComponentContainer
>   |I| Added class path for component : [security]
>
> 2019-05-25 14:48:42,323 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:42,615 |main |UtilXml
>   |W| [UtilXml.LocalResolver.resolveEntity] could not find LOCAL DTD/Schema
> with publicId [null] and the file/resource is [ofbiz-component.xsd]
>
> 2019-05-25 14:48:42,865 |main |ComponentContainer
>   |I| Added class path for component : [datafile]
>
> 2019-05-25 14:48:42,883 |main |UtilXml
>   |W| 

Re: [PROPOSAL] DataModel - Improve entities using fromPartyId & toPartyId

[Taher Alkhateeb]

I'm also in favor of the more flexible design based on roles. Let the
services worry about sorting this stuff out and leave the entity
domain layer solid and well designed.

On Thu, May 16, 2019 at 11:25 PM Michael Brohl  wrote:
>
> Hi Pierre,
>
> I think there are more sophisticated concepts for some of the mentioned
> entities, for example
>
> - OrderRole for orders allows to connect an unlimited number of parties
> with different roles
>
> - CustRequestParty, QuoteRole, CustRequestRole - same principle
>
> For these, introducing from/toPartyId would be no improvement IMO. *If*
> we would want to make a change, I would tend more to implementing the
> ...Role principle where it is missing and get rid of the from/toPartyId
> pattern. But this would be a big change...
>
> I'm not sure why we have these in some entities which also have the
> ...Role entities, such as Invoice.
>
> Maybe others can give more insights?
>
> Regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 13.05.19 um 13:41 schrieb Pierre Smits:
> > Hi All,
> >
> > Currently several entities capture the (contractual) parties in fields like
> > fromPartyId and toPartyId. These parties commonly represent the internal
> > (accounting) organisation and the external party (the customer, supplier,
> > contact, account, carrier etc).
> >
> > Such entities are:
> >
> > - Agreement (in party)
> > - Employment (in humanres)
> > - Invoice (in accounting
> > - OrderReportPurchasesGroupByProduct
> > - PartyBenefit (in humanres)
> > - Payment (in accounting)
> > - PayHistory (in humanres)
> > - ReturnHeader (in Order)
> > - UnemploymentClaim (in humanres
> >
> >
> > However there are a (quite a) few entities that defy these 1-on-1
> > relationships (between internal party and the object, and the external
> > party and the object), like:
> >
> > - OrderHeader: neither partyIdFrom nor partyIdTo
> > - Quote: neither partyIdFrom nor partyIdTo but having a partyId field
> > - CustRequest: only having fromPartyid (plus its role
> > - Subscription: having originatedFromPartyId (plus the role) and partyId
> > - ReorderGuideline: having partyId (plus the role)
> >
> > And I am confident I am missing a few.
> >
> > In oder to simplify processes for capturing the main parties in various
> > entity records I propose to realign these (master) entities to ensure that
> > both the primary internal and external parties (and their primary roles)
> > are captured.
> >
> > What are your thoughts?
> >
> > 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
> >
>

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

It's already done. I'm suggesting future actions for future JDKs

On Fri, Apr 19, 2019, 8:53 PM Jacques Le Roux 
wrote:

> Hi Taher,
>
> Sounds like a plan, will you create those Jiras Taher?
>
> Maybe as subtasks of OFBIZ-10757, or simply reusing it w/o closing it
> until we swap?
>
> I believe the later is the easiest for all of us, but could be confusing
> after a moment.
>
> Jacques
>
> Le 17/04/2019 à 10:02, Taher Alkhateeb a écrit :
> > I see no problem in sticking with 8. It would also probably be
> > beneficial to get the code base to be compatible with Java 11 so that
> > people who want to upgrade are not restricted from doing so (which we
> > have done already). In other words, like Scott said, it should be a
> > "minimum" instead of a "maximum". When we were trying to upgrade we
> > faced some obstacles and resolved them. which means this needs to be a
> > task regularly done.
> >
> > So we could perhaps regularly create JIRAs like "Ensure OFBiz can
> > operate on Java version X" so that the code base is always forward
> > compatible.
> >
> > On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
> >  wrote:
> >> Reasons to increase the minimum version:
> >> - compelling new features
> >> - end of support of current minimum
> >>
> >> Reasons to not increase the minimum:
> >> - potential instability of new version
> >> - complicates the life of users and contributors who still use the
> existing
> >> minimum
> >> - lack of expertise in configuring and using new features
> >>
> >> I think every few months we should discuss it but I don't think it's
> worth
> >> shifting any time soon. The pros need to outweigh the cons, and
> personally
> >> I don't really see it at the moment.
> >>
> >> The end of support date for 11 probably shouldn't be a consideration at
> >> this point, by the time we even get close to that java 23 LTS will
> probably
> >> be a year old :)
> >>
> >> Regards
> >> Scott
> >>
> >> On Tue, 16 Apr 2019, 00:50 Michael Brohl, 
> wrote:
> >>
> >>> Ah, sorry Taher if I was not clear enough.
> >>>
> >>> Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
> >>> trunk, 18.12 and 17.12 to make the project independent from the short
> >>> cycled releases of the Oracle JDK and the subscription for use of the
> >>> Oracle JDK 8 LTS.
> >>>
> >>> I just recognized that Adopt JDK 11 LTS will be available until Sept.
> >>> 2022. If that is not a mistake I have to refine the timeline: we can
> >>> then switch to Adopt Open JDK 11 LTS on trunk right before the release
> >>> branch for 19.x is created. I guess that the future LTS releases will
> >>> have support for at least 4 years.
> >>>
> >>> That means we would remain Java 8 compatible for the releases 16 to 18
> >>> and announce the Java 11 dependency for release 19 and up. This should
> >>> give users enough time to plan, test and migrate.
> >>>
> >>> Users could work with release branch 19.x on Open JDK 11 for 2,5 years
> >>> then.
> >>>
> >>> For the future, I would suggest to introduce a new Open JDK LTS version
> >>> about 3-6 months after the first release, we might want to create a new
> >>> release branch in the course of this.
> >>>
> >>> What do you think?
> >>>
> >>> Regards,
> >>>
> >>> Michael Brohl
> >>>
> >>> ecomify GmbH - www.ecomify.de
> >>>
> >>>
> >>> Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:
> >>>> Hi Michael,
> >>>>
> >>>> So just to understand your suggestion clearly. Are you recommending
> >>>> that we switch from oracle JDK to open JDK now (in 18 and trunk) and
> >>>> introduce open jdk 11 in 2021?
> >>>>
> >>>> On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl <
> michael.br...@ecomify.de>
> >>> wrote:
> >>>>> Hi Scott, all,
> >>>>>
> >>>>> yes, Adopt Open JDK 8 LTS is supported at least untile September 2023
> >>> [1]
> >>>>> Thinking about this a bit more I second to stay with Open JDK 8 LTS
> for
> >>>>> release branches 17.12, 18.12 and trunk for now.
> >>>>>
> >>>>> Prof

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

I see no problem in sticking with 8. It would also probably be
beneficial to get the code base to be compatible with Java 11 so that
people who want to upgrade are not restricted from doing so (which we
have done already). In other words, like Scott said, it should be a
"minimum" instead of a "maximum". When we were trying to upgrade we
faced some obstacles and resolved them. which means this needs to be a
task regularly done.

So we could perhaps regularly create JIRAs like "Ensure OFBiz can
operate on Java version X" so that the code base is always forward
compatible.

On Tue, Apr 16, 2019 at 11:57 AM Scott Gray
 wrote:
>
> Reasons to increase the minimum version:
> - compelling new features
> - end of support of current minimum
>
> Reasons to not increase the minimum:
> - potential instability of new version
> - complicates the life of users and contributors who still use the existing
> minimum
> - lack of expertise in configuring and using new features
>
> I think every few months we should discuss it but I don't think it's worth
> shifting any time soon. The pros need to outweigh the cons, and personally
> I don't really see it at the moment.
>
> The end of support date for 11 probably shouldn't be a consideration at
> this point, by the time we even get close to that java 23 LTS will probably
> be a year old :)
>
> Regards
> Scott
>
> On Tue, 16 Apr 2019, 00:50 Michael Brohl,  wrote:
>
> > Ah, sorry Taher if I was not clear enough.
> >
> > Yes, I think we should do the switch to Adopt Open JDK 8 LTS now for
> > trunk, 18.12 and 17.12 to make the project independent from the short
> > cycled releases of the Oracle JDK and the subscription for use of the
> > Oracle JDK 8 LTS.
> >
> > I just recognized that Adopt JDK 11 LTS will be available until Sept.
> > 2022. If that is not a mistake I have to refine the timeline: we can
> > then switch to Adopt Open JDK 11 LTS on trunk right before the release
> > branch for 19.x is created. I guess that the future LTS releases will
> > have support for at least 4 years.
> >
> > That means we would remain Java 8 compatible for the releases 16 to 18
> > and announce the Java 11 dependency for release 19 and up. This should
> > give users enough time to plan, test and migrate.
> >
> > Users could work with release branch 19.x on Open JDK 11 for 2,5 years
> > then.
> >
> > For the future, I would suggest to introduce a new Open JDK LTS version
> > about 3-6 months after the first release, we might want to create a new
> > release branch in the course of this.
> >
> > What do you think?
> >
> > Regards,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 15.04.19 um 13:25 schrieb Taher Alkhateeb:
> > > Hi Michael,
> > >
> > > So just to understand your suggestion clearly. Are you recommending
> > > that we switch from oracle JDK to open JDK now (in 18 and trunk) and
> > > introduce open jdk 11 in 2021?
> > >
> > > On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl 
> > wrote:
> > >> Hi Scott, all,
> > >>
> > >> yes, Adopt Open JDK 8 LTS is supported at least untile September 2023
> > [1]
> > >>
> > >> Thinking about this a bit more I second to stay with Open JDK 8 LTS for
> > >> release branches 17.12, 18.12 and trunk for now.
> > >>
> > >> Professional users/ companies have a very conservative update strategy
> > >> for base technologies like the JDK and we should support it as long as
> > >> it is reasonable.
> > >>
> > >> So, my suggestion would be to introduce Adopt Open JDK 11 LTS with the
> > >> release branch 21.x, meaning that we change to JDK 11 right before the
> > >> release branch will be created. This gives us plenty of time to test
> > >> with Java 11 and we can introduce Java 11 features in the trunk after
> > >> that. So release branch 22.x would be the first to depend on Java 11.
> > >>
> > >> What do you think?
> > >>
> > >> Best regards,
> > >>
> > >> Michael Brohl
> > >>
> > >> ecomify GmbH - www.ecomify.de
> > >>
> > >>
> > >> [1] https://adoptopenjdk.net/support.html
> > >>
> > >>
> > >> Am 15.04.19 um 00:07 schrieb Scott Gray:
> > >>> My understanding was that openjdk would support java 8 until 2023.
> > >>>
> > >>> In the past our strategy used to b

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

Hi Michael,

So just to understand your suggestion clearly. Are you recommending
that we switch from oracle JDK to open JDK now (in 18 and trunk) and
introduce open jdk 11 in 2021?

On Mon, Apr 15, 2019 at 11:46 AM Michael Brohl  wrote:
>
> Hi Scott, all,
>
> yes, Adopt Open JDK 8 LTS is supported at least untile September 2023 [1]
>
> Thinking about this a bit more I second to stay with Open JDK 8 LTS for
> release branches 17.12, 18.12 and trunk for now.
>
> Professional users/ companies have a very conservative update strategy
> for base technologies like the JDK and we should support it as long as
> it is reasonable.
>
> So, my suggestion would be to introduce Adopt Open JDK 11 LTS with the
> release branch 21.x, meaning that we change to JDK 11 right before the
> release branch will be created. This gives us plenty of time to test
> with Java 11 and we can introduce Java 11 features in the trunk after
> that. So release branch 22.x would be the first to depend on Java 11.
>
> What do you think?
>
> Best regards,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> [1] https://adoptopenjdk.net/support.html
>
>
> Am 15.04.19 um 00:07 schrieb Scott Gray:
> > My understanding was that openjdk would support java 8 until 2023.
> >
> > In the past our strategy used to be that we should ensure the code base
> > would operate on newer java versions but keep our minimum required version
> > as low as possible.  That effectively allows users to run whatever version
> > they like.  So unless there are some compelling new features in java
> > 9/10/11 that we think we must have, I'd prefer it if we kept our minimum
> > supported version as low as possible.
> >
> > For myself, all client projects are still running java 8 (openjdk) so
> > before I could continue contributing to OFBiz I would have to figure out
> > how to run both versions on my machine with minimal disruption.  Since I
> > don't have a huge amount of spare time, I would probably just put it off
> > for quite a while and work on other things.
> >
> > I'm not trying to veto the idea, if the community wants to proceed then it
> > should but I doubt I'm the only contributor we'd be putting another hurdle
> > in front of.
> >
> > Regards
> > Scott
> >
> > On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb 
> > wrote:
> >
> >> Well, I could be mistaken but it seems EOL for java 8 is coming soon (2019
> >> commercial 2020 personal) [1]. This seems to be the case because the new
> >> LTS is out which is java 11.
> >>
> >> Also this new release model from oracle seems to be annoying which is
> >> pushing developers to adopt the openjdk instead. So I guess the reason for
> >> the upgrade is to strike two birds with one stone: upgrade java and switch
> >> to openjdk.
> >>
> >> With that being said, I don't have a firm opinion on upgrading and I just
> >> wanted to highlight things, I leave it to other folks to decide.
> >>
> >> [1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> >>
> >> On Sun, Apr 14, 2019, 10:38 PM Scott Gray 
> >> wrote:
> >>
> >>> That would probably halt any further contributions from me in the short
> >> to
> >>> medium term.
> >>>
> >>> Can I ask why we need to require 11 when 8 is supported through to 2023?
> >>>
> >>> Regards
> >>> Scott
> >>>
> >>> On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <
> >> jacques.le.r...@les7arts.com>
> >>> wrote:
> >>>
> >>>> If nobody disagree, I'll make the last move (ie ask for Java 11 in
> >>>> build.gradle) in 3 days
> >>>>
> >>>> Jacques
> >>>>
> >>>> Le 13/04/2019 à 12:34, Nicolas Malin a écrit :
> >>>>> On 13/04/2019 11:47, Jacques Le Roux wrote:
> >>>>>> I just tested, without surprise the trunk HEAD works with Java 11
> >>>>> I did the same with 18.12, works fine
> >>>>>
> >>>>> Nicolas
> >>>>>
> >>>>>
>

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

Hi Scott,

I'm not sure if this helps with running two versions simultaneously, but I
have multiple versions on my machine, and I setup the $JAVA_HOME to point
to /opt/jdk which in turn is a symlink to the JDK found in /opt/java/jdk8.
This way changing the jdk version is as fast as changing the symlink. I
even wrote a little script that looks up versions and I select the one most
appropriate.

Of course this is a side note, staying on Java 8 is fine by me given
getting more contributions from the community including yourself. I remain
on the fence.


On Mon, Apr 15, 2019, 1:08 AM Scott Gray 
wrote:

> My understanding was that openjdk would support java 8 until 2023.
>
> In the past our strategy used to be that we should ensure the code base
> would operate on newer java versions but keep our minimum required version
> as low as possible.  That effectively allows users to run whatever version
> they like.  So unless there are some compelling new features in java
> 9/10/11 that we think we must have, I'd prefer it if we kept our minimum
> supported version as low as possible.
>
> For myself, all client projects are still running java 8 (openjdk) so
> before I could continue contributing to OFBiz I would have to figure out
> how to run both versions on my machine with minimal disruption.  Since I
> don't have a huge amount of spare time, I would probably just put it off
> for quite a while and work on other things.
>
> I'm not trying to veto the idea, if the community wants to proceed then it
> should but I doubt I'm the only contributor we'd be putting another hurdle
> in front of.
>
> Regards
> Scott
>
> On Mon, 15 Apr 2019 at 09:09, Taher Alkhateeb 
> wrote:
>
> > Well, I could be mistaken but it seems EOL for java 8 is coming soon
> (2019
> > commercial 2020 personal) [1]. This seems to be the case because the new
> > LTS is out which is java 11.
> >
> > Also this new release model from oracle seems to be annoying which is
> > pushing developers to adopt the openjdk instead. So I guess the reason
> for
> > the upgrade is to strike two birds with one stone: upgrade java and
> switch
> > to openjdk.
> >
> > With that being said, I don't have a firm opinion on upgrading and I just
> > wanted to highlight things, I leave it to other folks to decide.
> >
> > [1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> >
> > On Sun, Apr 14, 2019, 10:38 PM Scott Gray 
> > wrote:
> >
> > > That would probably halt any further contributions from me in the short
> > to
> > > medium term.
> > >
> > > Can I ask why we need to require 11 when 8 is supported through to
> 2023?
> > >
> > > Regards
> > > Scott
> > >
> > > On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, <
> > jacques.le.r...@les7arts.com>
> > > wrote:
> > >
> > > > If nobody disagree, I'll make the last move (ie ask for Java 11 in
> > > > build.gradle) in 3 days
> > > >
> > > > Jacques
> > > >
> > > > Le 13/04/2019 à 12:34, Nicolas Malin a écrit :
> > > > > On 13/04/2019 11:47, Jacques Le Roux wrote:
> > > > >> I just tested, without surprise the trunk HEAD works with Java 11
> > > > >
> > > > > I did the same with 18.12, works fine
> > > > >
> > > > > Nicolas
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

Well, I could be mistaken but it seems EOL for java 8 is coming soon (2019
commercial 2020 personal) [1]. This seems to be the case because the new
LTS is out which is java 11.

Also this new release model from oracle seems to be annoying which is
pushing developers to adopt the openjdk instead. So I guess the reason for
the upgrade is to strike two birds with one stone: upgrade java and switch
to openjdk.

With that being said, I don't have a firm opinion on upgrading and I just
wanted to highlight things, I leave it to other folks to decide.

[1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

On Sun, Apr 14, 2019, 10:38 PM Scott Gray 
wrote:

> That would probably halt any further contributions from me in the short to
> medium term.
>
> Can I ask why we need to require 11 when 8 is supported through to 2023?
>
> Regards
> Scott
>
> On Sun, 14 Apr 2019, 23:37 Jacques Le Roux, 
> wrote:
>
> > If nobody disagree, I'll make the last move (ie ask for Java 11 in
> > build.gradle) in 3 days
> >
> > Jacques
> >
> > Le 13/04/2019 à 12:34, Nicolas Malin a écrit :
> > > On 13/04/2019 11:47, Jacques Le Roux wrote:
> > >> I just tested, without surprise the trunk HEAD works with Java 11
> > >
> > > I did the same with 18.12, works fine
> > >
> > > Nicolas
> > >
> > >
> >
>

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

I would suggest to make the move as soon as ready. This includes a
final patch and an update of README

On Fri, Apr 12, 2019 at 3:28 PM Jacques Le Roux
 wrote:
>
> Hi All,
>
> This is now done. When should we switch the trunk and R18 to Java 11?
>
> Thanks
>
> Jacques
>
> Le 05/03/2019 à 17:53, Nicolas Malin a écrit :
> > I agree with all proposal that make sens :)
> >
> > Nicolas
> >
> > On 04/03/2019 12:31, Jacques Le Roux wrote:
> >> +1
> >>
> >> Jacques
> >>
> >> Le 04/03/2019 à 11:34, Jacopo Cappellato a écrit :
> >>> I think that the simplest way to convey this message is to edit the README
> >>> document with a link to OpenJDK rather than Oracle JDK.
> >>>
> >>> Jacopo
> >>>
> >>> On Mon, Mar 4, 2019 at 10:22 AM Jacques Le Roux <
> >>> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>>> We should then make clear to our users that they will need to switch to
> >>>> OpenJDK if they want free security support.
> >>>>
> >>>> I guess most are aware, but maybe not small companies or single users.
> >>>>
> >>>> Jacques
> >>>>
> >>>> Le 28/02/2019 à 18:48, Michael Brohl a écrit :
> >>>>> +1 for Taher's suggestion.
> >>>>>
> >>>>> Thanks, Michael
> >>>>>
> >>>>> Am 28.02.19 um 12:32 schrieb Taher Alkhateeb:
> >>>>>> Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
> >>>>>> switch to java 11 on openjdk. This might provide stability expected by
> >>>>>> users as indicated by Michael.
> >>>>>>
> >>>>>> On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
> >>>>>>  wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> During discussions in the "Oracle Java release model changes and
> >>>> consequences for the project" thread, we created "Upgrade OFBiz to use 
> >>>> Java
> >>>> JDK
> >>>>>>> Version 11" aka OFBIZ-10757.
> >>>>>>>
> >>>>>>> There we began to discuss not only if we should switch to Java 11 LTS
> >>>> (Long Time Support), which is obviously the best current choice, but also
> >>>> which
> >>>>>>> Java JDK origin we should use OOTB.
> >>>>>>>
> >>>>>>> So we have few options and we should clarify what the community wants.
> >>>>>>>
> >>>>>>> Options are:
> >>>>>>>
> >>>>>>>1. Do we agree to use https://adoptopenjdk.net/releases.html as
> >>>> Java JDK origin OOTB?
> >>>>>>>2. Which branches should switch to Java1? Obviously the trunk and
> >>>> R18 should. Should R17, which is not yet released, switch also?
> >>>>>>> I hope we don't need a vote and will quickly find a consensus.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>
> >

Re: Reformat and homogenize displaying number

[Taher Alkhateeb]

looks good. I'm not sure what's the difference between accounting and
default formats though? And why do we have Integer format?

I would probably limit the types of formatting to percentage and
currency and quantity. Between those three you probably have all cases
covered no?

On Fri, Apr 5, 2019 at 7:58 PM Nicolas Malin  wrote:
>
> Hello
>
> I would improve an idea present by Charles STELTZLEN on issue OFBIZ-7532 [1]
>
> Currently when you display a number you have different possibility to
> format it :
>   * by ftl with <@ofbizAmount>
>   * by widget with 
>   * or everywhere with UtilFormatOut.formatDecimalNumber(number,
> template, locale)
>
> Main problem, we haven't a simple solution to homogenize display
> template number by purpose without check each case on source code.
> A example, if you display your invoice amount on 3 digits and your order
> amount on 6 digits, you can't use ofbizAmount or accounting-number so
> you do raw call :
>   * for invoice: UtilFormatOut.formatDecimalNumber(invoiceAmount,
> '##0.000', locale)
>   * for order: UtilFormatOut.formatDecimalNumber(invoiceAmount,
> '##0.00', locale)
>
> on ftl
> ${Static["org.apache.ofbiz.base.util.UtilFormatOut"].formatDecimalNumber(invoiceAmount,
> '##0.000', locale)}
> on widget
>  
>
> All displaying template pass through new util
> *UtilFormatOut.formatNumber* as generic function to works with a format
> type present on properties. With this idea, you can use on you specific
> source code your own format and override standard ofbiz format.
>
> I will suggest a patch on issue OFBIZ-7532 [1]
>
> I thinks it's important feature to help customization so if you have a
> suggest, your welcome :)
>
> Cheers,
> Nicolas
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-7532
>
> --
> logoNrd 
> Nicolas Malin
> The apache way  : *Charity* Apache’s mission
> is providing software for the public good.
> informat...@nereide.fr
> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
> Apache OFBiz |The Apache Way
> |réseau LE 

Re: Strong dependency of OFBiz build on JCenter

[Taher Alkhateeb]

Ahh I get it now.

In that case the challenge might be making sure the naming and transitive
dependencies are equivalent on both sides.

Maybe another solution is to create two files, one for maven and the other
for jcenter each with its own unique set of dependencies that can be tested
and ensured correct behavior. This way differences in names or transitive
dependencies are not an issue.

On Sat, Mar 23, 2019, 5:09 PM Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Just to clarify, I was suggesting that we could add more repositories, not
> replace Jcenter with another one: the redundancy would mitigate the risk of
> unavailability.
>
> Jacopo
>
> On Fri, Mar 22, 2019 at 6:07 PM Taher Alkhateeb <
> slidingfilame...@gmail.com>
> wrote:
>
> > Whatever repository you choose, there is always the risk of going down.
> >
> > To mitigate this risk, you can (after deploying the system) use the -
> > -offline flag when running gradle. Alternatively you can simply run the
> > java - jar command.
> >
> > On Fri, Mar 22, 2019, 10:41 AM Swapnil M Mane <
> > swapnil.m...@hotwaxsystems.com> wrote:
> >
> > > Hello team,
> > >
> > > Yesterday JCenter was down for some time, due to which I was unable to
> > > start the OFBiz server (because the build was failed).
> > > Status of JCenter can be found at [1].
> > >
> > > This is a severe issue because it may be possible during any production
> > > deployment, JCenter is down. Do we have any solution for the issue?
> > > Please let me know if I am missing anything.
> > >
> > > [1] https://status.bintray.com/
> > >
> > > Here is stacktrace of build failure.
> > > ==
> > > *> Task :compileTestJava* FAILED
> > >
> > > FAILURE: Build failed with an exception.
> > >
> > > * What went wrong:
> > > Execution failed for task ':compileTestJava'.
> > > > Could not resolve all files for configuration
> ':testCompileClasspath'.
> > >> Could not resolve org.mockito:mockito-core:2.+.
> > >  Required by:
> > >  project :
> > >   > Failed to list versions for org.mockito:mockito-core.
> > >  > Unable to load Maven meta-data from
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > .
> > > > Could not HEAD '
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > '.
> > >> jcenter.bintray.com
> > >   > Failed to list versions for org.mockito:mockito-core.
> > >  > Unable to load Maven meta-data from
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > .
> > > > Could not HEAD '
> > >
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> > > <
> > >
> >
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> > > >
> > > '.
> > >> jcenter.bintray.com
> > >
> > > * Try:
> > > Run with *--stacktrace* option to get the stack trace. Run with
> *--info*
> > or
> > > *--debug* option to get more log output. Run with *--scan* to get full
> > > insights.
> > >
> > > * Get more help at *https://help.gradle.org
> > > <
> > >
> >
> https://www.google.com/url?q=https://help.gradle.org=D=hangouts=1553323118761000=AFQjCNF7cVissA1Dr2SsZDCnovsUYDUE7Q
> > > >*
> > >
> > > *BUILD FAILED* in 1m 14s
> > > ==
> > >
> > > - Best Regards,
> > > Swapnil M Mane,
> > > www.hotwax.co
> > >
> >
>

Re: Strong dependency of OFBiz build on JCenter

[Taher Alkhateeb]

Whatever repository you choose, there is always the risk of going down.

To mitigate this risk, you can (after deploying the system) use the -
-offline flag when running gradle. Alternatively you can simply run the
java - jar command.

On Fri, Mar 22, 2019, 10:41 AM Swapnil M Mane <
swapnil.m...@hotwaxsystems.com> wrote:

> Hello team,
>
> Yesterday JCenter was down for some time, due to which I was unable to
> start the OFBiz server (because the build was failed).
> Status of JCenter can be found at [1].
>
> This is a severe issue because it may be possible during any production
> deployment, JCenter is down. Do we have any solution for the issue?
> Please let me know if I am missing anything.
>
> [1] https://status.bintray.com/
>
> Here is stacktrace of build failure.
> ==
> *> Task :compileTestJava* FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':compileTestJava'.
> > Could not resolve all files for configuration ':testCompileClasspath'.
>> Could not resolve org.mockito:mockito-core:2.+.
>  Required by:
>  project :
>   > Failed to list versions for org.mockito:mockito-core.
>  > Unable to load Maven meta-data from
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> .
> > Could not HEAD '
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> '.
>> jcenter.bintray.com
>   > Failed to list versions for org.mockito:mockito-core.
>  > Unable to load Maven meta-data from
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> .
> > Could not HEAD '
> https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml
> <
> https://www.google.com/url?q=https://jcenter.bintray.com/org/mockito/mockito-core/maven-metadata.xml=D=hangouts=1553323118761000=AFQjCNG-BdHXv5XipPli0zc2Lzk033SwEg
> >
> '.
>> jcenter.bintray.com
>
> * Try:
> Run with *--stacktrace* option to get the stack trace. Run with *--info* or
> *--debug* option to get more log output. Run with *--scan* to get full
> insights.
>
> * Get more help at *https://help.gradle.org
> <
> https://www.google.com/url?q=https://help.gradle.org=D=hangouts=1553323118761000=AFQjCNF7cVissA1Dr2SsZDCnovsUYDUE7Q
> >*
>
> *BUILD FAILED* in 1m 14s
> ==
>
> - Best Regards,
> Swapnil M Mane,
> www.hotwax.co
>

Re: Removing the ‘:terminateOfbiz’ Gradle task

[Taher Alkhateeb]

I think I might prefer to keep it. Perhaps adjusting the ps command might
better solve the issue. I use this feature regularly myself.

On Sun, Mar 17, 2019, 11:59 PM Mathieu Lirzin 
wrote:

> Hello,
>
> The ‘:terminateOfbiz’ Gradle task is meant to be run when ‘./gradlew
> ofbiz --shutdown’ doesn't work.  Unfortunately this task is not working
> on my GNU/linux system because the output of ‘ps ax’ cuts long lines.
> As a consequence Gradle is not able to grep
> "org.apache.ofbiz.base.start.Start" even if it is actually part of the
> process command line as seen by the operating system.  As a reminder,
> here is the implementation of that task:
>
> task terminateOfbiz(group: ofbizServer,
> description: 'Force termination of any running OFBiz servers, only
> use if \"--shutdown\" command fails') {
> doLast {
> if (os.contains('windows')) {
> Runtime.getRuntime().exec("wmic process where
> \"CommandLine Like \'%org.apache.ofbiz.base.start.Start%\'\" Call
> Terminate")
> } else {
> def processOutput = new ByteArrayOutputStream()
> exec {
> commandLine 'ps', 'ax'
> standardOutput = processOutput
> }
>
> processOutput.toString().split(System.lineSeparator()).each { line ->
> if (line ==~
> /.*org\.apache\.ofbiz\.base\.start\.Start.*/) {
> exec { commandLine 'kill', '-9',
> line.tokenize().first() }
> }
> }
> }
> }
> }
>
> While it might be considered a bug at first hand, I personnally think
> this failure is more a symptom of a desperate endeavour which is to
> guess how the system of a user is managing its processes.  As a
> consequence I will suggest to simply remove this task to not make false
> promises to users and let them manage the processes on their system by
> themselves. :-)
>
> What do people think?
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

Re: [OPTIONS] Java 11 and Java JDK origin

[Taher Alkhateeb]

Perhaps we can keep ofbiz 17.12 on java 8, and let 18.12 and trunk
switch to java 11 on openjdk. This might provide stability expected by
users as indicated by Michael.

On Thu, Feb 28, 2019 at 2:27 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> During discussions in the "Oracle Java release model changes and consequences 
> for the project" thread, we created "Upgrade OFBiz to use Java JDK
> Version 11" aka OFBIZ-10757.
>
> There we began to discuss not only if we should switch to Java 11 LTS (Long 
> Time Support), which is obviously the best current choice, but also which
> Java JDK origin we should use OOTB.
>
> So we have few options and we should clarify what the community wants.
>
> Options are:
>
>  1. Do we agree to use https://adoptopenjdk.net/releases.html as Java JDK 
> origin OOTB?
>  2. Which branches should switch to Java1? Obviously the trunk and R18 
> should. Should R17, which is not yet released, switch also?
>
> I hope we don't need a vote and will quickly find a consensus.
>
> Thanks
>
> Jacques
>

Re: Pending works from Christian Carlow

[Taher Alkhateeb]

I think it's not a big deal just a side comment. We have too many JIRAs and
we really could benefit from cleaning them up. Perhaps after you close them
all you can just mention those tickets here as a reference for the future.

On Tue, Feb 19, 2019, 8:41 PM Jacques Le Roux  I agree about the value of these Jiras.
>
> What do you mean/think-about exactly by
>
> <>
>
> ?
>
> Is Michael's answer sufficient? You can indeed search for Christian's
> closed Jira with patches.
>
> Jacques
>
> Le 19/02/2019 à 16:20, Taher Alkhateeb a écrit :
> > +1
> >
> > It would be nice to highlight somehow the tickets that have patches as
> > I can see some value in the work in these JIRAs.
> >
> > On Tue, Feb 19, 2019 at 4:22 PM Jacques Le Roux
> >  wrote:
> >> Hi,
> >>
> >> There are a bunch of obsolete patches from Christian Carlow like in
> https://issues.apache.org/jira/browse/OFBIZ-6418 and related (from there)
> >>
> >> I suggest we close all of them as won't do and will do so in 1 week
> >>
> >> Jacques
> >>
>

Welcome to Mathieu Lirzin as new committer!

[Taher Alkhateeb]

The OFBiz PMC has invited Mathieu Lirzin to become a new committer and
we are happy to announce that he has accepted this role.

Some of the reasons for inviting Mathieu include:

- He is invested in the OFBiz project and has delivered substantial
work to the code base.
- He has demonstrated solid technical skills.
- He adopts a professional attitude towards coding and software development.
- He engages thoughtfully with others and likes to work with the community.

Please join me in welcoming and congratulating Mathieu!

Cheers,
Taher Alkhateeb

Re: Pending works from Christian Carlow

[Taher Alkhateeb]

+1

It would be nice to highlight somehow the tickets that have patches as
I can see some value in the work in these JIRAs.

On Tue, Feb 19, 2019 at 4:22 PM Jacques Le Roux
 wrote:
>
> Hi,
>
> There are a bunch of obsolete patches from Christian Carlow like in 
> https://issues.apache.org/jira/browse/OFBIZ-6418 and related (from there)
>
> I suggest we close all of them as won't do and will do so in 1 week
>
> Jacques
>

Re: Enabling HTTP/2 in the embedded Tomcat connectors

[Taher Alkhateeb]

clean and simple implementation, +1

on a side note, I wonder if we need to set any of the http2 attributes
listed in [1] or whether the defaults are okay.

[1] https://tomcat.apache.org/tomcat-8.5-doc/config/http2.html

On Mon, Feb 18, 2019 at 5:58 PM Jacques Le Roux
 wrote:
>
> Hi Jacopo,
>
> Sounds good to me, we can always easily revert in case of unexpected issue 
> anyway
>
> Thanks
>
> Jacques
>
> Le 18/02/2019 à 11:43, Jacopo Cappellato a écrit :
> > Hi all,
> >
> > I think it is time to enable the instance of Tomcat that is embedded in
> > OFBiz to communicate using the HTTP/2 protocol, when the client supports it.
> > For your review, before I commit, I am pasting here the patch that will
> > enable it (it is quite simple) .
> > In it I have enabled HTTP/2 by default, by setting upgradeProtocol=true, in
> > the http and https connectors (but they will continue to support also
> > HTTP/1.1); if the new property "upgradeProtocol", that I have introduced
> > for this specific purpose, is not set (as it would be the case in custom
> > configuration files) then the new protocol will not be enabled. Does the
> > approach look good to you?
> >
> > Thanks,
> >
> > Jacopo
> >
> > PS: you can test it, for example, using curl:
> >
> > curl -vso /dev/null --http2 http://localhost:8080
> >
> >
> > Index: framework/catalina/ofbiz-component.xml
> > ===
> > --- framework/catalina/ofbiz-component.xml (revision 1853787)
> > +++ framework/catalina/ofbiz-component.xml (working copy)
> > @@ -99,6 +99,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > @@ -128,6 +129,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > @@ -183,6 +185,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > @@ -194,6 +197,7 @@
> >   
> >   
> >   
> > +
> >   
> >   
> >   
> > Index:
> > framework/catalina/src/main/java/org/apache/ofbiz/catalina/container/CatalinaContainer.java
> > ===
> > ---
> > framework/catalina/src/main/java/org/apache/ofbiz/catalina/container/CatalinaContainer.java
> > (revision
> > 1853787)
> > +++
> > framework/catalina/src/main/java/org/apache/ofbiz/catalina/container/CatalinaContainer.java
> > (working
> > copy)
> > @@ -63,6 +63,7 @@
> >   import org.apache.catalina.util.ServerInfo;
> >   import org.apache.catalina.valves.AccessLogValve;
> >   import org.apache.catalina.webresources.StandardRoot;
> > +import org.apache.coyote.http2.Http2Protocol;
> >   import org.apache.ofbiz.base.component.ComponentConfig;
> >   import org.apache.ofbiz.base.concurrent.ExecutionPool;
> >   import org.apache.ofbiz.base.container.Container;
> > @@ -417,9 +418,12 @@
> >   private Connector prepareConnector(Property connectorProp) {
> >   Connector connector = new
> > Connector(ContainerConfig.getPropertyValue(connectorProp, "protocol",
> > "HTTP/1.1"));
> >   connector.setPort(ContainerConfig.getPropertyValue(connectorProp,
> > "port", 0) + Start.getInstance().getConfig().portOffset);
> > -
> > +if ("true".equals(ContainerConfig.getPropertyValue(connectorProp,
> > "upgradeProtocol", "false"))) {
> > +connector.addUpgradeProtocol(new Http2Protocol());
> > +Debug.logInfo("Tomcat " + connector + ": enabled HTTP/2",
> > module);
> > +}
> >   connectorProp.properties.values().stream()
> > -.filter(prop -> !"protocol".equals(prop.name) &&
> > !"port".equals(prop.name))
> > +.filter(prop -> !"protocol".equals(prop.name) &&
> > !"upgradeProtocol".equals(prop.name) && !"port".equals(prop.name))
> >   .forEach(prop -> {
> >   if (IntrospectionUtils.setProperty(connector, prop.name,
> > prop.value)) {
> >   if (prop.name.indexOf("Pass") != -1) {
> >

Re: Oracle Java release model changes and consequences for the project

[Taher Alkhateeb]

I think it would be great to upgrade to JDK 11 on openjdk and get this
issue over with. For those who want to switch to oracle JDK, they can
easily do so, but we should perhaps stabilize on openjdk by default
and get the build system and documentation pointing to openjdk as a
long term solution to this problem.

On Wed, Feb 13, 2019 at 2:39 PM Michael Brohl  wrote:
>
> Hi Jacopo,
>
> an alternative would be https://adoptopenjdk.net/ which provides
> prebuild packages. The scripts for package building are Apache 2.0
> licensed and they are providing Java 8 and 11 LTS versions.
>
> Seems a good fit to me.
>
> Since Java 8 is LTS there, we do not necessarily have to upgrade OFBiz
> for the use of Java 11.
>
> Best regards,
>
> Michael
>
>
> Am 13.02.19 um 11:06 schrieb Jacopo Cappellato:
> > Considering that now Oracle JDKs are no more free for commercial use, I
> > think that as a community we should make it a priority to suggest a
> > different Java build in the README and other public documents.
> > The simplest alternative (because it is the closest to Oracle JDK) is the
> > Open JDK 11 maintained by Oracle and distributed from:
> > https://jdk.java.net/11/
> >
> > In my opinion our README should point to it rather than:
> > http://www.oracle.com/technetwork/java/javase/downloads/index.html
> > as it is now.
> > However, before we can do it, we have to resolve:
> > https://issues.apache.org/jira/browse/OFBIZ-10757
> > which should not be too difficult to achieve.
> >
> > Just my two cents,
> >
> > Jacopo
> >
> >
> > On Wed, Oct 24, 2018 at 2:21 PM James Yong  wrote:
> >
> >> Answering my last question.
> >>  From the download page for Oracle JDK 11, demo purpose is allowed.
> >>
> >> On 2018/10/24 07:38:19, James Yong  wrote:
> >>> Hi all,
> >>>
> >>> Will the release model and licensing changes impact our demos hosted
> >> with Apache Software Foundation?
> >>> Regards,
> >>> James
> >>>
> >>> On 2018/10/24 06:54:05, James Yong  wrote:
>  Hi all,
> 
>  OFBiz can be used as an application framework and not all business
> >> use-case justify the yearly price-tag of Oracle JDK. Given that more
> >> products(1) are moving to support OpenJDK, should OFBiz follow?
>  Regards,
>  James
> 
>  (1) See plan of Atlasians product to support OpenJDK
> 
> >> https://community.atlassian.com/t5/Jira-discussions/Java-11-and-OpenJDK-support-for-Atlassian-Server-amp-Data-Center/m-p/872998#M4575
> 
>  On 2018/07/31 06:35:46, Jacques Le Roux 
> >> wrote:
> > Hi Michael,
> >
> > How (by which mean) do you envision to "actively inform users about
> >> our roadmap", blog, wiki or embedded documentation?
> > It seems the blog is not reaching all our users (needs attention).
> >> Maybe an initial statement could be used there though.
> > The wiki is slowly deprecating in favour of the embedded
> >> documentation. So I guess we will use the embedded documentation for
> >> lasting information, right?
> > BTW All, I want to close OFBIZ-9226 "Check that OFBiz runs and
> >> compile with Oracle JDK 9 (Java 9)" as unresolved and create a new similar
> >> issue for
> > Java 11, what do you think?
> >
> > Jacques
> >
> >
> > Le 28/07/2018 à 13:29, Michael Brohl a écrit :
> >> Hi Mathieu,
> >>
> >> my goal is to actively inform users about our roadmap and provide
> >> information on how the project will deal with the new Java release model.
> >> Users
> >> testing OFBiz for their needs in a professional environment also
> >> check if a project has answers to these questions so I am wrapping my mind
> >> around it.
> >> This is just to make clear that I am not eager to switch to newer
> >> Java versions just for the sake of it.
> >>
> >> Am 28.07.18 um 12:54 schrieb Mathieu Lirzin:
>  I wonder if we should base the OFBiz 17.12 release on Java 8 or
> >> Java
>  11. We have no fixed release date yet so we might have time to
> >> do it.
>  Another way would be to make a new branch which will support
> >> Java 11.
>  What do people think?
> >>> I think OFBiz should be conservative in its choices.
> >> I agree!
> >>
> >>> Given the fact Java 11 is not release yet or is about to be
> >> released,
> >> Java 11 will be released as GA in Sept 18. At the same time,
> >> non-subscribed users will get no updates for Java 8 any more.
> >>> OFBiz should keep compatibity with the previous LTS release
> >> meaning java 8.  Of course
> >> Yes, you are right. If you focus on subscribed users, they will
> >> get Java 8 support until September 2023 (2026 for extended subscription).
> >> So following my thoughts to assume that users will subscribe, we
> >> can stay with Java 8 for a while.
> >> On the other hand, if we test Java 11 and find that we will have
> >> few issues we can easily handle, it could be a good idea to make the switch
> >> with
> >> release 17.12.
> >>

Re: JobManager/JobPoller issues

[Taher Alkhateeb]

Hi Scott,

It seems we have some issues currently with our job scheduler [1]
which seems to be some sort of memory leak. We are also experiencing
some performance issues and other anomalies. It seems like a good time
to perhaps revisit the whole thing.

Are you suggesting to replace LinkedBlockingQueue with
PriorityBlockingQueue? If so I think it might actually be a better
option. I think being unbounded _might_ actually resolve some of the
pain points we're facing. I didn't get why it's not a drop-in
replacement though. It matches the signature of the call in the
executor service unless i'm missing something somewhere?

[1] https://issues.apache.org/jira/browse/OFBIZ-10592

On Wed, Jan 30, 2019 at 10:59 PM Scott Gray
 wrote:
>
> Hi folks,
>
> Just jotting down some issues with the JobManager over noticed over the
> last few days:
> 1. min-threads in serviceengine.xml is never exceeded unless the job count
> in the queue exceeds 5000 (or whatever is configured).  Is this not obvious
> to anyone else?  I don't think this was the behavior prior to a refactoring
> a few years ago.
> 2. The advice on the number of threads to use doesn't seem good to me, it
> assumes your jobs are CPU bound when in my experience they are more likely
> to be I/O bound while making db or external API calls, sending emails etc.
> With the default setup, it only takes two long running jobs to effectively
> block the processing of any others until the queue hits 5000 and the other
> threads are finally opened up.  If you're not quickly maxing out the queue
> then any other jobs are stuck until the slow jobs finally complete.
> 3. Purging old jobs doesn't seem to be well implemented to me, from what
> I've seen the system is only capable of clearing a few hundred per minute
> and if you've filled the queue with them then regular jobs have to queue
> behind them and can take many minutes to finally be executed.
>
> I'm wondering if anyone has experimented with reducing the queue the size?
> I'm considering reducing it to say 100 jobs per thread (along with
> increasing the thread count).  In theory it would reduce the time real jobs
> have to sit behind PurgeJobs and would also open up additional threads for
> use earlier.
>
> Alternatively I've pondered trying a PriorityBlockingQueue for the job
> queue (unfortunately the implementation is unbounded though so it isn't a
> drop-in replacement) so that PurgeJobs always sit at the back of the
> queue.  It might also allow prioritizing certain "user facing" jobs (such
> as asynchronous data imports) over lower priority less time critical jobs.
> Maybe another option (or in conjunction) is some sort of "swim-lane"
> queue/executor that allocates jobs to threads based on prior execution
> speed so that slow running jobs can never use up all threads and block
> faster jobs.
>
> Any thoughts/experiences you have to share would be appreciated.
>
> Thanks
> Scott

Re: Writing a Simple-service for simple-methods

[Taher Alkhateeb]

Hi Rahul,

Generally it is recommend to avoid simple services as they are deprecated
and being phased out. You might want to use Java, groovy or entity-auto
services instead.

On Sat, Jan 26, 2019, 10:49 AM Rahul Utkoor
 Hello,
> I just started working on ofbiz. As a part of my work I was supposed to
> write a service for "*create customer*" functionality in Party application.
> I wonder why there are no services written for some of the simple-method
> events.
> And also why there is no java service written for "*create customer*" while
> there is java service for "*create Person*"?
> And what are the complexities involved in defining a service for "*create
> customer*" simple-method?
> Please help me by pointing in the right direction.
> --
>
> *Thanks & Regards,*
> *Rahul.*
>

Re: git commit workflow for ofbiz

[Taher Alkhateeb]

+1

On Fri, Jan 25, 2019, 1:29 PM Deepak Dixit  Looks good Michael.
>
> Thanks & Regards
> --
> Deepak Dixit
>
>
>
> On Fri, Jan 25, 2019 at 1:54 PM Michael Brohl 
> wrote:
>
> > Hi everyone,
> >
> > thank you all for your feedback. It seems that we have consensus to
> > switch over to Git.
> >
> > I'll prepare a Wiki page to start documentation on the processes and the
> > needed steps to make the switch. I'll take over the topics mentioned in
> > this thread (Taher's initial proposed workflow, Jacques notes about
> > build scripts, auto-props etc.).
> >
> > We should then finish the process description, maybe discuss and decide
> > upon and then plan the technical switch.
> >
> > Makes sense?
> >
> > Best regards,
> >
> > Michael
> >
> >
> >
> > Am 23.01.19 um 07:37 schrieb Jacopo Cappellato:
> > > +1 for Git!
> > >
> > > Jacopo
> > >
> > > On Sat, Jan 12, 2019 at 1:01 PM Michael Brohl <
> michael.br...@ecomify.de>
> > > wrote:
> > >
> > >> Hi all,
> > >>
> > >> I'd like to revive this discussion again.
> > >>
> > >> Personally, I am now working with git for a few years and almost all
> > >> customer and company related projects have moved to git over time. In
> > >> the beginning, I found git complicated and less straight forward, a
> bit
> > >> like Adrian mentioned in [1]. But once I have understood the main
> > >> principles and get used to it, I won't like to switch back to svn ever
> > >> since.
> > >>
> > >> In my opinion, using git would make things much easier for
> > >> collaboration. Taher thoroughly described them in the inital thread
> > >> message.
> > >>
> > >> An important point for me would be that we could prevent premature
> > >> commits just to get things to be tested. Features which take some time
> > >> to be worked on or tested can be in separate branches which can be
> > >> updated with the main branch constantly.
> > >>
> > >> So, from my point of view, we should again have a disussion and/or
> vote
> > >> to see if the overall opinions have changed and if we could move to
> git.
> > >>
> > >> Thanks,
> > >>
> > >> Michael
> > >>
> > >>
> > >> [1] http://markmail.org/message/m4z5b5qevqx7n6u7
> > >>
> > >> Am 24.10.15 um 10:23 schrieb Taher Alkhateeb:
> > >>> Hello Everyone,
> > >>>
> > >>> I refer to the discussion about moving to git initiated by Hans
> Bakker
> > >> back in April. After a long, long discussion followed by a vote the
> > >> community agreed that we should develop a more elaborate and formal
> > >> workflow to vote on, as the initial vote was not detailed enough.
> Based
> > on
> > >> that, I have proposed a workflow to see if people are interested in
> it.
> > But
> > >> the topic just slowly died out.
> > >>> The links to both threads are listed below. I understand that there
> was
> > >> a lot of interest in the community as the thread was really long. I
> > would
> > >> like to revive the discussion and see if people are still interested
> in
> > >> implementing / amending the proposed workflow if they find it
> appealing.
> > >>> discussion and vote thread :
> > >>
> >
> http://ofbiz.markmail.org/message/ldo77qz34kte4gat?q=move+to+git+from:%22Hans+Bakker%22+list:org.apache.ofbiz.dev=1
> > >>> workflow proposition thread :
> > >>
> > http://ofbiz.markmail.org/message/nkthnbsgt37orynu?q=git+commit+workflow
> > >>> Taher Alkhateeb
> > >>> - Original Message -
> > >>>
> > >>> From: "Taher Alkhateeb" 
> > >>> To: dev@ofbiz.apache.org
> > >>> Sent: Wednesday, 24 June, 2015 5:25:31 PM
> > >>> Subject: Re: git commit workflow for ofbiz
> > >>>
> > >>>
> > >>> Hi Jacques,
> > >>>
> > >>> Very good read, thank you for sharing.
> > >>>
> > >>> The person who wrote complaining about gitflow (I think Adam Ruka)
> > makes
> > >> a good point. He prefers linear to branched history. I do not mind
> > branched
> > >> history myself as I know 

Re: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality

[Taher Alkhateeb]

+1 to default off

On Sat, Jan 19, 2019 at 7:25 PM Michael Brohl  wrote:
>
> No, we are mainly discussing if we should turn off the JWT functionality
> in the default setting and what could be done to make the current
> implementation more secure / fail proof.
>
>
> Am 19.01.19 um 16:54 schrieb Shi Jinghai:
> > I've just reviewed the code of JWT implements. Sorry for my bad English, 
> > I'm a bit lost, are we discussing which one is more secure, the tomcat 
> > session or JWT?
> >
> >
> > -邮件原件-
> > 发件人: Michael Brohl [mailto:michael.br...@ecomify.de]
> > 发送时间: 2019年1月19日 19:58
> > 收件人: dev@ofbiz.apache.org
> > 主题: [DISCUSSION] turn off OOTB JWT authorization/SSO functionality
> >
> > Hi all,
> >
> > during my work in [1] I realized that the OOTB JWT authorization /
> > single sign on is switched on by default. The logic to retrieve the
> > secret key uses a default if there is no configuration in SystemProperty
> > or security.properties.
> >
> > This makes it easy to prepare a JWT (e.g. by using [2] or [3]) and login
> > using a guessed userLoginId and this token (which can be retrieved from
> > the code).
> >
> > I think we should secure this so that this cannot be done in an OOTB
> > setting with the following additions:
> >
> > 1. make it configurable through a property which is initially turned
> > off. I think thi is better than commenting the preprocessor in/out
> > because it can be better integrated in (custom) configuration mechanisms.
> >
> > 2. don't use a default secret key if none is provided. The
> > user/administrator must explicitly set a secret key and should know what
> > he is doing then.
> >
> > 3. don't proceed if no secret key can be found (do not attempt a login
> > using the JWT)
> >
> >
> > I think that we should turn this feature off by default for the
> > following reasons:
> >
> > 1. it opens up a security hole if the user does not remove the
> > checkJWTLogin preprocessor (see above)
> >
> > 2. the functionality to have a single sign on between two OFBiz
> > instances will only be used in rare cases (I think). It is only designed
> > for this special case and cannot be used for standard single sign on
> > scenarios with other systems.
> >
> > 3. if it is not used, it will still try to read the authorization
> > header, key etc. *on every request*
> >
> >
> > What do think?
> >
> > Regards,
> >
> > Michael
> >
> >
> > [1] https://issues.apache.org/jira/browse/OFBIZ-10814
> >
> > [2] https://jwt.io/
> >
> > [3] http://jwtbuilder.jamiekurtz.com/
> >
> >
> >
> >
>