Re: [POLL] Defaults for Binary to Source Resolution

2020-01-21 Thread Laszlo Kishalmi 
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
ebre...@gmail.com

On January 20, 2020 at 4:19:26 AM CST, Neil C Smith  
wrote:
On Sun, 19 Jan 2020 at 10:25, Matthias Bläsing
 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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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

2020-01-21 Thread Eric Bresie 
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
ebre...@gmail.com
> On January 20, 2020 at 4:19:26 AM CST, Neil C Smith  
> wrote:
> On Sun, 19 Jan 2020 at 10:25, Matthias Bläsing
>  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-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@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

2020-01-20 Thread Neil C Smith 
On Sun, 19 Jan 2020 at 10:25, Matthias Bläsing
 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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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

2020-01-19 Thread Matthias Bläsing 
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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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

2020-01-18 Thread Kai Uwe Pel 

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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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

2020-01-18 Thread Josh Juneau 
Apologies for the late vote.  I vote: switch, enabled

Thanks

Josh Juneau
juneau...@gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=Juneau




On Tue, Jan 14, 2020 at 3: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-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

[POLL] Defaults for Binary to Source Resolution

2020-01-14 Thread 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.

Thank you!



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

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