copying the 6.7 jar file from netbeans-6.7/nb6.7/modules/org-netbeans-modules-jellytools.jar to
netbeans-6.8-m1/java2/modules/org-netbeans-modules-jellytools.jar solved my problem.  I can now compile the project in 6.8

jellytools/nbproject/project.xml specifies a number of public packages, yet its actual src tree contains no **/*.java.
Immediate fix is to replace with an empty <public-packages/>.

Beyond that, I don't see any reason for this module to still even exist, as all of its functionality has been split off
into jellytools.* submodules. The **/package-info.html should be moved to the "lowest" modules defining those packages;
the test/qa-functional should be split off into the defining modules.

Note that nbbuild/antsrc/org/netbeans/nbbuild/ParseProjectXml.java#getTestDeps still offers o.n.m.jellytools as a (test)
dep for modules which (in the old XTest style) fail to specify at least junit as a dep. This is already wrong, I guess,
since depending on just jellytools will not give you the right qa-f test classpath.

BTW as to the proximal cause, the zero-length JAR: this would seem to be a duplicate of issue #142733, long since fixed.
And in fact in my build/p-p-j there is no org-netbeans-modules-jellytools.jar. Specifically, if an attempt is made to
compile against a module (as a regular, not test, dep) that says it has public packages but none of them contain any
classes, (1) the p-p JAR is deleted immediately after its creation, (2) the build is halted. And there should be no
modules in the NB distribution which ask to compile against jellytools, since they could not anyway:

http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/build/generated/deps.txt

So what exactly did you do to get to this situation? The reference to harness/build.xml implies that you are not
building NB from sources, but building a suite or standalone module project (you did not supply any information about
this). Meaning that the root problem is likely in your code, though NB code may be producing inappropriate error
diagnostics. If you can produce a complete, self-contained test case which I can reproduce with, the issue is likely to
be resolved quickly: http://wiki.netbeans.org/DevFaqFileBug

I apologize for the lack of details.  Mr. Glick got it right.  I am building the OpenOffice plugin.  Unforturnately it
is pretty big and I doubt I can reduce it to a test case.  I am working on the editor for its idl.  I ran into the
jellytools issue and deprecation of XTest when I tried to compile using NB6.7.  I don't know what effort is going on in
the testing suite.

XTest was dropped in 6.5 and jellytools.platform was split off from the IDE-oriented portions of jellytools. In 6.8,
o.n.m.jellytools is just a shell; the actual code is split further into .cnd, .enterprise, .ide, .java, and .ruby
modules according to the cluster the code relies on. If you are testing using 6.8 you likely want to use just
jellytools.ide.

It's as Jesse said, the jellytools module itself does not contain any functionality. Right now it is merely a container
for tests testing jellytools functionality (jellytools.platform and jellytools.ide). It is so, because those tests
require functionality (that platform or ide does not have) to run (e.g. functionality from jellytools.java).

But I'll fix the project.xml for jelltools, so that it does not export any API. 
Thanks

Regarding jellytools/test, I would recommend that these tests be moved into the "lowest" module in which they can run,
e.g. jellytools.java/test; then jellytools could be deleted. Of course better still would be to fix the tests to not
require functionality higher than the module they are supposed to be testing, but this may take time to accomplish.