Community
Participate
Working Groups
Build Identifier: M20090917-0800 I want to exclude certain file path patterns from being added to the context. The "Resource Monitoring Exclusions" list will only exclude the file from the context if an entry in this list exactly matches (actually, I can't find any documentation that says exactly how it does the matching). This really would be more useful if each entry represented an Ant-style path, like "build/**/*.class" or "gen/**/*.java". Reproducible: Always
Shawn, what are your thoughts on that?
I think that this is a very interesting idea and it would provide greater flexibility to be able to setup resource exclusions. The only thing that I would be concerned about is that it can be much more difficult for users to write this type of pattern.
"Much more difficult"? I'd say that's a bit of an exaggeration. A complicated Ant-path pattern is a complicated pattern. At this point, the implemented feature doesn't allow any complicated patterns at all :) , so I think it shouldn't be difficult for people to implement patterns corresponding to the weak substring match that is currently available.
Considering that resource inclusion are an advanced feature I think it's reasonable to support the more powerful ant syntax. We just need to ensure to maintain backwards compatibility or convert existing patterns. I'll mark this P2 since there have been frequent requests to improve resource exclusion to support build processes that generate files etc.
+1
I have started looking into this and have committed performance tests to HEAD and the 3.3.x branch so that we have a baseline of what the current performance of the resource change monitor exclusions is before we start to work on this further.
In case you aren't completely convinced of the value of this yet: I find that the lack of this feature set is exacerbated by a couple of things: 1. There are certain operations that unexpectedly add a large number of files to the context, that I wish did not happen. I'm not sure exactly what those actions are, but perhaps checking out a project from SVN/CVS. I often find that my "gen" directories get re-added to the context when I didn't want them to. My feeling is that "background" or "indirect" actions generally shouldn't add files to the context, but I'm guessing Mylyn has no way (at this point) to know what "context" the action was performed in. 2. Removing a directory tree from the context is painfully slow.
Thanks for the information David. I actually just finished adding this support. Users can now specify ant patterns for filtering resources from automatically being added to the task context from the Resources preference page. The current exclusions should be migrated to the new form, which will create 4 ant patterns to ensure backwards compatibility. The unit tests and performance tests have been updated so that we can see what effect this has on the performance of resource monitoring.
Created attachment 165160 [details] mylyn/context/zip
Looks like two tests started failing. Shawn, could you take a look? junit.framework.AssertionFailedError: null at org.eclipse.mylyn.resources.tests.ResourceChangeMonitorTest.testPathPostfixExclusionPattern(ResourceChangeMonitorTest.java:276) at org.eclipse.mylyn.commons.tests.support.ManagedTestSuite.run(ManagedTestSuite.java:127) junit.framework.AssertionFailedError: null at org.eclipse.mylyn.resources.tests.ResourceChangeMonitorTest.testPathPrefixExclusionPattern(ResourceChangeMonitorTest.java:258) at org.eclipse.mylyn.commons.tests.support.ManagedTestSuite.run(ManagedTestSuite.java:127)
Reopening.
So, it turns out that the implementation of Path is platform dependent, so some of the tests that I wrote were only valid on Windows. I have fixed the tests so that they make sense on all platforms. Will leave open until I see that the tests pass on linux.
Tests now pass again. Marking resolved.
