Re: breaking ofbiz piece by piece - expose parts to outside
Hi Nicolas, Thanks for the support. I do hope we get the ball roling at one point. I won't be attending ApacheCon this year. I think it's been 13 years since my last ApacheCon :). Feel free to start merging changes. Regards, Eugen La 22.03.2024 18:23, Nicolas Malin a scris: Thanks both for your work and analyze ! I agree on the first point, we need to move forward to release the next OFBiz version and after we can breaking the wall :D If the person are present at the eu apachecon it would be nice place to start a workshop on face to face ? Nicolas -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: breaking ofbiz piece by piece - expose parts to outside
level wiki page to coordinate refactoring efforts since that will help inform what refactoring tasks we might want to see completed before creating the new release branch. I have other refactoring topics I would like to discuss at some point - such as considering whether we should bring plugins maintained by the project into the ofbiz-framework repository, or whether we should set cookies at site root to authenticate a user across all applications at once - but the above seems enough to grapple with for the time being. Thanks, Dan. On Sat, 17 Feb 2024 at 23:15, Eugen Stan wrote: Hi, Did anyone have time to check out the PR? I did rebase it on current trunk. https://github.com/apache/ofbiz-framework/pull/678 Thanks, Eugen La 02.01.2024 14:50, Eugen Stan a scris: Hello, Happy new year! I hope you had a great 2023. Has anyone had time to look over the exploratory work? If you have, please don't be shy, share your findings, good or bad. It would be great if we can work on concrete examples. I am still available to answer any questions and improve on the PR's to make the changes part of OFBiz moving forward. Let's make parts of OFBiz available as libraries so they can be used in other projects (ofbiz tooling) / other ways of building OFBiz. Regards, Eugen La 09.12.2023 01:04, Eugen Stan a scris: Hi, I pushed some changes that significantly reduce the number of lines changed and also the possibility of breakage: - merged back UtilValidateDateTime and UtilValidateEmpty into UtilValidate - moved some methods from *Runtime -> former class. If you test the changes and find some issues please let me know. I am willing to work to fix those and make the PR mergeable. I also did an exploratory work to see what would it take to have entity engine as a library see https://github.com/ieugen/ofbiz-framework/pull/3 On top of this PR, it adds only 670 lines and remove 370. Very small price to pay IMO. I have partial integration tests running. I have added some comments related to the blockers (EntityEca, Tennant) They should be doable, but I need more info / help. To reiterate, please let me know of any issue you find and I will work to fix it. Regards, Eugen La 07.12.2023 20:55, Eugen Stan a scris: Hi Michael, Thank you for taking a look. I will reply inline. I did a demo project to support my case https://github.com/ieugen/ofbiz-tooling-demo . La 07.12.2023 12:53, Michael Brohl a scris: Hi Eugen, can you give us some explanations/examples why this is a useful change? What are the downsides? I don't see any downsides. There might be some breaking changes on upgrades. We could work to mitigate them - will explain bellow. I see a lot of changes in the base API like UtilValidate, UtilProperties etc. which will brake almost every custom project out there. Have you tried it in your projects? Do you know how many fail? All the integrations tests pass. Also we could do some work to mitigate those braking changes: - copy those methods back to the classes they came from - implement delegation: add a method with same signature that calls on the class from base/util (UtilValidate calls UtilValidateEmpty). IMO this should be a transition period until the code is cleaned up. I did not do the mitigations because this is intendend as a POC to be prepared once we decide it's a good direction. Also - I don't have access to 'all the projects out there' to test. The changes also need explanation. For example: why the split of UtilValidate to UtilValidateEmpty etc. Because of the cyclic dependency between classes. There is a LOT of cyclic dependencies which IMO is a code smell. UtilValidate depens on UtilProperties which depens on UtilValidate. There are numerous cases for this. If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you will see them. ( I posted an image on gh issue) https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198 I think we need to have very strong advantages to make those changes and currently I do not see them. We open OFBiz to be used as libraries. Then developers can use things like entity-engine, datafile, bits to build tooling as CLI or services that integrate with OFBiz. - It opens a path forward to inovation - It will make life of integrators MUCH more easy as it will provide java API's for them to do integrations - It exposes the dependencies by making them explicit (as gradle deps) - Developers can focus on a smaller part of the code base: component loading, XML parsing, entity engine without worrying about the rest of the code. - It will allow users to build tools and ofbiz components and package them as jar files (component/datafile is a component as a jar file - it depends on base/util and base/crypto - but nothing else from OFBiz). - It will facilitate the developement of proper java API's - now OFBiz is an implementation only - the API is the implementation. I would like to build some import tooling that uses th
Re: breaking ofbiz piece by piece - expose parts to outside
Hi, Did anyone have time to check out the PR? I did rebase it on current trunk. https://github.com/apache/ofbiz-framework/pull/678 Thanks, Eugen La 02.01.2024 14:50, Eugen Stan a scris: Hello, Happy new year! I hope you had a great 2023. Has anyone had time to look over the exploratory work? If you have, please don't be shy, share your findings, good or bad. It would be great if we can work on concrete examples. I am still available to answer any questions and improve on the PR's to make the changes part of OFBiz moving forward. Let's make parts of OFBiz available as libraries so they can be used in other projects (ofbiz tooling) / other ways of building OFBiz. Regards, Eugen La 09.12.2023 01:04, Eugen Stan a scris: Hi, I pushed some changes that significantly reduce the number of lines changed and also the possibility of breakage: - merged back UtilValidateDateTime and UtilValidateEmpty into UtilValidate - moved some methods from *Runtime -> former class. If you test the changes and find some issues please let me know. I am willing to work to fix those and make the PR mergeable. I also did an exploratory work to see what would it take to have entity engine as a library see https://github.com/ieugen/ofbiz-framework/pull/3 On top of this PR, it adds only 670 lines and remove 370. Very small price to pay IMO. I have partial integration tests running. I have added some comments related to the blockers (EntityEca, Tennant) They should be doable, but I need more info / help. To reiterate, please let me know of any issue you find and I will work to fix it. Regards, Eugen La 07.12.2023 20:55, Eugen Stan a scris: Hi Michael, Thank you for taking a look. I will reply inline. I did a demo project to support my case https://github.com/ieugen/ofbiz-tooling-demo . La 07.12.2023 12:53, Michael Brohl a scris: Hi Eugen, can you give us some explanations/examples why this is a useful change? What are the downsides? I don't see any downsides. There might be some breaking changes on upgrades. We could work to mitigate them - will explain bellow. I see a lot of changes in the base API like UtilValidate, UtilProperties etc. which will brake almost every custom project out there. Have you tried it in your projects? Do you know how many fail? All the integrations tests pass. Also we could do some work to mitigate those braking changes: - copy those methods back to the classes they came from - implement delegation: add a method with same signature that calls on the class from base/util (UtilValidate calls UtilValidateEmpty). IMO this should be a transition period until the code is cleaned up. I did not do the mitigations because this is intendend as a POC to be prepared once we decide it's a good direction. Also - I don't have access to 'all the projects out there' to test. The changes also need explanation. For example: why the split of UtilValidate to UtilValidateEmpty etc. Because of the cyclic dependency between classes. There is a LOT of cyclic dependencies which IMO is a code smell. UtilValidate depens on UtilProperties which depens on UtilValidate. There are numerous cases for this. If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you will see them. ( I posted an image on gh issue) https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198 I think we need to have very strong advantages to make those changes and currently I do not see them. We open OFBiz to be used as libraries. Then developers can use things like entity-engine, datafile, bits to build tooling as CLI or services that integrate with OFBiz. - It opens a path forward to inovation - It will make life of integrators MUCH more easy as it will provide java API's for them to do integrations - It exposes the dependencies by making them explicit (as gradle deps) - Developers can focus on a smaller part of the code base: component loading, XML parsing, entity engine without worrying about the rest of the code. - It will allow users to build tools and ofbiz components and package them as jar files (component/datafile is a component as a jar file - it depends on base/util and base/crypto - but nothing else from OFBiz). - It will facilitate the developement of proper java API's - now OFBiz is an implementation only - the API is the implementation. I would like to build some import tooling that uses the OFBiz code (so I don't reinvent the weel). Currently I don't see a way on how to do that. See the https://github.com/ieugen/ofbiz-tooling-demo I just did for Crypto. It can help people migrate data from/to OFBiz by using the same crypto code and the same xml data processing code. I do not need to bring whole OFBiz if all I want is to push / pull data from DB or to some files. To my knowledge that is not possible with OFBiz right now (unlesss you reimplement the code). It will be possible once we publish libraries. There is much more that th
Re: Docker Image build from Release 22.01 does not start up - JAVA_HOME issues?
Hi Carsten, I tried the following and it worked: git checkout release22.01 DOCKER_BUILDKIT=1 docker build --tag ofbiz-docker . --load docker run -it -p 8443:8443 ofbiz-docker Please try the commands locally, and if it does not work, post the full list of commands. There is a large set of options in the document. I am on commit 4fa1b5c4a229eae4456275aaf4e6447a8d215b88 (HEAD -> release22.01, origin/release22.01) Author: Jacques Le Roux Date: Thu Jan 4 12:12:42 2024 +0100 Fixed: Replace SvnCheckout in Gradle (OFBIZ-12868) I believe the question should be on u...@ofbiz.apache.org. Regards, Eugen La 05.01.2024 17:45, Carsten Schinzer a scris: Hello all and Happy New Year, During my CI/CD pipeline run I do build a docker image as per the official document here: ofbiz-framework.png ofbiz-framework/DOCKER.md at release22.01 · apache/ofbiz-framework <https://github.com/apache/ofbiz-framework/blob/release22.01/DOCKER.md> github.com <https://github.com/apache/ofbiz-framework/blob/release22.01/DOCKER.md> <https://github.com/apache/ofbiz-framework/blob/release22.01/DOCKER.md> I do not manipulate any config or code from the framework repo. My pipeline job clones it (release 22.01), deploys my custom component and then runs the docker build command. Now when attempting to run as a sidecar on a later stage in the pipeline in order to test some REST API that my custom component exposes, the container does not start up properly. When I download and run the container locally using the exact command given on the document above, it runs through preliminary steps but then exits with the following error: - (…) + /ofbiz/bin/ofbiz --load-data readers=seed,seed-initial ERROR: JAVA_HOME is set to an invalid directory: /opt/java/openjdk Please set the JAVA_HOME variable in your environment to match the location of your Java installation. - I wonder why that is the case, as the JAVA_HOME should be the default path taken from the parent image (eclipse-temurin). On the image’s PATH variable, the java binary path is correctly added: /opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin Any advice that anyone has on this matter will be highly appreciated. Warm regards Carsten -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi, Inline: La 04.01.2024 12:03, Jacques Le Roux a scris: That is ok with me since I plan to use trunk anyway. So I guess the sooner we have OFBiz 24.01 the better :D . Are there otehr blockers for 24.01 besides the SVN issue? There is OFBIZ-12726 <https://issues.apache.org/jira/browse/OFBIZ-12726?src=confmacro> that I set as a blocker. I think we could continue with the workaround for now, the community to decide... 24.01 or such is now pressing... I think the workaround woks fine for JDk-17 but won't work for JDK-21. If we start splitting the modules we might make the testing part a bit more manageable. I think testing should be done using standard junit tooling. I might take a look at this once we start breaking up smaller parts. This said I was reading https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz and stumbled upon https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md Obviously some parts are obsolete since we rely now on Docker for demos. Could you please review and possibly amend? Is this for me or for Daniel? I assume it's for Daniel (as I read in your next emails). Last but not least, I guess we will need very soon to change something in Docker config for demos ; since pullAllPluginsSource relies on soon not usable SvnCheckout plugin? Yes indeed I confused, I finally handled Docker with the task https://issues.apache.org/jira/browse/OFBIZ-12876 For the READMEs it's more on my side than Daniel's. I'll clean the whole thing with https://issues.apache.org/jira/browse/OFBIZ-12863 For demos, we have now https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker I did not know about ofbiz-tools :) . Thanks, -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi Jacques,
I missed this thread for some reason (was collapsed in TB) and only saw
it now.
I read the thread.
Glad to see progress on fixing the SVN issue.
Also inline:
La 24.12.2023 13:05, Jacques Le Roux a scris:
Hi Eugen,
I tend to agree with your vision that sounds quite promising. I'm sorry
I got no time to review your PR yet. I hope to do so during next year...
It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the
idea the PR is meant for.
Of course, this architecture will need to be discussed more and
especially will not be part of the next release branch (24.01 ? 18.12
becoming really old).
That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?
This said I was reading
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
Obviously some parts are obsolete since we rely now on Docker for demos.
Could you please review and possibly amend?
Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).
Last but not least, I guess we will need very soon to change something
in Docker config for demos ; since pullAllPluginsSource relies on soon
not usable SvnCheckout plugin?
TIA
Jacques
Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
Hi Jacques,
Regarding the plugin workflow, the PR that I posted can offer
alternative ways to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz
optional / obsolete even (a choice).
If we move to have libraries that are published as jar files, then it
would be possible to develop plugins by depending on the specific
OFBiz bits.
It would also be possible to publish plugins / components as regular
java jars and consume them the same way.
So, in the future a custom OFBiz build could look something like this:
build.gradle
dependencies {
implementation 'org.apache.ofbiz:entity-engine:24.0'
implementation 'org.apache.ofbiz:service:24.0'
implementation 'org.apache.ofbiz:accounting:24.0'
implementation 'com.example:my-plugin:1.2.3'
}
On 23.12.2023 17:06, Jacques Le Roux
wrote:
It's ready for review before pushing and testing with GH and BB
TIA
Jacques
Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868
for > that... WIP...
>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not
be >> usable after January 8, 2024.
>>
>> So we need a replacement and it's clearly suggested by GitHub in
the >> link below
>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz
--
Eugen Stan
+40770 941 271 / https://www.netdava.com
Re: breaking ofbiz piece by piece - expose parts to outside
Hello, Happy new year! I hope you had a great 2023. Has anyone had time to look over the exploratory work? If you have, please don't be shy, share your findings, good or bad. It would be great if we can work on concrete examples. I am still available to answer any questions and improve on the PR's to make the changes part of OFBiz moving forward. Let's make parts of OFBiz available as libraries so they can be used in other projects (ofbiz tooling) / other ways of building OFBiz. Regards, Eugen La 09.12.2023 01:04, Eugen Stan a scris: Hi, I pushed some changes that significantly reduce the number of lines changed and also the possibility of breakage: - merged back UtilValidateDateTime and UtilValidateEmpty into UtilValidate - moved some methods from *Runtime -> former class. If you test the changes and find some issues please let me know. I am willing to work to fix those and make the PR mergeable. I also did an exploratory work to see what would it take to have entity engine as a library see https://github.com/ieugen/ofbiz-framework/pull/3 On top of this PR, it adds only 670 lines and remove 370. Very small price to pay IMO. I have partial integration tests running. I have added some comments related to the blockers (EntityEca, Tennant) They should be doable, but I need more info / help. To reiterate, please let me know of any issue you find and I will work to fix it. Regards, Eugen La 07.12.2023 20:55, Eugen Stan a scris: Hi Michael, Thank you for taking a look. I will reply inline. I did a demo project to support my case https://github.com/ieugen/ofbiz-tooling-demo . La 07.12.2023 12:53, Michael Brohl a scris: Hi Eugen, can you give us some explanations/examples why this is a useful change? What are the downsides? I don't see any downsides. There might be some breaking changes on upgrades. We could work to mitigate them - will explain bellow. I see a lot of changes in the base API like UtilValidate, UtilProperties etc. which will brake almost every custom project out there. Have you tried it in your projects? Do you know how many fail? All the integrations tests pass. Also we could do some work to mitigate those braking changes: - copy those methods back to the classes they came from - implement delegation: add a method with same signature that calls on the class from base/util (UtilValidate calls UtilValidateEmpty). IMO this should be a transition period until the code is cleaned up. I did not do the mitigations because this is intendend as a POC to be prepared once we decide it's a good direction. Also - I don't have access to 'all the projects out there' to test. The changes also need explanation. For example: why the split of UtilValidate to UtilValidateEmpty etc. Because of the cyclic dependency between classes. There is a LOT of cyclic dependencies which IMO is a code smell. UtilValidate depens on UtilProperties which depens on UtilValidate. There are numerous cases for this. If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you will see them. ( I posted an image on gh issue) https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198 I think we need to have very strong advantages to make those changes and currently I do not see them. We open OFBiz to be used as libraries. Then developers can use things like entity-engine, datafile, bits to build tooling as CLI or services that integrate with OFBiz. - It opens a path forward to inovation - It will make life of integrators MUCH more easy as it will provide java API's for them to do integrations - It exposes the dependencies by making them explicit (as gradle deps) - Developers can focus on a smaller part of the code base: component loading, XML parsing, entity engine without worrying about the rest of the code. - It will allow users to build tools and ofbiz components and package them as jar files (component/datafile is a component as a jar file - it depends on base/util and base/crypto - but nothing else from OFBiz). - It will facilitate the developement of proper java API's - now OFBiz is an implementation only - the API is the implementation. I would like to build some import tooling that uses the OFBiz code (so I don't reinvent the weel). Currently I don't see a way on how to do that. See the https://github.com/ieugen/ofbiz-tooling-demo I just did for Crypto. It can help people migrate data from/to OFBiz by using the same crypto code and the same xml data processing code. I do not need to bring whole OFBiz if all I want is to push / pull data from DB or to some files. To my knowledge that is not possible with OFBiz right now (unlesss you reimplement the code). It will be possible once we publish libraries. There is much more that this can help with but we will see if OFBiz to accepts some changes. And again, my changes don't break ANY integration test from the 780?! tests. I am very excited of finding this way of breaking
Re: SvnCheckout Gradle plugin soon no longer usable with GitHub
Hi Jacques,
Regarding the plugin workflow, the PR that I posted can offer alternative ways
to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz optional /
obsolete even (a choice).
If we move to have libraries that are published as jar files, then it would be
possible to develop plugins by depending on the specific OFBiz bits.
It would also be possible to publish plugins / components as regular java jars and consume them the same way.
So, in the future a custom OFBiz build could look something like this:
build.gradle
dependencies {
implementation 'org.apache.ofbiz:entity-engine:24.0'
implementation 'org.apache.ofbiz:service:24.0'
implementation 'org.apache.ofbiz:accounting:24.0'
implementation 'com.example:my-plugin:1.2.3'
}
On 23.12.2023 17:06, Jacques Le Roux wrote:
It's ready for review before pushing and testing with GH and BB
TIA
Jacques
Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for
> that... WIP...
>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not be
>> usable after January 8, 2024.
>>
>> So we need a replacement and it's clearly suggested by GitHub in the
>> link below
>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz
Re: breaking ofbiz piece by piece - expose parts to outside
Hi, I pushed some changes that significantly reduce the number of lines changed and also the possibility of breakage: - merged back UtilValidateDateTime and UtilValidateEmpty into UtilValidate - moved some methods from *Runtime -> former class. If you test the changes and find some issues please let me know. I am willing to work to fix those and make the PR mergeable. I also did an exploratory work to see what would it take to have entity engine as a library see https://github.com/ieugen/ofbiz-framework/pull/3 On top of this PR, it adds only 670 lines and remove 370. Very small price to pay IMO. I have partial integration tests running. I have added some comments related to the blockers (EntityEca, Tennant) They should be doable, but I need more info / help. To reiterate, please let me know of any issue you find and I will work to fix it. Regards, Eugen La 07.12.2023 20:55, Eugen Stan a scris: Hi Michael, Thank you for taking a look. I will reply inline. I did a demo project to support my case https://github.com/ieugen/ofbiz-tooling-demo . La 07.12.2023 12:53, Michael Brohl a scris: Hi Eugen, can you give us some explanations/examples why this is a useful change? What are the downsides? I don't see any downsides. There might be some breaking changes on upgrades. We could work to mitigate them - will explain bellow. I see a lot of changes in the base API like UtilValidate, UtilProperties etc. which will brake almost every custom project out there. Have you tried it in your projects? Do you know how many fail? All the integrations tests pass. Also we could do some work to mitigate those braking changes: - copy those methods back to the classes they came from - implement delegation: add a method with same signature that calls on the class from base/util (UtilValidate calls UtilValidateEmpty). IMO this should be a transition period until the code is cleaned up. I did not do the mitigations because this is intendend as a POC to be prepared once we decide it's a good direction. Also - I don't have access to 'all the projects out there' to test. The changes also need explanation. For example: why the split of UtilValidate to UtilValidateEmpty etc. Because of the cyclic dependency between classes. There is a LOT of cyclic dependencies which IMO is a code smell. UtilValidate depens on UtilProperties which depens on UtilValidate. There are numerous cases for this. If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you will see them. ( I posted an image on gh issue) https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198 I think we need to have very strong advantages to make those changes and currently I do not see them. We open OFBiz to be used as libraries. Then developers can use things like entity-engine, datafile, bits to build tooling as CLI or services that integrate with OFBiz. - It opens a path forward to inovation - It will make life of integrators MUCH more easy as it will provide java API's for them to do integrations - It exposes the dependencies by making them explicit (as gradle deps) - Developers can focus on a smaller part of the code base: component loading, XML parsing, entity engine without worrying about the rest of the code. - It will allow users to build tools and ofbiz components and package them as jar files (component/datafile is a component as a jar file - it depends on base/util and base/crypto - but nothing else from OFBiz). - It will facilitate the developement of proper java API's - now OFBiz is an implementation only - the API is the implementation. I would like to build some import tooling that uses the OFBiz code (so I don't reinvent the weel). Currently I don't see a way on how to do that. See the https://github.com/ieugen/ofbiz-tooling-demo I just did for Crypto. It can help people migrate data from/to OFBiz by using the same crypto code and the same xml data processing code. I do not need to bring whole OFBiz if all I want is to push / pull data from DB or to some files. To my knowledge that is not possible with OFBiz right now (unlesss you reimplement the code). It will be possible once we publish libraries. There is much more that this can help with but we will see if OFBiz to accepts some changes. And again, my changes don't break ANY integration test from the 780?! tests. I am very excited of finding this way of breaking OFBiz into smaller parts without breaking OFBiz runtime. There will be work to be done to streamline the code as libs but I am optimistic. Regards, -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: breaking ofbiz piece by piece - expose parts to outside
Hi Michael, Thank you for taking a look. I will reply inline. I did a demo project to support my case https://github.com/ieugen/ofbiz-tooling-demo . La 07.12.2023 12:53, Michael Brohl a scris: Hi Eugen, can you give us some explanations/examples why this is a useful change? What are the downsides? I don't see any downsides. There might be some breaking changes on upgrades. We could work to mitigate them - will explain bellow. I see a lot of changes in the base API like UtilValidate, UtilProperties etc. which will brake almost every custom project out there. Have you tried it in your projects? Do you know how many fail? All the integrations tests pass. Also we could do some work to mitigate those braking changes: - copy those methods back to the classes they came from - implement delegation: add a method with same signature that calls on the class from base/util (UtilValidate calls UtilValidateEmpty). IMO this should be a transition period until the code is cleaned up. I did not do the mitigations because this is intendend as a POC to be prepared once we decide it's a good direction. Also - I don't have access to 'all the projects out there' to test. The changes also need explanation. For example: why the split of UtilValidate to UtilValidateEmpty etc. Because of the cyclic dependency between classes. There is a LOT of cyclic dependencies which IMO is a code smell. UtilValidate depens on UtilProperties which depens on UtilValidate. There are numerous cases for this. If you run Intellij IDEA Analyze -> Analyze Cyclic dependencies you will see them. ( I posted an image on gh issue) https://github.com/apache/ofbiz-framework/pull/678#issuecomment-1845903198 I think we need to have very strong advantages to make those changes and currently I do not see them. We open OFBiz to be used as libraries. Then developers can use things like entity-engine, datafile, bits to build tooling as CLI or services that integrate with OFBiz. - It opens a path forward to inovation - It will make life of integrators MUCH more easy as it will provide java API's for them to do integrations - It exposes the dependencies by making them explicit (as gradle deps) - Developers can focus on a smaller part of the code base: component loading, XML parsing, entity engine without worrying about the rest of the code. - It will allow users to build tools and ofbiz components and package them as jar files (component/datafile is a component as a jar file - it depends on base/util and base/crypto - but nothing else from OFBiz). - It will facilitate the developement of proper java API's - now OFBiz is an implementation only - the API is the implementation. I would like to build some import tooling that uses the OFBiz code (so I don't reinvent the weel). Currently I don't see a way on how to do that. See the https://github.com/ieugen/ofbiz-tooling-demo I just did for Crypto. It can help people migrate data from/to OFBiz by using the same crypto code and the same xml data processing code. I do not need to bring whole OFBiz if all I want is to push / pull data from DB or to some files. To my knowledge that is not possible with OFBiz right now (unlesss you reimplement the code). It will be possible once we publish libraries. There is much more that this can help with but we will see if OFBiz to accepts some changes. And again, my changes don't break ANY integration test from the 780?! tests. I am very excited of finding this way of breaking OFBiz into smaller parts without breaking OFBiz runtime. There will be work to be done to streamline the code as libs but I am optimistic. Regards, -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: breaking ofbiz piece by piece - expose parts to outside
Hi, La 06.12.2023 18:01, Jacques Le Roux a scris: Le 06/12/2023 à 15:32, Eugen Stan a écrit : I need help with that one since I don't know how to run itests in IDE to debug Hi Eugen, I answered you at https://issues.apache.org/jira/browse/OFBIZ-12726 Merci Jacques :) . It seems all integration tests are passing for my branch. Please let me know your feedback and what will it take to have the PR merged. Once that is done I would like to focus on fixing the tests for JDK17 and see what will it take to get OFBiz on JDK21. Once the datafile is published (being optimistic) I would like to work on some CLI tooling to import data in OFBIz. Alternative to current gradle / WebTools tooling. -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: breaking ofbiz piece by piece - expose parts to outside
Hi,
To support my proposal I have made the changes in this PR
https://github.com/apache/ofbiz-framework/pull/678 .
The code above works:
- "./gradlew cleanAll loadAll testIntegration" - gives me 1 failed test
from 772 (I need help with that one since I don't know how to run itests
in IDE to debug)
- "./gradlew cleanAll loadAll "ofbiz --start" " - works and I can see
DataFile component
== How I got here
I introduced 3 gradle projects:
- base/util
- base/crypto (depends on base/util)
- components/datafile (depends on both the above)
I added dependencies to these projects to ofbiz/build.gradle via
implementation project(':build/util') // ...
Using Intellij "Move class" refactoring I moved classes to one of those
projects.
There where a lot of circular dependencies (for example: class
UtilValidate is using UtilProperties that uses UtilValidate ).
To solve these I use the following technicues:
- Split some methods to a new class and moved that one in base/util: See
UtilFormatOut -> UtilFormatOutBase for example and UtilValidate ->
UtilValidateEmpty and UtilProperties -> UtilPropertiesRuntime
You can recognize these by *Base or *Runtime sufixes.
- Inline some methods - copy one method to a class - creates a small
duplication but breaks dependency cycle.
A lot of time was spent fixing checkstyle errors.
Please please please adopt gradle spotless for automatic java formatting
from gradle.
Using something like google java code formattter you can have the same
formatter in IDE and in gradle cli
- https://github.com/diffplug/spotless/tree/main/plugin-gradle#java
== Where togo from here:
- I would like for us to merge this code ASAP and continue with the
approach for other bits and pieces.
IMO Focus should be on EntityEngine - but every reusable feature
should be split.
- Work can be merged as is IMO (pending some testing)
- Dependencies are starting to be explicit for each project
- We can publish datafile and base/util, base/crypto to Maven repo so
they can be reused in libraries / tooling.
- We need to breake up the cyclic dependencies between classes.
This is A MUST if we want to make OFBiz more modular.
Moving code to a project forces the dependencies to be explicit.
IDE's also have some helpers to detect cyclic dependencies.
Waiting for feedback,
Eugen
La 06.12.2023 01:15, Eugen Stan a scris:
Hello OFBiz devs,
I had some time to check out OFBiz again and I would like to propose
some improvements to OFBiz.
The purpose is to split some independent parts from ofbiz so they can be
used by other projects that wish to interact with OFBiz.
The main beneficiaries will be ofbiz related tooling IMO.
I believe I have identified two initial candidates for splitting:
- datafile component = "framework/datafile" - split as a project /
library - usefull for tooling
- base/crypto -
framework/base/src/main/java/org/apache/ofbiz/base/crypto - to do crypto
in tooling compatible with ofbiz
- base/util - framework/base/src/main/java/org/apache/ofbiz/base/util -
this is used across both of the above stuff
== How the split should happen and how it will look like:
Use gradle subprojects feature to define 3 subprojects in the
ofbiz-framework git repo:
- base/utils
- base/crypto
- components/datafile
The projects will be standalone gradle projects that can be built
individually and have dependencies.
https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html
Since these projects can build jar files, they can be published to maven
to be consumed by other apps.
Since they are projects part of ofbiz-framework, they will participate
as dependencies in the build.
I hope this can open the door to further refactoring and making OFBiz
play nicer with outside developers.
After the change, the code should function the same with regards to
normal OFBIz operations
It is somewhat related to https://issues.apache.org/jira/browse/OFBIZ-3500
--
Eugen Stan
+40770 941 271 / https://www.netdava.com
breaking ofbiz piece by piece - expose parts to outside
Hello OFBiz devs, I had some time to check out OFBiz again and I would like to propose some improvements to OFBiz. The purpose is to split some independent parts from ofbiz so they can be used by other projects that wish to interact with OFBiz. The main beneficiaries will be ofbiz related tooling IMO. I believe I have identified two initial candidates for splitting: - datafile component = "framework/datafile" - split as a project / library - usefull for tooling - base/crypto - framework/base/src/main/java/org/apache/ofbiz/base/crypto - to do crypto in tooling compatible with ofbiz - base/util - framework/base/src/main/java/org/apache/ofbiz/base/util - this is used across both of the above stuff == How the split should happen and how it will look like: Use gradle subprojects feature to define 3 subprojects in the ofbiz-framework git repo: - base/utils - base/crypto - components/datafile The projects will be standalone gradle projects that can be built individually and have dependencies. https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html Since these projects can build jar files, they can be published to maven to be consumed by other apps. Since they are projects part of ofbiz-framework, they will participate as dependencies in the build. I hope this can open the door to further refactoring and making OFBiz play nicer with outside developers. After the change, the code should function the same with regards to normal OFBIz operations It is somewhat related to https://issues.apache.org/jira/browse/OFBIZ-3500 -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: Lazy consensus: Host demo-trunk in a container.
+1 -- Eugen Stan +40770 941 271 / https://www.netdava.com begin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: Welcome to Daniel Watford as new PMC member
Congrats Daniel! On 28.01.2023 12:57, 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! -- Eugen Stan +40770 941 271 / https://www.netdava.com begin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: CI github failed : Java 11 or java 17
Hi Jaques, Any luck on this? I use sdkman to switch jdk's on linux. https://sdkman.io/install I noticed it has some Windows options as well, maybe they will work for you ?! I try to stay away from customizations since most of the time they are not worth the effort. If the build is slow it might also be an indication that we need to address the root cause instead of avoiding it. Having personal build customization that avoid the issues will make the false believe the issue does not exist. Also I don't imagine other people will use the same tricks so it will be harder to relate to their issues / experiences in running OFBiz. If the CI is building and other people are also building the project the PR should be moved forward. IMO, personal customization should not block the project moving forward. I do hope you get to the bottom of this on your machine. I don't use Windows myself, but I know a lot of people do and they should be able to run OFBiz. Regards, Eugen On 30.11.2022 19:39, Jacques Le Roux wrote: I found the cause. For performance reason, and especially in order to be able to quickly switch from a JDK version to another, I use a batch file to copy over JDKs to a RAM Disk. So java_home is always the same: this RAM Disk. It has been working since Java 8, It now fails with JDK 17 (from what I have read I guess since one version of JDK 16). When setting java_home to the initial location of JDK 17, instead of the RAM Disk, it works. I get only 2 warnings when compiling. I'll have another look ASAP... Le 30/11/2022 à 16:41, Jacques Le Roux a écrit : After upgrading non-functional changes at OFBIZ-12400 (Java code, AsciiDoc versions, Groovy from 2.5.18 to 3.0.13), we can focus on Gradle and JDK version. With last Java 17 and still Gradle 6.5,of of course the same error than before: "does not export com.sun.tools.javac.code to unnamed module" With last Java 17 and Gradle 7.6, also the same error than before: Execution failed for task ':compileJava'. > Error while evaluating property 'javaVersion' of task ':compileJava'. > Cannot invoke "java.nio.file.Path.toString()" because the return value of "java.nio.file.Path.getFileName()" is null I'll continue to dig starting from https://github.com/gradle/gradle/issues/20837 (notably last comment). It seems a not so obvious issue. I don't think it's related to my Windows version, but not sure... Le 30/11/2022 à 13:24, Jacques Le Roux a écrit : Hi Eugen, As you know I'm still on Win7 and was able to manage all related issues so far (like the need to use npm 13.14.0 locally in build.gradle) To simplify things I just committed the non functional Java changes unrelated to Gradle and JDK upgrades, not the same than your for CsrfUtil class. I tried several mixed things w/o success so far. I'll continue and inform you here later. Thanks Jacques Le 29/11/2022 à 12:12, Ioan Eugen Stan a écrit : An update to this: I've rebased the PR for gradle upgrade https://issues.apache.org/jira/browse/OFBIZ-12400 https://github.com/apache/ofbiz-framework/pull/354 I've bumped gradle to 7.6 . I started ofbiz with temurin jdk17 and it works (with warnings and some errors). See screenshot in PR. The CI build passes. Can you please review @Jacques ? I do hope this will help move things forward. Eugen On 2022/11/29 09:55:02 eugen.s...@netdava.com wrote: Hi, There are some open issues about this: https://issues.apache.org/jira/browse/OFBIZ-10757 - jdk 11 https://issues.apache.org/jira/browse/OFBIZ-12399 - jdk 17 https://issues.apache.org/jira/browse/OFBIZ-12400 - gradle 7.x for jdk17 There is also a PR for gradle upgrade https://github.com/apache/ofbiz-framework/pull/354 Gradle upgrade is a pre-requisite for JDK upgrade. I remember some issues with project not generating some docs as part of build on some system. I think this should not be considered an upgrade blocker IMO. Since we are using third party libraries that might not support all platforms. I really hope this gets merged. Regads, Eugen -- Eugen Stan +40770 941 271 / https://www.netdava.com begin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: CI github failed : Java 11 or java 17
An update to this: I've rebased the PR for gradle upgrade https://issues.apache.org/jira/browse/OFBIZ-12400 https://github.com/apache/ofbiz-framework/pull/354 I've bumped gradle to 7.6 . I started ofbiz with temurin jdk17 and it works (with warnings and some errors). See screenshot in PR. The CI build passes. Can you please review @Jacques ? I do hope this will help move things forward. Eugen On 2022/11/29 09:55:02 eugen.s...@netdava.com wrote: > Hi, > > There are some open issues about this: > > https://issues.apache.org/jira/browse/OFBIZ-10757 - jdk 11 > https://issues.apache.org/jira/browse/OFBIZ-12399 - jdk 17 > https://issues.apache.org/jira/browse/OFBIZ-12400 - gradle 7.x for jdk17 > > There is also a PR for gradle upgrade > https://github.com/apache/ofbiz-framework/pull/354 > > Gradle upgrade is a pre-requisite for JDK upgrade. > > I remember some issues with project not generating some docs as part of build > on some system. > I think this should not be considered an upgrade blocker IMO. > Since we are using third party libraries that might not support all > platforms. > > > I really hope this gets merged. > > Regads, > Eugen >
Re: CI github failed : Java 11 or java 17
Hi, There are some open issues about this: https://issues.apache.org/jira/browse/OFBIZ-10757 - jdk 11 https://issues.apache.org/jira/browse/OFBIZ-12399 - jdk 17 https://issues.apache.org/jira/browse/OFBIZ-12400 - gradle 7.x for jdk17 There is also a PR for gradle upgrade https://github.com/apache/ofbiz-framework/pull/354 Gradle upgrade is a pre-requisite for JDK upgrade. I remember some issues with project not generating some docs as part of build on some system. I think this should not be considered an upgrade blocker IMO. Since we are using third party libraries that might not support all platforms. I really hope this gets merged. Regads, Eugen
Using htmx to make OFbiz more dynamic - FYI
Hello, I recently came across htmx (and _hyperscript). I am currently evaluating it - no real experience yet. What I tested so far has impressed me. I think htmx can bring a lot of value to a project like OFBiz . It can provide a way to have a dynamic pages - that load fast and a good upgrade path: * You still get to have pages rendered on server * You add attributes to markup and these call in a service * The service will reply with the bits of HTML that will replace an element in the page. What I like about it is: * Very small footprint (10k gzipped JS) * Works with "normal" http * Simple to reason about * Content is generated on the back-end - so under all security rules * Easy (IMO) to adopt to OFBiz UI - progressive enhancement I do have some mixed feelings about _hyperscript - but that is optional. I will try it though in a personal project and see how it goes. Please try it out: https://htmx.org/ . Their tag line is: (Haiku) javascript fatigue: longing for a hypertext already in hand -- Eugen Stan +40770 941 271 / https://www.netdava.combegin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: OFBiz re-architecture thoughts
Hello Taher, Thank you for this initiative and sorry for not replying sooner. I meant to reply for so long but life ... I think most / 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.combegin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
I published the helm chart for Apache OFBiz to artifacthub.io
Hi, So I linked my OFBIz chart repository to artifacthub.io . This means that the OFBiz chart is discoverable for all people who search for kubernetes packages via Artifacthub. See link https://artifacthub.io/packages/search?ts_query_web=ofbiz=relevance=1 It would be great to make progress on the container front so that it's more usable: Also having a strategy to hold plugin configuration data in DB would help this use case a lot. Can't wait to have these fixed (personal order): * https://issues.apache.org/jira/browse/OFBIZ-9498 * https://issues.apache.org/jira/browse/OFBIZ-12401 * https://issues.apache.org/jira/browse/OFBIZ-10407 Regards, -- Eugen Stan +40770 941 271 / https://www.netdava.combegin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
On OFBiz components and making OFBiz modular
Hello, I'm continuing my work on splitting OFBiz into smaller, more manageable parts but I've hit a blocking point: I don't know how /can't package an ofbiz component as a jar/archive and load it from it. My work is in https://github.com/apache/ofbiz-framework/pull/381 I followed my idea of moving creating a gradle project for individual parts (right now framework, applications, themes and plugins). I made some progress and framework and applications projects compile and all but 5 tests pass. The issue is that when application starts, it tries to load components from filesystem and it fails. Looking at WAR files and how they are handled in application servers it seems to be a way of having a component as a directory and as a packaged archive. I ask myself if it's worth it going that route? Should OFBiz community invest time and effort into component loading logic and dependency management (See https://issues.apache.org/jira/browse/OFBIZ-11296)? Those are hard problems on their own and they are already solved at build level by tools like maven and gradle and at runtime via things like ServiceLoader and dependency injection / IoC. All in all I don't see how to evolve OFBiz without breaking the current way of doing things - developer workflow, plugin development and distribution building. And when it comes to breaking changes - and pushing those to people with production instances - from my experience it's hard to reach an agreement. Quite hard to find motivation with this road ahead. -- Eugen Stan +40770 941 271 / https://www.netdava.combegin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: Logical dependency tree for ofbiz components OFBIZ-12309
Hello Taher, Thanks for getting back. I think we are very much aligned on where we want to go but we have different perspectives on where we are in regards to OFBiz. I will motivate my reply inline: On 29.11.2021 10:36, Taher Alkhateeb wrote: 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. I disagree with your statement above. From my experience ofbiz is not split up in separate modules. If you read https://issues.apache.org/jira/browse/OFBIZ-12308 and comments from https://github.com/apache/ofbiz-framework/pull/319 you will see what I mean. There are circular dependencies between modules - so they are not split up. Also if you look at https://issues.apache.org/jira/browse/OFBIZ-12263 you can't build plugins that use other repositories, unless you add those repos (and I believe also dependencies) to OFBIz. Basically you can't publish binary plugins easily IMO. In order to fix these I believe we need to use gradle sub-projects and have a full fledged build.gradle in each directory (full fledged gradle project) complete with dependencies. 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. I do agree we should allow multiple aggregation of these modules in different configurations. That will allow us to build custom OFBiz distributions. As I stated in https://github.com/apache/ofbiz-framework/pull/319 , this is not possible since modules are interconnected (circular dependencies) and you can't split them apart. You can't publish and independently use framework/entities or services or base because they use classes from each other. Also the gradle build system is highly customized and hence not very friendly to new developers because - since they need to understand the 1000+ lines of custom build code. My proposal on this part is to: * Drop dynamic project add via activeComponents (maybe keep for plugins ?!) * Use standard build.gradle in every project - static project composition * Gradually refactor code -> move dependencies into each sub-project * Deprecate framework/start and replace with top level ofbiz-start gradle project that will depend and aggregate ofbiz modules and build the app. This will be the deliverable and also example on how to build your own ofbiz distribution. People should be able to customize or create their own copy of this project to have a custom OFBiz distribution with whatever modules and configuration they desire. If we publish jars for modules, this project could be anywhere on git(hub). Cheers, Taher Alkhateeb Regards, -- Eugen Stan +40770 941 271 / https://www.netdava.combegin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: I'm working on an OFBiz helm chart for kubernetes
Hello Alexis, Pierre, Alexis: if you have any questions or a specific interest, et me know on ofbiz slack channel, ask on email or open an issue on the chart repository. What are your plans for this? What are your interests? Are you currently running ofbiz in a dev/prod environment? Pierre, see my reply bellow: On 28.11.2021 11:15, Pierre Smits wrote: Hi Ioan, Would you say that OFBiz in Kubernetes is more geared towards a production environment, and OFBiz in Docker is more geared towards a development environment? kubernetes will use the same docker image IMO so depends on your setup and preference. Kubernetes is backed up by major cloud providers (you get hosting offerings) and not so much for docker clusters (beyond one server). This is of course debatable, and in the end left to the end user. Hope this helps, -- Eugen Stan +40770 941 271 / https://www.netdava.combegin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: Logical dependency tree for ofbiz components OFBIZ-12309
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.
--
Eugen Stan
+40770 941 271 / https://www.netdava.combegin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.s...@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard
Re: I'm working on an OFBiz helm chart for kubernetes
I made some small updates to the chart and it's now I managed to publish the chart https://github.com/ieugen/charts Instalation details are on the ofbiz chart page: https://github.com/ieugen/charts/tree/main/charts/ofbiz Right now I can use the chart + custom valus to start ofbiz in kubernetes but I don't have a clear way to load data into it. I'll open another thread about this if I don't find something online first. I'll add more examples on how to use it since right now it might not be that obvious, but it works for me. Let me know if you need help with it or if you would like to be involved with this. -- Eugen Stan +40770 941 271 / https://www.netdava.combegin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: please add me to OFBiz contributors
Thank you Jacques. Done. On 02.11.2021 10:55, Jacques Le Roux wrote: Hi Eugen, Done for Confluence (wiki), please update yourself the below wiki page Done for Jira also Welcome :) Le 01/11/2021 à 14:36, Eugen Stan a écrit : Hello, I would like to be added as an OFBiz contributor with email: eugen.s...@netdava.com . I did sign the CLA - I am an Apache James committer. My company (Netdava) also signed the CCLA and would be nice to be listed under Companies with CCLA on https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors I would like to be able to assign JIRA issue to myself and contribute towards https://issues.apache.org/jira/browse/OFBIZ-12141 . Regards, Eugen -- Eugen Stan +40770 941 271 / https://www.netdava.com
Re: please add me to OFBiz contributors
My apache id is: ieugen . On 01.11.2021 15:36, Eugen Stan wrote: Hello, I would like to be added as an OFBiz contributor with email: eugen.s...@netdava.com . I did sign the CLA - I am an Apache James committer. My company (Netdava) also signed the CCLA and would be nice to be listed under Companies with CCLA on https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors I would like to be able to assign JIRA issue to myself and contribute towards https://issues.apache.org/jira/browse/OFBIZ-12141 . Regards, Eugen
please add me to OFBiz contributors
Hello, I would like to be added as an OFBiz contributor with email: eugen.s...@netdava.com . I did sign the CLA - I am an Apache James committer. My company (Netdava) also signed the CCLA and would be nice to be listed under Companies with CCLA on https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Contributors I would like to be able to assign JIRA issue to myself and contribute towards https://issues.apache.org/jira/browse/OFBIZ-12141 . Regards, Eugen
Re: Next rather than old demo
On 03.09.2021 20:00, Jacques Le Roux wrote: Hi, We have an old demo. It's the previous stable. I think we should rather think about the future than the past. So I propose to change and replace the old demo by a next demo. It would be the next release to be done. For instance at the moment old is R16 and next would be R18, etc. I have already used the same for the documentation: https://ci.apache.org/projects/ofbiz/site/ What do you think? TIA Jacques I think it's a good idea. I imagine people who care about the old have already an instance running and can deploy it themselves. Stable and next would be great. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Re: Releasing 17.12.05, 18.12.01 and freezing R20
Hi, On 02.09.2021 18:03, Nicolas Malin wrote: I reactivate this thread :) Except if some remarks expressing reticence appears, I propose to * publish the version 18.12.01 this month * create the release branch 21.09 with official support of java 11 * migrate the trunk to support for java 17 Looking forward to seeing Java 17 on trunk :). That will certainly spark some cleanup and changes since the module system is enforced for java modules starting with 17. -- Eugen Stan +40720 898 747 / netdava.com
Re: Logical dependency tree for ofbiz components OFBIZ-12309
Hello Nicolas, Thank you for looking into this. I know it's not an easy task. I believe that where is a will, there is a way. Now let's see if the OFBiz community has a strong will in this direction. Let's discuss about your proposal and let's see where it goes. See my comments inline: On 02.09.2021 17:43, Nicolas Malin wrote: Hello Eugen, On 30/08/2021 11:48, Eugen Stan wrote: Hello, I've opened a new issue https://issues.apache.org/jira/browse/OFBIZ-12309 . I need community help with this. I analyzed at fresh head, It's a hard task to remove the circular dependency. Yes it is :(. We have some dependencies that would be easily to remove (and some introduce by myself I realized by misunderstanding or weakness of mind) and some other that have their own reason. If we want to go on increase the scalability, I search if the effort to scale at each component is coherent with the most-valuable to win. I'm mostly concerned with project maintainability and innovation - both are hard to do in a large project with unclear dependencies. I have on my mind to elaborate a framework-core an acceptable minimal circular dependencies and some other present as three dependency * core : common - base - start - entity - service - security - webapp * entityext : core * datafile: core * testtools: core * catalina: core * widget: core * webtools: widget, testtools, datafile, catalina I know this isn't your final objective but can it be an acceptable spot ? Thanks. It's a very good place to start. We might be able to introduce a 'core' gradle project that contains those and depend on that one in the others. I would move out start module. It seems to be responsible for starting up the app. I imagine components have an interface (the Container). All ofbiz plugins/modules implement this so there should not be a dependency on implementations. Perhaps this is a good point to start - separating the container and depending on it in other modules. start will start ofbiz and load modules list from xml + look them up on the classpath. WDYT? How would the list above change with a container API module? Another helpful thing is to establish the boundaries of each project. What should each module do and what it should NOT do? I think a lot of things will clear up once that is established. The functionality that does not fit in the module/project should be moved elsewhere. Can you (or anyone else) (please) provide some lines as to what should each module in framework do and NOT do? Eugen Nicolas From the exploratory branch https://github.com/apache/ofbiz-framework/pull/319 I discovered there are a lot of circular dependencies between components (components depending on each other in order to build). I believe it would be very useful to have a logical dependency tree between components. As a developer working to make OFBiz usable as a framework I need to solve issues like circular dependencies between components (see https://issues.apache.org/jira/browse/OFBIZ-12308 ) . This should serve as a guide to help me decide how to solve the circular dependency issue. This is the current list of dependencies in framework (applications should be in another issue IMO). Related work: * https://issues.apache.org/jira/browse/OFBIZ-3500 * https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+9.04 * https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+10.04 Looking forward to feedback on this. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Logical dependency tree for ofbiz components OFBIZ-12309
Hello, I've opened a new issue https://issues.apache.org/jira/browse/OFBIZ-12309 . I need community help with this. From the exploratory branch https://github.com/apache/ofbiz-framework/pull/319 I discovered there are a lot of circular dependencies between components (components depending on each other in order to build). I believe it would be very useful to have a logical dependency tree between components. As a developer working to make OFBiz usable as a framework I need to solve issues like circular dependencies between components (see https://issues.apache.org/jira/browse/OFBIZ-12308 ) . This should serve as a guide to help me decide how to solve the circular dependency issue. This is the current list of dependencies in framework (applications should be in another issue IMO). Related work: * https://issues.apache.org/jira/browse/OFBIZ-3500 * https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+9.04 * https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+10.04 Looking forward to feedback on this. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Re: [DISCUSSION] ofbiz framework as a library OFBiz "microservices" and composable builds
Hello, I made some progress on this - mostly exploratory code. I started making framework a gradle project, removed component activation code and converted some components to gradle subprojects (added build.gradle files and "include"ed them in settings.gradle) . I discovered some interesting things that I think need some attention: * framework has explicit dependency on libraries that are not specified in the dependency list - they come from transitive deps (commons-io, jsoup if my memory is good) * There are circular dependencies between the components: start depends on base, base on start and so on. It gets worse as we go to other components I'm afraid. * Base does quite a lot of stuff judging from dependencies: json, xml and html parsing, templates via freemarker, http file upload handling, etc. It's quite a lot of responsability for a low level component. I believe some of it could be moved up the stack (http related code is one IMO) Code is https://github.com/apache/ofbiz-framework/pull/319 if you want to try it out. Next steps IMO: * Find a way to break circular dependencies in framework components. IMO this will require: ** moving some classes around ** introducing other components (gradle projects) that will help us better organize code * Move to ofbiz application components once this is done. Like I mentioned above, this is exploratory code, not meant to be merged as is. The goals of this exploration is to see how we can * Migrate ofbiz components to use gradle projects. * Expose dependencies of each component. * Expose circular dependencies between components. * Allow easier future code changes / dependency updates. I think it is going to be long endeavor but I do think it is going to be worth it. What are your thoughts? Eugen On 8/6/21 12:30 PM, Nicolas Malin wrote: Hello Eugeu, Thanks for this discussion, I'm a little overworked to read and response quietly. I will try to work on next week, I plead your patience :) Nicolas On 02/08/2021 21:45, Eugen Stan wrote: Hello, This is to start a discussion around how OFBiz is being built and see how to improve the current situation. Some background: We plan to use (pitch stage) OFBiz with a client in a cloud setup to offer warehouse management functionality and more for an existing web store. The end goal is to help multiple small businesses have an online presence. IMO the current OFBiz setup is not very well suited for cloud deployments. It's quite large, has a lot of components that we don't plan to use => are a maintenance burden, might (have) caused security leaks. Some components could be split into another process and scaled independently: email sending, pdf rendering, batch jobs etc. Proposal: I believe that we need to use gradle projects/subprojects and exposes ofbiz components and plugins as concrete projects / jar libraries. This is in contrast to how it's currently done where there is a single gradle project that has subprojects created dynamically from ofbiz components. IMO, the benefits would be: * Ability to publish components as jar libraries to consume in other projects * Increase reusability of components and hopefully - more third party adoption. Ex: ofbiz entity engine could be used outside OFBiz and improved at a different pace this way * Modular design - where dependencies for each component/plugin are visible and may evolve independently (this ties well with java modules) * Ability for third party to create a custom OFBiz distribution based on select components/plugins. These can be slim/specialized version of OFBiz suitable for cloud deployment * Proper gradle dependency management and explicit dependencies https://issues.apache.org/jira/browse/OFBIZ-3500 (Think also IDE support for component projects). * ?!? I might have missed something. What changes: IMPORTANT: These changes will enable users to do more with OFBiz. They will not change developer workflow that much. * Create a build.gradle for each ofbiz component in ofbiz-framework and later for plugins * Depend on the gradle projects. This means using explicit include 'project-component' instead of dynamically adding them via settings.gradle / activeComponents . * Move java dependencies to each subproject * We can still keep the option to include projects dynamically * Apache OFBiz does not have to publish the jar libraries, but can offer support for users to do that Next steps: * Provide code sample to build a light OFBIz framework * Split some components into their own gradle module - to make them optional: service engines seems like a good candidate (JavaScript, http, etc) I am willing to work on this with the community when we reach consensus. I am not and OFBiz developer so I will need help pushing these upstream. Related issues that would be easier to solve * https://issues.apache.org/jira/browse/OFBIZ-12263 * https://issues.apache.org/jira/browse/OFBIZ-3500 * https://issues.apache.org/jira/brow
[DISCUSSION] ofbiz framework as a library OFBiz "microservices" and composable builds
Hello, This is to start a discussion around how OFBiz is being built and see how to improve the current situation. Some background: We plan to use (pitch stage) OFBiz with a client in a cloud setup to offer warehouse management functionality and more for an existing web store. The end goal is to help multiple small businesses have an online presence. IMO the current OFBiz setup is not very well suited for cloud deployments. It's quite large, has a lot of components that we don't plan to use => are a maintenance burden, might (have) caused security leaks. Some components could be split into another process and scaled independently: email sending, pdf rendering, batch jobs etc. Proposal: I believe that we need to use gradle projects/subprojects and exposes ofbiz components and plugins as concrete projects / jar libraries. This is in contrast to how it's currently done where there is a single gradle project that has subprojects created dynamically from ofbiz components. IMO, the benefits would be: * Ability to publish components as jar libraries to consume in other projects * Increase reusability of components and hopefully - more third party adoption. Ex: ofbiz entity engine could be used outside OFBiz and improved at a different pace this way * Modular design - where dependencies for each component/plugin are visible and may evolve independently (this ties well with java modules) * Ability for third party to create a custom OFBiz distribution based on select components/plugins. These can be slim/specialized version of OFBiz suitable for cloud deployment * Proper gradle dependency management and explicit dependencies https://issues.apache.org/jira/browse/OFBIZ-3500 (Think also IDE support for component projects). * ?!? I might have missed something. What changes: IMPORTANT: These changes will enable users to do more with OFBiz. They will not change developer workflow that much. * Create a build.gradle for each ofbiz component in ofbiz-framework and later for plugins * Depend on the gradle projects. This means using explicit include 'project-component' instead of dynamically adding them via settings.gradle / activeComponents . * Move java dependencies to each subproject * We can still keep the option to include projects dynamically * Apache OFBiz does not have to publish the jar libraries, but can offer support for users to do that Next steps: * Provide code sample to build a light OFBIz framework * Split some components into their own gradle module - to make them optional: service engines seems like a good candidate (JavaScript, http, etc) I am willing to work on this with the community when we reach consensus. I am not and OFBiz developer so I will need help pushing these upstream. Related issues that would be easier to solve * https://issues.apache.org/jira/browse/OFBIZ-12263 * https://issues.apache.org/jira/browse/OFBIZ-3500 * https://issues.apache.org/jira/browse/OFBIZ-9322 -- Eugen Stan +40720 898 747 / netdava.com
Re: Clojure service engine proposal for inclusion
Hello Nicolas, Pierre, Thanks for your feedback, I replied to the issue. @Pierre: I would like to be able to use a "slim" OFBiz version but that is not easy to do at the moment. I would like to announce my intention to work on this issue. One way that would get us closer to a "Slim" (composable) OFBiz is to have concrete gradle projects for OFBiz components instead of dynamically created projects as we have now. Once that is done, we could build and publish each component and assemble them in a different way than Apache OFBiz currently does. I think this is doable and the project workflow will not change too much from how it is now. Regards, On 29.07.2021 20:13, Pierre Smits wrote: Hi Nicolas, I wasn't aware of that constraint. Thanks for the insight. Pierre Op do 29 jul. 2021 17:40 schreef Nicolas Malin : Hello, @Eugeu Yeah nice, I added some suggest to the PR, and create the linked jira issue and we can push it on trunk @Pierre The service engine don't support an extension by plugins, you can't load a new engine without change the framework. In this case I prefer to load the minimal quantity of code to demonstrate an engine on the OFBiz framework instead of separate it in plugin and load it by apply a path or manually change the configuration. Nicolas On 29/07/2021 10:58, Pierre Smits wrote: Hi Ioan, Would it not be better for the community to be able to implement this set of functionalities by means of a downloadable plugin? It seems to me that - in a way - this levels up to plugins like the indexing (lucene) or the REST plugins. Not every adopters would be keen to have this by default OOTB. Best regards, Pierre Smits On Wed, Jul 28, 2021 at 10:23 PM Eugen Stan wrote: Hello Nicolas, Thanks for the suggestions. I've made a PR for this: https://github.com/apache/ofbiz-framework/pull/317 * has a service test * has a service example (defn echo-service "Echo back all the parameters" [dctx ctx] (doto (new java.util.LinkedHashMap) (.putAll ctx) (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS))) On 07.07.2021 09:58, Nicolas Malin wrote: Hello, Thanks for this detail email and your works. I'm not opposed to load closure in OFBiz code base for same reason that you exposed. For success the inclusion, I suggest to rename the namespace to org.apache.ofbiz, add test one framework/service/testdef and an example "hello world" service. Thanks Eugen ! Nicolas -- Eugen Stan +40720 898 747 / netdava.com -- Eugen Stan +40720 898 747 / netdava.com
Re: Clojure service engine proposal for inclusion
Hello Nicolas, Thanks for the suggestions. I've made a PR for this: https://github.com/apache/ofbiz-framework/pull/317 * has a service test * has a service example (defn echo-service "Echo back all the parameters" [dctx ctx] (doto (new java.util.LinkedHashMap) (.putAll ctx) (.put ModelService/RESPONSE_MESSAGE ModelService/RESPOND_SUCCESS))) On 07.07.2021 09:58, Nicolas Malin wrote: Hello, Thanks for this detail email and your works. I'm not opposed to load closure in OFBiz code base for same reason that you exposed. For success the inclusion, I suggest to rename the namespace to org.apache.ofbiz, add test one framework/service/testdef and an example "hello world" service. Thanks Eugen ! Nicolas -- Eugen Stan +40720 898 747 / netdava.com
Re: New Helveticus theme as default
The new theme looks good, the only thing that bothers me is the light blue text on white background - which is not very readable, esp. in high resolution (1080p). See here a screen capture: https://i.postimg.cc/HxcFKLt1/Captur-de-ecran-de-la-2021-07-07-08-41-31.png . I tried it on laptop 14" screen and also on a DELL desktop monitor. I think the issue is with the color contrast (light blue + white background) + small text on the accounting app main page. -- Eugen Stan +40720 898 747 / netdava.com
Clojure service engine proposal for inclusion
Hello,
I've implemented a clojure engine for OFBiz and I would like to
contribute this to OFBiz repo.
It was simpler than I thought.
NOTE: Right now the code is bundled with the ofbiz-repl-plugin in
https://github.com/netdava/ofbiz-clojure-repl .
Code is a draft and will be cleaned up for inclusion.
== Why?
* Allow OFBiz to use clojure libraries and ecosystem
* Allow Clojure developers to work with OFBiz in a friendlier way
* Does not increase OFBiz complexity
* Clojure is also dynamic like Groovy
* Enables powerful OFBiz administration and development via Clojure Repl
(work in progress, I have working babshka scripts that I can use to
manage OFBiz and call services remotely via REPL)
== The code
Code is based off of java engine:
https://github.com/netdava/ofbiz-clojure-repl/blob/main/src/main/java/com/netdava/ofbiz/clojure/ClojureEngine.java
Service it is defined the usual way:
https://github.com/netdava/ofbiz-clojure-repl/blob/main/servicedef/services.xml
A sample service looks like this
https://github.com/netdava/ofbiz-clojure-repl/blob/main/src/main/resources/com/netdava/ofbiz/clojure/sample.clj
Copy pasting code snippets from above links:
engine="clojure"
location="com.netdava.ofbiz.clojure.sample"
invoke="clojure-test-service" export="true"
max-retry="3" use-transaction="false">
Clojure repl service. Get service stats.
(ns com.netdava.ofbiz.clojure.sample
(:gen-class)
(:import org.apache.ofbiz.service.DispatchContext))
(defn clojure-test-service [^DispatchContext dctx ^java.util.Map ctx]
(println "test " dctx " " ctx)
{"status" {"msg" "Hello OFBiz from clojure"}})
The service prints contexts and returns a clojure map with "status" key
and a map as a value (that implements java.util.Map).
To test out the code, clone ofbiz-clojure-repl into plugins/
and apply two changes: clojars maven repo and the service engine definition.
https://github.com/ieugen/ofbiz-framework/commit/d50254ed57358544c8765a2647ec4bbdd3baf6a5
https://github.com/ieugen/ofbiz-framework/commit/e58ad5ed9d102210a1f1363e8337cef486cf999e
Regards,
--
Eugen Stan
+40720 898 747 / netdava.com
Re: I'm working on an OFBiz helm chart for kubernetes
Thank you Gil, that will come in handy. Long term I would like to see configuration overhaul. IMO and following good practices: Each "component/service" should use POJO's - simple properties (strings, longs, booleans, list and maps of those) "Components/services" will not read the configuration, it will be handed to them. Configuration loading should be done in the main entry point in OFBiz and this could take into account multiple sources like: * files and/or a directory of configs - like conf.d patter in linux /etc * env properties * cli args Config is loaded in one place, components are create with this configuration passed as Java objects / values. I think there are a few no-dependencies libraries out there that fit these requirements. p.s. I will do some more work on chart in the next months and get back. Regards, Eugen On 02.07.2021 11:11, Gil Portenseigne wrote: Hello Eugen, and thanks Pierre for the reminder :) I just wanted to mention there was a previous effort to implement environment variable configuration [1]. This has not yet be pushed into trunk, but is used by our customer projects. You could check the patch and test if it helps you ease the configuration process. Regards, Gil [1] https://issues.apache.org/jira/browse/OFBIZ-9498 -- Eugen Stan +40720 898 747 / netdava.com
Re: I can clean svn references from gradle - git migration happened some time ago
Hi Jacques, Here it is: https://issues.apache.org/jira/browse/OFBIZ-12267 https://github.com/apache/ofbiz-framework/pull/305 It builds locally. PullAllPlugins task does not seem to do anything for me ?! Maybe I don't know how to use it. On 28.06.2021 15:07, Jacques Le Roux wrote: Hi Eugen, We no longer support any version that use SVN indeed. So we can at least clean it from trunk as an improvement. A Jira fits. TIA Jacques Le 28/06/2021 à 13:10, Eugen Stan a écrit : Hello, I can clean svn references from gradle: svnFooterFile, svnInfoFooter . Not sure anyone is using SVN anymore. -- Eugen Stan +40720 898 747 / netdava.com
I can clean svn references from gradle - git migration happened some time ago
Hello, I can clean svn references from gradle: svnFooterFile, svnInfoFooter . Not sure anyone is using SVN anymore. -- Eugen Stan +40720 898 747 / netdava.com
Re: how to add repository for plugin dependency? how to plugins using private repositories?
Hello Jacques,
I've created an issue and a PR for this
https://issues.apache.org/jira/browse/OFBIZ-12263 .
https://github.com/apache/ofbiz-framework/pull/304/files
I did some research and the current solution for building plugin - that
depend on source does not allow us to declare repositories for plugins
IMO. Maybe gradle will provide this in future.
I would go the route of publishing binaries for OFBiz framework and use
those in plugins/apps via a gradle platform (BOM) dependency.
This should make plugins more independent of OFBiz - at least buildwise.
IMO current way of building plugins requires OFBiz sources - and while
it provides advantages, it is also a big dependency to pull in.
Regards,
Eugen
On 17.06.2021 14:34, Eugen Stan wrote:
Hi Jacques,
Tried and looked but no success unless I add directly to
ofbiz-framework/build.gradle .
Probably those plugins have all dependenices on maven central or the
others repo.
I updated my ofbiz-clojure-repl plugin but I can't build it unless I add
clojars repo.
Without the repository or adding the repo in
ofbiz-clojure-repl/build.gradle I get:
Build file '/home/ieugen/proiecte/ofbiz/ofbiz-framework/build.gradle'
line: 1124
* What went wrong:
A problem occurred evaluating root project 'ofbiz'.
> Could not resolve all files for configuration ':runtimeClasspath'.
> Could not resolve nrepl:nrepl:0.8.3.
Required by:
project : > project :plugins:ofbiz-clojure-repl
> Could not resolve nrepl:nrepl:0.8.3.
> Could not get resource
'https://repo.spring.io/plugins-release/nrepl/nrepl/0.8.3/nrepl-0.8.3.pom'.
> Could not HEAD
'https://repo.spring.io/plugins-release/nrepl/nrepl/0.8.3/nrepl-0.8.3.pom'.
Received status code 401 from server: Unauthorized
With this change it works:
--- a/build.gradle
+++ b/build.gradle
@@ -152,6 +152,10 @@ allprojects {
// com.springsource.com.sun.syndication
url "https://repo.spring.io/plugins-release;
}
+ maven {
+ url "https://clojars.org/repo;
+ }
}
}
https://github.com/netdava/ofbiz-clojure-repl
On 17.06.2021 12:59, Jacques Le Roux wrote:
Hi Eugen,
I'm not sure it's what you are looking for but you may have a look at
build.gradle files that you can fins in some plugins, eg
https://github.com/apache/ofbiz-plugins/blob/trunk/birt/build.gradle
HTH
--
Eugen Stan
+40720 898 747 / netdava.com
Re: OfBiz microservices
Hello Fahim, I'm also thinking about this. Microservices that share a DB might not be "true" microservices but we can go with that. I'm quite new to OFBiz myself and figuring out how to deploy it for the same purpose. I believe docker might help to ease deployment so I am working on making a docker image [1], [2] and kubernetes chart [3] Some of the ideas I have is to: * Deploy OFBiz apps with framework as libraries (need to be published) - as HTTP app * I think using a shared cache is mandatory * Use a proxy in front to route requests to the right microservice Some things that would help IMO are: * for OFBiz to have an API - it's easier IMO to reason about and less dependencies per microservice * OFBiz to publish libraries of framework apps so we can reuse them in apps without having to build everything I'm looking forward to hearing more ideas about this. [1] https://hub.docker.com/repository/docker/ieugen/ofbiz [2] https://github.com/ieugen/ofbiz-framework/ - branch OFBIZ-10407-docker-ieugen On 18.06.2021 15:35, Fahim Farook wrote: Hello everyone! I don't have much experience with ofbiz; nevertheless, I began looking for an ecommerce platform and came across it. I wanted to understand whether OfBiz applications could be deployed as microservices. i.e. ofbiz/framework + ofbiz/applications/some app> for each "microservice"? And what would the challenges in creating a single admin panel? Thanks, Fahim -- Eugen Stan +40720 898 747 / netdava.com
Re: how to add repository for plugin dependency? how to plugins using private repositories?
Hi Jacques,
Tried and looked but no success unless I add directly to
ofbiz-framework/build.gradle .
Probably those plugins have all dependenices on maven central or the
others repo.
I updated my ofbiz-clojure-repl plugin but I can't build it unless I add
clojars repo.
Without the repository or adding the repo in
ofbiz-clojure-repl/build.gradle I get:
Build file '/home/ieugen/proiecte/ofbiz/ofbiz-framework/build.gradle'
line: 1124
* What went wrong:
A problem occurred evaluating root project 'ofbiz'.
> Could not resolve all files for configuration ':runtimeClasspath'.
> Could not resolve nrepl:nrepl:0.8.3.
Required by:
project : > project :plugins:ofbiz-clojure-repl
> Could not resolve nrepl:nrepl:0.8.3.
> Could not get resource
'https://repo.spring.io/plugins-release/nrepl/nrepl/0.8.3/nrepl-0.8.3.pom'.
> Could not HEAD
'https://repo.spring.io/plugins-release/nrepl/nrepl/0.8.3/nrepl-0.8.3.pom'.
Received status code 401 from server: Unauthorized
With this change it works:
--- a/build.gradle
+++ b/build.gradle
@@ -152,6 +152,10 @@ allprojects {
// com.springsource.com.sun.syndication
url "https://repo.spring.io/plugins-release;
}
+maven {
+url "https://clojars.org/repo;
+}
}
}
https://github.com/netdava/ofbiz-clojure-repl
On 17.06.2021 12:59, Jacques Le Roux wrote:
Hi Eugen,
I'm not sure it's what you are looking for but you may have a look at
build.gradle files that you can fins in some plugins, eg
https://github.com/apache/ofbiz-plugins/blob/trunk/birt/build.gradle
HTH
--
Eugen Stan
+40720 898 747 / netdava.com
how to add repository for plugin dependency? how to plugins using private repositories?
Hello, How can I add a maven repository for plugin dependencies? My plugin depends on a library that is published on clojars.org . I could add the repo to main ofbiz-frameweork build.gradle but that would work only for me and I don't expect this to work for private dependencies. How does one develop in such cases? Plugin repo is https://github.com/netdava/ofbiz-clojure-repl . I clone the repo in plugins and try to build it. Regards, -- Eugen Stan +40720 898 747 / netdava.com
I'm working on an OFBiz helm chart for kubernetes
Hello, NOTE: I previously sent this email from an un-subscribed email address, please ignore that one. I'm working on a Helm chart for OFBiz https://github.com/ieugen/charts/tree/main/ofbiz . The goal is to have OFBiz running in Kubernetes. Right now it's a rough start: it starts OFBiz with Derby and that's about it. I'll keep pushing updates as soon as I have them. I'm interested in your feedback. If you plan on testing it and using it let me know. I do accept and encourage collaboration. If this is interesting I might push it upstream but it uses the binary build of OFBiz in Docker. I'm using docker images built from trunk on jdk-11. There are amd64 and arm64 (Raspberry PI4) images. Some issues that need solving are the many configuration files that OFBiz has. This details creates a lot of configuration when deploying in Docker / Kubernetes as they need to be mounted in a volume with many entries or multiple volumes. There are many potential solutions to this but it boils down to: * It would be nice to load max 1-2 or 3 configuration file with multiple sections instead of the currently many configs split over the code base. * It would be nice to support configuration (overwrite) via ENV vars for some things like DB connection. Regards. Eugen
Re: [OPTIONS] Java 11 and Java JDK origin
+1 for jdk11. We can focus on jdk17 once it's out. The transition will probably require some work. jdk17 is attractive though in terms of language features and enhancements. We could use multiple JDK's to build OFBiz . I can set this up in Jenkins or github actions with the community consent / support. Well I kind of did it for jdk8 and jdk11 for both amd64 and arm64 with docker images - https://github.com/ieugen/ofbiz-framework/actions/runs/510286929 . But it's not official and would like to upstream it (hint hint). Regards, -- Eugen Stan +40720 898 747 / netdava.com
Re: Ofbiz integrate Python script
Hi, Two other options would be * GraalVM https://www.graalvm.org/docs/getting-started/#run-python and https://www.graalvm.org/reference-manual/polyglot-programming/ * Run your python code as an external HTTP service and call it from OFBiz Please let us know which one you choose and why. Regards, Eugen On 26.01.2021 15:37, James Yong wrote: Hi Nguyen, Any python library you have in mind? For calling python from java, the information from the following link may helps: https://www.baeldung.com/java-working-with-python Regards, James On 2021/01/23 07:41:28, Thanh Nguyen wrote: Hi everyone, How do you think about integrate Python into Ofbiz? Python have a big libraries for data visualization and AI, so that we can use these libraries to build "Sales Forecast", " "detect Item error"... Thanks Thanh Nguyen -- Eugen Stan +40720 898 747 / netdava.com
Re: Clojure service engine
On 20.01.2021 12:23, Jacques Le Roux wrote: HI Eugen, This remembers me https://markmail.org/message/m4zdgpvrub5k2hed (did not re-read) and sounds like a good idea to me. Even if I don't think I'll offer any support...for now... Jacques Thanks. That is also me - just a plugin then. Will revisit that. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Clojure service engine
Hello, I would like to explore (and in the future propose for addition ?!) a Clojure service engine implementation. I would like to ask for feedback on this topic. Guidance as to how approach this process is very much appreciated. I use Clojure as my daily language and it has IMO a lot of feature that make it a great language. I would very much like to have the ability to write OFBiz services (and other components) using Clojure. Arguments for Clojure: - a single library with VERY good backward compatibility - Clojure (lisps in general) hasn't change much - it is dynamic like Groovy - has immutable data structures by default - a big win for developing safe code - seamless inter-op with Java and JVM languages - a very nice development experience using the REPL - simple syntax - once you get the hang of lisp style Clojure uses Maps, Sets and sequences (Collections) to process data so it is an excellent fit since services use map arguments. I will explore this and see the integration points that we have. For starters, I would like to be able to use a Clojure function as a service. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Re: OFBIZ-12081: DB driver download and configuration based on gradle property
Hi, See my reply inline: Regards, Eugen On 14.01.2021 18:02, Daniel Watford wrote: Hi Eugen, I think your point... > It's important to match the driver version with database version ... is a good reason for the ofbiz project to NOT be opinionated about database libraries and versions Originally I had only thought we would need to specify one driver for one DBMS type. I had failed to realise there would be lots of different versions of any one DBMS in use, each potentially requiring a different driver version. Figuring out the 'good' driver version for each DBMS version potentially used with ofbiz probably wouldn't be workable. I imagine at best we might have a web page where ofbiz administrators can report on the combination of DBMS version, driver and JVM they are successfully using. You've changed my mind! :) I'll drop the use of build-time properties to resolve database driver libraries. If that is the case then the solution might be simpler: We can set our own constraints. For a lot of web applications the norm is: We support only the latest 2-4 versions of Browser X, Y and Z. In Debian, the policy is to keep the major version of an app during the full lifetime of the release. If Debian 10 comes with Gnome 3.34 - That is the version people are going to use until Debian 11 comes ~ 2 years later. Only minor upgrades / patches are updated. This makes sense considering Debian packages ~ 65.000+ packages (?!). OFBiz could deliver only the latest versions at the time of release and upgrade only patch versions (?!) or during point releases. It's best if this policy is made explicit in the documentation. Let's say that OFBiz 18.x comes with - postgresql-jdbc 42.x which supports PostgreSQL 9.x -> 13.x - mysql connector 8.x - which supports MySQL and MariaDB 10.x + OFBiz 21.x will come with the latest drivers at it's release time, and so on. Also since OFBiz has a base JVM version used for building, we could use that version to match the drivers as well. This database version compatibility and information about jvm version is available on the provider website. If people use something else - it's on them to make the changes - this phrase should also be explicit. IMO It's not the community's obligation to support every permutation out there. Because I build Docker images and I can add libraries to classpath - I'm good either way. Once https://issues.apache.org/jira/browse/OFBIZ-12136 is merged (will submit a PR) - I'm all set for database drivers. IMO one reason to add drivers to the projects is to make make it easier to run integration tests for those databases OOTB. I'm still not familiar with the project structure to figure out how to run those tests. -- Eugen Stan +40720 898 747 / netdava.com
Re: Deprecating and removing unused HTML renderers
On 14.01.2021 16:43, Jacques Le Roux wrote: Hi Daniel, Quite a good question, we had similar discussions before. An old one is https://markmail.org/message/rlksriqjznsndq2g The end of last one is https://markmail.org/message/4aia3v5ugjjajmhf It's documented for services at https://s.apache.org/6ophi We currently have 201 @Deprecated occurrences in Java classes (121 in 2008). Apart by looking for revision information, in Java code we miss the date when the deprecation took place. I answered to David's proposition in the 1st thread above <> If we agree that "release created" means creation of a new release branch (and not releasing a package which would be confusing for packages inside a release branch), we could, as suggested recently, 1. create a R21 branch 2. Remove all the currently deprecated methods in the trunk (and not yet in R21?) 3. Document this process in in the same place than above in the wiki 4. Use this process for each new release branch created What do you people think? What about not removing in trunk before creating R21 as I believe most deprecations are old if not very old ones? Jacques Removing after a release branch is created is reasonable IMO (when "release created"). -- Eugen Stan +40720 898 747 / netdava.com
Re: OFBIZ-12081: DB driver download and configuration based on gradle property
Hi, Please see my reply inline: On 14.01.2021 16:21, Daniel Watford wrote: Hi Eugen, I like the approach of a config directory which can be used to override configuration files already compiled into a distribution (distTar/distZip). It's probably worth opening a separate ticket for that since it would be analogous to how the /lib directory is currently used for gradle builds. https://issues.apache.org/jira/browse/OFBIZ-12136 lib/ is not enough. Gradle hardcodes the classpath. Adding jars there has no effect IMO (see generated bin/ofbiz script). That is why I added lib-extra/ But my main question was intended to deal with how ofbiz administrators identify and retrieve the database driver libraries for their deployments. In your case did you find a list of recommended versions for use with Ofbiz or did you have a driver that you often use with your DBMS? Did it take much time to choose the driver? When talking database drivers I try to pick the latest release. It's important to match the driver version with database version and JVM version. With PostgreSQL the latest driver is fine with the postgres 13 (which I am using) and JVM 8 or 11 which I am using. For other databases it's the same: pick a driver that works with you database version and your JVM. Even if it was easy for you to figure out the driver version, do you think other less experienced ofbiz administrators would struggle? Having the ofbiz project declare, in code, what library versions are known to work with various DBMS would reduce the effort required for all administrators. Yes, for other people it might not be as easy - depending on their knowledge and expertise - that is why we have community and consultancy services. I agree that we probably don't want to change the content of configurations at build time, but it might be appropriate to break entityengine.xml into smaller DBMS specific files and then only include one of those files in a binary distribution specific to a particular DBMS, hopefully making it a bit easier for ofbiz administrators to get started. I would split database connection out of the config or have the ability to use environment properties or java system properties to configure the connection. This is better IMO than having to edit configuration files. If you have an OFBiz build than you can change just supply different params for DB instead of having to create config files. Modern configuration libraries have functionality to interpolate variables in the configuration file with env variables or system properties. See for example https://github.com/lightbend/config . My overall aim is to reduce the amount of additional library downloads and configuration an ofbiz administrator needs to perform in order to get started. Every step should help get closer to externalising configuration, as I believe you are already working towards, which should make deploying and upgrading ofbiz running in containers a bit easier. Thanks and I'll try to help you with this goal. Docker makes these deployment issues more visible. People handle deployment in many ways and with many tools. I believe documentation is better here than opinionated solutions. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Re: Deprecating and removing unused HTML renderers
Hi, I am all for getting rid of the extra "fat" ASAP. Working on less code is easier. Mark for 18 + remove in trunk sounds reasonable to me considering the time differences. Larger projects like Kubernetes have a deprecation policy: - deprecate in release X - keep in release X+1 - remove in X+2 or later depending on implications Kubernetes does have a 4 month release cycle while OFBiz - once every few years. I think it's important to let people know when they will be removed so they have some expectations. If you deprecate them in 18 with a message that they are going to be removed in trunk (next release) then it should be fine. People will have 6+ months to upgrade / find a solution which is reasonable IMO. NOTE: I don't maintain OFBiz in production so I don't have to migrate things. On 14.01.2021 15:57, Daniel Watford wrote: Hello, https://issues.apache.org/jira/browse/OFBIZ-11927 refers to HTML renderers which do not appear to be used anymore. James has confirmed this observation. I assume that we only need to keep the unused classes around in case they are being used by a third party plugin, but we can at least mark them as deprecated so that any such plugin authors might notice. My question is what should the timing be for deprecation and removal? My assumption would be that we can mark the HTML renderer classes as deprecated in both trunk and the release 18 branch asap. But when should we remove the unused HTML renderers? Is it okay to remove them from trunk at the same time as marking them deprecated in release 18? This would ensure they are removed from whichever release is planned to follow 18. Thanks, Dan -- Eugen Stan +40720 898 747 / netdava.com
Re: OFBIZ-12081: DB driver download and configuration based on gradle property
Hello Daniel,
I'll re-post with updates my github comment here since I imagine not
everyone will read the PR comments.
I think trying to meddle with those configs at build time is brittle and
would complicate the build.
It would help to have the ability to add jars and configuration files to
the classpath - since that is where ofbiz looks for.
So the idea is to make it easy for people to add things at the BEGINING
of the classpath so they can override ofbiz configurations (and / or
libraries ?!)
I believe this can achieved for both gradle deploy and binary
(ofbiz.tar) deploy with minimal changes.
If you could add the code snippet bellow to build.gradle then people can
add files to config/ and lib-extra/ directories and they will be
available for ofbiz when it starts.
I've tested this and it works for my ofbiz docker build (I'm planning an
article these next 2 days and will share it. Spoiler: it works on ARM -
raspberry pi 4 ;) ).
I'm also adding the database drivers post build to lib-extra .
That way I can keep the ofbiz source unchanged and still get what I need.
(I don't have windows to test the classpath ).
tasks.startScripts {
doLast {
// Alter the start script for Unix systems.
unixScript.text =
unixScript.text.replace('CLASSPATH=$APP_HOME/lib',
'CLASSPATH=$APP_HOME/config/:$APP_HOME/lib-extra/*:$APP_HOME/lib')
// Alter the start script for Windows systems.
//windowsScript.text =
//windowsScript.text.replace('CLASSPATH=$APP_HOME/lib',
//
'CLASSPATH=$APP_HOME\\conf\\:$APP_HOME/lib-extra/*:$APP_HOME/lib')
}
}
For adding things to the classpath when running gradle there is
something in place:
// Libraries downloaded manually
implementation fileTree(dir: file("${rootDir}/lib"), include:
'**/*.jar')
--
Eugen Stan
+40720 898 747 / netdava.com
help review PR for starting ofbiz from binary
Hello there, Please help review and merge this PR: https://github.com/apache/ofbiz-framework/pull/250 . My goal is to run ofbiz using the jars generated via gradle build (ofbiz.tar). I've ran into this issue: https://issues.apache.org/jira/browse/OFBIZ-12118 and supplied a PR for it at https://github.com/apache/ofbiz-framework/pull/250 . I'm also working on a PR to build docker images for OFBiz and use external databases. I will write come back with another email to ask feedback on merging it. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Re: Welcome to Daniel Watford as new committer!
Congratulations Daniel, -- Eugen Stan +40720 898 747 / netdava.com
Re: [DISCUSSION] Adopting Docker for OFBiz - what are the objectives?
Hi, Thank you all for your feedback. I've started working on my version of docker image / build for OFBiz. It is still work in progress and I will share my work when I have the demo running with Docker. Perhaps we will find a way to have OFBiz docker images. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Re: [DISCUSSION] Adopting Docker for OFBiz - what are the objectives?
On 04.12.2020 23:32, Daniel Watford wrote: Interesting point about Kubernetes, especially since its use would promotes use of runtimes other than docker - https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m I'd be interested to explore using Kubernetes, but worry it might be a step too far at the moment. Hopefully some people will have Ofbiz-Kubernetes success stories to share that could encourage others to give it a try. I wonder if a benefit of Kubernetes could be how it externalises common application services such as config (etcd) and logging. On Fri, 4 Dec 2020 at 19:35, Ean Schuessler wrote: Thank you Daniel for the detailed description of your workflow and everyone else for input. I also use Kubernetes mostly and it brings a lot to the table but with a learning curve, especially if you administer your cluster. For people starting out iwht kubernetes I recommend k3s distribution: https://k3s.io/ It's a single binary that is easy to deploy. Regarding OFBiz, I thought about how to approach this and I think I will publish binaries to a bintray repository. From there anyone (including me) can build their own distribution fast. If all works well I can automate that to do daily builds. Once I have the docker image I can build a kubernetes helm chart for it. The alternative would be to make a repo with ofbiz and plugins and build everything from source. Maybe gradle multi project builds can help here https://docs.gradle.org/current/userguide/multi_project_builds.html Regards, -- Eugen Stan +40720 898 747 / netdava.com
[DISCUSSION] Adopting Docker for OFBiz - what are the objectives?
Hi, There has been some discussion regarding Docker and OFBiz, however no consensus yet. I'm starting this thread after discussions on Slack with Jacques Le Roux, Daniel Watford and Michael Brohl. The the aim to establish some goals / objectives regarding Docker and OFBiz. Please add your feedback, comments and suggestions. Prior work regarding this is found https://issues.apache.org/jira/browse/OFBIZ-10407 https://lists.apache.org/thread.html/r40fd679818a37e113b469add51755b1097a2b02d3961e71a2cfe928d%40%3Cdev.ofbiz.apache.org%3E and in the links stemming from the links above. == How can we integrate Docker in OFBiz ? Docker can be used in two distinct ways: a. Use Docker as a way to build OFBiz components - this will make builds more portable - as long as people have Docker (or containerd or podman) installed locally, they will be able to build OFBiz "for sure" (tm). This aims to solve the issue of people not having the proper JDK and required tools installed (gradle, git ?! etc). b. Use Docker to deploy OFBiz for production purposes (and demos) IMO this means building a slim Docker image with only JRE and OFBiz + a custom selection of plugins. IMO this is best achieved with pre-built, published binaries for ofbiz. c. Use Docker to develop / debug OFBiz I'm not sure if this is really a thing since IMO falls into b). Using docker multi stage image builds is something that could help. The goals are sometimes at odds with one another in the sense that doing something to fix a goal will hinder the other. Do you see other use-cases for Docker and OFBiz? == My personal take Personally I would like to focus on b). I did not have good experience with building sources with Docker - I could not get used to the workflow. Also when I deploy to production, I don't really care how it's built as long as I have the binary and I can run just that. So we might end up with two or more Dockerfiles, each focusing on specific objectives. Regards, -- Eugen Stan +40720 898 747 / netdava.com
Ofbiz data for Romania
Hello, I would like to deploy OFBiz for my company in Romania and I know Pierre mentioned some seed data that I need. I'll work on building that and contribute it upstream. I'm not sure yet how to do it so anay links are appreciated. I will go through the documentation tomorrow. Regards,Eugen
Re: A little bit of Lombok
La 28.07.2020 16:10, Michael Brohl a scris: Hi Daniel, can you explain what the advantages and disadvantages are? Is it worth the introduction of an additional framework, more complex IDE configuration, an additional Gradle plugin and more memory consumption and why? Thanks for clarification, Michael Brohl Hi, My 2c: I think Lombok is great. I've used it with my previous Java projects to reduce the amount of boilerplate needed when writing Java code. The lombok annotations are only applied during compilation so they don't change the runtime behavior. The cons are an initial quick setup and a very small learning curve. The pros are less code to write and review and safer equals and hashcode (they are generated) . I would argue that some of the advantages regarding getters and setters will be diminished once Records are adopted in Java (second preview) https://openjdk.java.net/projects/jdk/15/ I believe this will be done probably in march 2021 and it will be in time for the next LTS which hopefully it will be JDK 16 in september 2021 as per https://www.oracle.com/java/technologies/java-se-support-roadmap.html . That being said Lombok has advantages and can be used very easily. I do think Lombok can be set without a plugin since grade has annotationProcessor configuration https://tomgregory.com/annotation-processors-in-gradle-with-the-annotationprocessor-dependency-configuration/ -- Eugen Stan +40720 898 747 / netdava.com
Re: Documentation "issues"
Hi, I think it's great that you are migration your docs to AsciiDoc. What are you using to publish them? We've been working on doing a similar process in Apache James. We decided to use Antora for publishing the content which is pretty great so far. We haven't finished our process. I've managed to make the automated build and the next goal is to work on the content and structure. If you are interested, here are some links: * https://github.com/apache/james-site/ - repo to build the documentation website - includes gradle tasks to build the theme and run antora. * Jenkinsfile is used to publish the staged website to https://james.staged.apache.org/main/3.5/index.html * https://issues.apache.org/jira/browse/JAMES-3226 Jira issue to track the progress La 20.07.2020 11:54, Olivier Heintz a scris: Thanks Jacques, for this list, I will finish the plugins docbook migration to asciidoc and I will continue with these JIRA, with a first step to be sure to migrate all old format to the new one. This list is a good road to clean before doing some new doc. Thanks Olivier Le 17/07/2020 à 09:46, Jacques Le Roux a écrit : Hi All, Olivier, Again Olivier, I must say I'm so glad that you took the documentation challenge in hands. That's very promising for the future of the project. Thanks for your work! At this stage I'd like to clean the situation as much as possible. It's not about your work, but about all that we have left behind us. It's difficult to figure out what the situation really is. There are few minor things and some others more systemic. What are your thought about them? Take your time ;) Among the minor issues: I think we should begin to close issues like: OFBIZ-6644: This is deprecated with its sub-tasks OFBIZ-11893: Trivial issues I collected before forgetting them. You might found more. https://demo-trunk.ofbiz.apache.org/cmssite/cms/APACHE_OFBIZ_HTML: This is now broken. I guess after you removed some files referenced by documents in /plugins/cmssite/documents Related with OFBIZ-11364 I guess. OFBIZ-9926 should be closed. OFBIZ-6243: Should we take the burden of migrating the existing README.md? I don't think so. I'd like to remove them with the related wiki pages, like: https://cwiki.apache.org/confluence/display/OFBENDUSER/Financial+Accounting+and+Reporting All that is mostly deprecated and redundant. Among the more serious ones: = OFBIZ-10285: What are your thoughts about this one (sorry not enough time to dig in)? It's clearly time to prune the sub-tasks, I mean close them if possible, like: OFBIZ-10251 OFBIZ-10255 OFBIZ-11364 etc. Also we need to update, actually mainly prune, the wiki, there is too much deprecated and MISLEADING documentation there! A bit of pontification :): One thing I learned is that it's hard to maintain a documentation. Because things evolve and are not always related to each other (like code). So we should restrain ourselves to refer to things that may disappear or change in the future. If not possible we need to generalise them as much as possible. An example is OFBIZ-6243. Jacques -- Eugen Stan +40720 898 747 / netdava.com
Re: JUnit 5?
Hello Jacques,
I think it makes sense to make the transition.
In James we do have it ongoing.
Junit5 people have documented the upgrade process and you can make it
gradually and have both.
Use ` git grep org.junit.Test | wc -l `to count the non-migrated tests.
This is what we have based on the migration samples
https://github.com/junit-team/junit5-samples#gradle-migration-
https://github.com/junit-team/junit5-samples/blob/main/junit5-migration-gradle/build.gradle
https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.5.1'
testImplementation 'org.junit.jupiter:junit-jupiter-params:5.5.1'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.5.1'
testCompileOnly 'junit:junit:4.13'
testRuntimeOnly 'org.junit.vintage:junit-vintage-engine:5.5.1'
}
test {
useJUnitPlatform()
}
La 05.07.2020 10:01, Jacques Le Roux a scris:
> I created https://issues.apache.org/jira/browse/OFBIZ-11870 for that
>
> Jacques
>
> Le 04/09/2018 à 09:15, Jacques Le Roux a écrit :
>> Hi,
>>
>> I stumbled upon this tweet
>>
>> https://twitter.com/junitteam/status/1036707906706698243
>>
>> Had a quick look at
>>
>> https://junit.org/junit5/docs/5.3.0/release-notes/
>>
>> https://www.baeldung.com/junit-5-migration
>>
>> I did not rememberf, so searched if we discussed moving from JUnit 4
>> to JUnit 5, but did not find anything.
>>
>> Did we discuss it, if so what were the conclusions? If not, should we
>> not discuss it?
>>
>> Thanks
>>
>> > https://twitter.com/junitteam/status/1036707906706698243witter.com/junitteam/status/1036707906706698243
>>
>> Jacques
>>
>>
--
Eugen Stan
+40720 898 747 / netdava.com
<>
signature.asc
Description: OpenPGP digital signature
Re: [Presentation] Slides for empower screen engine
I'm a begginer in OFBiz and looking forward to see the new theme. Very nice presentation. The sound volume in the second video is very low. Once you merge this, it would be nice to publish the videos on Apache OFBiz youtube channel. Regards, Eugen La 03.07.2020 11:14, Nicolas Malin a scris: > > Hello all, > > To finalize our current work presentation to homogenize and empower > the screen engine, we realized some slides [1] to summarize it. > > We opened an issue to prepare to load of it in trunk (OFBIZ-11808 [2]) > with the idea to not introduce any regression on old theme and screen. > > So to continue to move forward, we appreciate to have any remark, > suggest or feeling about that, your welcome ! > > Cheers, > > Nicolas > > [1] https://s.apache.org/EmpowerOFBizScreen > [2] https://issues.apache.org/jira/browse/OFBIZ-11808 > > -- > logoNrd <https://nereide.fr/> > Nicolas Malin > The apache way <http://theapacheway.com/> : *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 <http://ofbiz.apache.org/>|The Apache Way > <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/> -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Re: [PROPOSAL] Change implementation/runtimeOnly in build.gradle to comma separated style?
Hi Shi Jinghai, What are the benefits? Why do all this work? It seems to me they are only mild cosmetic improvements (arguably an improvement). In my apps I usually copy dependencies from maven (the copy button) and they include the 'implementation' word, as most similar sites do. Example: https://search.maven.org/artifact/org.huihoo/ofbiz-smart-framework/0.9.5/jar La 30.06.2020 06:05, Shi Jinghai a scris: > Hi there, > > While typing implementation, runtimeOnly and etc. in build.gradle, I find > they can be changed to comma separated style, as the build.gradle is a groovy > file, for example: > > implementation 'xerces:xercesImpl:2.11.0' > implementation 'com.google.zxing:core:3.4.0' > implementation > 'com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.2' > implementation 'com.googlecode.ez-vcard:ez-vcard:0.9.10' > implementation > 'com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:1.1' > > EQUALS to > > implementation 'xerces:xercesImpl:2.11.0', >'com.google.zxing:core:3.4.0', > > 'com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.4.2', >'com.googlecode.ez-vcard:ez-vcard:0.9.10', > > 'com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:1.1' > > Just the same as > int a, b > equals to > int a > int b > > What do you think? > > Kind Regards, > > Shi Jinghai > > -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Re: OFBiz-GraphQL Webinar Recording on YouTube
Thanks for the webinar. I watched it full as an API on top of Of Biz is of interest to me. I have some feedback which I believe you are already aware of: - the audio is of poor quality and hard to understand in some points - the video is very long and could use some editing to remove the silent / dead parts. - If editing is not an option, I think it's easy to add "skip this section" buttons on youtube. Please share future videos in this direction. Regards, Eugen La 08.05.2020 18:10, Pranay Pandey a scris: > Here is the direct URL: https://youtu.be/VK0o0OBAS1I > > Best regards, > Pranay Pandey > > > On Fri, May 8, 2020 at 8:39 PM Pranay Pandey < > pranay.pan...@hotwaxsystems.com> wrote: > >> Hello OFBiz Devs, Users >> >> OFBiz-GraphQL webinar recording is now available for everyone's reference >> on YouTube. >> >> Thank you Girish Vasmatkar for this doing this webinar and providing the >> recording for upload. >> >> Best regards, >> Pranay Pandey >> -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Re: New Online Help, base on ci.apache.org/projects/ofbiz/site/ofbizdoc
gt;>> any thoughts? >>>>>>>>>>>>> >>>>>>>>>>>>> ps: this week, I will do this job for accounting component >>>>>>>>>>>>> >>>>>>>>>>>>> Le 11/05/2020 à 15:38, Olivier Heintz a écrit : >>>>>>>>>>>>>> Hi community, >>>>>>>>>>>>>> >>>>>>>>>>>>>> First step about Docbook migration to asciidoc is done, all >>>>>> existing files have been converted >>>>>>>>>>>>>> (waiting a review before PR merge) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Next step is to have a new help system, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I propose to do a very simple solution which would be a link >> to >>>> a >>>>>> documentation site. >>>>>>>>>>>>>> This solution would use >>>>>>>>>>>>>>1. at ofbiz level, a default proprety for documentation >>>>>> website uri >>>>>>>>>>>>>>2. at the screen level >>>>>>>>>>>>>> * it would be possible to give a other uri (for user >>>>>> documentation) >>>>>>>>>>>>>> * if the anchor in the user documentation for this >>>> screen >>>>>> is put, the new help is used otherwise the older link is used >>>>>>>>>>>>>> If this solution is validated, next step will be to update all >>>>>> the screens with the correct link value >>>>>>>>>>>>>> I propose to create the Jira (and the implmentation) with this >>>>>> very simple solution (using the doc generated by Buildbot as >>>> documentation >>>>>> site) >>>>>>>>>>>>>> when some other people with a good knowledge of gradle and/or >>>>>> ofbiz cms have time to do a internal documentation website, it will be >>>>>> possible to >>>>>>>>>>>>>> change the default uri ;-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> what's your opinion about ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le 26/02/2020 à 17:10, Olivier Heintz a écrit : >>>>>>>>>>>>>>> inline >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Le 26/02/2020 à 14:02, Taher Alkhateeb a écrit : >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> In my experience, as I'm working with >>>>>>>>>>>>>>>- current ofbiz online help >>>>>>>>>>>>>>>- ofbiz webhelp >>>>>>>>>>>>>>>- some static doc website done with Grav (build with >>>>>> multiple small files) >>>>>>>>>>>>>>>- some static doc website done with asciidoc (only one >>>>>> large file) >>>>>>>>>>>>>>>- ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With multiple small files it's needed to have a very good >>>> search >>>>>> engine and a global index / TOC >>>>>>>>>>>>>>> With the One page doc, the TOC is very large and not always >>>> very >>>>>> convenient, but exist and the browser-find works >>>>>>>>>>>>>>>and it's easy to navigate between details and >> generality >>>>>>>>>>>>>>> So, as a user, I prefer help base on One page documentation. >>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>> When we have tried, in the past to dynamically generate html >>>>>> from standard docbook process it was too slow >>>>>>>>>>>>>>>it's why it was decide to use a freemarker template >> to do >>>>>> the generation, even if only 5% of docbook syntax >>>>>>>>>>>>>>>was managed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Documentation not change very often, static page seem enough >>>> for >>>>>> our need. >>>>>>>>>>>>>>>> On Wed, Feb 26, 2020 at 2:29 PM Olivier Heintz < >>>>>> holiv...@apache.org> 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 >>>>>>>>>>>>>>>>> -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Re: Clojure Repl for OFBiz - repl driven development
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 for that. 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 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
Re: Clojure Repl for OFBiz - repl driven development
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/) > > > 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 > > > -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Clojure Repl for OFBiz - repl driven development
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 <> signature.asc Description: OpenPGP digital signature
