Romain, The discussion is mainly about conflicts between Maven and user plugins. This can be fixed by either: 1. removing javax.inject from Guice and/or using another container with reduced dependencies, or 2. ClassLoader level
I wrote a container in my company and wrote a test framework using beans, Proxy, DI and IoC, transaction boundaries. Not that difficult at all. On Mon, Oct 14, 2019 at 1:56 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Did you investigate the isolation between IoC beans and mojos? the IoC > beans can see the maven/lib/jsr-whatever.jar whereas mojos can't see it - > they dont use it - but can inject the beans. > Mojo have a dedicated API so only issue is for the IoC so I guess it would > make everyone happy to get the best of both worlds, no? > > 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 lun. 14 oct. 2019 à 13:42, Olivier Lamy <ol...@apache.org> a écrit : > > > +1 > > I definitely agree with Stuart, This is a very simple API with a minimum > of > > interfaces and used a lot. > > I guess we already did such mistake with Maven2 and Plexus :) > > So it's only a matter of not replay history. > > Who really wants to have to maintain another already existing library > > whereas we already need people for what we have now. > > > > On Mon, 14 Oct 2019 at 21:37, Stuart McCulloch <mccu...@gmail.com> > wrote: > > > > > Sorry, but why would you want to write your own version of javax.inject > > > which is a very small static API supported by many injection systems, > > both > > > EE and non-EE > > > > > > It means you can't inject components written outside of Maven unless > you > > > write adapters or manually construct them. > > > > > > It also means that someone who wants to write an injectable component > for > > > Maven and re-use it elsewhere (such as with Spring) now needs to write > > two > > > versions. > > > > > > You'll spend a lot of time and end up with duplicate APIs for doing > > exactly > > > the same thing, when you could have just bumped the JSR-250 version and > > > moved on. > > > > > > On Mon, 14 Oct 2019 at 12:22, Tibor Digana <tibordig...@apache.org> > > wrote: > > > > > > > It would not be finally the same/identical list of annotations. > > > > We do not have to copy everything, as for instance we do not have to > > copy > > > > descriptive methods, names of annotations, packages. > > > > So custom annotations means that: > > > > + we have all responsibility in our hands > > > > + we do not have to rely on dead Java EE annotations > > > > + we can add new annottaions tailored to our Maven domain (not EE > > domain) > > > > > > > > We can erase some annotations, e.g.: > > > > 1. https://docs.oracle.com/javaee/6/api/javax/inject/Named.html - > not > > > sure > > > > if we use expressions with @Named beans > > > > instead maybe we meant something like @javax.annotation.ManagedBean > but > > > it > > > > is only my guess because @Named is useless without using expressions > in > > > the > > > > code (not in POM). > > > > 2. we can erase > > > > https://docs.oracle.com/javaee/6/api/javax/inject/Scope.html > > > > because we do not have e.g. HTTP Session, Conversation scope and Html > > > > forms, we do not have Request Sope because we have our own lifecycle > > with > > > > phases. So again not very compatible with Maven domain. Usually we > have > > > > singletones and I have never seen scope of liveness of the bean > > instances > > > > in Maven. Maybe we would need to have a range of phases in the future > > > where > > > > the bean would be valid (from compile to process-classes) even in the > > > > parallel Maven -T 2C, maybe. > > > > > > > > It's good that we have tried to adopt annotations from different > domain > > > and > > > > IMHO the MNG-6084 is the experience that we should not repeat and > > should > > > > not again adopt foreign annotations (as here in non-EE container) > from > > > > non-Maven domains. > > > > > > > > > > > > On Mon, Oct 14, 2019 at 12:43 PM Stuart McCulloch <mccu...@gmail.com > > > > > > wrote: > > > > > > > > > There are already equivalents, adding yet another "standard" that's > > > > > specific to Maven is just like writing yet another logging API > IMHO: > > > > > > > > > > javax.annotation.Priority > > > org.eclipse.sisu.Priority > > > > > > > > > > javax.annotation.PostConstruct > > > > > > > org.codehaus.plexus.personality.plexus.lifecycle.phase.Initializable > > > > > javax.annotation.PreDestroy > > > > > org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable > > > > > > > > > > (these last two are not totally equivalent since the Plexus API > > uses > > > > > interfaces instead of annotations, but they support the same goal) > > > > > > > > > > The container will work with or without JSR-250 on the classpath so > > > this > > > > is > > > > > more about what you want to let plugin component authors to use. If > > > > you're > > > > > happy with them only using Maven specific annotations and having to > > > > > retro-fit or add adapters when they want to use components outside > of > > > > Maven > > > > > that use PostConstruct and PreDestroy then just roll back MNG-6084, > > > > making > > > > > sure to add a release note warning any plugin authors depending on > > this > > > > > feature that they will need to rewrite or adapt their plugins. > > > > > > > > > > Also note that this API is only exposed to plugins, it should _not_ > > be > > > > > leaking onto the build classpath ... if it is then that's a bug. So > > > this > > > > > situation is specific to when a plugin either actively uses a > > > dependency > > > > > that wants a later version of JSR-250 or wants to use that later > > > version > > > > > itself. > > > > > > > > > > Since the JSR-250 API doesn't change much I still think just > bumping > > > the > > > > > version in the distro is the simplest and less disruptive option. > > > > > > > > > > On Mon, 14 Oct 2019 at 11:03, Tibor Digana <tibordig...@apache.org > > > > > > wrote: > > > > > > > > > > > All these annotations are for Java EE containers and application > > > > servers. > > > > > > A clear solution in 4.0 or 5.0 would be to develop our own > > > annotations > > > > > for > > > > > > Maven Domain (not EE domain) within or Java package. > > > > > > > > > > > > This way we would reach: > > > > > > + annotations looking similar to EE annotations > > > > > > + isolation on the package level > > > > > > + the purpose of the annotations would match specific Maven > domain > > > > > > + the JavaDoc would not be EE specific anymore > > > > > > > > > > > > Many coleagues have negative opinion to my proposal but this was > > only > > > > > mine > > > > > > view. > > > > > > > > > > > > On Mon, Oct 14, 2019 at 11:40 AM Stuart McCulloch < > > mccu...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > The JSR-250 API was exposed in > > > > > > > https://issues.apache.org/jira/browse/MNG-6084 > > > > > > > > > > > > > > It provides the @PostConstruct, @PreDestroy, and @Priority > > standard > > > > > > > extension annotations for use by plugin components. > > > > > > > > > > > > > > Isolating that API would affect any plugin components that rely > > on > > > > > > MNG-6084 > > > > > > > - they would then need to revert back to Initializable and > > > Disposable > > > > > > from > > > > > > > the Plexus API (although note that the benefit of using a javax > > API > > > > is > > > > > > that > > > > > > > it makes components more reusable, especially when they come > from > > > > > outside > > > > > > > the Maven ecosystem and just happen to be used in a Maven > > plugin.) > > > > > > > > > > > > > > The best solution would be to either upgrade that dependency - > or > > > > > > > alternatively just expose the @PostConstruct, @PreDestroy, and > > > > > @Priority > > > > > > > annotation types rather than the whole package. > > > > > > > > > > > > > > On Mon, 14 Oct 2019 at 06:01, Romain Manni-Bucau < > > > > > rmannibu...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Guess it just comes from guice or friends and since they dont > > > > support > > > > > > > > recent API it was not upgraded. > > > > > > > > We can upgrade it or just isolate it IMO - but requires some > > > > careness > > > > > > > since > > > > > > > > custom components can use it so needs an evolution to toggle > it > > > > > > probably. > > > > > > > > > > > > > > > > Le lun. 14 oct. 2019 à 03:43, Tibor Digana < > > > tibordig...@apache.org > > > > > > > > > > a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > It is a similar issue to the problem with "javax.inject" > API. > > > > > > > > > What about relocating these two APIs to a package > > > > > "org.apache.maven"? > > > > > > > Any > > > > > > > > > thoughts? > > > > > > > > > > > > > > > > > > On Mon, Oct 14, 2019 at 12:11 AM Petar Tahchiev < > > > > > > paranoia...@gmail.com > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hello guys, > > > > > > > > > > > > > > > > > > > > I just decided to upgrade my build from 3.5.0 to 3.6.2 > last > > > > night > > > > > > > and I > > > > > > > > > > stumbled across multiple problems, latest one being the > > > > following > > > > > > > > > > exception: > > > > > > > > > > > > > > > > > > > > Nested exception is java.lang.NoSuchMethodError: > > > > > > > > > > javax.annotation.Resource.lookup()Ljava/lang/String; > > > > > > > > > > > > > > > > > > > > Seems like maven 3.6.2 comes with jsr-250-api-1.0.jar in > > the > > > > lib/ > > > > > > > > folder > > > > > > > > > > and that seems to cause problems for me because I have > > moneta > > > > in > > > > > my > > > > > > > > > > classpath which brings newer version of jsr250: > > > > > > > > > > > > > > > > > > > > [INFO] --- maven-dependency-plugin:3.1.1:tree > > (default-cli) @ > > > > > > > drmartens > > > > > > > > > --- > > > > > > > > > > [INFO] com.demo:drmartens:war:1.0-SNAPSHOT > > > > > > > > > > [INFO] \- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > com.nemesis.platform:nemesis-platform-core:jar:2.1.67.BUILD-SNAPSHOT:compile > > > > > > > > > > [INFO] \- org.javamoney:moneta:pom:1.3:compile > > > > > > > > > > [INFO] \- > > > > > > > javax.annotation:javax.annotation-api:jar:1.3.2:compile > > > > > > > > > > [INFO] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > So I was able to fix this following this recommendation: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://stackoverflow.com/questions/52607814/how-to-remove-a-maven-lib-jsr250-api-1-0-jar-from-the-plugin-classpath-jetty > > > > > > > > > > using extensions, but I was wondering: why do we need the > > > > JSR250 > > > > > in > > > > > > > the > > > > > > > > > lib > > > > > > > > > > folder? Also why do we need such an old version? > > > > > > > > > > -- > > > > > > > > > > Regards, Petar! > > > > > > > > > > Karlovo, Bulgaria. > > > > > > > > > > --- > > > > > > > > > > Public PGP Key at: > > > > > > > > > > > > > > > > > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > > > > > > > > > > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 > > > C311 > > > > > 0611 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Olivier Lamy > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > >
