Re: JSR250 in the lib

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: JSR250 in the lib

Stuart McCulloch
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> > 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
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: JSR250 in the lib

rfscholte
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>  
>> 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 <[hidden email]>
>> > 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 <[hidden email]>
>> > 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  
>> <[hidden email]
>> >
>> > > > 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 <
>> > > [hidden email]>
>> > > > > 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 <
>> [hidden email]
>> > >
>> > > 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 <
>> > > > [hidden email]
>> > > > > >
>> > > > > > > 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: [hidden email]
For additional commands, e-mail: [hidden email]