Nathan Beyer wrote: > After looking through the logs. It seems these 'accessibility' tests > were just added around Aug 3rd. The Eclipse IDE artifacts aren't even > updated to reflect their existence. Prior to this the tests were in > the "awt_swing_modules". > > Looking at the tests, most of them don't even use the functionality in > the BasicSwingTestCase. Some do use a few of the inner classes of > BasicSwingTestCase, but these should really be factored out, as they > are completely independent. I'm going to go through these tests and > clean them up to be as isolated as the module is.
ack -- I was going to let you go in and fix things, but consensus was that the breakage was holding things up so we did a partial rollback. Thanks for looking into it again and doing the right thing. The tidy-up work is great. > Also, the 'support' project's manifest isn't exporting all of the it's > packagings, so the other project's can't see the classes, at least > within the Eclipse IDE. If the OSGi manifests and the Eclipse > artifacts aren't going to be maintained, should we just get rid of > them? The only place they are used is inside of Eclipse for > developers. Keep them because it is our rigorous definition of the class library modularity. I agree that it is hard to keep them up to date if you are not using an IDE that understands this stuff, which is why I wrote the manifest checker tool. I'm trying to get it to Stefano to report status on melody for all to see. The longer term vision, as discussed a while ago is to use the modularity info at runtime to allow implementation hiding and versioning. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
