You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by Petar Tahchiev <pa...@gmail.com> on 2019/10/13 22:10:43 UTC

JSR250 in the lib

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

Re: JSR250 in the lib

Posted by Petar Tahchiev <pa...@gmail.com>.

+1 on Tibor's proposal

На пн, 14.10.2019 г. в 13:03 ч. Tibor Digana <ti...@apache.org>
написа:

> 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 <mc...@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 <rm...@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 <ti...@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 <
> paranoiabla@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
> > > > >
> > > >
> > >
> >
>


-- 
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

Re: JSR250 in the lib

Posted by Robert Scholte <rf...@apache.org>.

Petar,

can you create a JIRA issue[1] for it plus a PR based on the advice of  
Stuart.
You should be able to verify the change for yourself, if upgrading the  
dependency works.

thanks,
Robert

[1] https://issues.apache.org/jira/browse/MNG

On Mon, 14 Oct 2019 13:42:40 +0200, Olivier Lamy <ol...@apache.org> wrote:

> +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 <mc...@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 <ti...@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 <mc...@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 <ti...@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  
>> <mcculls@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 <
>> > > rmannibucau@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 <
>> tibordigana@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 <
>> > > > paranoiabla@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
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: JSR250 in the lib

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Didn't say it was difficult ;)

The point is that we can't revert the fact to use these annotations as
previously explained so we must leave with them and ensure user can use its
own api in mojos, this is why i suggested adding a classloader (like
ClassRealm) doing the dispatching for these API.

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 à 15:04, Tibor Digana <ti...@apache.org> a
écrit :

> 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 <rm...@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 <mc...@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 <ti...@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 <
> mcculls@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 <
> tibordigana@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 <
> > > mcculls@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 <
> > > > > > rmannibucau@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 <
> > > > tibordigana@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 <
> > > > > > > paranoiabla@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
> > >
> >
>

Re: JSR250 in the lib

Posted by Tibor Digana <ti...@apache.org>.

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 <rm...@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 <mc...@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 <ti...@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 <mcculls@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 <tibordigana@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 <
> > mcculls@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 <
> > > > > rmannibucau@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 <
> > > tibordigana@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 <
> > > > > > paranoiabla@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
> >
>

Re: JSR250 in the lib

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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 <mc...@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 <ti...@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 <mc...@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 <ti...@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 <
> mcculls@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 <
> > > > rmannibucau@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 <
> > tibordigana@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 <
> > > > > paranoiabla@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
>

Re: JSR250 in the lib

Posted by Olivier Lamy <ol...@apache.org>.

+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 <mc...@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 <ti...@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 <mc...@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 <ti...@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 <mcculls@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 <
> > > rmannibucau@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 <
> tibordigana@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 <
> > > > paranoiabla@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

Re: JSR250 in the lib

Posted by Stuart McCulloch <mc...@gmail.com>.

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 <ti...@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 <mc...@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 <ti...@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 <mc...@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 <
> > rmannibucau@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 <tibordigana@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 <
> > > paranoiabla@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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: JSR250 in the lib

Posted by Tibor Digana <ti...@apache.org>.

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 <mc...@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 <ti...@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 <mc...@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 <
> rmannibucau@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 <ti...@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 <
> > paranoiabla@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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: JSR250 in the lib

Posted by Stuart McCulloch <mc...@gmail.com>.

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 <ti...@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 <mc...@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 <rm...@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 <ti...@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 <
> paranoiabla@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
> > > > >
> > > >
> > >
> >
>

Re: JSR250 in the lib

Posted by Tibor Digana <ti...@apache.org>.

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 <mc...@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 <rm...@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 <ti...@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 <paranoiabla@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
> > > >
> > >
> >
>

Re: JSR250 in the lib

Posted by Stuart McCulloch <mc...@gmail.com>.

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 <rm...@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 <ti...@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 <pa...@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
> > >
> >
>

Re: JSR250 in the lib

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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 <ti...@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 <pa...@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
> >
>

Re: JSR250 in the lib

Posted by Tibor Digana <ti...@apache.org>.

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 <pa...@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
>