Re: What is OFBiz public API?
Hi all, > Am 05.01.20 um 18:32 schrieb Mathieu Lirzin: > > > > I urge other contributors to join this discussion which is crucial to > > define our capability to work together as a community and my willing to > > continue to participate. I also hope others contributors will eventually join (many thanks to Jacques for joining!) since this discussion seems to me to be larger than a particular feature (component-load.xml): it is about the process of contributing to OFBiz. Michael has started to discuss because he had missed the commit which removes component-load.xml in applications and framework and he claimed [2] that we didn't discuss in d...@obfiz.apache.org before: completely true! Why do we need to discuss such an implementation detail? Some argue that we have to discuss before intruducing any *big* changement :confused: What is a *big* changement? In software library/framework it is quite easy to answer: a big changement is a breaking in public api. So here is the question from Mathieu: what is OFBiz public API? In my opinion we need an answer for this question otherwise we need to discuss every single changement! which seems to be really cumbersome! And even if we discuss every single changement how to decide it is good for our community: *one* other contributor thumb-up is enough? maybe *two*? do we need to wait forever if others don't care about a particular changement? > OFBiz is not just a library or core framework, it is a multi-level project: > > * a web development framework > > * a web based ERP system on base of this framework > > * highly flexible and extendable through various mechanisms. Like so many frameworks, OFBiz is not different according to this points. And like so many frameworks which are extendable we need API to ease extension. > > To my understanding, if we use depends-on exclusively for framework, > applications and plugins, this would not be possible anymore. This is where you're wrong. From the beginning using depends-on in framework doesn't imply using it in plugins! The thing which drive Mathieu to revert is that you cannot, in *framework* override depends-on with a component-load.xml. And here we are with the actual discussion: 1. component-load.xml in plugin directory seems to be feature (nobody discuss this point) 2. what about component-load.xml in framework and applications directories? is it also a feature (in other words a public API) or an implementation detail > [1] > https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+10.04 This reference is a bit old and stated as wip so I will consider it as irrelevant for our discussion ;) cheers, Samuel [1]: https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E [2]: https://lists.apache.org/thread.html/7eab3d2ae3bbeadb184b02f75f7b2b86263532485e88ecba4d4dc780%40%3Cdev.ofbiz.apache.org%3E signature.asc Description: signature
Fwd: Re: What is OFBiz public API?
(re)Forwarded at Michael's request
Message transféré
Sujet : Re: What is OFBiz public API?
Date : Sun, 5 Jan 2020 20:33:03 +0100
De :Jacques Le Roux
Organisation : Les Arts Informatiques
Pour : dev@ofbiz.apache.org
Hi Mathieu,
Inline too...
Le 05/01/2020 à 18:32, Mathieu Lirzin a écrit :
Hello,
The arguments provided by Michael are very general and go beyond the
specific question of “component-load.xml” so I am opening a general
discussion about how to make OFBiz evolve smoothly by precising the
extent of its public API.
I urge other contributors to join this discussion which is crucial to
define our capability to work together as a community and my willing to
continue to participate.
Michael Brohl writes:
This project is not only about tech, it has a user base with serious
business running on base of OFBiz. This has always to be considered as
serious as good technical solutions should be considered. So we cannot
simply change things because single contributors like other technical
solutions better. We have to remain downwards compatible and manage
deprecation of features carefully.
First to clarify things, making evolutions in the framework is not about
developers changing arbitrary stuff, it is about structuring internals
in an understandeable way to enable correctness and the inclusion of new
features that satisfies evolving requirements.
Maybe you could clarify what you want to achieve. I have the feeling that you have a long term view and the “component-load.xml change” is only a
step, right?
Backwards compability only makes sense when something has a public API
otherwise every evolution is a breaking change. In OFBiz we lack a
proper specification of what is a feature provided by the framework
subject to backward compatibility and what is an implementation detail
that can evolve/disappear between version silently. We rely on an
informal consensus to distinguish between the two.
The fact that some mechanism appears to be used in production is a valid
argument against its removal only if that mechanism is part of the
public API, otherwise it is up to the client code to adapt.
I agree, that's why I asked Michael, in answer to his last email, if he could adapt his mechanism to "generate the resulting component-load.xml at
build time" using the new proposed mechanism. Of course it would not longer relies on the component-load.xml file (to be eventually removed) but on
the new mechanism.
My broad understanding of what is part of OFBiz public API is:
- the plugin mechanism
- the data model and data access (Entity Engine)
- The ability to call existing services and implement new ones (Service Engine)
- the HTTP routing mechanism (Event Handler)
- the various configuration files location in “{component}/config” directories.
I think there are more, those are part of it.
[...]
If you read carefully what I previously wrote, there are several uses
for the applications component-load.xml:
* deactivation of unused component(s) by commenting out the
load-component entry (why load marketing resources if you don't use
the component at the moment)
* addition of components (yes, I've seen projects where this was not
done through the hot-deploy mechanism)
* ordering these components in the right load order
While you can argument that these might be "wrong" approaches, they
are technically valid and used in customer projects. Therefore we
cannot simply switch the mechanisms without a proper deprecation
period.
The general problem here is not to know if things are wrong or
technically valid, it is to know if something is part of the public API
or is an implementation detail. This determines how to handle an
evolution on that part. Something wrong but part of the public API like
using XML for code should be handled with care (deprecation, migration
guides), but something technically valid but inappropriate like patching
framework Java source code from a plugin should be ignored.
Fortunately I have never seen "patched framework Java source code from a
plugin" :), but I agree about the idea.
In the case of ordering/enabling core components I consider it as an
implementation detail. If a component inside framework/applications is
effectively optional (like the marketing example you brought) it should
eventually be moved in the official plugins if we actually want to
provides the capability for users to disable it.
+1
However users should
not be entitled to think that they can freely desactivate/reorder/add
new components inside the framework/applications directory and that such
modifications will continue to work in a future release.
+1
The larger question is about knowing if the internal organisation of the
files inside the "framework/applications" directories with the exception
of the “config” directories is considered part of OFBiz public API or
not? What do people think?
It should not be but, as with other aspects in OFBiz, it's
Re: What is OFBiz public API?
Hi Samuel, Inline too... Le 06/01/2020 à 10:29, Samuel Trégouët a écrit : Hi all, [snip...] Michael has started to discuss because he had missed the commit which removes component-load.xml in applications and framework and he claimed [2] that we didn't discuss in d...@obfiz.apache.org before: completely true! Why do we need to discuss such an implementation detail? Some argue that we have to discuss before intruducing any *big* changement :confused: What is a *big* changement? In software library/framework it is quite easy to answer: a big changement is a breaking in public api. So here is the question from Mathieu: what is OFBiz public API? In my opinion we need an answer for this question otherwise we need to discuss every single changement! which seems to be really cumbersome! And even if we discuss every single changement how to decide it is good for our community: *one* other contributor thumb-up is enough? maybe *two*? do we need to wait forever if others don't care about a particular changement? Mathieu and you make good points with the notion of "OFBiz public API". It would be indeed good to have a such concept to officially (ie w/ a prior consensus) collect all parts that always need deeper discussions and consents. But I fear it's not easy to define and this needs if not a deep discussion at least a long one (see the kinda recursion here?). So before having all agreed about what the "OFBiz public API" is I think we need to cure the present issue. Except if Mathieu is pleased to wait before this is agreed on. Remember at the ASF most is about discussion and agreement. As the motto, which has has proved is efficiency over years, says: *"Community over code".* [snip...] Michael's = To my understanding, if we use depends-on exclusively for framework, applications and plugins, this would not be possible anymore. This is where you're wrong. From the beginning using depends-on in framework doesn't imply using it in plugins! The thing which drive Mathieu to revert is that you cannot, in *framework* override depends-on with a component-load.xml. So you say that depends-on and component-load.xml are incompatible? This opens a new discussion to me. Because then we don't speak about deprecation but about replacement... And here we are with the actual discussion: 1. component-load.xml in plugin directory seems to be feature (nobody discuss this point) 2. what about component-load.xml in framework and applications directories? is it also a feature (in other words a public API) or an implementation detail I tend to think that it's not a feature. I'd though not say that it's an "implementation detail" ;) As often in "real-life" it's not black or white. It's greyed and implications may be complex... [1] https://cwiki.apache.org/confluence/display/OFBIZ/Ofbiz+as+a+development+framework+-+release+10.04 This reference is a bit old and stated as wip so I will consider it as irrelevant for our discussion ;) I think we can indeed consider a 10 years old WIP reference a "bit old". I even don't see how what was wrote then still currently applies *in trunk*. It even me wonder what I should to about OFBIZ-3500 :/ Certainly not close it! My 2cts Jacques cheers, Samuel [1]: https://lists.apache.org/thread.html/c2612f1e296b6ea15872185871d3a9d83d6a4afc6d2a76f7a336a126%40%3Cdev.ofbiz.apache.org%3E [2]: https://lists.apache.org/thread.html/7eab3d2ae3bbeadb184b02f75f7b2b86263532485e88ecba4d4dc780%40%3Cdev.ofbiz.apache.org%3E
Re: What is OFBiz public API?
Hello, Jacques Le Roux writes: > Le 06/01/2020 à 10:29, Samuel Trégouët a écrit : >> >>what is OFBiz public API? >> >> In my opinion we need an answer for this question otherwise we need to >> discuss every single changement! which seems to be really cumbersome! >> And even if we discuss every single changement how to decide it is good >> for our community: *one* other contributor thumb-up is enough? maybe >> *two*? do we need to wait forever if others don't care about a >> particular changement? > > Mathieu and you make good points with the notion of "OFBiz public API". > It would be indeed good to have a such concept to officially (ie w/ a prior > consensus) collect all parts that always need deeper discussions and consents. > > But I fear it's not easy to define and this needs if not a deep discussion at > least a long one (see the kinda recursion here?). > > So before havi ng all agreed about what the "OFBiz public API" is I > think we need to cure the present issue. Except if Mathieu is pleased > to wait before this is agreed on. I think it is an important discussion that is overdue. Given that I need a break to both get over the frustration of the recent heated discussions and focus on my research work, As far as I am concerned this is a good moment for this discussion to happen. The goal of this discussion would be to define the boundaries between deprecated/stable/experimental/internal code by considering both the stability requirements that are important for production environments (that need to be able to upgrade smoothly) and the capability for developers to refactor code that is necessary to be able to implement the features allowing OFBiz to remain relevant in the future. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
