Re: Second MNG-6765 ([Regression] tycho pom-less builds fails with 3.6.2)

[Robert Scholte]

Tibor,

you're doing it again. The title of this topic is "Second MNG-6765  
([Regression] tycho pom-less builds fails with 3.6.2)" and none of your  
comments helped on that, i.e. trying to move it forward.
Based on your reply you should a new discussion on the mailinglist.
Robert

ps. I won't make it to ApacheCon this year.


On Sat, 19 Oct 2019 15:48:36 +0200, Tibor Digana <tibordig...@apache.org>  
wrote:

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