Re: What is OFBiz public API?

[Michael Brohl]

Hi Jacques,

you've created another mail thread with exactly the same title. The 
first thread already has answers which would get lost if your new thread 
would be answered.


I propose that you simply answer the first thread directly.

Thanks,

Michael


Am 08.01.20 um 05:38 schrieb Jacques Le Roux:

Hi All,

Following Mathieu's question about "OFBiz public API" and the points 
he already mentioned I decided to create a new thread.
I don't know what will happen with the other tread (mostly about 
removing/replacing component-load.xml). That's not the subject here.


Mathieu wrote:

   < - 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 tend to agree with this list. From the top of my head, I'd add 
(maybe not a the same level and maybe we need to define level/s)


1. Obviously, the Java API !
2. All things (why not?) supported by XSD files.
   It includes Entity and Services Engines, not all feature are 
documented/supported by XSD files though.
   It also includes component-loader.xsd and ofbiz-component.xsd which 
are somehow parts of the subject of the other thread

3. OFBiz Gradle tasks

I don't know what to say about Groovy scripts which are replacing 
simple-method services.


What else?

Jacques






smime.p7s
Description: S/MIME Cryptographic Signature

Re: What is OFBiz public API?

[Paul Foxworthy]

On Mon, 6 Jan 2020 at 20:29, Samuel Trégouët 
wrote:


>   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?
>

Hi Samuel,

I think this isn't a choice between having a public API and cumbersome
decision making. An API is a bits and bytes thing and won't magically
streamline decision making. A better architected, designed and understood
API will help **people** get an **initial impression** of what is easy to
refactor and re-implement.  Being clearer about it would be a good thing.
There is still the potential that a change that seems simple and
straightforward to one contributor is disruptive to others. And if it truly
is disruptive, we should collaborate on what comes next. Are the benefits
worth the disruption? Should there be some sort of deprecation, phase-out
or backwards compatibility option? I can't clearly define what "big" is,
but I know it when I see it.

And as a starting point for making these decisions, I suggest
https://www.apache.org/foundation/how-it-works.html#decision-making .

Cheers

Paul Foxworthy

-- 
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au

Re: What is OFBiz public API?

[Jacques Le Roux]

Le 07/01/2020 à 00:56, Mathieu Lirzin a écrit :

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.

Hi Mathieu,

I started the "What is OFBiz public API?" thread

Actually I did yesterday but had to reboot my Internet box because of IP blocked issue and then ask barracudacentral.org to remove my IP from their 
blocked list (I don't thanks my Internet Provider!)


Jacques

What is OFBiz public API?

[Jacques Le Roux]

Hi All,

Following Mathieu's question about "OFBiz public API" and the points he already 
mentioned I decided to create a new thread.
I don't know what will happen with the other tread (mostly about 
removing/replacing component-load.xml). That's not the subject here.

Mathieu wrote:

   <>

I tend to agree with this list. From the top of my head, I'd add (maybe not a 
the same level and maybe we need to define level/s)

1. Obviously, the Java API !
2. All things (why not?) supported by XSD files.
   It includes Entity and Services Engines, not all feature are 
documented/supported by XSD files though.
   It also includes component-loader.xsd and ofbiz-component.xsd which are 
somehow parts of the subject of the other thread
3. OFBiz Gradle tasks

I don't know what to say about Groovy scripts which are replacing simple-method 
services.

What else?

Jacques

Re: What is OFBiz public API?

[Michael Brohl]

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





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Removing “base/config/component-load.xml”

[Pierre Smits]

I am +1,

as it is going to provide more clarity and devops simplicity for adopters

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sun, Dec 8, 2019 at 2:34 AM Mathieu Lirzin 
wrote:

> Hello,
>
> We have in OFBiz two redundant ways to define the order in which
> components are loaded.
>
> * “component-load.xml” files stored in components directories meaning
>   directories containing single components. They define a total order
>   between every component inside that directory.
>
> *  XML elements inside “ofbiz-component.xml” files stating
>   that a component ‘c’ requires a set of components ‘D’ to exist and to
>   be loaded before trying to load ‘c’.  Globally this constructs a
>   dependency graph which defines a partial order between available
>   components.
>
> Currently  is used everywhere in the framework on ‘trunk’
> because it is more declarative and open for extensibility due the
> partial ordering capability.
>
> The only exception is “base/config/component-load.xml” which is a
> special components directory configuration defining the order of other
> components directories meaning “framework”, “themes”, “applications” and
> “plugins” in their respective dependency order.
>
> This file allows integrators to add and reorder components
> directories. This feature is not really useful nowadays considering that
> our plugin mechanism provides sufficient extensibility capability when
> combined with  definitions.
>
> In order to simplify things which helps the endeavour towards
> transforming OFBiz in an extensible JVM based library, I would like to
> remove such configuration point and hard-code the list of component
> directories inside the code.
>
> I guess this low-level technical proposition is not interesting for most
> people but in case someone want to understand more or object before
> things are actually removed. I am opening a discussion on this ML.
>
> If nobody step-up in a week, I will go ahead.
>
> Thanks.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>