You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Lukas Finster <lu...@ecomify.de> on 2026/06/02 13:04:49 UTC
Re: Proposal to move REST-API Plugin into framework
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
Re: Proposal to move REST-API Plugin into framework
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Moenieb,
thanks for reaching out.
If I understand your suggestions correctly, the current implementation
mostly supports them.
You can either expose a service through the service definition or
through the component's /api/*.rest.xml REST definition file. The latter
provides more detailed configuration options and lets you map a service
against a defined endpoint.
You find some documentation in [1] and [2].
After the migration from plugins to the framework, we will also
contribute enhanced functionality to make it more flexible and
feature-rich and provide more documentation.
See [3] for the main Jira issue and the subtasks. Most of the suggested
enhancements there are already in production in our custom projects for
quite some time.
Hope that helps.
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
[1]:
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+implement+RESTful+APIs+using+the+OFBiz+rest-api+plugin
[2]:
https://nightlies.apache.org/ofbiz/trunk/plugins/rest-api/html5/rest-api.html
[3]: https://issues.apache.org/jira/browse/OFBIZ-11328
Am 03.06.26 um 23:48 schrieb Moenieb Davids:
> 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 <lu...@ecomify.de>
> 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 <lu...@ecomify.de>
>>> 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
>>
>>
Re: Proposal to move REST-API Plugin into framework
Posted by Moenieb Davids <mo...@gmail.com>.
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 <lu...@ecomify.de>
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 <lu...@ecomify.de>
> > 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
>
>
Re: Proposal to move REST-API Plugin into framework
Posted by Carsten Schinzer <ca...@dcs-verkaufssysteme.de>.
Thanks to clarify, Lukas.
I shall then log according refactoring to my backlog in order to make my life easier and come close to the reference implementation for the PR :)
… and definitely +1 for merging this into the framework.
> Am 11.06.2026 um 14:15 schrieb Lukas Finster <lu...@ecomify.de>:
>
> Hello Carsten,
>
> no need for apologies, I am glad to have your input.
>
> Regarding proper HTTP error codes, we have locally implemented the ability to set and overwrite the response code from within the called service in order to return logically conditioned status codes/responses. Our company has been using this feature for about 3 years in production environment and would contribute it to the standard, once migration is complete.
>
> Leveraging swagger documentation should already be possible if im not mistaken by providing a .rest.xml file mapping url to services and Providing additional information to swagger. Just had a quick look, the loadApiDefinitions in OFBizApiConfig supports this. But since there appears to be no demo file I see how that could be confusing. Something else I will address once migration is trough.
>
> Best regards,
>
> Lukas
>
>
>
> Am 11.06.26 um 10:36 schrieb Carsten Schinzer:
>> Hello,
>>
>>
>> Apologies to jump on this late.
>> This is really a great evolution. I spent quite some time on exposing a REST API for a fairly small adoption of OfBiz (extending products to be Seats for an event like a concert along with seat maps etc.).
>>
>> I also truly appreciate that the PR comes with decent documentation.
>>
>>
>> Where I have doubts is the following:
>>
>> - how can we leverage OpenAPI / Swagger documentation? I can see description and parameter documentation being possible (but who does consistently use service/attribute/description elements?)
>> - how can we map proper HTTP protocol return codes in the 4xx range?
>>
>> I don’t see these are blockers to move forward, but adoption of REST APIs in enterprise environments w/o such features these days appears at risk.
>>
>> For example, in my project, this is where I spent most of the time honestly.
>> In the app I mentioned, in the REST Controller classes:
>> - approx. 10% of the code lines are input validation and service calls
>> - approx. 40% of lines are OpenAPI annotations and
>> - approx. 50% of code lines are logging, exception handling and mapping to proper HTTP returns.
>>
>> So in brief, I see the value of being able to simplify REST API exposure for OfBiz Services, but we need to find a way to amend the shortcomings of the underlying service engine with regards to documentation and return code mapping.
>>
>> Maybe I am overlooking something - I just threw a brief read into the doc on the PR. Then feel free to point me 🙂
>>
>> Warm regards
>
> --
> 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
>
Re: Proposal to move REST-API Plugin into framework
Posted by Lukas Finster <lu...@ecomify.de>.
Hello Carsten,
no need for apologies, I am glad to have your input.
Regarding proper HTTP error codes, we have locally implemented the
ability to set and overwrite the response code from within the called
service in order to return logically conditioned status codes/responses.
Our company has been using this feature for about 3 years in production
environment and would contribute it to the standard, once migration is
complete.
Leveraging swagger documentation should already be possible if im not
mistaken by providing a .rest.xml file mapping url to services and
Providing additional information to swagger. Just had a quick look, the
loadApiDefinitions in OFBizApiConfig supports this. But since there
appears to be no demo file I see how that could be confusing. Something
else I will address once migration is trough.
Best regards,
Lukas
Am 11.06.26 um 10:36 schrieb Carsten Schinzer:
> Hello,
>
>
> Apologies to jump on this late.
> This is really a great evolution. I spent quite some time on exposing a REST API for a fairly small adoption of OfBiz (extending products to be Seats for an event like a concert along with seat maps etc.).
>
> I also truly appreciate that the PR comes with decent documentation.
>
>
> Where I have doubts is the following:
>
> - how can we leverage OpenAPI / Swagger documentation? I can see description and parameter documentation being possible (but who does consistently use service/attribute/description elements?)
> - how can we map proper HTTP protocol return codes in the 4xx range?
>
> I don’t see these are blockers to move forward, but adoption of REST APIs in enterprise environments w/o such features these days appears at risk.
>
> For example, in my project, this is where I spent most of the time honestly.
> In the app I mentioned, in the REST Controller classes:
> - approx. 10% of the code lines are input validation and service calls
> - approx. 40% of lines are OpenAPI annotations and
> - approx. 50% of code lines are logging, exception handling and mapping to proper HTTP returns.
>
> So in brief, I see the value of being able to simplify REST API exposure for OfBiz Services, but we need to find a way to amend the shortcomings of the underlying service engine with regards to documentation and return code mapping.
>
> Maybe I am overlooking something - I just threw a brief read into the doc on the PR. Then feel free to point me 🙂
>
> Warm regards
--
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
Re: Proposal to move REST-API Plugin into framework
Posted by Carsten Schinzer <ca...@dcs-verkaufssysteme.de>.
Hello,
Apologies to jump on this late.
This is really a great evolution. I spent quite some time on exposing a REST API for a fairly small adoption of OfBiz (extending products to be Seats for an event like a concert along with seat maps etc.).
I also truly appreciate that the PR comes with decent documentation.
Where I have doubts is the following:
- how can we leverage OpenAPI / Swagger documentation? I can see description and parameter documentation being possible (but who does consistently use service/attribute/description elements?)
- how can we map proper HTTP protocol return codes in the 4xx range?
I don’t see these are blockers to move forward, but adoption of REST APIs in enterprise environments w/o such features these days appears at risk.
For example, in my project, this is where I spent most of the time honestly.
In the app I mentioned, in the REST Controller classes:
- approx. 10% of the code lines are input validation and service calls
- approx. 40% of lines are OpenAPI annotations and
- approx. 50% of code lines are logging, exception handling and mapping to proper HTTP returns.
So in brief, I see the value of being able to simplify REST API exposure for OfBiz Services, but we need to find a way to amend the shortcomings of the underlying service engine with regards to documentation and return code mapping.
Maybe I am overlooking something - I just threw a brief read into the doc on the PR. Then feel free to point me :)
Warm regards
Carsten
> Am 10.06.2026 um 15:20 schrieb Lukas Finster <lu...@ecomify.de>:
>
> ted pose the question to the com
Re: Proposal to move REST-API Plugin into framework
Posted by Lukas Finster <lu...@ecomify.de>.
Thanks for the clarification Deepak.
My understanding is that the concern regarding rewriting history is more
for existing repos where commit hashes would change if history is
rewritten. This is not an issue here.
By preserving commit messages, authorship und development history we are
abbiding by the spirit of this rule if not the letter. The resulting
commit hashes are (neccessarily) different, yes, but the history itself
remains intact and traceable.
At this point I would as Deepak suggested pose the question to the
community:
Do you see a problem with the suggested approach?
For anyone wanting to validate the result, you can compare commits in
the PR with the ones in ofbiz-plugins repo.
https://github.com/apache/ofbiz-framework/pull/1325
If you see no problem feedback is also welcome. Baring any issues with
the approach I would like to push this trough to start working on
integrating our beforementioned enhanced functionality into the
rest-api-plugin.
Thanks and best regards,
Lukas
Am 08.06.26 um 11:32 schrieb Deepak Dixit:
> Hi Luke,
>
> Thanks, and sorry for the short comment earlier.
>
> Yes, git-filter-repo provides a way to move a subfolder or merge one
> repository into another while preserving history. However, it rewrites
> history, so we need to check whether ASF policy allows this kind of history
> rewrite.
>
> I remember reading somewhere that rewriting history is generally not
> recommended. However, in this case, since we are moving the rest-api plugin
> from plugins to the framework, it might be acceptable if the community
> agrees.
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Wed, Jun 3, 2026 at 5:18 PM Lukas Finster <lu...@ecomify.de>
> 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 <lu...@ecomify.de>
>>> 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
>>
>>
--
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
Re: Proposal to move REST-API Plugin into framework
Posted by Deepak Dixit <de...@apache.org>.
Hi Luke,
Thanks, and sorry for the short comment earlier.
Yes, git-filter-repo provides a way to move a subfolder or merge one
repository into another while preserving history. However, it rewrites
history, so we need to check whether ASF policy allows this kind of history
rewrite.
I remember reading somewhere that rewriting history is generally not
recommended. However, in this case, since we are moving the rest-api plugin
from plugins to the framework, it might be acceptable if the community
agrees.
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Wed, Jun 3, 2026 at 5:18 PM Lukas Finster <lu...@ecomify.de>
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 <lu...@ecomify.de>
> > 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
>
>
Re: Proposal to move REST-API Plugin into framework
Posted by Lukas Finster <lu...@ecomify.de>.
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 <lu...@ecomify.de>
> 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
Re: Proposal to move REST-API Plugin into framework
Posted by Ashish Vijaywargiya <as...@hotwaxsystems.com>.
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 <lu...@ecomify.de>
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
>
>
Re: Proposal to move REST-API Plugin into framework
Posted by Nicolas Malin via dev <de...@ofbiz.apache.org>.
I'm really interested to know how do that because in my mind git is an
atomic system, so I have some difficulty to show how we can cut a block
of a repo to push it in an other.
I hope I'm wrong and I'll be learn something :)
Nicolas
Le 02/06/2026 à 15:30, Lukas Finster a écrit :
> 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
>>
Re: Proposal to move REST-API Plugin into framework
Posted by Lukas Finster <lu...@ecomify.de>.
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