[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re: [equinox-dev] Package access across plug-ins...

Alex,

  Essentially, I have four constraints:

1. Unit tests running in Nightly Builds via Eclipse builds in an Eclipse Application.
2. Not bloating shipping applications (no test code and JUnit libraries shipping with plug-ins).
3. Not generating more plug-ins or fragments then is necessary.
4. Test code near prod code. (Organizationally, inside the same SVN module).


I layout the details in case someone has a better approach, but to read my own words.

I've been tasked with meeting as many as I can (and in that priority order). I was hoping to group a number of smaller plug-ins into a single test plug-in. I was also hoping to avoid having some plug-ins and some being fragments (the grouped tests have to be plug-ins, the ones having protection issues have to be fragments). I work with ~60 people, and I'd prefer not to have to teach all details about the Eclipse OSGi rules and how the rules differ between the two.

I'll look thru the blog link. I've got everything mostly done. The JUnit interfaces/implementations would be worth porting to. I've decided to use fragments for the existing tests. My current problem is finding a canonical way to say "Always load this fragment".

  Right now, I'm using:
(| (osgi.ws=gtk) (!(osgi.ws=gtk)))

Which is a tautology, it's just not as obvious as I'd like it to be. Leaving it blank causes it to filter out, not filter in. It works just fine on my "win32" platform. If anybody has an answer for that, it'd be worth knowing about. I'm trying to track down the code that does the parsing right now.

     Kirby


From: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
Reply-To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
Subject: Re: Re: [equinox-dev] Package access across plug-ins...
Date: Sun, 22 Oct 2006 08:40:39 +0100

Why not have just one test fragment per bundle? After all, if you want
to test internals then a fragment is a good place to do it. Your test
API then only needs to iterate across each of the bundles, invoking
the tests as they go.

The other possibility is to use a single plugin to test swathes of
external functionality, like Eclipse uses to run the jdt-tests etc.

By the way, I don't know if this is helpful:

http://alblue.blogspot.com/2006/03/javaeclipse-running-all-tests-in.html

I put it together to solve having to explicitly manage running all
tests without the need for a hard-coded AllTests class, as well as
having subsets of tests that can only be run inside an OSGi runtime.
As the comment says down at the bottom, it can be improved with the
PackageAdmin service, but I've not revisited the code there yet.

Alex.

On 22/10/06, BJ Hargrave <hargrave@xxxxxxxxxx> wrote:
You can't do it with 2 bundles (plugins). Each bundles uses a distinct
class loader and package privacy does not cross class loader boundaries.
Fragments can access package private members since a fragment is loaded by
its host bundle's class loader.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx

office: +1 407 849 9117
mobile: +1 386 848 3788




"Kirby Bohling" <computerslicer23@xxxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx 10/21/2006 07:38 PM Please respond to Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To equinox-dev@xxxxxxxxxxx cc

Subject
[equinox-dev] Package access across plug-ins...






All,

I'm still working on the Unit testing application described in an e-mail

yesterday.  I am splitting my plug-ins so that test code is not with
application code.

   When I run the tests thru the "Run As -> JUnit Test", it works fine.
When I right click it and do "Run as JUnit Test Plug-in", I get an error
when I attempt to access anything that is "protected" or "package
protected"
scope?  I have several API's that expose calls to be used for testing as
protected or package level scope.

   It appears that Fragments would solve this problem, but I'd like to
have
one test plug-in for a number of plug-ins.  So I don't think I'd have
access
to all of the various tests unless I could have many hosts for the
fragment
(I don't believe that's possible).  I was curious if there is a way to to
give the plug-in org.foo.test access so that it can access org.foo
protected
constructors and package protected scope objects.  When the code is all in
a
single plug-in it appears to work fine.

   If this is an inappropriate list, a pointer to the correct list would
be
useful.

   Thanks,
        Kirby

_________________________________________________________________
All-in-one security and maintenance for your PC.  Get a free 90-day trial!

http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail


_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_________________________________________________________________
Try Search Survival Kits: Fix up your home and better handle your cash with Live Search! http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmtagline