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.
Gesendet: Dienstag, 21. Januar 2020 um 12:10 Uhr
Von: "Mickael Istria" <mistria@xxxxxxxxxx>
An: "Eclipse platform general developers list." <platform-dev@xxxxxxxxxxx>
Betreff: Re: [platform-dev] Marking nested projects as derived, what are the risks?
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@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
