Re: breaking ofbiz piece by piece - expose parts to outside

[Eugen Stan]

Hi Nicolas,

Thanks for the support. I do hope we get the ball roling at one point.

I won't be attending ApacheCon this year.
I think it's been 13 years since my last ApacheCon :).
Feel free to start merging changes.

Regards,
Eugen

La 22.03.2024 18:23, Nicolas Malin a scris:

Thanks both for your work and analyze !

I agree on the first point, we need to move forward to release the next 
OFBiz version and after we can breaking the wall :D


If the person are present at the eu apachecon it would be nice place to 
start a workshop on face to face ?


Nicolas


--
Eugen Stan

+40770 941 271  / https://www.netdava.com

Re: breaking ofbiz piece by piece - expose parts to outside

[Nicolas Malin]

Thanks both for your work and analyze !

I agree on the first point, we need to move forward to release the next 
OFBiz version and after we can breaking the wall :D


If the person are present at the eu apachecon it would be nice place to 
start a workshop on face to face ?


Nicolas

Le 27/02/2024 à 11:45, Daniel Watford a écrit :

Hello all,

I haven't been able to fully review the PR yet - it is quite long! :)  I
feel I have read enough of it, along with Eugen's comments in this thread,
to appreciate its aims. That doesn't mean I'm ready to merge it.yet!

I'm broadly supportive of efforts to remove cyclic dependencies and to
identify project components that could be treated as standalone libraries.
In the long run I think this could help simplify project code by further
defining 'layers' of software such as (ordered lower- to higher-level):
- 1. Standalone functional (e.g. cryptography functions, utilities)
- 2. Technology services (e.g. persistence/entity, properties, service
despatch, caching, content, user, authentication/authorisation, ui/widget
rendering, multi-server clustering, REST API, logging)
- 3. Technology applications (e.g. webtools, backup/restore, cache control,
user management, cluster management, metrics, log management)
- 4. Business services (e.g. Parties, Orders, GL Transactions)
- 5. Business applications (e.g Party Manager, Order Manager)
- 6. Plugins
-- Plugins which add new behaviour (e.g. webpos)
-- Plugins which override services and/or screen and form rendering (e.g.
BIRT reporting)

Software in one layer may only reference software in the same or a lower
layer.

>From previous jira tickets and wiki pages (
https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies)
I believe the project is also broadly in support of these aims. At least, I
haven't noticed any comments suggesting otherwise. (There are comments
reminding us to be mindful of the impact to existing
customisations/integrations which I have tried to address below - re
deprecation)

We can already point to one beneficiary if we were to extract the
cryptography functions into a standalone library. In docker-entrypoint.sh,
the code at the following link is used to encrypt the admin user's password
as part of spinning up an OFBiz container instance. If we change how user
passwords are persisted in OFBiz, then we will likely need to rework
docker-entrypoint.sh to reflect those changes. Being able to utilise an
ofbiz-crypto library to encrypt the password, or even a slightly higher
level ofbiz-user library in concert with an ofbiz-entity library to prepare
and persist the admin user's data, could help keep docker-entrypoint.sh in
sync with the ofbiz-framework.

https://github.com/apache/ofbiz-framework/blob/6ad1c20518ad75773fca02ceac3c1d116f097f77/docker/docker-entrypoint.sh#L228C4-L241C62

I'm also broadly supportive of Eugens suggestion to only apply
autodiscovery of components to Plugins (layer 6). This would remove a level
of indirection that developers need to follow when understanding how OFBiz
is loaded at runtime. I think it might also benefit tools in navigating
project structure.

Although I think most developers would be happy to see some refinements of
ofbiz's layered architecture, we must still consider the impact on those
existing ofbiz deployments, providing them an upgrade path to newer major
releases. Since we have no sight of those ofbiz-deployments and cannot
easily quantify the impact of any changes, I think we need to take the
approach of deprecating, rather than breaking, APIs.

That being said, I don't think the project should be shackled to the
long-term maintenance of APIs that do not serve our development goals. I
therefore think an aggressive deprecation policy is acceptable where we
require an API item to be marked as deprecated for the entire life of only
a single release before it is removed in a subsequent release. I am happy
to consider even more aggressive policies where an API item could be
deprecated at any point during a major release's life and then removed in
the next, but that might have the consequence of deprecating something in a
release such as 18.12.13 and then removing it is the (theoretical) 24.4
release.

Since we do not yet use Java Modules in ofbiz-framework, essentially every
class is a potential API item. I think we can take a pragmatic view here
and determine whether any given class should be considered part of an API
or an internal implementation detail. Internal implementation details can
be changed/removed without regard to deprecation policy. Other API items
include service definitions and widget screens/forms/grids since these can
all be referred to by other components. This may mean we need to extend
service and widget definitions to incorporate a deprecation flag which is
logged when the API item is used.

A justification for the above deprecation policy proposal is that we have
limited resources available to work on the 

Re: Proposal: Merge ofbiz-plugins trunk HEAD into ofbiz-framework

[gil.portenseigne]

Hi Daniel,

I understand your points, and I agree that the level of care to the
framework and plugins repositories are quite not the same as of today.

I dug in mailing list history to get the origin of plugins [1]

Before plugins exists, every components we can find in plugin repo where
present in /specialpurpose directory, in the main svn repository, and
integrators used to develop their own application within an /hot-deploy.

Plugin initiative was lead by Taher [2], in the thread we can find lot
of references to past discussions that express some concern about
CI (those introducing gradle task "pullAllPluginsSource"),
"plugins following the framework trend" and so on.

The idea was to be able to install/delete plugin using gradle easily
from distant repository, to easily customisation of an OFBiz instance.

Plugin effort lead to separate repository in february 2017 [3]

>From my experience I see plugins code as specific extensions to the
OFBiz framework that where contributed in the past, that are possible basis
for custom component for integrators. Those are valuable resources, but
i feel unsure about their maintenance quality (thinking of codenarc for
example)

I sadly do not use the plugin ecosystem, only for the createPlugin tasks
to initiate a new component, and about the fact that the releases we make are
shipped with all plugins (some enabled and others not), i consider that
even if I liked the idea of a plugin system, i feel like that the need
was not here for me...

So i lean towards the idea to merge back into OFBiz framework repository
plugins that we would consider relevant about their quality and
importance for the project, with the condition to respect CI tests, and
to let aside other plugins... Writing it, i'm not sure i like the idea 
of letting aside those contributions (make me think of incubating or attic
plugins).

I wonder about the future releases, should we ship all the plugins, or
only the enabled ones, and offer the users to pull the one they needs (from 
the community repository or from custom ones) using plugins system.

Thanks.

[1] https://issues.apache.org/jira/browse/OFBIZ-7972
[2] https://lists.apache.org/thread/94q920hsfr9z08vw3sz92r084j0c5kkn
[3] https://blogsarchive.apache.org/ofbiz/entry/apache-ofbiz-news-february-2017

On 13/03/24 09:40, Daniel Watford wrote:
>
> Hi Michael,
> 
> By symlink, are you referring to a filesystem symlink? If so, this
> unfortunately won't solve the problem of identifying which branch/tag of
> the ofbiz-plugins repository should be checked out for a continuous
> integration build - a problem we are seeing for tagged releases.
> 
> Also, I think (but may be wrong) that checkstyle runs against plugin code
> as part of the CI process. This means we have to set checkstyle error count
> thresholds in ofbiz-framework in such a way that takes ofbiz-plugins into
> account. This complicates the decision around what is an acceptable
> threshold at any given time. Happily the threshold in trunk is currently 0
> (see tasks.checkstyleMain.maxErrors in build.gradle), but when we introduce
> a new checkstyle rule we will need to track checkstyle errors in both
> ofbiz-framework and ofbiz-pluginsand we work towards being the error count
> back to zero.
> 
> If the plugins are not really the focus of the ofbiz-framework developers,
> should we even include them in the ofbiz-framework CI process at all?
> Perhaps we should instead document and provide examples on how an
> integrator would retrieve and build a plugin, but remove platform-specific
> code - such as pull*PluginSources* - from ofbiz-framework completely.
> 
> Interested parties could then augment ofbiz-plugins with a solution to
> insert plugin sources into the ofbiz-framework source and trigger a build
> accordingly.
> 
> If a particular plugin is deemed important enough to the ofbiz-framework
> developers - such as the rest-api plugin - then we could port that plugin
> to become a component of ofbiz-framework. We would therefore think of
> ofbiz-plugins as a contributed code area when components are incubated
> before being integrated.
> 
> I suppose the broader problem I'm trying to address is that I'm uneasy with
> the idea that we ofbiz-framework developers need to ensure the content of a
> seperate ofbiz-plugins repository remains compatible with our build checks,
> particularly since contributors may not event be aware ofbiz-plugins
> exists. (This position of course does not affect the need to maintain our
> API for use by plugins/integrations). Bringing a subset of plugins that
> need to be supported into the ofbiz-framework repository should address
> this problem.
> 
> Thanks,
> 
> Dan.
> 
> On Tue, 5 Mar 2024 at 10:32, Michael Brohl  wrote:
> 
> > Hi Dan,
> >
> > just a short reply for now: you can easily integrate the plugins using a
> > symlink to the plugins repository to check if changes in the framework
> > are compatible with the plugins.
> >
> > The plugins do not get as much 

Re: OFBiz REST API

[Nicolas Malin]

Hello both,

On customer project we deployed different engine and handler to use 
OFBiz as Rest api server.
I think I would be nice to share the different method use to expose 
service, screen and other thourgh OFBiz.


I hope that we have the time during the next month to share our work.

Nicolas

Le 13/03/2024 à 10:55, Daniel Watford a écrit :

Hi Michael,

I'm very keen to see how the REST API component has been progressing. Do
you think it could be added to ofbiz-framework soon so that we could get a
version incorporated in the 24.x release?

One feature that I think would be useful would be to produce an access
token within OFBiz's decorator screens such that the token is available for
use by javascript running on a page. We might then be able to build an HTTP
client delivered through ofbizutils.js (or other) which helps with making
authenticated calls to the REST API.

The approach of adding an access token to a rendered page was implemented
in the example plugin's example-react-decorator screen using
ApiTokenGenerator.groovy and ApiKey.ftl. ApiContext.tsx would then retrieve
the key from the page and add it to an authorization header in a fetch call.

Another feature I'm hoping for is for components to register themselves
with the API at various paths, rather than the rest-api component
attempting to derive api endpoints from the various services xml file. I
think this would allow for a leaner api without the need to work around any
legacy stuff from the service api. That being said, I imagine a lot of
components would end up registering thin adapter layers to their standard
services.

Looking forward to seeing the new component and contributing where possible.

Thanks,

Dan.

Re: Tomcat 10 Migration

[Michael Brohl]

Hi Gaetan,

in general, it seems to be a good idea to make this change (although I 
did not dig deeper into the breaking change/API change documentation).


In addition, I think we should first create a new release branch out of 
current trunk an try to put out a 24.x release this year. This would be 
the last Tomcat 9 based release series then.


Work on the Tomcat 10 migration could be made in a feature branch 
starting any time and be merged to trunk after creating the release 24.x 
branch, so that there would be no delay if you want to work on it soon.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 22.03.24 um 10:55 schrieb Gaetan:

Hello community,
We are thinking of building a Prometheus plugin the OFBiz. are 
thinking of using this library [1]
We already made a small POC. The problem is that we had to create a 
second HTTP server for this puspose only.
We thought about using the already existing Tomcat structure, but the 
library uses Tomcat 10, and OFBiz is Tomcat 9.
The migration will have to be made at some point, and this is the 
occasion for us to do it. There is a documentation that can be 
followed [2].


Is there any opposition ?

Gaetan and Nicolas.

[1] https://prometheus.github.io/client_java/

[2] https://tomcat.apache.org/migration-10.html 

Community over code 2024, Bratislava

[gil.portenseigne]

Hello everyone,

Some people from Nereide Team are planning to attend the Community Over Code
Europe Event in Bratislava this summer. 

We would love to see members of Apache OFBiz community there and would like to
know if any of you are also planning to come.

It would be great to plan something to get to know more each other and better
build our community, we could discuss some specific subjects, like OFBiz
modularity (Eugen contribution) or others current subjects.

It seems to me that Nicola Mazzoni [1] had already express his wish to go and
would be happy to see more participants familiar with OFBiz

Looking forward reading you,

Regards, 

Gil

[1] https://lists.apache.org/thread/pfkks77tb91kwy4wyox8lq99so82wb10

Tomcat 10 Migration

[Gaetan]

Hello community,
We are thinking of building a Prometheus plugin the OFBiz. are thinking 
of using this library [1]
We already made a small POC. The problem is that we had to create a 
second HTTP server for this puspose only.
We thought about using the already existing Tomcat structure, but the 
library uses Tomcat 10, and OFBiz is Tomcat 9.
The migration will have to be made at some point, and this is the 
occasion for us to do it. There is a documentation that can be followed [2].


Is there any opposition ?

Gaetan and Nicolas.

[1] https://prometheus.github.io/client_java/

[2] https://tomcat.apache.org/migration-10.html