Re: [platform-dev] Marking nested projects as derived, what are the risks?

2020-01-22 Thread Alexander Fedorov 

Hello,

-1 for setting derived=true for nested resources as consequences are 
unpredictable.


There is a set of API calls like:
IWorkspaceRoot.findContainersForLocationURI(URI)
IWorkspaceRoot.findFilesForLocationURI(URI)

I'm using it for complex IDE scenarios to understand about possible 
resource duplication and I believe they may be used to implement UI 
filtering for nested resources as well.


Regards,
AF

22.01.2020 12:30, Andrey Loskutov пишет:
Mickael, Resources API is not about UI. "*Hidden resources are 
invisible to most clients" *means almost all clients will never get 
hidden resources at all in almost all "usual" Resources API calls.
So this is NOT the API you want. There is NO API for what do you want 
to achieve, therefore you need new API if you want to "hide" nested 
resources in "some" places where nested resources are not supposed to 
be shown.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
*Gesendet:* Mittwoch, 22. Januar 2020 um 10:23 Uhr
*Von:* "Mickael Istria" 
*An:* "Eclipse platform general developers list." 

*Betreff:* Re: [platform-dev] Marking nested projects as derived, what 
are the risks?
On Wed, Jan 22, 2020 at 10:04 AM Andrey Loskutov > wrote:


I fully agree with Tom.
In one of the my answers I've already suggested to think about
something like boolean IResource::isNested() API.

If we do that, then we need to change all clients to read this new 
state. I'm really looking for something that would work without having 
to rewrite a navigators and resource lists.


 Regarding isHidden() question: *NO*.
As javadoc on setHidden() says: *Hidden resources are invisible to
most clients.*

The resource API does return those resources, so programmatically, 
they're visible.
What I'm unsure is what's meant by invisible and from which 
perspective. To my understanding, hiding is visual and it's a UI hint, 
it's exactly what I'm looking for then if I don't want folders for 
nested subprojects to leak in UI.
___ platform-dev mailing 
list platform-dev@eclipse.org To change your delivery options, 
retrieve your password, or unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev


___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Mass changes again

2020-01-22 Thread Aleksandar Kurtakov 
On Wed, Jan 22, 2020 at 1:29 PM Lakshmi P Shanmugam 
wrote:

> > Mac and Windows builds are unstable for probably a year now (or even
> more!).
> The Mac and Windows builds are stable. But, the tests in e4.ui.tests and
> ui.tests.* have been failing, many of them for several releases. It should
> be investigated if the tests are unstable.
>

We can go into semantic analysis of what stable means of course :) but the
simple fact is I go to
https://download.eclipse.org/eclipse/downloads/drops4/I20200121-2225/ and I
claim all unstable (until looking into the tests themselves). And I know
many would not do that.


>
> Kalyan has been opening bugs for the failing tests and investigating many
> of them. Bug numbers for all failing tests in 4.15M1 are in comment
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=558953#c7. Component owners
> or people familiar with the affected areas need to investigate the failing
> tests to see if they are real problems in the code.
>
> Since these long failing ones affect developers from seeing new failures,
> they could disable the tests for the failing platform and open a bug for
> tracking and investigation.
>

If this is the best path forward I recommend anyone that cares about these
platforms to step up and do it.


> We did this in 4.14 for the 2 SWT tests that were failing for a long time
> on the Mac test machine.
>
> Thanks & Regards,
> Lakshmi P Shanmugam,
> Eclipse Platform Co-lead,
> India Software Lab, Bangalore
>
>
>
> - Original message -
> From: Aleksandar Kurtakov 
> Sent by: platform-dev-boun...@eclipse.org
> To: "Eclipse platform general developers list." 
> Cc:
> Subject: [EXTERNAL] Re: [platform-dev] Mass changes again
> Date: Tue, Jan 21, 2020 2:42 PM
>
>
>
> On Tue, Jan 21, 2020 at 10:46 AM Andrey Loskutov  wrote:
>
> Hi,
>
> we had numerous regressions in two last builds, I've opened
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559352
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559353
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559355
>
> And I guess there are more, we just don't see them because our test
> coverage is not the best.
>
> I don't know why should we continue this practice of blind "mass changes"
> for no good reason, that caused so many regressions so far.
>
> My best example of such regression, on which I've spent a full work week
> of my time, was https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147.
>
> I'm tired to spend my time to do house keeping for others, and I don't see
> anyone else doing this work. I don't think this is fair.
>
> I would propose that committers that merge "mass changes" *must* do the
> work I do:
>
> 1) Check SDK build results after integration of mass changes and identify
> new failures
> 2) Report bugs for new failures
> 3) Identify offending commits and notify authors
>
> If this sounds as too much work, I would propose to re-think the "benefit"
> of mass changes.
> If we continue in the same way as today, at some point in time the code is
> "fully optimized" but Eclipse is not usable anymore.
>
>
> This actually brings one very significant problem - Mac and Windows builds
> are unstable for probably a year now (or even more!). This is long enough
> period for contributors to gain the habbit of just ignoring test results on
> Mac and Windows. I can't blame anyone for that (thanks Andrey for still
> checking them!).
> IMHO is current failing tests on Mac and Windows tests can't/won't be
> fixed ASAP - these should be run only on Linux so seeing test failure
> finally means there is something to be looked at. As it should have always
> been.
> Lakshmi, Niraj, as you're respective SWT port maintainers and the long
> failing tests are UI related: What is your opinion on this?
>
>
>
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
>
>
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev



-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit

Re: [platform-dev] Mass changes again

2020-01-22 Thread Lakshmi P Shanmugam 
> Mac and Windows builds are unstable for probably a year now (or even more!).
The Mac and Windows builds are stable. But, the tests in e4.ui.tests and ui.tests.* have been failing, many of them for several releases. It should be investigated if the tests are unstable.
 
Kalyan has been opening bugs for the failing tests and investigating many of them. Bug numbers for all failing tests in 4.15M1 are in comment https://bugs.eclipse.org/bugs/show_bug.cgi?id=558953#c7. Component owners or people familiar with the affected areas need to investigate the failing tests to see if they are real problems in the code.
 
Since these long failing ones affect developers from seeing new failures, they could disable the tests for the failing platform and open a bug for tracking and investigation. We did this in 4.14 for the 2 SWT tests that were failing for a long time on the Mac test machine.
 
Thanks & Regards,Lakshmi P Shanmugam,Eclipse Platform Co-lead,India Software Lab, Bangalore
 
 
- Original message -From: Aleksandar Kurtakov Sent by: platform-dev-boun...@eclipse.orgTo: "Eclipse platform general developers list." Cc:Subject: [EXTERNAL] Re: [platform-dev] Mass changes againDate: Tue, Jan 21, 2020 2:42 PM 
  

On Tue, Jan 21, 2020 at 10:46 AM Andrey Loskutov  wrote:
Hi,we had numerous regressions in two last builds, I've openedhttps://bugs.eclipse.org/bugs/show_bug.cgi?id=559352https://bugs.eclipse.org/bugs/show_bug.cgi?id=559353https://bugs.eclipse.org/bugs/show_bug.cgi?id=559355And I guess there are more, we just don't see them because our test coverage is not the best.I don't know why should we continue this practice of blind "mass changes" for no good reason, that caused so many regressions so far.My best example of such regression, on which I've spent a full work week of my time, was https://bugs.eclipse.org/bugs/show_bug.cgi?id=551147.I'm tired to spend my time to do house keeping for others, and I don't see anyone else doing this work. I don't think this is fair.I would propose that committers that merge "mass changes" *must* do the work I do:1) Check SDK build results after integration of mass changes and identify new failures2) Report bugs for new failures3) Identify offending commits and notify authorsIf this sounds as too much work, I would propose to re-think the "benefit" of mass changes.If we continue in the same way as today, at some point in time the code is "fully optimized" but Eclipse is not usable anymore.
 
This actually brings one very significant problem - Mac and Windows builds are unstable for probably a year now (or even more!). This is long enough period for contributors to gain the habbit of just ignoring test results on Mac and Windows. I can't blame anyone for that (thanks Andrey for still checking them!).
IMHO is current failing tests on Mac and Windows tests can't/won't be fixed ASAP - these should be run only on Linux so seeing test failure finally means there is something to be looked at. As it should have always been.
Lakshmi, Niraj, as you're respective SWT port maintainers and the long failing tests are UI related: What is your opinion on this?
 
 
Kind regards,Andrey LoskutovСпасение утопающих - дело рук самих утопающихhttps://www.eclipse.org/user/aloskutov___platform-dev mailing listplatform-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev--
Alexander KurtakovRed Hat Eclipse Team
___platform-dev mailing listplatform-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev
 

___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Marking nested projects as derived, what are the risks?

2020-01-22 Thread Andrey Loskutov 
Mickael, Resources API is not about UI. "Hidden resources are invisible to most clients" means almost all clients will never get hidden resources at all in almost all "usual" Resources API calls.

So this is NOT the API you want. There is NO API for what do you want to achieve, therefore you need new API if you want to "hide" nested resources in "some" places where nested resources are not supposed to be shown.

 

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

 
 

Gesendet: Mittwoch, 22. Januar 2020 um 10:23 Uhr
Von: "Mickael Istria" 
An: "Eclipse platform general developers list." 
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?



 
 


On Wed, Jan 22, 2020 at 10:04 AM Andrey Loskutov  wrote:




I fully agree with Tom.

In one of the my answers I've already suggested to think about something like boolean IResource::isNested() API.




 

If we do that, then we need to change all clients to read this new state. I'm really looking for something that would work without having to rewrite a navigators and resource lists.

 




 Regarding isHidden() question: NO.

As javadoc on setHidden() says: Hidden resources are invisible to most clients.




 

The resource API does return those resources, so programmatically, they're visible.

What I'm unsure is what's meant by invisible and from which perspective. To my understanding, hiding is visual and it's a UI hint, it's exactly what I'm looking for then if I don't want folders for nested subprojects to leak in UI.

 


___ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev



___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Marking nested projects as derived, what are the risks?

2020-01-22 Thread Mickael Istria 
On Wed, Jan 22, 2020 at 10:04 AM Andrey Loskutov  wrote:

> I fully agree with Tom.
> In one of the my answers I've already suggested to think about something
> like boolean IResource::isNested() API.
>

If we do that, then we need to change all clients to read this new state.
I'm really looking for something that would work without having to rewrite
a navigators and resource lists.


>  Regarding isHidden() question: *NO*.
> As javadoc on setHidden() says: *Hidden resources are invisible to most
> clients.*
>

The resource API does return those resources, so programmatically, they're
visible.
What I'm unsure is what's meant by invisible and from which perspective. To
my understanding, hiding is visual and it's a UI hint, it's exactly what
I'm looking for then if I don't want folders for nested subprojects to leak
in UI.
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Marking nested projects as derived, what are the risks?

2020-01-22 Thread Andrey Loskutov 
I fully agree with Tom.

In one of the my answers I've already suggested to think about something like boolean IResource::isNested() API.

 

Regarding isHidden() question: NO.

As javadoc on setHidden() says: Hidden resources are invisible to most clients.

 

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

 
 

Gesendet: Mittwoch, 22. Januar 2020 um 09:52 Uhr
Von: "Tom Schindl" 
An: "Eclipse platform general developers list." 
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?

Hi,
 

I think the only correct solution is to enhance the core API and then adjust all components. Is it a lot of work? yes! But I think it is the only viable long term solution.

 

Tom
 
Von meinem iPhone gesendet

 
Am 22.01.2020 um 09:34 schrieb Mickael Istria :
 




Hi all,

 

So I'm making progress in my thoughts around those issues.

What about hidden resources? To rephrase "Marking folders for nested projects as hidden, what are the risks?"

 

I'm not really sure of what hidden implies under the hood, but the documentation seems pretty flexible in usage. Maybe it's just the exact match for nested projects? m2e has is available as "Experimental", and Till found a few (fixable) issues in https://bugs.eclipse.org/bugs/show_bug.cgi?id=500624#c14 . Before investing more in trying to fix some of those issues, I'd like some other opinions on whether it seems like a good track to follow.

 

Thanks in advance







___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Marking nested projects as derived, what are the risks?

2020-01-22 Thread Tom Schindl 
Hi,

I think the only correct solution is to enhance the core API and then adjust 
all components. Is it a lot of work? yes! But I think it is the only viable 
long term solution.

Tom

Von meinem iPhone gesendet

> Am 22.01.2020 um 09:34 schrieb Mickael Istria :
> 
> 
> Hi all,
> 
> So I'm making progress in my thoughts around those issues.
> What about hidden resources? To rephrase "Marking folders for nested projects 
> as hidden, what are the risks?"
> 
> I'm not really sure of what hidden implies under the hood, but the 
> documentation seems pretty flexible in usage. Maybe it's just the exact match 
> for nested projects? m2e has is available as "Experimental", and Till found a 
> few (fixable) issues in 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=500624#c14 . Before investing 
> more in trying to fix some of those issues, I'd like some other opinions on 
> whether it seems like a good track to follow.
> 
> Thanks in advance
> ___
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev

Re: [platform-dev] Marking nested projects as derived, what are the risks?

2020-01-22 Thread Mickael Istria 
Hi all,

So I'm making progress in my thoughts around those issues.
What about hidden resources? To rephrase "Marking folders for nested
projects as hidden, what are the risks?"

I'm not really sure of what hidden implies under the hood, but the
documentation seems pretty flexible in usage. Maybe it's just the exact
match for nested projects? m2e has is available as "Experimental", and Till
found a few (fixable) issues in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=500624#c14 . Before investing
more in trying to fix some of those issues, I'd like some other opinions on
whether it seems like a good track to follow.

Thanks in advance
___
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev