Community
Participate
Working Groups
The current design of incremental compilation is such that it involves a 'repair relationships' step which goes through the relationships map and removes any where one of the endpoint handles points to something that does not exist in the model. Currently there is a bug where handles are created for inpath elements that are the target of ITDs (there is no model element for the inpath element). On a subsequent incremental build these phantom handles are discovered and removed. But we want to move to a situation where these handles are allowed - since AJDT can pick them apart and find the right element. This enhancement is to cover incremental support when the relationship map contains these kind of handles.
this is a bit tricky. As well as stopping the repair code from removing relationships involving these handles, we need to be able to identify the types in the handles at some later time than when they were constructed. This is because upon an incremental build that weaves a file from the inpath for the second time, we need to remove existing relationships and replace them with any new ones. Basically this means we encounter phantom handles and need to know which type they are for. Damn shame to spend time reparsing them, hmmm.
ok - I have a workable solution for incremental inpath. Or at least not destroying the relationships. Test and fixes committed - might put this into AJDT too. However, I think there are also shortcomings in the inpath analysis code. I don't think it is doing enough timestamp checking. On a rudimentary test it doesn't seem to notice me deleting a class file from the inpath. Inpath is very different to classpath - for inpath we care about non-structural changes too, and even whitespace changes because it could affect the woven result. This is likely to mean in the short term that we may now leak relationships for inpath elements over time.
initial drop is in AJDT - far from complete.
I'm concerned about the amount of work there is to get general incremental inpath compilation working properly. I've written a testcase for deletion of entries on the inpath - and right now an incremental build does not notice. However, switching from inpath to linked src folders does the right thing and gives the full correct incremental experience. Seems a shame to invest too much effort into inpath incremental when linked src folders works fine. (I'm talking from a build point of view here, not from a markers/navigation point of view) This leaves inpath jar weaving as a case that can't be solved by moving to linked source folders, so I might spend a little time on that next.
unsetting the target field which is currently set for something already released
