Hi All, I’m really excited about this development and the change in approach. I’d be happy to assist with performance testing or pipeline-related work if any support is needed.
I have a question/suggestion that may already have been considered, but I wanted to raise it for discussion. Would it be feasible to allow a plugin to define a configuration XML containing a list of internal OFBiz services that should be exposed through the REST application, rather than requiring changes to the services themselves? For example, if I wanted to expose Party-related services such as create and update operations, I could include a configuration file within my plugin that specifies: - The internal services to expose - The REST endpoint paths (optional, defaulting to a standard URL pattern) - Supported HTTP methods (GET, POST, PUT, DELETE) - Request/response mappings (optional, defaulting to standard OFBiz behavior, but allowing internal field names to be masked or sensitive fields to be excluded) - Required security permissions or authentication settings This would allow developers to expose existing OFBiz services through REST in a configurable and modular way without modifying core application code. It could also make it easier to package, maintain, and distribute functionality as plugins while keeping the REST layer flexible and extensible. Potential benefits could include: - Reduced boilerplate when exposing existing services - Better separation between business logic and API definitions - Easier maintenance during OFBiz upgrades - Plugin-level ownership of API contracts - Consistent security and endpoint configuration across components Just a thought—I'd be interested to hear whether this aligns with the current direction and whether there are any technical or architectural concerns that would make it difficult to implement. On Wed, Jun 3, 2026 at 1:48 PM Lukas Finster <[email protected]> wrote: > Hello Ashish, > > Thank you for your input! > > I found a way of keeping the commit history using git-filter-repo. > > I will describe my approach in the corresponding Jira-Ticket if anyone > is interested. > > I also changed the final destination to framework folder as you suggested. > > Best regards, > > Lukas > > Am 03.06.26 um 12:29 schrieb Ashish Vijaywargiya: > > Hello Lukas, > > > > Thank you for your work in moving rest-api folder from plugins to > > ofbiz-framework. 👏👍 > > > > I think this is what Deepak is recommending here: > > > > Find out the history of commit logs from > > https://github.com/apache/ofbiz-plugins/tree/trunk/rest-api (old > location) > > and move the commit history along with the folder to the new location: > > > https://github.com/apache/ofbiz-framework/pull/1314/changes/2ed52de4d7b5bb4db5e320745214a9c7404f8280 > > . > > > > Important Note: If you wish to move the code from the same repository, > then > > it is easy to do it, just move the folder, and the version control system > > should take care of rest of the part. > > > > For example: Imagine you are moving "securityext" from the "applications" > > folder to the "framework" folder, then you can easily do it. The base > > folder is same: > > https://github.com/apache/ofbiz-framework/tree/trunk > > > > But you are moving the rest-api folder from plugins( > > https://github.com/apache/ofbiz-plugins/tree/trunk/rest-api) to the > > ofbiz-framework(https://github.com/apache/ofbiz-framework) > folder(probably > > inside "framework" folder), so you need to explore how to migrate the > > commit history of rest-api folder from one repo to another one. > > > > And IMO, you should put the rest component inside the framework folder. > > Here is the location where we should move the rest-api plugin. > > https://github.com/apache/ofbiz-framework/tree/trunk/framework/ > > > > "applications" folder is being designed to put the business applications > > like accounting, party, product, order, workeffort etc. > > > > rest-api should be part of the "framework" folder and moved here -> > > https://github.com/apache/ofbiz-framework/tree/trunk/framework. > > > > Once you have moved the rest-api folder from plugins folder to > > ofbiz-framework(inside the "framework" folder) then you can remove the > > rest-api folder from plugins folder and mention the details in the OFBiz > > Attic page: https://cwiki.apache.org/confluence/x/JNOoAQ > > > > This is all I could think of on this subject. > > Hopefully, it helps. 👍 > > > > -- > > Kind Regards, > > Ashish Vijaywargiya > > Vice President of Operations > > *HotWax Systems* > > *Enterprise open source experts* > > http://www.hotwaxsystems.com > > > > > > > > On Tue, Jun 2, 2026 at 7:01 PM Lukas Finster <[email protected]> > > wrote: > > > >> Edit: > >> > >> As Deepak mentioned, we should check the possibility of preserving git > >> history while migrating and what the ASF approved approach ist. > >> Unfortunatly I could not find information regarding what the ASF > >> approved approach in a case like this is. Can someone point me in the > >> right direction? > >> > >> Thank you, > >> > >> Lukas > >> > >> > >> Am 02.06.26 um 15:04 schrieb Lukas Finster: > >>> Hi everyone, > >>> > >>> I created a pull request for migrating the rest-api plugin into > >>> ofbiz-framework. Now I am wondering about two things: > >>> > >>> how to go about the eventual removal of the rest-api plugin from the > >>> ofbiz-plugin-repository. Naturaly it would be best to keep it as a > >>> plugin for a while, to ensure people using rest are not forced to use > >>> the latest ofbiz version containing the migration. My idea is to > >>> already create a jira issue for its removal and link it with the > >>> current one and tackle it at an appropriate point in time. How many > >>> versions do you think we should still keep the old rest-plugin? > >>> > >>> Also people using the plugin need be informed once they migrate to a > >>> version with the migration done, as running both the old plugin and > >>> the migrated version might cause issues. Also we don't want people > >>> accidentaly developing on the plugin-repo version. Any ideas on how to > >>> effectivly communicate this? Maybe there is an apropriate wiki-article > >>> i can append this information. > >>> > >>> Next i will tackle bringing our improvements into the rest-api as well > >>> as the ideas that have already been mentioned (@Nicolas webapp docs i > >>> already renamed, as it was a minor change ;) > >>> > >>> Best regards, > >>> > >>> Lukas > >>> > >> -- > >> Lukas Finster > >> Softwareentwickler & Berater > >> > >> ecomify GmbH, Stralsunder Straße 63, 33605 Bielefeld > >> Fon: +49 521 448157-90 | Fax: +49 521 448157-99 | www.ecomify.de > >> Court Registration: Amtsgericht Bielefeld, HRB 41683 | CEO: Martin > Becker, > >> Michael Brohl > >> > >> > -- > Lukas Finster > Softwareentwickler & Berater > > ecomify GmbH, Stralsunder Straße 63, 33605 Bielefeld > Fon: +49 521 448157-90 | Fax: +49 521 448157-99 | www.ecomify.de > Court Registration: Amtsgericht Bielefeld, HRB 41683 | CEO: Martin Becker, > Michael Brohl > >
