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