Hi Delany, from Sisu website: "Sisu is a modular JSR330-based container that supports *classpath scanning*, *auto-binding*, and *dynamic auto-wiring*. Sisu uses Google-Guice to perform dependency injection and provide the core JSR330 support, but removes the need to write explicit bindings in Guice modules.".
Simply, SISU will scan your classpath for components and dynamically pick them up and wire them up. For Guice, you need to _explicitly add_ bindings (as this "dynamism" is a Sisu feature). ServiceLocator is deprecated, leave it out (but same thing stands: is "static"). === More simpler: with Sisu, just throw a component onto classpath, and Sisu will "automagically" pick it up, no code change needed. This is how extensions and other things work in Maven for example (just copy a JAR with components to classpath and they are discovered). Locking implementations like Redisson and Hazelcast are "opt-in", they are not bundled with Maven (to not bloat distro). They work only after you "install" them (provide JARs with their components and all component dependencies to Maven classpath, as explained in the Install step on that page). This remark you quoted is geared more toward "resolver integrators", for those using Resolver into some other project than Maven. If you integrate Resolver, then: - if you use Sisu, you have nothing to do :) - if you use vanilla Guice, then in your integration you have to provide the things you want on classpath and explicitly bind them - if you use ServiceLocator, move away from it (will be soon dropped), simplest is to "roll your own" bootstrap class (that does same as ServiceLocator was doing, statically wiring things up), and again, you should upfront provide whatever you need on classpath and instantiate them using your own "bootstrap" class. If you just want to use it with Maven, nothing to be done for you, just Install it as per page. === HTH Tamas On Thu, Oct 7, 2021 at 10:07 AM Delany <delany.middle...@gmail.com> wrote: > Michael, could you clarify this line pls: "It only works when Sisu DI is > used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu > dependency injection)." > > https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html > > What should I do about this issue? > > Thanks, > Delany > > > On Wed, 6 Oct 2021 at 22:18, Michael Osipov <micha...@apache.org> wrote: > > > Am 2021-10-06 um 21:05 schrieb Francois Marot: > > > Michael, I do not agree. As a user and maintainer of the build chain in > > my > > > company, I think Maven would really benefit from an out of the box > > > solution. I think any user is susceptible to the bug by launching > > multiple > > > Maven instances at the same time on his computer. Bugs then encountered > > are > > > really a bad sign sent to users, and requiring each dev to setup a > > database > > > (even simple) is cumbersome. > > > > I agree with you, but we are developers after all, I can expect people > > to set up something if necessary. > > At the end you need to consider that file based locking has issues, it > > does not work everywhere, it is advisory at best, it protects you only > > from multiprocess access, multithreaded requires an extra layer of > > in-JVM locks. Given that we are all volunteers and the pain for the > > community isn't big enough to contribute something valuable, I won't. > > Especially that Tamás and me invested almost year developing the named > > locks approach with pluggable providers is more than enough to solve any > > type of build setup on any FS and OS. > > > > I'd like to quote Marshall Kirk McKusick: Why write something good if > > you can steal something better? (trade file locks with Redis). > > > > A more lightweight approach would be something like POSIX semaphores > > available everywhere, but Windows. Requires likely native code or JNR > > and time. Out of personal interest I'd peek at it next year. > > > > M > > > > > Le lun. 4 oct. 2021 à 22:13, Michael Osipov <micha...@apache.org> a > > écrit : > > > > > >> Tamás, > > >> > > >> Redis is so easy to install and get going in 5 minutes that I would > > >> rather see your energy go into areas which need more attention. > > >> > > >> M > > >> > > >> Am 2021-10-04 um 22:02 schrieb Tamás Cservenák: > > >>> Hi Bernd, > > >>> > > >>> nothing is wrong with advisory file locking, as long as you don't > store > > >>> local repo on NFS ;) > > >>> Will re-add file locking once I get there, as in my opinion it is the > > >> most > > >>> "lightweight" MP (multi process) solution on a single host. > > >>> Redis and Hazelcast are more for "farms", where several hosts with > many > > >>> processes (and each with many threads) is bashing local repo (that > MAY > > be > > >>> on NFS as well). > > >>> > > >>> Thanks > > >>> Tamas > > >>> > > >>> On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels < > e...@zusammenkunft.net > > > > > >>> wrote: > > >>> > > >>>> What’s the problem with adivisory locking, as long as Maven honors > the > > >>>> advice it is the same as it’s a redis lock? (But much less > footprint). > > >> In > > >>>> fact on the same machine it should even work without locking as Long > > as > > >> you > > >>>> use pidfiles? > > >>>> > > >>>> Gruss > > >>>> Bernd > > >>>> > > >>>> > > >>> > > >> > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: users-h...@maven.apache.org > > >> > > >> > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
