[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] converting dsf-gdb test plug-in into a fragment
|
Actually, that technique you used is needed whether or not the test
plugin is a fragment. What you're doing there is getting around
compile-time visibility barriers. Making the test project a
fragment gets around
runtime access barriers resulting from the
fact that each plugin has its own classloader.
Another way to say that is: without your accessor class, you wouldn't
have been able to code the the tests; the compiler would have blocked
you. However, even with your solution, you could have run into
IllegaAccessError exceptions at runtime. That's what's prevented by
turning the project into a fragment.
John
At 02:30 PM 1/20/2011, Marc Khouzam wrote:
BTW, I got around this
limitation up to now by using an
accessor class that I put in the test plugin but using
the same package name as the class I want to access.
Look at the class ClassAccessor
Marc
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
>
[
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> Sent: Thursday, January 20, 2011 2:21 PM
> To: CDT General developers list.
> Subject: [cdt-dev] converting dsf-gdb test plug-in into a
fragment
>
> I'd like to change
>
> org.eclipse.cdt.tests.dsf.gdb
>
> to be a fragment, so that the tests can access non-public fields and
> methods. It's common practice for tests to be housed in fragments,
to
> avoid the OSGi-imposed runtime barrier between plug-ins (every
> plug-in gets its own classloader).
>
> I have the changes on my machine and it all seems to be working
well.
> Any objections?
>
> John
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev