[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-user
Subject:    Re: Local repository accessed by multiple Maven instances - how is it solved ?
From:       Delany <delany.middleton () gmail ! com>
Date:       2021-10-08 8:05:21
Message-ID: CAO2uShz=qzz1Q6apunwSapnunZPhOFXw0GorrFkYqm7K_60bvg () mail ! gmail ! com
[Download RAW message or body]


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 <tamas@cservenak.net> 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 <delany.middleton@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 <michaelo@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 <michaelo@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 <
> > ecki@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-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: users-help@maven.apache.org
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>


[prev in list] [next in list] [prev in thread] [next in thread]