You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/11/28 12:51:06 UTC
[classlib][tests] Refactoring breakage
Looks like a few people are having problems with tests at the moment.
On Linux I see a bunch of compiler errors, like this:
[exec] [echo] Compiling ACCESSIBILITY tests
...
[exec] [javac] 1. ERROR in
/home/hybld/continuum-working-directory/6/classlib/modules/accessibility/src/test/api/java/common/javax/accessibility/AccessibleBundleTest.java
[exec] [javac] (at line 25)
[exec] [javac] import javax.swing.BasicSwingTestCase;
[exec] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[exec] [javac] The import javax.swing.BasicSwingTestCase cannot be
resolved
which is because in r479469 the BasicSwingTestCase was moved from the
'support' module to the 'swing' module, but as you can see it is
referenced from the 'accessibility' module.
In the implementation code, where we cannot control the cyclical
dependencies inherent in the JSE spec, we do a global build first then
compile the individual modules against the HDK.
In the test code we can specify our dependencies to avoid cycles, so the
testing code has to be in the module itself, or in the 'support' module.
This refactoring seems to have broken that design, so I suggest that the
support classes used by numerous modules are returned to 'support'.
Regards,
Tim
(fighting a losing cause it would seem to regain a stable pass rate ;-)
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][tests] Refactoring breakage
Posted by Tim Ellison <t....@gmail.com>.
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][tests] Refactoring breakage
Posted by Nathan Beyer <nb...@gmail.com>.
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.
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.
-Nathan
On 11/28/06, Tim Ellison <t....@gmail.com> wrote:
> Stepan Mishura wrote:
> > On 11/28/06, Tim Ellison wrote:
> >>
> >> Stepan Mishura wrote:
> >> > I agree with moving it back to 'support'. Tim, are you working on this
> >> > (just to avoid duplicate work)?
> >>
> >> No I'm not. I was going to let Nathan comment, and if necessary fix,
> >> since he made the change. If it is a blocker that cannot wait for the
> >> next couple of hours then you/I/anyone can take a look at it.
> >
> > I'd consider it as a blocker cause the classlib build is broken.
>
> Ok, I'll fix it. It will take 40 mins or so because I'll have to run
> all the tests again (hint, hint :-) )
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][tests] Refactoring breakage
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> On 11/28/06, Tim Ellison wrote:
>>
>> Stepan Mishura wrote:
>> > I agree with moving it back to 'support'. Tim, are you working on this
>> > (just to avoid duplicate work)?
>>
>> No I'm not. I was going to let Nathan comment, and if necessary fix,
>> since he made the change. If it is a blocker that cannot wait for the
>> next couple of hours then you/I/anyone can take a look at it.
>
> I'd consider it as a blocker cause the classlib build is broken.
Ok, I'll fix it. It will take 40 mins or so because I'll have to run
all the tests again (hint, hint :-) )
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][tests] Refactoring breakage
Posted by Mark Hindess <ma...@googlemail.com>.
On 28 November 2006 at 19:28, "Stepan Mishura" <st...@gmail.com> wrote:
>
> On 11/28/06, Tim Ellison wrote:
> >
> > Stepan Mishura wrote:
> > > I agree with moving it back to 'support'. Tim, are you working on this
> > > (just to avoid duplicate work)?
> >
> > No I'm not. I was going to let Nathan comment, and if necessary fix,
> > since he made the change. If it is a blocker that cannot wait for the
> > next couple of hours then you/I/anyone can take a look at it.
>
>
> I'd consider it as a blocker cause the classlib build is broken.
Me too. Reverted in r480040.
-Mark.
Re: [classlib][tests] Refactoring breakage
Posted by Stepan Mishura <st...@gmail.com>.
On 11/28/06, Tim Ellison wrote:
>
> Stepan Mishura wrote:
> > I agree with moving it back to 'support'. Tim, are you working on this
> > (just to avoid duplicate work)?
>
> No I'm not. I was going to let Nathan comment, and if necessary fix,
> since he made the change. If it is a blocker that cannot wait for the
> next couple of hours then you/I/anyone can take a look at it.
I'd consider it as a blocker cause the classlib build is broken.
Thanks,
Stepan.
Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][tests] Refactoring breakage
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> I agree with moving it back to 'support'. Tim, are you working on this
> (just to avoid duplicate work)?
No I'm not. I was going to let Nathan comment, and if necessary fix,
since he made the change. If it is a blocker that cannot wait for the
next couple of hours then you/I/anyone can take a look at it.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][tests] Refactoring breakage
Posted by Stepan Mishura <st...@gmail.com>.
On 11/28/06, Tim Ellison wrote:
>
> Looks like a few people are having problems with tests at the moment.
>
> On Linux I see a bunch of compiler errors, like this:
>
> [exec] [echo] Compiling ACCESSIBILITY tests
> ...
> [exec] [javac] 1. ERROR in
>
> /home/hybld/continuum-working-directory/6/classlib/modules/accessibility/src/test/api/java/common/javax/accessibility/AccessibleBundleTest.java
> [exec] [javac] (at line 25)
> [exec] [javac] import javax.swing.BasicSwingTestCase;
> [exec] [javac] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> [exec] [javac] The import javax.swing.BasicSwingTestCase cannot be
> resolved
>
>
> which is because in r479469 the BasicSwingTestCase was moved from the
> 'support' module to the 'swing' module, but as you can see it is
> referenced from the 'accessibility' module.
>
> In the implementation code, where we cannot control the cyclical
> dependencies inherent in the JSE spec, we do a global build first then
> compile the individual modules against the HDK.
>
> In the test code we can specify our dependencies to avoid cycles, so the
> testing code has to be in the module itself, or in the 'support' module.
>
> This refactoring seems to have broken that design, so I suggest that the
> support classes used by numerous modules are returned to 'support'.
I agree with moving it back to 'support'. Tim, are you working on this (just
to avoid duplicate work)?
Thanks,
Stepan.
Regards,
> Tim
> (fighting a losing cause it would seem to regain a stable pass rate ;-)
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>