Hi all, myportal, firstdatapaymentgateway and the JMS service engine are now removed from trunk too, each recorded in the UPGRADING.md of its repository. As before, tables and seed data stay in existing databases and release24.09 is unchanged.
- myportal (OFBIZ-13825, OFBIZ-13826): portal pages and the portlets each application defines stay. The customer-only portlets went with it, and editing someone else's portal page now needs PORTALPAGE_ADMIN. - firstdatapaymentgateway (OFBIZ-13828): its PaymentGatewayFirstData table holds gateway credentials, so clear it if you had it configured. - JMS service engine (OFBIZ-13829): the distributedClear* services went with it, so there is no built-in cross-server cache clearing for now. I'll propose a cluster cache plugin in a separate thread. The Attic page has an entry for each. Thanks, Mridul Pathak On Thu, Nov 12, 2026 at 11:58 AM Mridul Pathak <[email protected]> wrote: > Hi all, > > myportal, firstdatapaymentgateway and the JMS service engine were left > open in the proposal for anyone who relied on them or wanted to look after > them. Nobody has come forward, so I'll go ahead and remove all three from > trunk the same way as the earlier rounds, with nothing touching > release24.09. > > - myportal: I'll first remove what the core borrows from it (portlet > permission services, a hard-coded /myportal/ path in the shared portlet > script, order email links and labels), then the plugin. Portal pages and > the portlets each application defines stay. > - firstdatapaymentgateway: the payment gateway framework stays, so a > gateway can still be added as a plugin. > - JMS service engine: the distributed cache clearing hook stays, and I'll > propose a plugin for it on a current transport in a separate thread, as > with the OpenID Connect login plugin. > > Thanks, > Mridul Pathak > > On Thu, Nov 12, 2026 at 6:47 AM Mridul Pathak <[email protected]> > wrote: > >> Hi all, >> >> The rest of the list is now merged in trunk. Each removal is recorded in >> the UPGRADING.md of its repository, and tables and seed data stay in >> existing databases as before. >> >> - passport (OFBIZ-13814, https://github.com/apache/ofbiz-plugins/pull/517): >> the GitHub and LinkedIn login tables stay; a standard OpenID Connect login >> plugin is the replacement I'll propose in a separate thread. >> - ldap plugin (OFBIZ-13823, >> https://github.com/apache/ofbiz-plugins/pull/521, >> https://github.com/apache/ofbiz-framework/pull/2618): LDAP login stays >> available in the framework through security.ldap.enable. >> - datafile (OFBIZ-13815, >> https://github.com/apache/ofbiz-framework/pull/2602): projects with >> their own flat-file definitions can keep the component from release24.09 as >> a plugin. >> - iCalendar servlet (OFBIZ-13816, >> https://github.com/apache/ofbiz-framework/pull/2605): this also removed >> the org.apache.ofbiz.webapp.webdav package, which I hadn't listed in the >> proposal. It was a 2009 starting point written for iCalendar, never >> completed, and iCalendar was its only user; a webapp that needs WebDAV can >> use Tomcat's WebdavServlet, which is already on the classpath. >> - Old webtools developer pages (OFBIZ-13817, >> https://github.com/apache/ofbiz-framework/pull/2609): the EOModel >> export, the JSP entity tools and the 2006 test endpoints. The entity >> reference, Check/Update Database and Induce Model XML stay. >> - scrum (OFBIZ-13818, https://github.com/apache/ofbiz-plugins/pull/518, >> https://github.com/apache/ofbiz-framework/pull/2612): projectmgr stays, >> and the extra CustRequest and TimeEntry columns stay in existing databases. >> - cmssite (OFBIZ-13819, https://github.com/apache/ofbiz-plugins/pull/519, >> https://github.com/apache/ofbiz-framework/pull/2613): the core CMS and >> the multi-site support in RequestHandler stay, but the plugin's >> WebSiteFilter went with it, so a webapp serving several web sites by >> hostedPathAlias now needs its own filter. What that filter has to do is in >> applications/UPGRADING.md, and the release24.09 classes are a starting >> point. The verify-email notification, which linked into cmssite, now links >> to the store's own webapp. >> - EntitySync (OFBIZ-13820, >> https://github.com/apache/ofbiz-framework/pull/2616): this went further >> than the proposal, which said offline sync would stay. Once I looked >> closer, the offline export could not complete a sync (an export left it >> pending with no working way to finish), so the offline export and import >> were removed along with remote push and pull. The EntitySync records stay >> and can still select entities in the Webtools XML Data Export; to move data >> between instances, use the XML export and import. >> - SOAP and RMI (OFBIZ-13821, >> https://github.com/apache/ofbiz-framework/pull/2617, >> https://github.com/apache/ofbiz-plugins/pull/520): as discussed in >> Anil's thread. The REST API is the way to call services remotely. >> >> If the EntitySync or WebDAV changes cause a problem for anyone, please >> say so and we can look at bringing back what's needed. >> >> Thanks, >> Mridul Pathak >> >> On Fri, Nov 6, 2026 at 1:32 PM Mridul Pathak <[email protected]> >> wrote: >> >>> Hi all, >>> >>> A short update on this thread: the first five removals are now merged in >>> trunk. >>> >>> - exampleext (OFBIZ-13795, >>> https://github.com/apache/ofbiz-plugins/pull/496, >>> https://github.com/apache/ofbiz-framework/pull/2552): the extension >>> techniques it demonstrated are now documented in the developer manual under >>> "Extending a component without modifying it". >>> - multiflex (OFBIZ-13796, >>> https://github.com/apache/ofbiz-plugins/pull/497, >>> https://github.com/apache/ofbiz-framework/pull/2553): stores still set >>> to the MULTIFLEX visual theme should switch to EC_DEFAULT before upgrading. >>> - msggateway (OFBIZ-13797, >>> https://github.com/apache/ofbiz-plugins/pull/498): the core telecom >>> services it plugged into remain as an extension point. >>> - The Clojure service engine (OFBIZ-13798, >>> https://github.com/apache/ofbiz-framework/pull/2559): anyone with their >>> own Clojure services can keep the engine class in a plugin, as the upgrade >>> notes explain. >>> - pricat (OFBIZ-13799, https://github.com/apache/ofbiz-plugins/pull/503, >>> https://github.com/apache/ofbiz-framework/pull/2561): its >>> ExcelImportHistory table and enumerations stay in existing databases and >>> can be dropped by hand. >>> >>> The entity tables of removed plugins are not dropped, and each removal >>> is recorded in the UPGRADING.md of its repository. >>> >>> Thanks, >>> Mridul Pathak >>> >>> On Thu, Nov 5, 2026 at 5:06 PM Mridul Pathak <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> No objections so far. I'll start with the smallest items (exampleext, >>>> multiflex, msggateway, the Clojure engine and pricat) and leave the rest >>>> open until Monday 9 November; if you use any of them or would like to look >>>> after one, please reply here before then. >>>> >>>> Thanks, >>>> Mridul Pathak >>>> >>>> On Wed, Nov 4, 2026 at 11:07 AM Shivansh Sharma < >>>> [email protected]> wrote: >>>> >>>>> +1 >>>>> >>>>> Thanks, >>>>> Shivansh >>>>> >>>>> On Mon, Nov 2, 2026 at 1:00 PM Mridul Pathak via dev < >>>>> [email protected]> >>>>> wrote: >>>>> >>>>> > Hi all, >>>>> > >>>>> > Following the BIRT and bi threads, where Jacopo suggested taking the >>>>> same >>>>> > approach to other experimental features, I went through applications, >>>>> > framework and every plugin looking for components that are unused, >>>>> > unmaintained or already disabled. The evidence for each one (origin >>>>> and >>>>> > history, status, JIRA, mailing-list and wiki mentions, consumers, >>>>> and what >>>>> > stays behind in existing databases) is on the wiki: >>>>> > >>>>> > >>>>> https://cwiki.apache.org/confluence/spaces/OFBIZ/pages/462815951/Proposal+Retiring+Experimental+and+Abandoned+Features+2026 >>>>> > >>>>> > In short, I'd like to propose removing from trunk only: exampleext >>>>> (the >>>>> > extension pattern it demonstrates would move to a page in the >>>>> developer >>>>> > manual), multiflex, msggateway, the Clojure service engine, pricat, >>>>> > passport, the ldap plugin (the framework's own LDAP login stays), >>>>> the old >>>>> > webtools developer pages (EOModel export, JSP entity tools, 2006 test >>>>> > endpoints) and remote EntitySync push/pull (offline sync stays). For >>>>> SOAP >>>>> > and RMI I'd suggest we simply act on Anil's July thread, which had >>>>> support >>>>> > and no objections. >>>>> > >>>>> > I'd also remove four larger features that are unmaintained and >>>>> either no >>>>> > longer work or would need a redesign: scrum (donated in 2011; its SVN >>>>> > integration has been broken since 2021 and its demo page shows an >>>>> error), >>>>> > cmssite (its demo pages are FreeMarker templates stored in the >>>>> database, >>>>> > which the CVE-2026-29207 fixes no longer render), datafile (no >>>>> definitions >>>>> > ship on trunk since the Taxware/ZipSales removal) and the iCalendar >>>>> servlet >>>>> > (only the demo calendar has worked since 2016, and it never supported >>>>> > CalDAV). >>>>> > >>>>> > External login and single sign-on are real needs, but passport and >>>>> the ldap >>>>> > plugin are not the way to meet them: they use provider-specific >>>>> APIs, are >>>>> > not wired into any login page, and LinkedIn login no longer works. >>>>> I'd >>>>> > rather remove them and propose, in a separate thread, a plugin built >>>>> on >>>>> > standard OpenID Connect that covers Google, Microsoft, GitHub and >>>>> > Keycloak-style providers. >>>>> > >>>>> > projectmgr and assetmaint have real users and stay. For myportal, >>>>> > firstdatapaymentgateway and the JMS engine I found no evidence of >>>>> use: >>>>> > myportal stays for now because core depends on it, firstdata is our >>>>> last >>>>> > payment gateway integration, and JMS cache clearing is off by >>>>> default. If >>>>> > you rely on any of these three, or would like to look after one, >>>>> please say >>>>> > so; otherwise I'd bring them back for removal in a later round, after >>>>> > decoupling core from myportal. >>>>> > >>>>> > Each removal would get its own JIRA and PRs, smallest first, and >>>>> nothing >>>>> > touches release24.09. Tables and seed data from removed components >>>>> stay in >>>>> > existing databases (OFBiz never drops them), and each removal's >>>>> release >>>>> > note will list them. If you use anything on the removal list, or >>>>> think one >>>>> > should stay, please say so here. >>>>> > >>>>> > Thanks, >>>>> > Mridul Pathak >>>>> > >>>>> >>>>
