Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi,
I am working on the restructuring of the Groovy scripts. So far, I have
written a script that moves all Groovy files to the 'src' directory and
changes the references. In the second step, a package declaration is
added for all Groovy scripts. Prior to running my script, I did some
manual work such as moving imports under the license header and renaming
Groovy scripts to avoid duplicated classes.
At this point, I am encountering some trouble with the build. When I run
'./gradlew test', it doesn't work because some variables (e.g.
delegator, dispatcher, security) are not available. I set a breakpoint
in SimpleTests.groovy's testDelegator() function, and when I run the
testIntegration, the delegator is not null. However, when I run the
'test' task, the delegator is null.
Does anyone have an idea why I am getting null for the delegator in test
(build)?
I have created a pull request in OFBIZ-12813, so if anybody wants to
test it, feel free to do so.
Best regards,
Wiebke
Am 12.05.23 um 12:13 schrieb Wiebke Pätzold:
Hi everyone,
for the restructuring concerning the Groovy classes I have thought
about a few more things and have worked out a rough plan for a script/
Steps to be done.
If there are no objections here I would start with the implementation
of such a script.
The idea from Gil Portenseigne to implement a inspection feature as a
plugin to detect bad references could be a nice feature to check if
the restructuring was successful.
Steps for the restructuring:
1st step:
* move all groovy test files to
{basedir}/src/test/groovy/org/apache/ofbiz/*
* bevore moving add file to list of moved files
* work throu the list of moved files and adjust references (should be
under {basedir}/testdef/*)
2nd step (services and frontend scripts) :
* move the remaining groovy files to
{basedir}/src/main/groovy/org/apache/ofbiz/*/*.groovy
* bevore moving add file to list of moved files
* adjust references
** Work through the list of files moved and search for occurrences in
other files and adapt import * for frontend scripts, adapt the
location for services in the service definition.
3rd step:
* add package if none exists in groovy file yet
4th step:
* check moved files lists to see if this is a proper package
declaration (Has to be done manually)
Best regards,
Wiebke
Am 05.05.23 um 15:52 schrieb Wiebke Pätzold:
Hi everyone, to minimize the potential for errors, I would like to
see if it is possible to write a script that moves the groovy files
and references in the first step and adds the package declaration for
the Groovy files in a second step.
If the general consensus is that we do this restructuring for the
trunk, then I would deal next week with how such a script has to look
like and to which degree the restructuring can be done automatically.
Best regards, Wiebke
Am 02.05.23 um 09:16 schrieb Daniel Watford:
Hi Michael,
I would be concerned about our capacity to move all these groovy
scripts
and ensure correct location updates are made to the type="groovy"
path="..." /> elements in the controller.xml files and elements in service definitions in
both trunk and the release22.01 branch.
If we were to pursue these changes, could we add a test mode to code
that
parses service definitions and controller xml files to check that the
groovy location (and invoked methods were relevant) are accessible?
This
means we would have some automation to help ensure changes have been
applied correctly.
This will be a big undertaking, so I would suggest creating some
mini-project-management similar to that done for the CodeNarc
integration
where we have a list of files that need moving and committers add their
name to files they are actively working on. I would also request
that we
introduce rules for this mini-project such as, 'No functional
changes to
code', and 'keep Pull Requests small', etc.
To answer your original question, if we do not make the proposed
changes to
release 22.01, we will substantially degrade the ability for developers
using Eclipse to work with OFBiz. But if we do proceed with this
work, we
will effectively need to do it twice - once for the release22.01
branch and
once for trunk - a pretty heavy undertaking.
On balance I think it would be bad for the project to release OFBiz
in a
state which is difficult for developers/system integrators to work
with, so
we MUST ensure OFBiz is 'debuggable'.
I'll ask one more question (and then run for cover!): Rather than
carry out
this work twice. What if we abandon the 22.01 release and instead
make a
new release branch (23.xx) soon after moving the Groovy sources?
Thanks,
Dan.
On Wed, 26 Apr 2023 at 12:23, Michael Brohl
wrote:
Hi,
I suggest to start with a new ticket to coordinate the refactoring
work
(will you take this into your hands, Wiebke?).
OFBIZ-10226 has another intention which will not solve the overall
problem Wiebke described.
D
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi everyone,
for the restructuring concerning the Groovy classes I have thought about
a few more things and have worked out a rough plan for a script/ Steps
to be done.
If there are no objections here I would start with the implementation of
such a script.
The idea from Gil Portenseigne to implement a inspection feature as a
plugin to detect bad references could be a nice feature to check if the
restructuring was successful.
Steps for the restructuring:
1st step:
* move all groovy test files to {basedir}/src/test/groovy/org/apache/ofbiz/*
* bevore moving add file to list of moved files
* work throu the list of moved files and adjust references (should be
under {basedir}/testdef/*)
2nd step (services and frontend scripts) :
* move the remaining groovy files to
{basedir}/src/main/groovy/org/apache/ofbiz/*/*.groovy
* bevore moving add file to list of moved files
* adjust references
** Work through the list of files moved and search for occurrences in
other files and adapt import * for frontend scripts, adapt the location
for services in the service definition.
3rd step:
* add package if none exists in groovy file yet
4th step:
* check moved files lists to see if this is a proper package declaration
(Has to be done manually)
Best regards,
Wiebke
Am 05.05.23 um 15:52 schrieb Wiebke Pätzold:
Hi everyone, to minimize the potential for errors, I would like to see
if it is possible to write a script that moves the groovy files and
references in the first step and adds the package declaration for the
Groovy files in a second step.
If the general consensus is that we do this restructuring for the
trunk, then I would deal next week with how such a script has to look
like and to which degree the restructuring can be done automatically.
Best regards, Wiebke
Am 02.05.23 um 09:16 schrieb Daniel Watford:
Hi Michael,
I would be concerned about our capacity to move all these groovy scripts
and ensure correct location updates are made to the elements in the controller.xml files and elements in service definitions in
both trunk and the release22.01 branch.
If we were to pursue these changes, could we add a test mode to code
that
parses service definitions and controller xml files to check that the
groovy location (and invoked methods were relevant) are accessible? This
means we would have some automation to help ensure changes have been
applied correctly.
This will be a big undertaking, so I would suggest creating some
mini-project-management similar to that done for the CodeNarc
integration
where we have a list of files that need moving and committers add their
name to files they are actively working on. I would also request that we
introduce rules for this mini-project such as, 'No functional changes to
code', and 'keep Pull Requests small', etc.
To answer your original question, if we do not make the proposed
changes to
release 22.01, we will substantially degrade the ability for developers
using Eclipse to work with OFBiz. But if we do proceed with this
work, we
will effectively need to do it twice - once for the release22.01
branch and
once for trunk - a pretty heavy undertaking.
On balance I think it would be bad for the project to release OFBiz in a
state which is difficult for developers/system integrators to work
with, so
we MUST ensure OFBiz is 'debuggable'.
I'll ask one more question (and then run for cover!): Rather than
carry out
this work twice. What if we abandon the 22.01 release and instead
make a
new release branch (23.xx) soon after moving the Groovy sources?
Thanks,
Dan.
On Wed, 26 Apr 2023 at 12:23, Michael Brohl
wrote:
Hi,
I suggest to start with a new ticket to coordinate the refactoring work
(will you take this into your hands, Wiebke?).
OFBIZ-10226 has another intention which will not solve the overall
problem Wiebke described.
Does the community agree that we'll have to do this work?
Even more, do we agree that it has to be done before we can ship a
first
22.01 release based on JDK 17?
Best regards,
Michael Brohl
ecomify GmbH -www.ecomify.de
Am 25.04.23 um 18:30 schrieb Jacques Le Roux:
Thanks Wiebke,
I know that for a while (https://s.apache.org/kewrn) but was
desperately trying to avoid what you propose. It's indeed the right
solution.
So I think we can go on with OFBIZ-10226. At the bottom there is a
link to a related discussion with some opinions from then. Or do you
prefer to start anew for the sake of clarity?
Thanks again for your work, I was not aware of this Groovy page. It
definitely confirms what Mathieu said then.
Jacques
Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit :
Hi everyone,
I did a bit of research regarding the groovy debugging.
After some research I found this:
“The Java Platform Module System requires that classes in distinct
modules have distinct package names. Groovy has its own "modules" but
these haven’t historically been structured according to the above
requirement. For t
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi everyone, to minimize the potential for errors, I would like to see if it is possible to write a script that moves the groovy files and references in the first step and adds the package declaration for the Groovy files in a second step. If the general consensus is that we do this restructuring for the trunk, then I would deal next week with how such a script has to look like and to which degree the restructuring can be done automatically. Best regards, Wiebke Am 02.05.23 um 09:16 schrieb Daniel Watford: Hi Michael, I would be concerned about our capacity to move all these groovy scripts and ensure correct location updates are made to the elements in the controller.xml files and elements in service definitions in both trunk and the release22.01 branch. If we were to pursue these changes, could we add a test mode to code that parses service definitions and controller xml files to check that the groovy location (and invoked methods were relevant) are accessible? This means we would have some automation to help ensure changes have been applied correctly. This will be a big undertaking, so I would suggest creating some mini-project-management similar to that done for the CodeNarc integration where we have a list of files that need moving and committers add their name to files they are actively working on. I would also request that we introduce rules for this mini-project such as, 'No functional changes to code', and 'keep Pull Requests small', etc. To answer your original question, if we do not make the proposed changes to release 22.01, we will substantially degrade the ability for developers using Eclipse to work with OFBiz. But if we do proceed with this work, we will effectively need to do it twice - once for the release22.01 branch and once for trunk - a pretty heavy undertaking. On balance I think it would be bad for the project to release OFBiz in a state which is difficult for developers/system integrators to work with, so we MUST ensure OFBiz is 'debuggable'. I'll ask one more question (and then run for cover!): Rather than carry out this work twice. What if we abandon the 22.01 release and instead make a new release branch (23.xx) soon after moving the Groovy sources? Thanks, Dan. On Wed, 26 Apr 2023 at 12:23, Michael Brohl wrote: Hi, I suggest to start with a new ticket to coordinate the refactoring work (will you take this into your hands, Wiebke?). OFBIZ-10226 has another intention which will not solve the overall problem Wiebke described. Does the community agree that we'll have to do this work? Even more, do we agree that it has to be done before we can ship a first 22.01 release based on JDK 17? Best regards, Michael Brohl ecomify GmbH -www.ecomify.de Am 25.04.23 um 18:30 schrieb Jacques Le Roux: Thanks Wiebke, I know that for a while (https://s.apache.org/kewrn) but was desperately trying to avoid what you propose. It's indeed the right solution. So I think we can go on with OFBIZ-10226. At the bottom there is a link to a related discussion with some opinions from then. Or do you prefer to start anew for the sake of clarity? Thanks again for your work, I was not aware of this Groovy page. It definitely confirms what Mathieu said then. Jacques Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit : Hi everyone, I did a bit of research regarding the groovy debugging. After some research I found this: “The Java Platform Module System requires that classes in distinct modules have distinct package names. Groovy has its own "modules" but these haven’t historically been structured according to the above requirement. For this reason, Groovy 2.x and 3.0 should be added to the classpath not module path when using JDK9+. This places Groovy’s classes into the unnamed module where the split package naming requirement is not enforced.“ http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages For testing I used the service "sendEmailDated" in CommunicationEventServices.groovy. I can confirm the described behavior of Jacques, without a package declaration the service does not stop at my breakpoint. If I add the package declaration for the class, the service stops at my breakpoint. From my point of view it would make sense for the project not only to add the package declaration in all groovy classes, but also to ensure a consistent folder structure. For example, under framework -> base -> src there is a distinction between main and test. Within the test folder there is again a distinction between groovy and Java. Therefore I would suggest to introduce this structure everywhere, which means that there would be a src folder which in turn contains main, test, ... within these folders there is again a distinction between groovy and java. Example: applications -> product -> src -> main -> groovy -> org -> apache -> ofbiz ->... -> java -> org -> apache -> ofbiz ->...
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
Hi everyone, I have created OFBIZ-12813 to coordinate the refactoring work. Best regards, Wiebke Am 27.04.23 um 19:18 schrieb Jacques Le Roux: Hi Michael, Actually, as you may have seen with recent Daniel's work, lazy consensus is de facto if nobody oppose :) Cheers Jacques Le 27/04/2023 à 18:49, Michael Brohl a écrit : Hi everyone, what do you think about this refactoring suggestion? We would organize to do this work but won't start until the community decides to do so. It will be some amount of work so it should definetely be backed by the community. Can we apply lazy consensus here or do we need some kind of voting? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 26.04.23 um 13:21 schrieb Michael Brohl: Hi, I suggest to start with a new ticket to coordinate the refactoring work (will you take this into your hands, Wiebke?). OFBIZ-10226 has another intention which will not solve the overall problem Wiebke described. Does the community agree that we'll have to do this work? Even more, do we agree that it has to be done before we can ship a first 22.01 release based on JDK 17? Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 25.04.23 um 18:30 schrieb Jacques Le Roux: Thanks Wiebke, I know that for a while (https://s.apache.org/kewrn) but was desperately trying to avoid what you propose. It's indeed the right solution. So I think we can go on with OFBIZ-10226. At the bottom there is a link to a related discussion with some opinions from then. Or do you prefer to start anew for the sake of clarity? Thanks again for your work, I was not aware of this Groovy page. It definitely confirms what Mathieu said then. Jacques Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit : Hi everyone, I did a bit of research regarding the groovy debugging. After some research I found this: “The Java Platform Module System requires that classes in distinct modules have distinct package names. Groovy has its own "modules" but these haven’t historically been structured according to the above requirement. For this reason, Groovy 2.x and 3.0 should be added to the classpath not module path when using JDK9+. This places Groovy’s classes into the unnamed module where the split package naming requirement is not enforced.“ http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages For testing I used the service "sendEmailDated" in CommunicationEventServices.groovy. I can confirm the described behavior of Jacques, without a package declaration the service does not stop at my breakpoint. If I add the package declaration for the class, the service stops at my breakpoint. From my point of view it would make sense for the project not only to add the package declaration in all groovy classes, but also to ensure a consistent folder structure. For example, under framework -> base -> src there is a distinction between main and test. Within the test folder there is again a distinction between groovy and Java. Therefore I would suggest to introduce this structure everywhere, which means that there would be a src folder which in turn contains main, test, ... within these folders there is again a distinction between groovy and java. Example: applications -> product -> src -> main -> groovy -> org -> apache -> ofbiz ->... -> java -> org -> apache -> ofbiz ->... -> test -> groovy -> org -> apache -> ofbiz ->... -> java -> org -> apache -> ofbiz ->... What do you think about this idea? Best regards, Wiebke ecomify GmbH - www.ecomify.de Am 20.04.23 um 11:46 schrieb Michael Brohl: We have a working solution with all tests passing for release22.01 and trunk, I have created a Jira issue to track the effort. https://issues.apache.org/jira/browse/OFBIZ-12808 Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 19.04.23 um 15:52 schrieb Michael Brohl: Hi everyone, it seems that we have a solution for the Eclipse Java build and runtime problems we faced with JDK 17 (not speaking of the Groovy build problems). We removed some (transitive) dependencies in the build file and updated some of them so that libraries are used from the JDK instead of external libaries. This avoids the compiler from finding duplicate classes which seem to be ignored and therefore not being found also at runtime. We are checking the changes with a project now and provide a pull request when we are sure everything works fine. Best regards, Michael Brohl ecomify GmbH - www.ecomify.de Am 14.04.23 um 21:53 schrieb Michael Brohl: Thanks Jacques! for me, org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage only works as far as the build problems get away but there are still packages and classes not found by Eclipse at runtime so not real
Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.
vices.java /ofbiz/plugins/ebay/src/main/java/org/apache/ofbiz/ebay line 993 Java Problem Document cannot be resolved to a type EntitySaxReader.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 112 Java Problem Document cannot be resolved to a type EntitySaxReader.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 339 Java Problem Document cannot be resolved to a type EntitySaxReader.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 556 Java Problem Document cannot be resolved to a type EntitySaxReader.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util line 561 Java Problem Document cannot be resolved to a type EntitySyncServices.java /ofbiz/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization line 483 Java Problem Document cannot be resolved to a type EntitySyncServices.java /ofbiz/framework/entityext/src/main/java/org/apache/ofbiz/entityext/synchronization line 561 Java Problem Document cannot be resolved to a type FedexServices.java /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/fedex line 381 Java Problem Document cannot be resolved to a type FedexServices.java /ofbiz/applications/product/src/main/java/org/apache/ofbiz/shipment/thirdparty/fedex line 1020 Java Problem Document cannot be resolved to a type FormFactory.java /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model line 58 Java Problem Document cannot be resolved to a type FormFactory.java /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model line 71 Java Problem Document cannot be resolved to a type FormFactory.java /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model line 101 Java Problem Document cannot be resolved to a type FormFactory.java /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model line 114 Java Problem Document cannot be resolved to a type FormFactory.java /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model line 142 Java Problem Document cannot be resolved to a type GatewayResponse.java /ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway line 170 Java Problem Document cannot be resolved to a type GenericDelegator.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line 2182 Java Problem Document cannot be resolved to a type GenericEntity.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line 1230 Java Problem Document cannot be resolved to a type GenericEntity.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line 1231 Java Problem Document cannot be resolved to a type GenericEntity.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line 1241 Java Problem Document cannot be resolved to a type GenericEntity.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line 1245 Java Problem Document cannot be resolved to a type GenericEntity.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line 1268 Java Problem Document cannot be resolved to a type GenericEntity.java /ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity line 1277 Java Problem Document cannot be resolved to a type GridFactory.java /ofbiz/framework/widget/src/main/java/org/apache/ofbiz/widget/model line 60 Java Problem Any clue on how to fix these issues? Thanks. Carlos Navarro -- Wiebke Pätzold Beraterin und Softwareentwicklerin ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld Fon: +49 521 448157-90 | Fax: +49 521 448157-99 | www.ecomify.de Court Registration: Amtsgericht Bielefeld, HRB 41683 | CEO: Martin Becker, Michael Brohl
Re: [VOTE] Apache OFBiz 18.12.02
Hi all, Thank you everyone for the congratulations to become a committer. It’s a honor to me to be part of the team. I committed the fix for the build in release18.12 and I also proviede a PR for the ERROR Jacques mentioned for ViewBlogArticle in the following Jira Ticket: https://issues.apache.org/jira/browse/OFBIZ-12363 I would suggest to test these PR as well and then provid the new release with both fixes. What do you think? Best Regards, Wiebke
Re: [VOTE] Apache OFBiz 18.12.02
-1 The reason for the new release is a fix for https://issues.apache.org/jira/browse/OFBIZ-12351, but as far as I can see the temporary fix is only applied to trunk. So the Release18.12.02 has no changes to Release18.12.01 or am I something missing? I also provided a PR for the 18.12 branch with a better fix, since this one does not depend on jcenter. Am 02.11.21 um 08:37 schrieb Jacques Le Roux: +1 $ ./verify-ofbiz-release.sh apache-ofbiz-18.12.02.zip sha check of file: apache-ofbiz-18.12.02.zip Using sha file: apache-ofbiz-18.12.02.zip.sha512 apache-ofbiz-18.12.02.zip: D553F8DC C8360B4B 7B1A3181 463EB1C2 3B0E8A89 1DEEB786 AF269072 1DE385CF 23BB1171 0EC9EDAE 6ECF598F 2355019F 23E5A33C C968493E 54AF5848 91F406DD apache-ofbiz-18.12.02.zip: D553F8DC C8360B4B 7B1A3181 463EB1C2 3B0E8A89 1DEEB786 AF269072 1DE385CF 23BB1171 0EC9EDAE 6ECF598F 2355019F 23E5A33C C968493E 54AF5848 91F406DD sha checksum OK GPG verification output gpg: Signature made Mon Nov 1 15:11:59 2021 gpg: using RSA key 7A580908847AF9E0 gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) " Tests are OK but I had to change 38802 to 39676 in checkstyle::maxErrors, not sure why. Seems like last time, checkstyle disallow building. Seems more an issue on my side, not the same than last time. I'll investigate Jacques Le 01/11/2021 à 15:34, Jacopo Cappellato a écrit : This is the vote thread to publish "Apache OFBiz 18.12.02", the second release from the release18.12 branch. The release files can be downloaded from here: https://dist.apache.org/repos/dist/dev/ofbiz/ and are: * apache-ofbiz-18.12.02.zip * KEYS: text file with keys * apache-ofbiz-18.12.02.zip.asc: the detached signature file * apache-ofbiz-18.12.02.zip.sha512: checksum file Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 18.12.02 [ -1] do not release This vote will be open for 5 days. For more details about this process please refer to http://www.apache.org/foundation/voting.html Best Regards, Jacopo -- Wiebke Pätzold Developer und Consultant ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld Fon: +49 521 448157-90 | Fax: +49 521 448157-99 | www.ecomify.de Court Registration: Amtsgericht Bielefeld, HRB 41683 | CEO: Martin Becker, Michael Brohl
Re: OFBiz features/functions overview in the wild
Hi all, I contacted the US site owner as well as the German one. Until now I didn’t get a helpful answer to my question how we can complete the Information about OFBiz on their site. The only answers I get was a link to reset my password on Capterra which I didn’t request and I was add to a Mailing-list for reviews on Apache Software. Best regards, Wiebke Pätzold On 2020/01/22 11:06:40, Michael Brohl wrote: > Just to keep you updated: we have contacted the site owner and got no > > answer yet. We also contacted the German site owner.> > > We are waiting for a reply until end of the week and try again if there > > is no answer.> > > Thanks,> > > Michael Brohl> > > ecomify GmbH - www.ecomify.de> > > > Am 10.01.20 um 14:35 schrieb Michael Brohl:> > > This is the english version: > > > https://www.capterra.com/p/164046/Apache-OFBiz/> > >> > > There are similar websites providing such informations with very > > > different quality. In a few occasions where I tried to get the data > > > updated/corrected I learned that I would have to pay for it. Seems > > > most of them are targeted to commercial software vendors.> > >> > > It would be interesting how it works on this website. If there isn't > > > anyone working on this I'll see if our team can clarify with the > > > website owner.> > >> > > Best regards,> > >> > > Michael Brohl> > >> > > ecomify GmbH - www.ecomify.de> > >> > >> > > Am 09.01.20 um 10:45 schrieb Pierre Smits:> > >> Hi Jacques,> > >>> > >> There are (as far as I can tell) 3 possibilities where this is coming > > >> from:> > >>> > >> 1. It is automagically scraped from our official documentation (by> > >> crawling through our pages on the site and wiki) and collated> > >> 2. it is taken from what is in the definition on> > >> https://projects.apache.org> > >> 3. it is a manual action to provide that information (when this > > >> Dutch> > >> site is different from others)> > >>> > >> Regarding aspects 1 and 2 the solution would be to insert the applicable> > >> and appropriate keywords in our artefacts, so that they get reflected in> > >> such sites.> > >>> > >> Digging a little into the website I found that it is US based and> > >> affiliated with Gartner.> > >>> > >> Best regards,> > >>> > >> Pierre Smits> > >>> > >> *Apache Trafodion <https://trafodion.apache.org>, Vice President*> > >> *Apache Directory <https://directory.apache.org>, PMC Member*> > >> Apache Incubator <https://incubator.apache.org>, committer> > >> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without > > >> privileges)> > >> since 2008*> > >> Apache Steve <https://steve.apache.org>, committer> > >>> > >>> > >> On Thu, Jan 9, 2020 at 10:31 AM Jacques Le Roux <> > >> jacques.le.r...@les7arts.com> wrote:> > >>> > >>> Hi Pierre,> > >>>> > >>> Right, how can we fix that though?> > >>>> > >>> Jacques> > >>>> > >>> Le 09/01/2020 à 10:01, Pierre Smits a écrit :> > >>>> Hi all,> > >>>>> > >>>> Recently I came across this Dutch website (> > >>>> https://www.capterra.nl/software/164046/apache-ofbiz) that states> > >>>> functions about our product. I don’t know where this originated but I> > >>>> presume somewhere data is is pulled/scraped from our official > > >>>> elements.> > >>>>> > >>>> The most important thing I want to bring to the attention of this> > >>> community> > >>>> is that under the functions section (I am confident you can find > > >>>> similar> > >>>> sites in your country/language that shows the same) it does NOT > > >>>> highlight> > >>>> key features/functions like purchasing, order management, planning,> > >>> project> > >>>> and time management. This should be corrected asap.> > >>>>> > >>>> Best regards,> > >>>>> > >>>> Pierre Smits> > >>>>> > >>>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*> > >>>> *Apache Directory <https://directory.apache.org>, PMC Member*> > >>>> Apache Incubator <https://incubator.apache.org>, committer> > >>>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without> > >>> privileges)> > >>>> since 2008*> > >>>> Apache Steve <https://steve.apache.org>, committer> > >>>> > >> > >
Please add me as an Apache OFBiz Contributor
Hello everyone, I would like to ask you to add me as an Apache OFBiz Contributor. My Confluence username is: wpaetzold Thanks and kind regards, Wiebke
