Unable to extend DirectoryIteratingTaskScanner

[GoogleCodeExporter]

It is currently impossible to create a new Scanner extension based on the 
DirectoryIteratingTaskScanner because its abstract method uses private class 
ResourceTaskProvider:

protected void scan(ResourceTaskProvider source, TaskCollector collector) { }

Either ResourceTaskProvider and ResourceTaskReference need to be moved to an 
exported package or part of their methods need to be extracted to an interface 
in an exported package.

What version of the product are you using? On what operating system?
Linking against latest stable release, v0.0.3, still present in latest 

Original issue reported on code.google.com by albert.t...@gmail.com on 4 Mar 2011 at 12:48

[GoogleCodeExporter]

Oops! I will fix shortly.

Original comment by konigsb...@gmail.com on 4 Mar 2011 at 12:58

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Is this still an issue when using the latest version on the testing update 
site? 
http://workspacemechanic.eclipselabs.org.codespot.com/hg.update/mechanic-testing
/

Original comment by konigsb...@gmail.com on 6 Mar 2011 at 9:49

[GoogleCodeExporter]

This is still an issue when I grab the jar from the "testing" update site.

Even when I declared version 0.0.5 of workspace-mechanic in my plugin's 
manifest, Eclipse kept complaining that the ResourceTaskProvider and 
ResourceTaskReference are inaccessible due to the current access rules in the 
mechanic plugin.

Please note I can work around this issue for now by coaxing Eclipse to turn the 
access rule errors into warnings. It is not recommended though, so running 
"Refactor > Extract Interface" on these two classes and moving those interface 
source files to com.google.eclipse.mechanic should quickly deal with the 
problem.

Original comment by albert.t...@gmail.com on 7 Mar 2011 at 1:33

[GoogleCodeExporter]

OK. I see this needs to be addressed, thanks.

My only worry is that I've been thinking about reworking that particular API, 
particularly since that scanner will now respect URls as well as files. I don't 
have my thoughts on the matter written down but I'll take another look. Mind if 
I ask what kind of tasks you're writing?

Original comment by konigsb...@gmail.com on 7 Mar 2011 at 1:36

[GoogleCodeExporter]

I was trying to import my carefully crafted workbench layout without having to 
resort to "Switch workspace / copy settings". It was something of an experiment 
though and it hasn't been particularly successful, so in the end I might not go 
through with it.

Still, the issue remains problematic for anyone wanting to use the existing 
directory or URI scanners. The workaround I described causes 
ClassNotFoundExceptions at runtime because OSGi will not retrieve non-exported 
classes.

Original comment by albert.t...@gmail.com on 7 Mar 2011 at 4:36

[GoogleCodeExporter]

It's now fixed in head. Gonna try to publish a 0.0.6 update site.

Original comment by konigsb...@gmail.com on 11 Mar 2011 at 7:08

• Changed state: Accepted

[GoogleCodeExporter]

In testing repo as 0.0.6.

Original comment by konigsb...@gmail.com on 11 Mar 2011 at 7:28

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by konigsb...@gmail.com on 11 Mar 2011 at 7:32

• Changed state: Verified