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