You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2020/01/14 21:30:28 UTC
[POLL] Defaults for Binary to Source Resolution
Dear all,
Please tell me how the IDE shall be working, regarding
https://issues.apache.org/jira/browse/NETBEANS-3115
Summary: When two otherwise independent Gradle projects has declared
dependency over a released artifact through a repository, shall sources
loaded from the available released sources.jar in the repository, or
shall we try to open the source form the opened project?
Right now the Gradle plugin behaves semantically correct as it is
opening the source from the released source jar file from the local
repository cache. Creating a composite build of these projects could
help. See: https://github.com/apache/netbeans/pull/1861
However I have another implementation which does not need the include
build (as that might be side effects). My question is the following.
Shall the resolving the third party source against opened projects be
the default behavior or shall it be put behind a switch and if it is
behind the switch what shall be the default behavior.
Let me do a poll on this, so reply with the following if you care,:
- enabled
- switch, enabled
- switch, disabled
The poll will be open for at least 3 days.
Thank you!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [POLL] Defaults for Binary to Source Resolution
Posted by Laszlo Kishalmi <la...@gmail.com>.
Whatever comes from the jar is read-only, and that way it's editor tab
is displayed with italic, in some cases the background of the file could
be different as well, though that's theme dependent.
On 1/21/20 10:53 AM, Eric Bresie wrote:
> A small tangent...Does some sort of decoration (I.e maybe path specified, grayed out / colorized, etc.) to distinguish between the project source version and the jar source version occur and if not would that help in some way?
>
> Eric Bresie
> Ebresie@gmail.com
>> On January 20, 2020 at 4:19:26 AM CST, Neil C Smith <ne...@apache.org> wrote:
>> On Sun, 19 Jan 2020 at 10:25, Matthias Bläsing
>> <mb...@doppel-helix.eu> wrote:
>>> I see the Maven implementation as the correct one ... So I would say implement it like describe above for maven is the right
>>> thing to do ... I doubt, that a switch is a good idea,
>> Well, while we're repeating what we said on the PR! ;-) I generally
>> agree with you that the Maven behaviour is the right default. But I'm
>> also potentially in favour of the switch.
>>
>> I don't think you can ignore that Maven and Gradle behave slightly
>> differently here, in particular related to
>> https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:case-for-maven-local
>>
>> The important thing is that the right source opens! One option for
>> the switch might include whether mavenLocal() is set? It's possible
>> to shoot yourself in the foot either way. :-)
>>
>> Best wishes,
>>
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re: [POLL] Defaults for Binary to Source Resolution
Posted by Eric Bresie <eb...@gmail.com>.
A small tangent...Does some sort of decoration (I.e maybe path specified, grayed out / colorized, etc.) to distinguish between the project source version and the jar source version occur and if not would that help in some way?
Eric Bresie
Ebresie@gmail.com
> On January 20, 2020 at 4:19:26 AM CST, Neil C Smith <ne...@apache.org> wrote:
> On Sun, 19 Jan 2020 at 10:25, Matthias Bläsing
> <mb...@doppel-helix.eu> wrote:
> > I see the Maven implementation as the correct one ... So I would say implement it like describe above for maven is the right
> > thing to do ... I doubt, that a switch is a good idea,
>
> Well, while we're repeating what we said on the PR! ;-) I generally
> agree with you that the Maven behaviour is the right default. But I'm
> also potentially in favour of the switch.
>
> I don't think you can ignore that Maven and Gradle behave slightly
> differently here, in particular related to
> https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:case-for-maven-local
>
> The important thing is that the right source opens! One option for
> the switch might include whether mavenLocal() is set? It's possible
> to shoot yourself in the foot either way. :-)
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: [POLL] Defaults for Binary to Source Resolution
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 19 Jan 2020 at 10:25, Matthias Bläsing
<mb...@doppel-helix.eu> wrote:
> I see the Maven implementation as the correct one ... So I would say implement it like describe above for maven is the right
> thing to do ... I doubt, that a switch is a good idea,
Well, while we're repeating what we said on the PR! ;-) I generally
agree with you that the Maven behaviour is the right default. But I'm
also potentially in favour of the switch.
I don't think you can ignore that Maven and Gradle behave slightly
differently here, in particular related to
https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:case-for-maven-local
The important thing is that the right source opens! One option for
the switch might include whether mavenLocal() is set? It's possible
to shoot yourself in the foot either way. :-)
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [POLL] Defaults for Binary to Source Resolution
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
I see the Maven implementation as the correct one (this is a copy of the reasoning in the PR):
--------------
My scenario I tested:
- I create a project `library` (just a `DemoLib` class with a `dummyMethod`)
- I `maven -Prelease-profile install`ed version `1.0`, `2.0` and `3.0-SNAPSHOT`
- I created an application project that depends on library version `3.0-SNAPSHOT`, both projects are open in netbeans
- I invoke "Navigate -> Go to Source" on `demoLib.dummyMethod()`
At this point netbeans takes me to the code in the project that I have open.
- I change the dependency to `2.0`
- I invoke "Navigate -> Go to Source" on `demoLib.dummyMethod()`
At this point the source code of the source jar is opened and shown.
- I checkout version `2.0` of `library`
- I invoke "Navigate -> Go to Source" on `demoLib.dummyMethod()`
At this point I'm taken to the source of the open project.
From my perspective the behavior of the Integration of Maven in
NetBeans in completely sane: If you have the source for a maven
project open _and_ the version of the project matches the version
of the dependency then the project source code is used, else
the source jar is used to show the source.
If you don't do this, you will get misleading results. I once
accidentally chased a bug that I misdiagnosed, because the lines
in the source code did not match the one in the stack trace
because I had the wrong version opened.
IMHO this would be a sane implementation for gradle as well.
And here is the code I used to test:
[TestVersions.zip](https://github.com/apache/netbeans/files/4073228/TestVersions.zip)
--------------
So I would say implement it like describe above for maven is the right
thing to do.
If a different implementation is switched on by default for gradle user
experience will suffer, because behavior of the IDE differes between
project types.
I doubt, that a switch is a good idea, as people tend to not understand
the consequences of their choices and at the end we have to deal with
bugs where people shot themselfes into the their food.
Greetings
Matthias
Am Dienstag, den 14.01.2020, 13:30 -0800 schrieb Laszlo Kishalmi:
> Dear all,
>
> Please tell me how the IDE shall be working, regarding
> https://issues.apache.org/jira/browse/NETBEANS-3115
>
> Summary: When two otherwise independent Gradle projects has declared
> dependency over a released artifact through a repository, shall
> sources
> loaded from the available released sources.jar in the repository, or
> shall we try to open the source form the opened project?
>
> Right now the Gradle plugin behaves semantically correct as it is
> opening the source from the released source jar file from the local
> repository cache. Creating a composite build of these projects could
> help. See: https://github.com/apache/netbeans/pull/1861
>
> However I have another implementation which does not need the
> include
> build (as that might be side effects). My question is the following.
> Shall the resolving the third party source against opened projects
> be
> the default behavior or shall it be put behind a switch and if it is
> behind the switch what shall be the default behavior.
>
> Let me do a poll on this, so reply with the following if you care,:
>
> - enabled
> - switch, enabled
> - switch, disabled
>
>
> The poll will be open for at least 3 days.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [POLL] Defaults for Binary to Source Resolution
Posted by Kai Uwe Pel <ka...@asia.com>.
I prefer as follow:
- switch, enabled
Cheers,
Kai
On 1/14/2020 10:30 PM, Laszlo Kishalmi wrote:
> Dear all,
>
> Please tell me how the IDE shall be working, regarding
> https://issues.apache.org/jira/browse/NETBEANS-3115
>
> Summary: When two otherwise independent Gradle projects has declared
> dependency over a released artifact through a repository, shall
> sources loaded from the available released sources.jar in the
> repository, or shall we try to open the source form the opened project?
>
> Right now the Gradle plugin behaves semantically correct as it is
> opening the source from the released source jar file from the local
> repository cache. Creating a composite build of these projects could
> help. See: https://github.com/apache/netbeans/pull/1861
>
> However I have another implementation which does not need the include
> build (as that might be side effects). My question is the following.
> Shall the resolving the third party source against opened projects be
> the default behavior or shall it be put behind a switch and if it is
> behind the switch what shall be the default behavior.
>
> Let me do a poll on this, so reply with the following if you care,:
>
> - enabled
> - switch, enabled
> - switch, disabled
>
>
> The poll will be open for at least 3 days.
>
> Thank you!
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [POLL] Defaults for Binary to Source Resolution
Posted by Josh Juneau <ju...@gmail.com>.
Apologies for the late vote. I vote: switch, enabled
Thanks
Josh Juneau
juneau001@gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=Juneau
<https://www.apress.com/index.php/author/author/view/id/1866>
On Tue, Jan 14, 2020 at 3:30 PM Laszlo Kishalmi <la...@gmail.com>
wrote:
> Dear all,
>
> Please tell me how the IDE shall be working, regarding
> https://issues.apache.org/jira/browse/NETBEANS-3115
>
> Summary: When two otherwise independent Gradle projects has declared
> dependency over a released artifact through a repository, shall sources
> loaded from the available released sources.jar in the repository, or
> shall we try to open the source form the opened project?
>
> Right now the Gradle plugin behaves semantically correct as it is
> opening the source from the released source jar file from the local
> repository cache. Creating a composite build of these projects could
> help. See: https://github.com/apache/netbeans/pull/1861
>
> However I have another implementation which does not need the include
> build (as that might be side effects). My question is the following.
> Shall the resolving the third party source against opened projects be
> the default behavior or shall it be put behind a switch and if it is
> behind the switch what shall be the default behavior.
>
> Let me do a poll on this, so reply with the following if you care,:
>
> - enabled
> - switch, enabled
> - switch, disabled
>
>
> The poll will be open for at least 3 days.
>
> Thank you!
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>