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