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, 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
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
+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
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
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
There are already equivalents, adding yet another "standard" that's
specific to Maven is just like writing yet another logging API IMHO:
javax.annotation.Priorityorg.eclipse.sisu.Priority
javax.annotation.PostConstruct
+1 on Tibor's proposal
На пн, 14.10.2019 г. в 13:03 ч. Tibor Digana
написа:
> 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
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
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
10 matches
Mail list logo
