Robert we suffer from bad design in Maven. There is Jira issue where Maven accepted these annotation maybe because they are so famous and I do not remember if we had any Vote for this significant change. If there was a Vote I would vote -1 and I would explain why. We can talk about it in the conference the next week but gaian I am saying that this feature with these annotations crerated conflicts between Maven and plugins. I doubt that Google Guice is certified by TCK and the Oracle which means that these annotations are a fan of developers but not a container I can trust. Additionally, joining Maven domain with EE domain is like joining Applet with Weld container of EE, the same mess.
On Sat, Oct 19, 2019 at 3:41 PM Robert Scholte <rfscho...@apache.org> wrote: > Tibor, please lower your voice. > You're turning this topic into an unnecessary fight. > We're solving a regression introduced in 3.6.2. > Stuart was able to identify the problem, provide the fix and clearly > explain what happened. > Code has been review, fix is confirmed, so we're good to go. > > So don't hijack this thread and complain by sharing your strong opinions. > They might be related to the code we're touching, but it doesn't help > fixing the issue. > If you want to discuss that, please just start a new topic on the dev-list. > > thanks, > Robert > > On Sat, 19 Oct 2019 15:20:23 +0200, Tibor Digana <tibordig...@apache.org> > > wrote: > > > Stuart, you are wrong. > > It is no more Java SE > > It is JakartaEE ans if you want to obey wrong design of Java SE go for it > > but then Maven would become a mess of Java EE annotations in non-EE > > container. > > Do you understand that @Name represents a key in the container? And how > > can > > you create a string like "core-default"? What's that? I do not know. > > It would be worth to have commercial experiences with Java EE and then > > you > > will understand that this is a big mistake and mess in Maven. > > > > On Sat, Oct 19, 2019 at 2:31 PM Stuart McCulloch <mccu...@gmail.com> > > wrote: > > > >> @Named is not specific to Java EE, it's from JSR 330 which actually > >> targets > >> Java SE (and there are many SE based containers that support it) > >> > >> All @Named does is give a component an identity in the container (think > >> of @Named like the hint in Plexus [1]) so it can be referenced by that > >> name > >> elsewhere. It also means you can inject lists or maps, where the key > is > >> the > >> name, of all component implementations for a given type. This lets > >> plugins > >> and extensions contribute implementations of a core type and core can > >> then > >> see them and choose the right one for the job (such as "file" for a file > >> specific implementation.) > >> > >> Maven historically also supports overriding of components by plugins and > >> extensions, where if you have a component with the same interface (role) > >> and name (hint) then it can override the core component while that > >> plugin > >> is active. This lets plugins customize certain core behaviour in a > >> controlled manner. If we didn't allow overriding then a lot of plugins > >> would fail and Maven would be a lot less flexible. > >> > >> [1] https://wiki.eclipse.org/Sisu/PlexusMigration > >> > >> On Sat, 19 Oct 2019 at 11:58, Tibor Digana <tibordig...@apache.org> > >> wrote: > >> > >> > Are you talking about > >> > @Named( “not-default” ) > >> > @Named( “coreAllowingOverride” ) or @Named( “coreExtensionPoint” )? > >> > > >> > In Java EE (and these annotations are from Java EE application > >> servers) > >> > mean the name of the bean which is unique - it is not a group of > >> beans. > >> > Please notice that beans container is Map<String, Bean> simply > >> speaking. > >> > and therefore here it would mean : > >> > > >> > "core-default" -> singleton instance (DefaultModelProcessor@1234567) > >> > > >> > so this means a conflict because you cannot create: > >> > > >> > "core-default" -> singleton instance (DefaultModelProcessor@1234567) > >> > "core-default" -> singleton instance (DefaultResolver@1234567) > >> > "core-default" -> singleton instance (AnotherBeanType@1234567) > >> > > >> > logical would be to have Expression API from Java EE and: > >> > > >> > "core-default-modelprocessor" -> singleton instance > >> > (DefaultModelProcessor@1234567) > >> > "core-default-resolver" -> singleton instance > >> (DefaultResolver@1234567) > >> > "core-default-xxx" -> singleton instance (AnotherBeanType@1234567) > >> > > >> > > >> > On Sat, Oct 19, 2019 at 12:03 PM Hervé BOUTEMY <herve.bout...@free.fr > > > >> > wrote: > >> > > >> > > +1 > >> > > just added a comment on a typo > >> > > > >> > > for the name of the component, perhaps "core-default", but I won't > >> > > complain > >> > > about any choice: the javadoc is what was really needed > >> > > > >> > > notice: perhaps we have other component that should have the same > >> > > improvement > >> > > to permit overriding in the future > >> > > > >> > > Regards, > >> > > > >> > > Hervé > >> > > > >> > > Le vendredi 18 octobre 2019, 20:04:53 CEST Robert Scholte a écrit : > >> > > > Hi, > >> > > > > >> > > > with the help from Stuart McCulloch we've been able to provide a > >> patch > >> > > for > >> > > > MNG-6765[1] > >> > > > Please review and test. > >> > > > > >> > > > thanks, > >> > > > Robert > >> > > > > >> > > > [1] https://issues.apache.org/jira/browse/MNG-6765 > >> > > > [2] > >> > > > > >> > > > >> > > >> > https://github.com/apache/maven/commit/24e6c0ec0a87b6682513287a23c36db6996b8 > >> > > > 74c [3] > >> > > > > >> > > > >> > > >> > https://github.com/apache/maven/commit/53a70bc8543124569ee787725b2004bc92a68 > >> > > > 1b6 > >> > > > > >> > > > > >> --------------------------------------------------------------------- > >> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> --------------------------------------------------------------------- > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > >> > > > >> > >
