Thanks Tamás. Since I use the wrapper, I was thinking there's a case for Maven wrapper variants. But I guess this is what containers are all about anyway. Delany
On Thu, 7 Oct 2021 at 11:32, Tamás Cservenák <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < > > [email protected] > > > > > > > >>> 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: [email protected] > > > >> For additional commands, e-mail: [email protected] > > > >> > > > >> > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
