Hi Samuel,

inline...

Am 06.01.20 um 10:29 schrieb Samuel Trégouët:
...
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

I already explained why the applications component-load.xml is not an implementation detail but used in real life projects.

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.

It's not about being a big change, it's about breaking existing mechanisms/configurations on the user side.

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!

It's common that you propose a change, ask for comments/review and maybe advice if you work in a community, yes. It saves time and energy and adds value to the final solution (mostly).

...

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.

Yes, but it makes a diffrence in the argumentation. The argument was, that the load configuration is an implementation detail.

This might be true for pure ERP users but it is not users who utilize existing mechanisms of the web development framework.

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)

That *might* be a misunderstanding (if Mathieu agrees on this point). My understanding was that he first implemented and committed the change for framework and applications (on Nov. 25).

From his mail in dev [1] and also the issue title of [2] I understand that the component-load mechanism should be removed *everywhere* afterwards. The dev mail would not make sense otherwise because already committed the work at the time of writing (two weeks before) and he announces to go on if noone objects.

I apologize if I missed a point here, maybe Mathieu can clarify this?

I do not object against the change in framework, because I consider the change of component-load in framework an exceptional use case.

For applications and plugins I have explained why we should not change the mechanism.


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 ;)

This reference was only given to document that the mechanism is meant to be used in the way I described it. How old it is or if it is WIP does not make the meaning less relevant.

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

Thanks,

Michael


[1] https://lists.apache.org/thread.html/441d038d1d000429dc1f09784db4b90bdc4cdd2b0e7c9bc4ccc9e48f%40%3Cdev.ofbiz.apache.org%3E

[2] https://issues.apache.org/jira/browse/OFBIZ-11296



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to