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

Tom,

The Package Admin Service looks like it work nicely, I'll investigate. As to what I'm doing, computers are really good at searching filesystems, and humans are really bad at remembering to do small details. IMHO, you are much better off to have tests be blacklist out, rather then whitelist in if you want to ensure that all tests are run. I want something to programatically search my plug-ins and fragments for anything that resembles a JUnit test and have it be run. It should attempt to run it unless it is explicitly filtered out.

I've found that people write tests, but forgot to attach them to the JUnit test harness at one level or another. In order to figure out that someone has missed adding a test, is a lot of manual work that must be done periodically or writting a program to search for class files that implement tests and compare them against the output of what actually ran. If I can write a program that can generate the set of tests that should be run, I'd much rather use that. I am doing exactly what you are suggesting (at least I think so). The code sketched out looks like this:

TestSuite globalSuite = new TestSuite();
for (extensions it : registry.getExtensionPoint(testLocationExtName)) {
  Bundle bundle = Platform.getBundle(it.getContributer().getName());

// At this point, I need code that can search out the list of directories
// I need DevClassPathHelper code in there that will give me a list of
// classpaths so that when this runs inside of the IDE, I can get bin/test-classes, bin/
// bin/classes, etc from all plug-ins and fragments.
List<String> classpathPrefixes = /** DevClassPathHelper magic here */


// I have yet to write the non-Dev class path code, but I don't believe this will
// will be a significant effort.
classPathPrefixes.add(searchNonDevClassPaths());


for(String path : classpathPrefixes) {
Enumeration classNameEnum = bundle.findEntries(path, ".class", true );
while (classNameEnum.hasMoreElements()) {
Class clazz = bundle.loadClass(extractClassName(prefix, classNameEnum.nextElement()));


// Do reflection magic to ensure it's a JUnit Test, it's not on a list of excluded tests, it's
// not an abstract test, or any other criteria you like...
if (passesFilter(clazz)) {
// Use reflection to see if class implements a static method suite(), if it does, great,
// use that, otherwise use TestSuite.addTestSuite(Class);
addTest(globalSuite, clazz);
}
}
}


  suite.run();
}

With this code, you remove all TestSuites from the various levels, and just let this go find them. Now it's trivial to check the list of exclusions (it's a static list, maintained in a file, or source code). I can also just turn on the debugging flag/logging that will tell me what it's excluding.

That's the heart of what I'm attempting to accomplish. Then I'm going to use a headless application that runs the suite and logs the details (I've looked at org.eclipse.test as an example). Then running JUnit tests is as simple as building a product that contains all of the plug-ins you want to test. Put everything of interest into a feature, add the JUnit plug-ins or fragments, run the application. I don't have to enumerate the tests, or maintain a list of plug-ins to test in an Ant file. I create a "JUnit Product" for each "Application Product". The JUnit Product is maintained by specific feature that includes the application release feature, and the Junit Plug-ins and fragments.

Then it becomes a package/product just like all the others that I have to manage and maintain. I double click on it, and it runs my tests for me.

Thanks,
   Kirby

From: Thomas Watson <tjwatson@xxxxxxxxxx>
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: Mon, 23 Oct 2006 09:52:56 -0500

Kirby,

Yes that clears some things up, but I still have some questions about what
you are trying to do.  See below ...

Tom.

equinox-dev-bounces@xxxxxxxxxxx wrote on 10/23/2006 09:12:40 AM:

> Thomas,
>
>   Let me try and be a bit more formal about the description of my
issues:
>
> If I have a host plug-in "plugin.host" and a fragment called
"plugin.frag".
>
> plugin.host has an output directory of "bin/classes" and plugin.frag has
> an output directory of "bin/test-classes", then
>
> When given "plugin.host" to DevClassPathHelper, I get back
"bin/classes".
> I'm reasonable sure that if I passed int "plugin.frag" to
DevClassPathHelper
> I would get back "bin/test-classes" (if it doesn't, I can just inspect
the
> property file myself).  So when I start using Bundle.findEntries(...),
if
> the plugin.host and plugin.frag have the same output directories, my
current
> code works.  If plugin.host and plugin.frag my current code fails, as I
> never find the classes "bin/test-classes".
>

Why are you trying to find the class files here?  You mentioned this
before in another note.  Do you not know the class names from the fragment
bundles?  In other tests I've seen the testcase typically knows the test
class in the fragment bundle and it simply calls
Bundle.loadClass(<classname>) on the host bundle to access the class from
the fragment bundle.  Then it uses that class to create objects and test
the code in the host.  Is this not possible?  I highly recommend using
this approach if at all possible.  This is how the Eclipse platform
architects all of its tests that involve testing internal API of a bundle,
so it is much more likely to work for you.

> An extension point added to "plugin.frag", reports itself as contributed
via
> "plugin.host", there is no way I can find to get the name "plugin.frag"
out
> of the system using the string "plugin.host" as a starting point.  The
> bundle for "plugin.host" appears to have no interfaces for providing you

> back the fragments that have been attached.

If you really want to do this you can use the
org.osgi.service.packageadmin.PackageAdmin OSGi service provided by the
framework.  It has a method PackageAdmin.getFragments(Bundle).  This
method will return an array a Bundle fragments to the specified host
Bundle.

>
> What I meant by "connecting", was the possibility of listening to bundle

> startups via the Plug-in Activator (I believe with any bundle or bundle
> context you can register a listener).  If I observed all of the
startups, it
> might be possible thru public calls to receive the name "plugin.frag".
>From
> that point, build a data structure that associates "plugin.frag" with
it's
> host "plugin.host".  This way, when I start searching for classes
available
> thru the "plugin.host", I'll know to call DevClassPathHelper with the
bundle
> identifier for the host and all of it's fragments (in this example
> plugin.host and plugin.frag).
>

Fragment bundles cannot be activated so you will never see an activation
bundle event (STARTED) from a fragment bundle.  You may be able to listen
to RESOLVED events for fragment bundles.  But I would recommend using
PackageAdmin to figure out what bundles are attached to a host bundle
instead.

> Hopefully this is a clear description of the issues I am facing.
>
>         Kirby
>
>
> >From: Thomas Watson <tjwatson@xxxxxxxxxx>
> >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: Mon, 23 Oct 2006 08:47:32 -0500
> >
> >equinox-dev-bounces@xxxxxxxxxxx wrote on 10/22/2006 09:19:56 PM:
> >
> > > Jeff,
> > >
> > >    Well, I feel stupid, I have attempted to reconstruct this with a
> >trivial
> > > example I could upload, and I can't.  I'd swear it was broken, but
it
> >has
> > > since started working.  Using the commands you gave me, I managed to
get
> >my
> > > plug-ins and fragments working together in the example I really care
> >about.
> > > So that was very helpful.
> > >
> > >    Now, I'm having problems, because the helpful suggestions about
using
> >
> > > DevClassPathHelper are less useful with fragments.  The
> >DevClassPathHelper
> > > doesn't report back the directories used by the fragment, but the
> >Extension
> > > Point successfully hides bundle-id of the fragment.  So I can't use
the
> > > osgi.dev properties file to look it up without getting the bundle id
of
> >the
> > > fragment from somewhere.
> > >    The fragments are inside of the AbstractBundle, but it's hidden
> >behind a
> > > protected accessor.
> > >
> > >     If the fragment and the plug-in use the same directories it all
> >works
> > > (because overlay of bundles works great), but if the fragments use a
> > > different directory it all stops working.
> >
> >I'm not sure what you mean by "same directories".  Do you mean the
output
> >folders you specify for the source folders of your projects (e.g.
bin/)?
> >The framework should be able to handle fragments having different
output
> >folders than their hosts.  If it is not handling this correctly then
there
> >is a bug.
> >
> >What do you mean by stops working, do you get class loading errors or
> >package access errors etc.?  Can you create a sample host and fragment
> >project which we can use to reproduce your problem?  You should be able
to
> >do everything you need to with a fragment without using any internal
API's
> >of the Equinox framework.
> >
> > > I'm getting fairly close to just
> > > using an extension point to enumerate the directories by hand.  I
can
> >fix up
> > > the auto-detection later if I find it a good way to do it.
> > >
> > >     A BundleListener might be useful, as performance isn't very
> >important.
> > > If you can connect a fragment to the host bundle thru public
methods, it
> >
> > > might work out.
> >
> >Your fragments should be treated and any other fragment and get
> >automatically attached to your host bundle.  There is no need to use
API
> >to connect a fragment to a host yourself.
> >
> >Tom.
> >
> >
> > >    Just wanted to be sure and say thank you for all of your help,
you
> >guys
> > > have been very helpful in getting my little project on track.
> > >
> > >     Thanks,
> > >         Kirby
> > >
> > >
> > >
> > > >From: Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
> > > >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 14:35:08 -0400
> > > >
> > > >Kirby wrote on 10/22/2006 02:18:59 PM:
> > > >
> > > > > 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.
> > > >
> > > >Hmmm, this feels like a bug/issue to me.  To clarify, are you
saying
> >that
> > > >if you omit the Eclipse-PlatformFilter header from the fragment
> >manifest
> > > >that the fragment is somehow disabled?  If so, please run with
-console
> > > >and use "ss" and "diag NN" where NN is the bundle id number of the
> > > >fragment bundle.  The fragment should be RESOLVED and should show
the
> >host
> > > >bundle id as "master".  If it is just INSTALLED then diag should
say
> >why
> > > >it is not RESOLVED.  It may be worthwhile opening a bug report if
the
> > > >fragment really is not getting resolved.
> > > >
> > > >Jeff
> > >
> > >
> > > >_______________________________________________
> > > >equinox-dev mailing list
> > > >equinox-dev@xxxxxxxxxxx
> > > >https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > >
> > > _________________________________________________________________
> > > Get FREE company branded e-mail accounts and business Web site from
> > > Microsoft Office Live
> > > http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> > >
> > > _______________________________________________
> > > 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
>
> _________________________________________________________________
> Get today's hot entertainment gossip
> http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001
>
> _______________________________________________
> 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

_________________________________________________________________
Use your PC to make calls at very low rates https://voiceoam.pcs.v2s.live.com/partnerredirect.aspx