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
Re: Releasing 17.12.05, 18.12.01 and freezing R20
Hi, At least 18.12.01 release seems doable this month: https://s.apache.org/3ztp7 Jacques Le 02/09/2021 à 17:03, Nicolas Malin a écrit : 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 Suggest ? On 24/12/2020 06:18, Pranay Pandey wrote: +1 to the original proposal and to the additional idea for skipping r20 and making an r21. As discussed defining the 5 Years support policy will surely help. Best regards, Pranay Pandey On Tue, Dec 22, 2020 at 5:39 PM Aditya Sharma wrote: +1 to the initial proposal of release 3 years of support for r17 and 5 years of support starting with r18 sounds good to me. I think we can define a policy well stated on our release page with an additional idea: maybe better skip r20 and make a r21 right at the beginning of the year with the chance to release also in 21. +1. We can think upon defining a timeline for stabilizing new release branches with a tentative time period like maybe 3-12 months. There are numerous new features that our users can benefit from and defining certain timelines may reduce the wait time. -- Thanks and Regards, Aditya Sharma On Tue, Dec 22, 2020 at 4:38 PM Jacques Le Roux wrote: Le 22/12/2020 à 10:08, Jacques Le Roux a écrit : If we don't release R20 it means that we will at best release R21 at the end of 2021, again a lot of years between 2018 and 2021. OK forget it, OK this does not make sense, anyway it will be end of 2021, OK for me for a brand new R21 :) But we need to release R18 ASAP... Jacques
Re: Releasing 17.12.05, 18.12.01 and freezing R20
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 Suggest ? On 24/12/2020 06:18, Pranay Pandey wrote: > +1 to the original proposal and to the additional idea for skipping r20 and > making an r21. > > As discussed defining the 5 Years support policy will surely help. > > Best regards, > Pranay Pandey > > > On Tue, Dec 22, 2020 at 5:39 PM Aditya Sharma > wrote: > >> +1 to the initial proposal of release >> >> 3 years of support for r17 and 5 years of support starting with r18 >> sounds good to me. >> I think we can define a policy well stated on our release page >> with an additional idea: maybe better skip r20 and make a r21 right at the beginning of the year with the chance to release also in 21. >> +1. We can think upon defining a timeline for stabilizing new release >> branches with a tentative time period like maybe 3-12 months. There >> are numerous new features that our users can benefit from and defining >> certain timelines may reduce the wait time. >> >> -- >> Thanks and Regards, >> Aditya Sharma >> >> On Tue, Dec 22, 2020 at 4:38 PM Jacques Le Roux >> wrote: >>> Le 22/12/2020 à 10:08, Jacques Le Roux a écrit : If we don't release R20 it means that we will at best release R21 at >> the end of 2021, again a lot of years between 2018 and 2021. >>> OK forget it, OK this does not make sense, anyway it will be end of >> 2021, OK for me for a brand new R21 :) >>> But we need to release R18 ASAP... >>> >>> Jacques >>>
Re: Blacklist and whitelist replacements
Hi, The diversity team has provided a tool which helps in this regard. I made a try, here are the results: https://clc.diversity.apache.org/projects.html Some are easy to replace (eg "master" by "main" in some places), I'll change them. Some need to be excluded. All 3rd libs for instance. Help appreciated Jacques Le 30/01/2021 à 10:52, Jacques Le Roux a écrit : Hi, After a discussion between ASF members, I saw that an effort has been done by Infra, and I guess in some TLPs, to replace some connoted words like blacklist and whitelist. We have not much occurrences of these words, so I suggest that we replace blacklist and whitelist list respectively by denylist and allowlist as suggested by https://english.stackexchange.com/questions/51088/alternative-terms-to-blacklist-and-whitelist#answer-51104 There is also this article: https://developer-tech.com/news/2020/jun/15/github-replace-slavery-terms-master-whitelist/ We have only 1 occurrence of slave in our own code, that would be easy. For master it's more annoying 1771 occurrences, so that would need a review. What do you think? Jacques
Re: Logical dependency tree for ofbiz components OFBIZ-12309
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. 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 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 ? 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,
