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

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

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

rfscholte
Hi,

the adjusted @Named annotation is on DefaultModelProcessor, not  
DefaultModelBuilder.
They both implement the ModelBuilder interface, but the one that  
extensions like to overwrite is the implementation of DefaultModelBuilder.
So I'd prefer to stick to "core" as proposed my Stuart.

thanks for the confirmation that this works,
Robert

On Fri, 18 Oct 2019 21:10:18 +0200, Jason van Zyl <[hidden email]>  
wrote:

> Hi,
>
> As noted in Slack I think it would be more clear if we used something  
> like
>
> @Named( “allowDefaultOverride” )
>
> vs
>
> @Named( “core” )
>
> As that expresses the intent and can be used anywhere it's allowed for a  
> client to override the default component.
>
> The tests in polyglot all pass with this change, and I’m able to run  
> polyglot example projects again, so I assume the Tycho POM-less are  
> happy again as well but hopefully someone can verify.
>
> Jason
>
>> On Oct 18, 2019, at 2:04 PM, Robert Scholte <[hidden email]>  
>> wrote:
>>
>> 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-67
>> [2]  
>> https://github.com/apache/maven/commit/24e6c0ec0a87b6682513287a23c36db6996b874c
>> [3]  
>> https://github.com/apache/maven/commit/53a70bc8543124569ee787725b2004bc92a681b6
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Stuart McCulloch
@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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

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

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

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