Re: [platform-dev] Marking nested projects as derived, what are the risks?
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 <mailto:losku...@gmx.de>> 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] Marking nested projects as derived, what are the risks?
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 <losku...@gmx.de> 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?
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?
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?
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?
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?
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 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?
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" An: "Eclipse platform general developers list." Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks? On Tue, Jan 21, 2020 at 11:34 AM Daniel Megert <daniel_meg...@ch.ibm.com> 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 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?
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" An: "Eclipse platform general developers list." Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks? On Tue, Jan 21, 2020 at 12:03 PM Daniel Megert <daniel_meg...@ch.ibm.com> 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 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?
On Tue, Jan 21, 2020 at 12:03 PM 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 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?
That's a very limited experiment. What happens if I delete all derived resources? Dani From: Mickael Istria To: "Eclipse platform general developers list." Date: 21.01.2020 11:47 Subject:[EXTERNAL] Re: [platform-dev] Marking nested projects as derived, what are the risks? Sent by:platform-dev-boun...@eclipse.org On Tue, Jan 21, 2020 at 11:34 AM 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 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?
On Tue, Jan 21, 2020 at 11:34 AM 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 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?
The Javadoc says it all. Dani From: Mickael Istria To: "Eclipse platform general developers list." Date: 21.01.2020 11:28 Subject:[EXTERNAL] Re: [platform-dev] Marking nested projects as derived, what are the risks? Sent by:platform-dev-boun...@eclipse.org On Tue, Jan 21, 2020 at 11:24 AM 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 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?
> No, please don't do that! +1 Dani From: "Andrey Loskutov" To: platform-dev@eclipse.org Date: 21.01.2020 10:53 Subject: [EXTERNAL] Re: [platform-dev] Marking nested projects as derived, what are the risks? Sent by:platform-dev-boun...@eclipse.org 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" An: "Eclipse platform general developers list." 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 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] Marking nested projects as derived, what are the risks?
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" An: "Eclipse platform general developers list." 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 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
