It was the idea of the watcher - it is actually: https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-core/src/main/java/org/apache/meecrowave/watching/ReloadOnChangeController.java . Issue is it is not an easy impl since the best impl you can do is to debounce the reloading to avoid to reload 15 times just for one atomic change. but it rarely really match the dev experience. So it works well for small projects with 2-3 classes but for real projects it depends a lot on the compilation. This is how the manual reloading command started, it avoids all these pitfalls. The alternative is to have a post refresh command automatically called (a bit like livereload), but we don't have it yet.
So to summarize, here are the enhancements I can see: 1. integrate more deeply reloadGoals with watcherBouncing (watching sources, calling reloadGoals and then reloading the context) 2. ensure watcherBouncing can recreate the classloader of the mojo, 3. potentially add a "manualrefresh" goal which would integrate with run mojo and force a reload *after* the actual resource/classes recompilation/reprocessing to avoid timing issues (can be as simple as creating a file .dirty, if present the reload controller refreshes the context and deletes it - or just tracks the last modified date, something like that) hope it makes sense Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 23 avr. 2020 à 13:12, Arne Limburg <arne.limb...@openknowledge.de> a écrit : > Switching to dev-list... > > It should be easy to implement a (configurable, filewatcher-based) > auto-reload based on that setup, shouldn't it? > > If there is some interest here, I'll take a look into that. > > Wdyt? > > > Cheers, > > Arne > > > OPEN KNOWLEDGE GmbH > Poststraße 1, 26122 Oldenburg > Mobil: +49 151 - 108 22 942 > Tel: +49 441 - 4082-154 > Fax: +49 441 - 4082-111 > arne.limb...@openknowledge.de > www.openknowledge.de <https://www.openknowledge.de/> > > Registergericht: Amtsgericht Oldenburg, HRB 4670 > Geschäftsführer: Lars Röwekamp, Jens Schumann > > Treffen Sie uns auf kommenden Konferenzen und Workshops: > > Zu unseren Events<https://www.openknowledge.de/event/> > > > > > > ________________________________ > Von: Arne Limburg > Gesendet: Donnerstag, 23. April 2020 13:10 > An: u...@openwebbeans.apache.org > Betreff: AW: Meecrowave auto reload > > > OK, thank you, that setup works. > > Cheers, Arne > > ________________________________ > Von: Romain Manni-Bucau <rmannibu...@gmail.com> > Gesendet: Donnerstag, 23. April 2020 12:06:03 > An: u...@openwebbeans.apache.org > Betreff: Re: Meecrowave auto reload > > Hi Arne, > > personally I don't use the polling but this setup: > > 1. configure what the reloading recompile through reloadGoals: > > > <plugin> > <groupId>org.apache.meecrowave</groupId> > <artifactId>meecrowave-maven-plugin</artifactId> > <version>1.2.9</version> > <configuration> > <reloadGoals> > <reloadGoal>process-classes</reloadGoal> > </reloadGoals> > </configuration> > </plugin> > > 2. do the changes you want > 3. go in the terminal meecrowave:bake/meecrowave:run is executed and type > "r" (or "reload" from memory) > 4. test your changes > > It just executes mvn <reload goals> and redeploy the app. > > watcherBouncing was more about static resources (frontend) and should be > combined with <webResourceCached>false</webResourceCached>. > > The watcher on his side watches the deployed folders (target/classes) and > reloads when it changes (which can be too early sometimes depending watcher > duration). > The issue you hit is that target/classes is in the classloader created > once for the runtime in the mojo (since you deploy classpath and not as a > webapp - <useClasspathDeployment>false</useClasspathDeployment>) so you > actually don't reload the classes with just the watcher by default. > > > Romain Manni-Bucau > @rmannibucau<https://twitter.com/rmannibucau> | Blog< > https://rmannibucau.metawerx.net/> |Old Blog< > http://rmannibucau.wordpress.com> | Github<https://github.com/rmannibucau> > |LinkedIn<https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le jeu. 23 avr. 2020 à 11:50, Arne Limburg <arne.limb...@openknowledge.de > <mailto:arne.limb...@openknowledge.de>> a écrit : > > Hi, > > I am fiddling around with the auto-reload feature in meecrowave. > > I have configured the maven plugin to set watcherBouncing to 1 and start > meecrowave with the plugin. > > The log correctly states that target classes is scanned > > OpenWebBeans scanning: > [...] > [11:41:48.738][INFO ][cher-redeployer][ans.OWBTomcatWebScannerService] > [...]/target/classes > > > When I change a class in the deployment, the server correctly does a > redeploy, > > but after the redeploy the content of the changed class seems not to have > changed in the server. > > The class behaves like before. > > Is there some hidden class caching somewhere (in cxf or tomcat or so), > which I have to turn of? > > Any ideas? > > > Cheers, > > Arne >
