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