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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > > 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 <[email protected]> > > > 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 < > [email protected] > > > > > > > > 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 < > > > > [email protected]> > > > > > > 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 < > > [email protected] > > > > > > > > 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 < > > > > > [email protected] > > > > > > > > > > > > > > > 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 >
