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