Marking nested projects as derived, what are the risks?

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

Marking nested projects as derived, what are the risks?

Mickael Istria-5
Hi all,

In m2e, BuildShip or even for the Open Resources and other views, one issue appears often: duplication of resources in visible area, confusing users.
Eclipse Platform has the idea of "derived" resources which are well integrated in several views/dialogs so they can be hidden. So I'm curious about what would be the impact of marking nested projects as derived? Let's say I have A and A/B imported as projects in workspace, what bad things could happen if the B folder inside A is marked as derived when A/B is here?
Is the derived flag affecting some core stuff or only UI?
Would it be do-able to have a property to control whether to automatically mark such folders as derived when they're nested project, and let users manage it or is it too much risk...?

Thanks in advance for your insights.
--
Mickael Istria
Eclipse IDE developer, for Red Hat Developers

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Andrey Loskutov
No, please don't do that!
 
I think the javadoc of IResource.setDerived explains why:
 
##########

derived resource is a regular file or folder that is created in the course of translating, compiling, copying, or otherwise processing other files. Derived resources are not original data, and can be recreated from other resources. It is commonplace to exclude derived resources from version and configuration management because they would otherwise clutter the team repository with version of these ever-changing files as each user regenerates them.

If a resource or any of its ancestors is marked as derived, a team provider should assume that the resource is not under version and configuration management by default. That is, the resource should only be stored in a team repository if the user explicitly indicates that this resource is worth saving.

Newly-created resources are not marked as derived; rather, the mark must be set explicitly using setDerived(true, IProgressMonitor). Derived marks are maintained in the in-memory resource tree, and are discarded when the resources are deleted. Derived marks are saved to disk when a project is closed, or when the workspace is saved.

Projects and the workspace root are never considered derived; attempts to mark them as derived are ignored.

##########
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Dienstag, 21. Januar 2020 um 10:39 Uhr
Von: "Mickael Istria" <[hidden email]>
An: "Eclipse platform general developers list." <[hidden email]>
Betreff: [platform-dev] Marking nested projects as derived, what are the risks?
Hi all,
 
In m2e, BuildShip or even for the Open Resources and other views, one issue appears often: duplication of resources in visible area, confusing users.
Eclipse Platform has the idea of "derived" resources which are well integrated in several views/dialogs so they can be hidden. So I'm curious about what would be the impact of marking nested projects as derived? Let's say I have A and A/B imported as projects in workspace, what bad things could happen if the B folder inside A is marked as derived when A/B is here?
Is the derived flag affecting some core stuff or only UI?
Would it be do-able to have a property to control whether to automatically mark such folders as derived when they're nested project, and let users manage it or is it too much risk...?
 
Thanks in advance for your insights.
--
Mickael Istria
Eclipse IDE developer, for Red Hat Developers
_______________________________________________ platform-dev mailing list [hidden email] 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Mickael Istria-5
Thanks Andrey. I actually tried that first to validate SCM integration isn't really an issue
1. Create or import a project
2. Pick a folder (that will be turned into a project later, so it's good if it's a project), mark is a derived
3. Try to edit a File
   => Got a pop-up "this file is derived, do you want to edit it?", which is actually a good thingz
   => Got EGit staging the file anyway (EGit prefers trusting the .gitignore) and mark the file and folder as modified
4. Open the folder as project
5. Edit another file
   => Everything file
   => EGit stages the change and marks the file and folder as modified

So to me, this workflow looks totally desirable for cases of nested projects: it warns users when editing the "non-leaf" duplicate resource, it still makes EGit works well, it hides duplicated resources in many views...

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Daniel Megert
In reply to this post by Andrey Loskutov
> No, please don't do that!

+1

Dani



From:        "Andrey Loskutov" <[hidden email]>
To:        [hidden email]
Date:        21.01.2020 10:53
Subject:        [EXTERNAL] Re: [platform-dev] Marking nested projects as derived, what are the risks?
Sent by:        [hidden email]




No, please don't do that!
 
I think the javadoc of IResource.setDerived explains why:
 
##########
A derived resource is a regular file or folder that is created in the course of translating, compiling, copying, or otherwise processing other files. Derived resources are not original data, and can be recreated from other resources. It is commonplace to exclude derived resources from version and configuration management because they would otherwise clutter the team repository with version of these ever-changing files as each user regenerates them.
If a resource or any of its ancestors is marked as derived, a team provider should assume that the resource is not under version and configuration management by default. That is, the resource should only be stored in a team repository if the user explicitly indicates that this resource is worth saving.
Newly-created resources are not marked as derived; rather, the mark must be set explicitly using setDerived(true, IProgressMonitor). Derived marks are maintained in the in-memory resource tree, and are discarded when the resources are deleted. Derived marks are saved to disk when a project is closed, or when the workspace is saved.
Projects and the workspace root are never considered derived; attempts to mark them as derived are ignored.
##########
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Dienstag, 21. Januar 2020 um 10:39 Uhr
Von:
"Mickael Istria" <[hidden email]>
An:
"Eclipse platform general developers list." <[hidden email]>
Betreff:
[platform-dev] Marking nested projects as derived, what are the risks?

Hi all,
 
In m2e, BuildShip or even for the Open Resources and other views, one issue appears often: duplication of resources in visible area, confusing users.
The m2e issue about it is https://bugs.eclipse.org/bugs/show_bug.cgi?id=500624.
Eclipse Platform has the idea of "derived" resources which are well integrated in several views/dialogs so they can be hidden. So I'm curious about what would be the impact of marking nested projects as derived? Let's say I have A and A/B imported as projects in workspace, what bad things could happen if the B folder inside A is marked as derived when A/B is here?
Is the derived flag affecting some core stuff or only UI?
Would it be do-able to have a property to control whether to automatically mark such folders as derived when they're nested project, and let users manage it or is it too much risk...?
 
Thanks in advance for your insights.
--
Mickael Istria
Eclipse IDE developer, for Red Hat Developers
_______________________________________________ platform-dev mailing list [hidden email] 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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Mickael Istria-5
On Tue, Jan 21, 2020 at 11:24 AM Daniel Megert <[hidden email]> wrote:
> No, please don't do that!

+1

Can you please explain why this shouldn't be done in your opinion?

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Daniel Megert
The Javadoc says it all.

Dani



From:        Mickael Istria <[hidden email]>
To:        "Eclipse platform general developers list." <[hidden email]>
Date:        21.01.2020 11:28
Subject:        [EXTERNAL] Re: [platform-dev] Marking nested projects as derived,        what are the risks?
Sent by:        [hidden email]




On Tue, Jan 21, 2020 at 11:24 AM Daniel Megert <daniel_megert@...> wrote:
> No, please don't do that!

+1


Can you please explain why this shouldn't be done in your opinion?_______________________________________________
platform-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Mickael Istria-5
On Tue, Jan 21, 2020 at 11:34 AM Daniel Megert <[hidden email]> wrote:
The Javadoc says it all.

My experiment shows the Javadoc isn't really accurate in practice with EGit.
Also, with the proposal:
* "Derived resources are not original data, and can be recreated from other resources." is true as the duplicate in nested project can be perceived as the original data
* "a team provider should assume that the resource is not under version and configuration management by default. That is, the resource should only be stored in a team repository if the user explicitly indicates that this resource is worth saving." it's the case if user explicitly says the resource is worth saving in the parent project (moreover, EGit ignores that apparently as it prefers the .gitignore)

I do not fully see the Javadoc as being against that change, and my experiment seems to confirm that the proposal of marking nested project folders as derived seems to fit int the main invariants enforced by the javadoc.

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Daniel Megert
That's a very limited experiment.

What happens if I delete all derived resources?

Dani



From:        Mickael Istria <[hidden email]>
To:        "Eclipse platform general developers list." <[hidden email]>
Date:        21.01.2020 11:47
Subject:        [EXTERNAL] Re: [platform-dev] Marking nested projects as derived,        what are the risks?
Sent by:        [hidden email]




On Tue, Jan 21, 2020 at 11:34 AM Daniel Megert <daniel_megert@...> wrote:
The Javadoc says it all.

My experiment shows the Javadoc isn't really accurate in practice with EGit.
Also, with the proposal:
* "Derived resources are not original data, and can be recreated from other resources." is true as the duplicate in nested project can be perceived as the original data
* "a team provider should assume that the resource is not under version and configuration management by default. That is, the resource should only be stored in a team repository if the user explicitly indicates that this resource is worth saving." it's the case if user explicitly says the resource is worth saving in the parent project (moreover, EGit ignores that apparently as it prefers the .gitignore)

I do not fully see the Javadoc as being against that change, and my experiment seems to confirm that the proposal of marking nested project folders as derived seems to fit int the main invariants enforced by the javadoc._______________________________________________
platform-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Mickael Istria-5


On Tue, Jan 21, 2020 at 12:03 PM Daniel Megert <[hidden email]> wrote:
That's a very limited experiment.

I imagine It's the 90% of use-cases experiment.

What happens if I delete all derived resources?

Removing resources is already a tricky case in current state with duplication (duplicated resources are still listed although their backend filesystem doesn't exist any more, resulting in erased editor content or editor suddenly marked as dirty and not able to save properly...). I don't get how deleting a derived resource would be any different. Which area do you specifically have in mind that could become more faulty?

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Daniel Megert
> I imagine It's the 90% of use-cases experiment.
Here I completely disagree. You have no clue what people do with derived resources.

As per the Javadoc a builder or something else must be capable to bring back the deleted stuff. If there are already issues with nested projects then this is a different case and not reason/excuse to use the derived state.

Dani



From:        Mickael Istria <[hidden email]>
To:        "Eclipse platform general developers list." <[hidden email]>
Date:        21.01.2020 12:11
Subject:        [EXTERNAL] Re: [platform-dev] Marking nested projects as derived,        what are the risks?
Sent by:        [hidden email]






On Tue, Jan 21, 2020 at 12:03 PM Daniel Megert <daniel_megert@...> wrote:
That's a very limited experiment.

I imagine It's the 90% of use-cases experiment.

What happens if I delete all derived resources?

Removing resources is already a tricky case in current state with duplication (duplicated resources are still listed although their backend filesystem doesn't exist any more, resulting in erased editor content or editor suddenly marked as dirty and not able to save properly...). I don't get how deleting a derived resource would be any different. Which area do you specifically have in mind that could become more faulty?_______________________________________________
platform-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Andrey Loskutov
In reply to this post by Mickael Istria-5
Beside the javadoc that explains a lot, "derived" is used to determine if the files are "throw away" candidates.
 
So from the Eclipse code point of view it is:
 
- "safe" to delete all derived resources (they can be recreated from sources)
- uninteresting to search in derived resources (they are not "sources")
- don't care during refactoring (they are not "sources")
- don't care during move/delete (they are not "sources")
- OK to add them to "ignored" for team operations (they are not "sources")
 
Look in SDK who uses isDerived() - you will find ~150 matches, with ~50 for setDerived().
EGit *for sure* will be broken in few places if isDerived() will report true for regular projects / resources. Just grep the code for the use of isDerived().
All builders (and build related code) will most likely affected, all version control contributions, many generators etc.
CDT, XText, EGit, ECore are relying on that flag to be properly managed. *Our* Advantest product relies on that.
 
So with the proposal to mark nested resources as "derived" all the code above will be fooled sooner or later.
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Dienstag, 21. Januar 2020 um 12:10 Uhr
Von: "Mickael Istria" <[hidden email]>
An: "Eclipse platform general developers list." <[hidden email]>
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?
 
 
On Tue, Jan 21, 2020 at 12:03 PM Daniel Megert <[hidden email]> wrote:
That's a very limited experiment.
 
I imagine It's the 90% of use-cases experiment.
 
What happens if I delete all derived resources?
 
Removing resources is already a tricky case in current state with duplication (duplicated resources are still listed although their backend filesystem doesn't exist any more, resulting in erased editor content or editor suddenly marked as dirty and not able to save properly...). I don't get how deleting a derived resource would be any different. Which area do you specifically have in mind that could become more faulty?
_______________________________________________ platform-dev mailing list [hidden email] 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Andrey Loskutov
In reply to this post by Mickael Istria-5
Mickael, I wonder if for your your use case you want something like:
 
IResource::boolean isNested()
 
API, that would return true if the resource is located in the project that is located inside any other project in the workspace.
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Dienstag, 21. Januar 2020 um 11:46 Uhr
Von: "Mickael Istria" <[hidden email]>
An: "Eclipse platform general developers list." <[hidden email]>
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?
On Tue, Jan 21, 2020 at 11:34 AM Daniel Megert <[hidden email]> wrote:
The Javadoc says it all.
 
My experiment shows the Javadoc isn't really accurate in practice with EGit.
Also, with the proposal:
* "Derived resources are not original data, and can be recreated from other resources." is true as the duplicate in nested project can be perceived as the original data
* "a team provider should assume that the resource is not under version and configuration management by default. That is, the resource should only be stored in a team repository if the user explicitly indicates that this resource is worth saving." it's the case if user explicitly says the resource is worth saving in the parent project (moreover, EGit ignores that apparently as it prefers the .gitignore)
 
I do not fully see the Javadoc as being against that change, and my experiment seems to confirm that the proposal of marking nested project folders as derived seems to fit int the main invariants enforced by the javadoc.
_______________________________________________ platform-dev mailing list [hidden email] 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Mickael Istria-5
In reply to this post by Mickael Istria-5
Thanks Andrey and Dani for the solid arguments. I think I have to give up on this idea then.

But that brings me to another question that could help improving some use-cases: if we have project A and its nested project B in A/B, and there is a folder A/B/C (which is duplicated as B/C in A, and as C in B). If C is marked as derived in *any* of the duplicates, shouldn't it automatically be marked as derived in all of them?

_______________________________________________
platform-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Andrey Loskutov
Hi Mickael,
 
This is tricky and shows limits of "nested" feature.
 
The "derived" is usually maintained by the builders / generators, that are always project specific.
 
So builder X in project B doesn't know anything (and should not) about project A.
Therefore if it sets "derived" flag on C only.
 
So the "system" (in this case resources framework) should know better and set the same flag on all re-incarnations of C in all projects.
Assume now that we also have A/B/D, and D is "derived" in project A, because project A has builder that builds D. Following the logic above we should also set "derived" on B/D in project B.
 
This means, in setDerived() for every resource (not only for resources that are "nested") we must compute set of projects containing this resource. This is probably doable, but not sure how fast/slow it could be (we have also linked and virtual resources). This can seriously affect performance of setDerived().
 
More interesting will be, that the setDerived() changes on one project will require now resource locks taken/events sent on/to *other* projects.
 
This may affect all client code that sets resource locks per-project / resource (all properly implemented resource operations), but the underlined code will now "touch" seemingly "unrelated" resources, causing "nested rule errors" or eventually deadlocks?
 
This means, that if we do implement such "derived" propagation, we must perform it asynchronous to the original call, which will open a door for inconsistent resource states (C in B will be already derived but B/C in A will be seen as derived later). Not sure if this is something we can/should allow.
 
Kind regards,
Andrey Loskutov

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

https://www.eclipse.org/user/aloskutov
 
 
Gesendet: Dienstag, 21. Januar 2020 um 13:22 Uhr
Von: "Mickael Istria" <[hidden email]>
An: "Eclipse platform general developers list." <[hidden email]>
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?
Thanks Andrey and Dani for the solid arguments. I think I have to give up on this idea then.
 
But that brings me to another question that could help improving some use-cases: if we have project A and its nested project B in A/B, and there is a folder A/B/C (which is duplicated as B/C in A, and as C in B). If C is marked as derived in *any* of the duplicates, shouldn't it automatically be marked as derived in all of them?
_______________________________________________ platform-dev mailing list [hidden email] 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Mickael Istria-5
In reply to this post by Mickael Istria-5
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Tom Schindl-2
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 <[hidden email]>:


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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

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" <[hidden email]>
An: "Eclipse platform general developers list." <[hidden email]>
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 <[hidden email]>:
 

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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

Mickael Istria-5


On Wed, Jan 22, 2020 at 10:04 AM Andrey Loskutov <[hidden email]> 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

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" <[hidden email]>
An: "Eclipse platform general developers list." <[hidden email]>
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?
 
 
On Wed, Jan 22, 2020 at 10:04 AM Andrey Loskutov <[hidden email]> 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 [hidden email] 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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
Reply | Threaded
Open this post in threaded view
|

Re: Marking nested projects as derived, what are the risks?

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" [hidden email]
An: "Eclipse platform general developers list." [hidden email]
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?
 
 
On Wed, Jan 22, 2020 at 10:04 AM Andrey Loskutov <[hidden email]> 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 [hidden email] 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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev