You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@netbeans.apache.org by GitBox <gi...@apache.org> on 2020/11/21 22:04:56 UTC

[GitHub] [netbeans] lkishalmi opened a new pull request #2553: [NETBEANS-4938] TestCase for a SourceGroup bug in Gradle Projects

lkishalmi opened a new pull request #2553:
URL: https://github.com/apache/netbeans/pull/2553

This bug is haunting me for years, and I really need someone looking into it who is expert in the Lookup works. Fortunately it happens usually as an edge case, but I really would like to know what is the issue.

Let's imagine the following situation:
1. I create an empty Gradle project which could be a root project.
2. I open that in NetBeans
3. Later on I decide make a java project out of it by creating some source files and applying the Java plugin
4. The IDE won't show the Java Source Group till it is restarted.

It could happen in a way that the IDE fails to detect the existence of the java plugin, as the heuristics miss that, then when the IDE got the correct information from Gradle. It still not able to show the SourceGroups.

More details later...

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[GitHub] [netbeans] JaroslavTulach commented on pull request #2553: [NETBEANS-4938] TestCase for a SourceGroup bug in Gradle Projects

Posted by GitBox <gi...@apache.org>.

JaroslavTulach commented on pull request #2553:
URL: https://github.com/apache/netbeans/pull/2553#issuecomment-752334389


   > I think I have where the contradiction is.
   > The Project API allows to create some LazyLookupProviders.
   > 
   > https://github.com/apache/netbeans/blob/49f8d408b0ce827692b7dee5d8db8b6236d23ad2/ide/projectapi/src/org/netbeans/modules/projectapi/LazyLookupProviders.java#L66
   > 
   > This is implemented as a ProxyLookup which has the initial `data` as `ImmutableInternalData.EMPTY`.
   > Upon the change of the lookup set we never ask for calling `beforeLookup()` so we never actually initialize the data read from the layer attributes.
   > 
   > @JaroslavTulach I do not know how to resolve this contradiction, as I do not know why is the callBeforeLookup made into an option. What I can do is not to use ProjectServiceProvider, but to register a LookupProvider and place the SourceGroup instance directly into the Lookup. 
   
   Do I get it right that the problem is in the implementation of `@ProjectServiceProvider`? I could get 291eac5 and let the test fail and then try to find out what to change in the project modules to make the test pass. I may take a look, but I haven't written that code, so I am not going to have much advantage.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[GitHub] [netbeans] lkishalmi commented on pull request #2553: [NETBEANS-4938] TestCase for a SourceGroup bug in Gradle Projects

Posted by GitBox <gi...@apache.org>.

lkishalmi commented on pull request #2553:
URL: https://github.com/apache/netbeans/pull/2553#issuecomment-751504093


   After a two days debug session, I've found that the problem is most probably in the Lookup API implementation.
   Whenever the [ProxyLookup.setLookups()](https://github.com/apache/netbeans/blob/e087135bddcea43cea64fba402aa0c156fc0cc1c/platform/openide.util.lookup/src/org/openide/util/lookup/ProxyLookup.java#L183) is called, some listeners on the LookupResult do not get called as the changes in LazyLookups do not get evaluated.
   That boils down to https://github.com/apache/netbeans/blob/e087135bddcea43cea64fba402aa0c156fc0cc1c/platform/openide.util.lookup/src/org/openide/util/lookup/ProxyLookup.java#L684 ```allItems()``` is being called wit a ```callBeforeLookup``` ```false```, changing that to true is an actual solution to the SourceGroup change problem, but it could break other testcases.
   It seems the template evaluation would happen at https://github.com/apache/netbeans/blob/e087135bddcea43cea64fba402aa0c156fc0cc1c/platform/openide.util.lookup/src/org/openide/util/lookup/ProxyLookup.java#L734
   without that the next call of initResults() would end up with some unevaluated cached result at 
   https://github.com/apache/netbeans/blob/e087135bddcea43cea64fba402aa0c156fc0cc1c/platform/openide.util.lookup/src/org/openide/util/lookup/ProxyLookup.java#L440


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[GitHub] [netbeans] lkishalmi commented on pull request #2553: [NETBEANS-4938] TestCase for a SourceGroup bug in Gradle Projects

Posted by GitBox <gi...@apache.org>.

lkishalmi commented on pull request #2553:
URL: https://github.com/apache/netbeans/pull/2553#issuecomment-752660231

> Do I get it right that the problem is in the implementation of @ProjectServiceProvider? I could get 291eac5 and let the test fail and then try to find out what to change in the project modules to make the test pass. I may take a look, but I haven't written that code, so I am not going to have much advantage.

Yes, that's the case. If you get that commit the ```org.netbeans.modules.gradle.java.classpath.GradleSourcesImplTest,testSourceProviderChange()``` testcase will fail.

Well, it is either the ProjectServiceProvider's Lazy Lookup is wrong or the ProxyLookup does. The LazyLookup might wrongly assume that the beforeLookup() would be called in every case when it's content being queried, or the ProxyLookup does not fullfill that contract in every case.

It worked so far well in NetBeans as the dynamic nature of ProxyLookup was rarely used. So if plugins register ProjectServiceProvider on the main project type. then it works as initially the LazyLookups on some code path got initialized.

Maven Plugin has a dynamic nature based on the packaging type, so services can be registered on war, osgi, and jar packaging type explicitly. There are only a few, maybe less than 5, such registration occurs in the codebase. They are not used by mergers, and eventually get initialized on some other code paths (I haven't explored them deeply though.)

Gradle Support is a bit different, as planned to allow plugin based ProjectServiceProvider registration. So simple aggregator root project of a multi-project build would not have all the Java bells and whistles in its lookup. But the most common use case is when the user opens a project in NetBeans, that time it is only some heuristics used in order to avoid the immediate turn to Gradle. Heuristic can go wrong in some cases, failing to assume some plugins. After a priming build the project lookup needs to be updated...

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[GitHub] [netbeans] lkishalmi merged pull request #2553: [NETBEANS-4938] TestCase for a SourceGroup bug in Gradle Projects

Posted by GitBox <gi...@apache.org>.

lkishalmi merged pull request #2553:
URL: https://github.com/apache/netbeans/pull/2553


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

[GitHub] [netbeans] lkishalmi commented on pull request #2553: [NETBEANS-4938] TestCase for a SourceGroup bug in Gradle Projects

Posted by GitBox <gi...@apache.org>.

lkishalmi commented on pull request #2553:
URL: https://github.com/apache/netbeans/pull/2553#issuecomment-752138306

I think I have where the contradiction is.
The Project API allows to create some LazyLookupProviders.
https://github.com/apache/netbeans/blob/49f8d408b0ce827692b7dee5d8db8b6236d23ad2/ide/projectapi/src/org/netbeans/modules/projectapi/LazyLookupProviders.java#L66
This is implemented as a ProxyLookup which has the initial ```data``` as ```ImmutableInternalData.EMPTY```.
Upon the change of the lookup set we never ask for calling ```beforeLookup()``` so we never actually initialize the data read from the layer attributes.

@JaroslavTulach I do not know how to resolve this contradiction, as I do not know why is the callBeforeLookup made into an option. What I can do is not to use ProjectServiceProvider, but to register a LookupProvider and place the SourceGroup instance directly into the Lookup. Actually it might be a safer bet to create direct instances of all merge-able project services at least, but then all project services.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists