Hi everyone,
I've been struggling with classfileset quite a bit in the last couple of
days and I'm afraid I'm just as confused now as I when I started out. Maybe
it's time to take a step back and ask a conceptual question or two.
Given a single root class, named mydomain.foo.Foo.class, which resides in a
package called mydomain.foo that is situated in a directory called foo, can
I construct a classfileset that contains all of the classes upon which class
mydomain.foo.Foo.class depends, directly AND indirectly, even if they are in
different packages and directories? Or is classfilepath only capable of
finding direct dependents and/or dependents that are in the same package as
the root class?
Here is my situation explained in a graphical manner.
The main new code that I have written is in directory 'foo' which contains
two packages, 'mydomain.foo' and 'mydomain.foo.Resources'. Package
mydomain.foo contains three classes:
- Foo
- FooConstants
- FooPreferences
Package mydomain.foo.Resources contains a variety of List, Text, and Message
resource bundles used by class Foo and class FooPreferences.
Class Foo is dependent on all of the items in these two packages. However,
only the List resource bundles actually involve class files; the other two
resource bundle types only result in .properties files.
IN ADDITION, class FooPreferences has direct dependencies on these classes:
- AnimationPanel
- AudioPanel
- DigitalCountdownPanel
- DigitalClockPanel
all of which are in package mydomain.common AND
- LocalizationUtils
- LogUtils
- PreferenceUtils
- ReflectionUtils, all of which are in package mydomain.common.utilities.
All of the packages whose names begin 'mydomain.common' are in a directory
called 'common'.
IN TURN, these classes have dependencies of their own, all of which are also
found in packages beginning with 'mydomain.common'. Therefore, they are all
found in directory 'common' too.
There are a lot of classes in the 'common' directory, many of which are not
needed by class Foo to do its job, and they are organized into a variety of
packages, many of which Foo doesn't need, so I was hoping to construct a jar
that contained only the classes needed by Foo or its dependents. However, I
would be willing to simplify my requirement to having only the packages
needed by Foo to do its job, even if that means having several classes in
the jar that Foo will never use.
I'm finding the documentation about classfileset confusing at best so I
truly can't tell if I have unrealistic expectations of 'classfileset' or if
I am just writing my definition incorrectly.
It would really help me if someone could confirm categorically that a
classfileset will contain all direct AND INDIRECT dependencies of the root
class, even if they reside in different packages and directories than the
root class.
If classfileset is capable of recursing to other packages in the same and
different directories, how do I make that happen? Right now, my classfileset
definition -
<classfileset id="reqdClasses" dir="foo">
<root classname="mydomain.foo.Foo"/>
</classfileset>
is returning only these three classes: Foo, FooConstants, and
FooPreferences, in other words the immediate dependents of the root class
that are in the same package. The other immediate dependents that are in
another package in the same directory are NOT being picked up, nor are the
dependents in other packages under the common directory being picked up.
If it is possible to incorporate all direct and indirect dependencies of my
root class in my classfileset, even if those depedent classes reside in
different packages and jars, what do I need to change in my definition to
make that happen? I have tried everything I could think of without success.
Your assistance with this would be VERY VERY greatly appreciated.
Rhino
---
rhino1 AT sympatico DOT ca
"There are two ways of constructing a software design. One way is to make it
so simple that there are obviously no deficiencies. And the other way is to
make it so complicated that there are no obvious deficiencies." - C.A.R.
Hoare
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.4 - Release Date: 25/01/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
