Bugzilla – Full Text Bug Listing
| Summary: | [Xtend] Xtend2BuilderParticipant: Make Whiping and Derived Feature Optional | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Christian Dietrich <christian.dietrich.opensource> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | clay, knut.wannheden, mail, sebastian.zarnekow, sven.efftinge |
| Version: | unspecified | Flags: | sebastian.zarnekow:
indigo+
|
| Target Milestone: | SR2 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 353464 | ||
| Bug Blocks: | |||
|
Description
Christian Dietrich
The builder participant does not simply wipe the Xtend folder but uses the information / APIs of the team provider. That is, the SVN plug-in *should* be able to cope with the clean build. Does a clean build lead to deleted .svn meta data? Hi, no the Files are still there, but the plugin and tortoise say that there was a deletion - and not a change/no change after regeneration ~Christian Actually found that the Problematic line regarding the deletion is targetFile.delete(true, progress.newChild(10)); I don't think that this line is problematic per se. The core problem is, that Eclipse does not have the concept of a Clean+Build in the builder life cycle. That is, a clean build is triggered and we do not know whether there will be an a subsequent build or not. Since the contract of Clean says, that any produced artifact and state shall be discarded, we have to remove the file. Note that the file will not be deleted during an incremental build. We have the same problem: Java files generated into xtend-gen are marked as derived (IResource#setDerived()) and can as a result not be checked into the SVN repository using Subversive. As a result of that our Hudson continuous integration job fails as there are Java compilation errors due to missing Java classes. I suppose I could override the Xtend2BuilderParticipant by defining a corresponding binding in an Guice module registered using the overridingGuiceModule extension point. Any other ideas? Since the Xtend2BuilderParticipant is bound in the UI Module of Xtend2 you might not even have a change to change this from outside: we currently work with a patched Xtend2 Ui Bundle ;-( It should be configurable (in the Preferences) whether you want to have the files marked as derived. A patch would be welcome. what about merging this into bug353463 on a per-outlet basis ? (In reply to comment #7) > It should be configurable (in the Preferences) whether you want to have the > files marked as derived. > A patch would be welcome. (In reply to comment #6) > Since the Xtend2BuilderParticipant is bound in the UI Module of Xtend2 you > might not even have a change to change this from outside: we currently work > with a patched Xtend2 Ui Bundle ;-( Correct :-( Apart from the problem with the files being marked as derived I also encountered the problem with clean builds. I think the problem is that a clean will invoke FolderUtil#clearFolder() which deletes the contents of the "xtend-gen" folder. The SVN team provider intercepts this and causes the local file system directory to be marked for deletion in the SVN metadata. When the contained files (and folders) get recreated they don't get matched up with the previous contents, instead they appear as new files. So in addition to an option to mark the created files as derived or not I think we might also need an option to control whether folders in "xtend-gen" should be deleted or not. Quite possibly Git users will encounter similar issues if they use EGit. I suppose it will also treat derived resources differently. Although I don't think it will have issues with deleted and recreated folders. All builders (incl. the one from Xtend) should manage the list of derived resources, such that deleting whole directories is not necessary. So this one depends on Bug #353464 We have sort of a conflict here: The contract of 'clean' is to remove all derived information. A IResource#delete will certainly be propagated to the team provider which will perform the necessary changes, e.g. in the svn meta data. However, a IResource#create in a subsequent build (after clean) will not trigger any action in the team provider and even worse: a manual add of the newly created resource will not revert the previous delete. I'm afraid we have to circumvent this dilemma explicitly by hooking into the team api and undo the delete or something alike. This one is actually scheduled for 2.1 *** This bug has been marked as a duplicate of bug 353463 *** |