Thank you, Divesh and Arun. Today I merged the 'devreload' plugin into the plugins directory of the Apache OFBiz project.
Here is my PR: https://github.com/apache/ofbiz-plugins/pull/316 I have simplified most of the things; now, only a single gradle command can be run and edit a Java service/event method, a services.xml file, or add a brand-new method, and the change is live in under a second — no OFBiz restart is required. ./gradlew ofbizDev --no-watch-fs Note: You need to set the DCEVM_HOME before you run the above command. export DCEVM_HOME="/Applications/IntelliJ IDEA.app/Contents/jbr" (This path is from my laptop) I have also updated the README.md file with the latest information and the setting of DCEVM_HOME: https://github.com/apache/ofbiz-plugins/blob/trunk/devreload/README.md If someone is testing/using this plugin and facing issues, then I will provide quick assistance. Thank you. -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com On Fri, Jul 10, 2026 at 2:18 PM Arun Patidar <[email protected]> wrote: > Hi Ashish, > > Contributing this feature as a separate plugin is safe and can be very > useful for developers. > > > Best regards, > Arun Patidar > > > On Tue, Jul 7, 2026 at 4:04 PM Ashish Vijaywargiya < > [email protected]> wrote: > > > Hello Jacques, > > > > It's already in my TODO list, I will take care of it soon. Thank you! > > > > -- > > Kind Regards, > > Ashish Vijaywargiya > > Vice President of Operations > > *HotWax Systems* > > *Enterprise open source experts* > > http://www.hotwaxsystems.com > > > > > > > > On Tue, Jul 7, 2026 at 3:19 PM Jacques Le Roux via dev < > > [email protected]> > > wrote: > > > > > Hi, > > > > > > Should we not care about > > > > > > https://sonarcloud.io/project/issues?issueStatuses=OPEN%2CCONFIRMED&pullRequest=316&id=apache_ofbiz-plugins > > > ? > > > > > > Disclaimer: I did not get more than that. > > > > > > Jacques > > > > > > Le 07/07/2026 à 10:48, Divesh Dutta a écrit : > > > > I welcome this contribution as a plugin. > > > > > > > > Thanks > > > > -- > > > > Divesh Dutta > > > > www.hotwaxsystems.com > > > > > > > > On Tue, Jul 7, 2026 at 1:17 PM Ashish Vijaywargiya < > > > > [email protected]> wrote: > > > > > > > >> Hello Gaetan, > > > >> > > > >> Thanks for taking the time to share your thoughts again, I really do > > > >> appreciate the honest pushback. > > > >> > > > >> I have to admit, I'm still having trouble fully understanding the > > > reasoning > > > >> behind it. Why are we so hesitant to welcome a contribution like > this > > > into > > > >> the project? We're not making any changes to the framework itself, > > this > > > is > > > >> purely an addition to the plugins folder. I'd hope that kind of > > > >> contribution would be an easy one to accept. If something can > > genuinely > > > >> help someone in the community, even in a small way, I feel it's > worth > > > >> contributing rather than turning away. > > > >> > > > >> To lay out a bit more context on what "merging" would actually mean > > > here, > > > >> in case it helps: > > > >> > > > >> - No core framework functionality changes. devreload lives entirely > as > > > an > > > >> isolated component under plugins/devreload. The only framework-side > > > >> touchpoint is a small, reflective hook that safely no-ops when the > > > plugin > > > >> isn't present on the classpath - so a system that never installs the > > > plugin > > > >> behaves exactly as it does today. > > > >> > > > >> - It's fully opt-in. Nothing changes for the default workflow. > Anyone > > > who > > > >> doesn't want this feature keeps using `./gradlew ofbiz` exactly as > > > before. > > > >> The hot-reload behavior is only reachable through a separate > command, > > > >> `./gradlew ofbizDev`, that a developer has to explicitly choose to > > run. > > > >> > > > >> - The plugins repo already exists to host supporting/optional > > components > > > >> that can benefit part of the community without obligating everyone > to > > > use > > > >> or maintain them. That's the model I'm following here, not a > proposal > > to > > > >> fold this into framework/ or make it a default dependency. > > > >> > > > >> On the gain/work ratio, I'd gently push back a little: the gain is > > real > > > for > > > >> anyone doing active OFBiz development without an IDE-based hot-swap > > > setup > > > >> (which is a non-trivial setup burden today, especially for > newcomers). > > > The > > > >> ongoing maintenance surface is small and self-contained, it's one > > plugin > > > >> directory that can be updated, deprecated, or removed independently > of > > > >> core, like any other plugin in that repo. > > > >> > > > >> I still believe this small plugin will be a valuable addition to the > > > >> plugins directory and will benefit Apache OFBiz developers. With > that > > in > > > >> mind, I plan to commit the devreload component to the plugins > > directory > > > >> sometime later this week. > > > >> > > > >> -- > > > >> Kind Regards, > > > >> Ashish Vijaywargiya > > > >> Vice President of Operations > > > >> *HotWax Systems* > > > >> *Enterprise open source experts* > > > >> http://www.hotwaxsystems.com > > > >> > > > >> > > > >> > > > >> On Tue, Jul 7, 2026 at 12:19 PM gaetan.chaboussie via dev < > > > >> [email protected]> wrote: > > > >> > > > >>> Hi Ashish, Hi all. > > > >>> > > > >>> I am still not ok with the idea of this code being merged in > plugins > > > >>> repo, i'm refering to this line you wrote : > > > >>> > > > >>> I will be merging this "devreload" plugin sometime in the next > week. > > > >>> > > > >>> Again, IMO it shouldn't be the community's job to maintain this > > feature > > > >>> considering the gain / work ratio. > > > >>> > > > >>> Even if the code has been refactored and streamlined, it doesn't > > > changes > > > >>> my opinion. > > > >>> > > > >>> Regards, > > > >>> > > > >>> Gaetan. > > > >>> > > > >>> > > > >>> On 7/6/26 16:06, Ashish Vijaywargiya wrote: > > > >>>> Hello All, > > > >>>> > > > >>>> Here is the quick update on the "*devreload*" hot-reload plugin: > the > > > >> two > > > >>>> separate Gradle commands have been merged into a single one. > > > >>>> > > > >>>> Previously, there were two tasks, ./gradlew ofbizDev for stock-JDK > > > >>>> hot-reload and ./gradlew ofbizDevEnhanced for DCEVM-backed > > structural > > > >>>> hot-reload. Now there is just one task, ofbizDev, and enhanced > mode > > is > > > >> a > > > >>>> flag on it. > > > >>>> > > > >>>> ./gradlew ofbizDev still starts OFBiz normally on a stock JDK, > > > >>>> hot-reloading method body edits and services.xml changes live, > > exactly > > > >> as > > > >>>> before. > > > >>>> > > > >>>> ./gradlew ofbizDev -Photreload.enhanced=true --no-watch-fs runs > the > > > >> same > > > >>>> task on a DCEVM-patched JVM instead (JetBrains Runtime is > > > auto-detected > > > >>>> from a local IntelliJ IDEA install, or point at one explicitly > with > > > >>>> -PdcevmHome or DCEVM_HOME), additionally hot-swapping structural > > > >> changes > > > >>>> like new or removed methods live, with no restart. > > > >>>> > > > >>>> Both modes still support component scoping via > > > >>>> -Photreload.components=compA,compB for a faster, narrower startup > on > > > >>> large > > > >>>> checkouts. > > > >>>> > > > >>>> Under the hood, this is now a single JavaExec task rather than two > > > >>> separate > > > >>>> task types, so enhanced mode also picks up JavaExec's built-in > > safety > > > >>> nets, > > > >>>> like automatic classpath-argfile handling on Windows and > --debug-jvm > > > >>>> support, which the old separate Exec-based task did not have. > > > >>>> > > > >>>> No other behavior has changed. Full details are in > > > >>>> plugins/devreload/README.md. > > > >>>> > > > >> > > > > > > https://github.com/ashishvijaywargiya/ofbiz-plugins/blob/add-devreload/devreload/README.md > > > >>>> And here is the PR that I created over the weekend. > > > >>>> https://github.com/apache/ofbiz-plugins/pull/316 > > > >>>> > > > >>>> -- > > > >>>> Kind Regards, > > > >>>> Ashish Vijaywargiya > > > >>>> Vice President of Operations > > > >>>> *HotWax Systems* > > > >>>> *Enterprise open source experts* > > > >>>> http://www.hotwaxsystems.com > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Sat, Jul 4, 2026 at 6:34 PM Ashish Vijaywargiya < > > > >>>> [email protected]> wrote: > > > >>>> > > > >>>>> Thank you, Konstantinos Marinos, Jacques for sharing your > thoughts. > > > >>>>> > > > >>>>> Hello Gaetan, > > > >>>>> > > > >>>>> I tried the HotSwap option available in IntelliJ IDEA. > > > >>>>> > > > >>>>> Enable HotSwap Settings + DCEVM Plugin > > > >>>>> > > > >>>>> File Watcher Plugin setup > > > >>>>> > > > >>>>> CronJob setup so that it could manage your login information. > > > >>>>> > > > >>>>> But it's trickier, confusing, and more lengthy to set up. > > > >>>>> > > > >>>>> I dropped the idea of continuing with IntelliJ settings instead, > > and > > > >>>>> continued with creating an independent plugin "devreload" for > > OFBiz. > > > >>>>> Sharing more details below. > > > >>>>> > > > >>>>> Hello Dev Community, > > > >>>>> > > > >>>>> Wanted to share an update on the Java hot-reload tooling for > OFBiz > > > >>>>> development (the devreload plugin) that removes the > > restart-and-wait > > > >>> cycle > > > >>>>> when iterating on services, events, and services.xml files. > > > >>>>> > > > >>>>> https://github.com/apache/ofbiz-plugins/pull/316 > > > >>>>> > > > >>>>> > > > >> > > > > > > https://github.com/ashishvijaywargiya/ofbiz-plugins/tree/add-devreload/devreload > > > >>>>> Based on the community feedback around not wanting > framework-level > > > >> code > > > >>>>> changes, I have moved everything into the devreload plugin > itself — > > > >>> there > > > >>>>> are now zero changes required in ofbiz-framework. > > > >>>>> > > > >>>>> Now the plugin is entirely self-contained: dropping > > plugins/devreload > > > >>> into > > > >>>>> a checkout (or removing it) has zero effect on the rest of OFBiz > > > >> either > > > >>>>> way, since it hooks in purely through the standard > > > component/container > > > >>>>> discovery mechanism and the JVM's own Instrumentation API, with > no > > > >>>>> reflective bridge or hook anywhere in framework code. > > > >>>>> > > > >>>>> The plugin provides two Gradle commands, both drop-in > replacements > > > for > > > >>> the > > > >>>>> normal ofbiz start command. > > > >>>>> > > > >>>>> The two devreload commands > > > >>>>> > > > >>>>> 1. ./gradlew ofbizDev > > > >>>>> > > > >>>>> What it does: Starts OFBiz normally (stock JDK), with hot-reload > > > >> active. > > > >>>>> Java method-body edits and services.xml changes go live within > > ~300ms > > > >> of > > > >>>>> saving, no restart. It cannot hot-swap structural changes (a > > > brand-new > > > >>>>> method, a removed method/field, a changed signature) — those > still > > > >>> require > > > >>>>> a restart on a plain JDK. > > > >>>>> > > > >>>>> 2. ./gradlew ofbizDevEnhanced --no-watch-fs > > > >>>>> > > > >>>>> What it does: Starts OFBiz on a JVM with enhanced class > > redefinition > > > >>>>> support, instead of a stock JDK. On top of everything ofbizDev > > does, > > > >> it > > > >>>>> additionally hot-swaps structural changes — a brand-new method, a > > > >>> removed > > > >>>>> method or field, a changed signature — live as well, with no > > restart. > > > >>> The > > > >>>>> --no-watch-fs flag is recommended on a full checkout to avoid a > > > >>>>> directory-watch resource ceiling we found and root-caused during > > > >>> testing. > > > >>>>> Both commands also support optional component scoping via > > > >>>>> -Photreload.components=compA,compB for a faster, narrower startup > > > >> while > > > >>>>> working on a couple of components. > > > >>>>> > > > >>>>> Both commands have been tested end to end, including editing > > existing > > > >>>>> methods, editing services.xml, and adding brand-new methods and > > > >>> services, > > > >>>>> with all changes verified to take effect live without a restart. > > > >>>>> > > > >>>>> I will be merging this "devreload" plugin sometime in the next > > week. > > > >>>>> > > > >>>>> Please share your feedback on this whenever you can. > > > >>>>> > > > >>>>> -- > > > >>>>> Kind Regards, > > > >>>>> Ashish Vijaywargiya > > > >>>>> Vice President of Operations > > > >>>>> *HotWax Systems* > > > >>>>> *Enterprise open source experts* > > > >>>>> http://www.hotwaxsystems.com > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> On Thu, Jul 2, 2026 at 7:53 PM Konstantinos Marinos < > > > >>> [email protected]> > > > >>>>> wrote: > > > >>>>> > > > >>>>>> Hello Ashish, > > > >>>>>> > > > >>>>>> thank you for your work on this feature. I personally find the > > > >> approach > > > >>>>>> very interesting. > > > >>>>>> > > > >>>>>> Although I can see the point of view and the concerns raised by > > > >> Geatan, > > > >>>>>> offering extensive hot-reload capabilities directly from the > > > >>>>>> framework/tooling without relying on the IDE is for me a nice > > > >> addition. > > > >>>>>> After all, it is an extra option for developers that don't use > > > >> eclipse > > > >>> or > > > >>>>>> Intellij - although I imagine they are a very small minority. > > > >>>>>> > > > >>>>>> To the concern regarding "plugin" code residing inside the main > > > >>> project, > > > >>>>>> I was wondering if there was an option for some "creative" > > > >> refactoring > > > >>>>>> where you bind your new classloader through properties or a > > similar > > > >>>>>> mechanism. Of course if any additional configuration is absent, > it > > > >>> should > > > >>>>>> default to the current implementation. In that case even your > > > >>> DevReloadHook > > > >>>>>> class could live in the plugin and be picked up through a more > > > >>> generalised > > > >>>>>> Interface that just provides the appropriate classloader. > > > >>>>>> > > > >>>>>> This way no changes in the main project hint to the existence of > > the > > > >>> dev > > > >>>>>> container plugin, but anyone can provide their own > implementation > > of > > > >> a > > > >>>>>> "classloader provider" that modifies the standard classloading > > > >>> behaviour > > > >>>>>> for java. > > > >>>>>> > > > >>>>>> This is only an idea I had after looking at the modifications in > > > >>> trunk. I > > > >>>>>> hope I was able to get my point across and that it addresses the > > > >>> concerns > > > >>>>>> in this thread. > > > >>>>>> > > > >>>>>> Best of luck with further development and the future adoption of > > > this > > > >>>>>> functionality. > > > >>>>>> > > > >>>>>> Konstantinos Marinos > > > >>>>>> > > > >>>>>> On 2026/07/02 12:24:07 Ashish Vijaywargiya wrote: > > > >>>>>>> Hello Jacques and Geatan, > > > >>>>>>> > > > >>>>>>> Thank you for sharing your thoughts. They were very helpful. 👍 > > > >>>>>>> > > > >>>>>>> I thought about my implementation again and updated it a bit. > The > > > >>>>>>> implementation (WatchService + in-process compiler + a > > child-first > > > >>>>>>> classloader) lives entirely in a small plugin, published > > separately > > > >> at > > > >>>>>>> https://github.com/ashishvijaywargiya/devreload. This plugin > is > > > >>>>>> available > > > >>>>>>> to anyone, and anyone can clone it if required. > > > >>>>>>> > > > >>>>>>> I can also move it to the ofbiz-plugins folder if the community > > > >>> members > > > >>>>>>> agree to put the "devreload" component codebase there. > > > >>>>>>> > > > >>>>>>> To make the framework pick up hot-reloaded classes when that > > plugin > > > >> is > > > >>>>>>> present, I need a small footprint in ofbiz-framework itself: a > > > >>>>>> reflective > > > >>>>>>> bridge, a small file DevReloadHook.java, plus one gated > > classloader > > > >>>>>> check > > > >>>>>>> each in StandardJavaEngine and JavaEventHandler. > > > >>>>>>> > > > >>>>>>> Branch for reference: > > > >>>>>>> > > > >> > > > > > > https://github.com/apache/ofbiz-framework/compare/trunk...ashishvijaywargiya:ofbiz-framework:dev-reload-container-support > > > >>>>>>> Hopefully, now the changes in the > "dev-reload-container-support" > > > >>> branch > > > >>>>>> can > > > >>>>>>> be merged into the OFBiz trunk code. > > > >>>>>>> > > > >>>>>>> To demonstrate the feature, I have added a new field > "comments2" > > on > > > >>> the > > > >>>>>>> form, and then made the changes in services.xml, and then made > > the > > > >>>>>> changes > > > >>>>>>> in OfbizDemoServices.java file. The changes in services.xml and > > > java > > > >>>>>> files > > > >>>>>>> are reflected without restarting OFBiz. > > > >>>>>>> > > > >>>>>>> > > > >> > > > > > > https://drive.google.com/drive/folders/1W5ILWVOSBD956GcDT50-GmZkV_seMNRv?usp=sharing > > > >>>>>>> I have made the changes in a demo component - > > > >>>>>>> https://github.com/ashishvijaywargiya/ofbizDemo. > > > >>>>>>> > > > >>>>>>> Please let me know your thoughts on this. > > > >>>>>>> > > > >>>>>>> I will also explore the HotSwap plugin in IntelliJ IDEA and get > > > back > > > >>>>>> with > > > >>>>>>> my thoughts. > > > >>>>>>> > > > >>>>>>> Thank you. > > > >>>>>>> > > > >>>>>>> -- > > > >>>>>>> Kind Regards, > > > >>>>>>> Ashish Vijaywargiya > > > >>>>>>> Vice President of Operations > > > >>>>>>> *HotWax Systems* > > > >>>>>>> *Enterprise open source experts* > > > >>>>>>> http://www.hotwaxsystems.com > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Wed, Jul 1, 2026 at 9:49 PM Jacques Le Roux via dev < > > > >>>>>> [email protected]> > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>>> Hi, > > > >>>>>>>> > > > >>>>>>>> I tend to agree with Gaetan. > > > >>>>>>>> > > > >>>>>>>> Jacques > > > >>>>>>>> > > > >>>>>>>> Le 01/07/2026 à 09:18, gaetan.chaboussie via dev a écrit : > > > >>>>>>>>> Hello Ashish, hello all. > > > >>>>>>>>> First, thanks for the effort put into this. Seems like a lot > of > > > >> work > > > >>>>>>>> (even if it looks like there has been some AI help on the > code). > > > >>>>>>>>> This being said, I'm not sure how i feel seeing a 'developer > > > only' > > > >>>>>>>> intended feature in the project code. > > > >>>>>>>>> I think that it's the IDE's job to provide this kind of > > feature. > > > >> In > > > >>>>>> my > > > >>>>>>>> experience, Eclipse handles it natively pretty well, and > > Intellij > > > >> is > > > >>>>>> making > > > >>>>>>>>> great progress (and has a Hotsawp plugin that i personally > > use). > > > >>>>>>>>> Also, i believe that it's precisely the point of > GroovyScripts > > to > > > >>>>>> allow > > > >>>>>>>> editing without recompiling. > > > >>>>>>>>> Although I understand the idea, I would personnaly not advise > > > this > > > >>>>>>>> change, that creates low level code changes, and looks tricky > to > > > >>>>>> maintain. > > > >>>>>>>>> Gaetan. > > > >>>>>>>>> > > > >>>>>>>>> On 6/30/26 18:03, Ashish Vijaywargiya wrote: > > > >>>>>>>>>> Hello OFBiz Dev Community, > > > >>>>>>>>>> > > > >>>>>>>>>> I would like to share a prototype that removes the need to > > > >> restart > > > >>>>>> OFBiz > > > >>>>>>>>>> when developing Java services, events and service > > > >>>>>>>> definitions(services.xml). > > > >>>>>>>>>> Many years ago I came across Tomcat's reloadable="true" > > context > > > >>>>>>>> attribute. > > > >>>>>>>>>> When enabled, Tomcat's application deployer watches for > class > > > >> file > > > >>>>>>>> changes > > > >>>>>>>>>> and > > > >>>>>>>>>> automatically reloads the web application — no server > restart, > > > no > > > >>>>>> manual > > > >>>>>>>>>> step. I always thought that was a great developer > experience, > > > and > > > >>>>>> at the > > > >>>>>>>>>> back of my mind I wondered whether something similar could > be > > > >> done > > > >>>>>> in > > > >>>>>>>> OFBiz. > > > >>>>>>>>>> The standard Java change cycle in OFBiz today is: > > > >>>>>>>>>> edit .java → ./gradlew classes → kill OFBiz → wait 30-60 s → > > > >>>>>> restart → > > > >>>>>>>> test > > > >>>>>>>>>> Groovy scripts and Freemarker templates already pick up > > changes > > > >>>>>> without > > > >>>>>>>> a > > > >>>>>>>>>> restart; Java does not. This prototype brings the same > > > >> convenience > > > >>>>>> to > > > >>>>>>>> Java > > > >>>>>>>>>> development, specifically targeting *Services.java and > > > >> *Events.java > > > >>>>>>>> files > > > >>>>>>>>>> which are the ones developers touch most during active > feature > > > >>>>>> work. > > > >>>>>>>>>> --- What it does --- > > > >>>>>>>>>> > > > >>>>>>>>>> A new class called DevReloadContainer is added to > > > framework/base. > > > >>>>>> It is > > > >>>>>>>>>> activated by passing -Dofbiz.hotreload=true on startup and > > does > > > >>>>>> three > > > >>>>>>>>>> things: > > > >>>>>>>>>> > > > >>>>>>>>>> 1. Watches build/classes/java/main/ for changed .class files > > and > > > >>>>>>>>>> hot-swaps them into a fresh class loader without > > > >> restarting > > > >>>>>> OFBiz. > > > >>>>>>>>>> In practice this means saving a *Services.java or > > > >>>>>> *Events.java > > > >>>>>>>> file > > > >>>>>>>>>> is enough — the change is live in under a second. > > > >>>>>>>>>> > > > >>>>>>>>>> 2. Watches all component servicedef/ directories and clears > > the > > > >>>>>> service > > > >>>>>>>>>> model cache when any *services.xml file changes, so > > new > > > or > > > >>>>>>>> modified > > > >>>>>>>>>> service definitions are picked up immediately. > > > >>>>>>>>>> > > > >>>>>>>>>> 3. Watches all component src/main/java/ directories and > > compiles > > > >>>>>> changed > > > >>>>>>>>>> .java files in-process (using > > javax.tools.JavaCompiler), > > > >> so > > > >>>>>> you > > > >>>>>>>> do not > > > >>>>>>>>>> need a second terminal running ./gradlew -t classes. > > > >>>>>>>>>> > > > >>>>>>>>>> A 300 ms debounce window batches a burst of file-save events > > > >> into a > > > >>>>>>>> single > > > >>>>>>>>>> reload, so rapid edits do not cause multiple reloads. > > > >>>>>>>>>> > > > >>>>>>>>>> --- The new dev workflow --- > > > >>>>>>>>>> > > > >>>>>>>>>> A new Gradle task wraps everything into one command: > > > >>>>>>>>>> > > > >>>>>>>>>> ./gradlew ofbizDev > > > >>>>>>>>>> > > > >>>>>>>>>> Start OFBiz with that command, then edit any *Services.java, > > > >>>>>>>> *Events.java, > > > >>>>>>>>>> or *services.xml file and save — changes are live without > any > > > >>>>>> restart. > > > >>>>>>>>>> The working code is on branch dev-reload-container-support. > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >> > > > > > > https://github.com/ashishvijaywargiya/ofbiz-framework/tree/dev-reload-container-support > > > >> > > > > > > https://github.com/apache/ofbiz-framework/compare/trunk...ashishvijaywargiya:ofbiz-framework:dev-reload-container-support > > > >>>>>>>>>> The implementation went through several rounds of debugging > > and > > > >>>>>>>>>> covers 32 test cases including child-first class loading, > > > >>>>>> multi-cycle > > > >>>>>>>>>> reload correctness, > > > >>>>>>>>>> inner and anonymous class reloading, concurrent class > loading, > > > >>>>>>>>>> malformed-bytecode handling, shutdown races, and the macOS > > > >>>>>>>> spurious-event > > > >>>>>>>>>> suppression. > > > >>>>>>>>>> > > > >>>>>>>>>> Please review this feature and let me know your > > > >> thoughts/feedback. > > > >>>>>>>>>> And please report any issues you find. > > > >>>>>>>>>> > > > >>>>>>>>>> Very soon, I will be creating a pull request for this > feature. > > > >>>>>>>>>> > > > >>>>>>>>>> I am hopeful that this feature will be helpful to all > > developers > > > >>>>>> who are > > > >>>>>>>>>> building enterprise applications using the Apache OFBiz > > project. > > > >> 👍 > > > >>>>>>>>>> Thank you. > > > >>>>>>>>>> > > > >>>>>>>>>> -- > > > >>>>>>>>>> Kind Regards, > > > >>>>>>>>>> Ashish Vijaywargiya > > > >>>>>>>>>> Vice President of Operations > > > >>>>>>>>>> *HotWax Systems* > > > >>>>>>>>>> *Enterprise open source experts* > > > >>>>>>>>>> http://www.hotwaxsystems.com > > > >>>>>>>>>> > > > > > >
