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