Ok. That's what I figured.
So, to keep up with dependancies would you have tasks in project A
that builds each dependency, or have a list in a properties file and
read from that, building each one?
My goal is to have really generic scripts that can build ears, wars,
or jars.
Sent from my iPhone
On Jun 27, 2008, at 12:11 PM, Dominique Devienne <[EMAIL PROTECTED]>
wrote:
On Fri, Jun 27, 2008 at 11:11 AM, Steven Guitar <[EMAIL PROTECTED]>
wrote:
I am working on some build scripts for projects that have a dynamic
listing
of dependancies.
when i try to compile project A that depends on project B, there is
not a
way for me to know which project to compile first (short of having
the
developer keep track of it in a properties file) - so i have
resorted to
using the sourcepath reference stuff of javac to point to the
source files
to use so that javac can compile project A that depends on project B.
Hmmm, that's a pretty bad "smell" when projects don't have clear
dependencies...
enter the problem...
project A eventually gets packaged into a WAR, and when i examine
the WAR,
it also has the classes needed from project B. i have a feeling
that the
sourcepath is implicitly casting these guys, and spitting the
resulting
.class files into the same directory with project A's actual .class
files,
and then when i war that directory up my war contains everything.
Well that's what sourcepath is meant to do. That's built-in behavior
from SUN's Javac, not Ant's <javac> (the latter is a wrapper for the
former).
the problem is, there is nothing about the file structures or package
structures that will help me determine what should be excluded from
the WAR.
i really need a way to use the sourcepath stuff without it
generating class
files OR have those generated class files NOT put in the same spot as
project A's class files.
is there a way to do this?
Nope. Again, built-in Javac behavior; Ant can't do anything about
that. If Javac is told to compile a class (file) which depends on
another class for which it can't find .class for via the classpath,
then it starts looking in the sourcepath for the equivalent .java, and
if it finds it, compiles it. But then they all go to the .class
destination dir, since Javac has only one.
as an added pain, when i tell javac to list the files its going to
compile,
it does not mention the classes from project B, but they show up in
the
destdir location. i can only assume that because they are listed on
the
sourcepath that they are getting compiled.
That's because it's <javac> which gives you this list. Whereas it's
Javac that compiles the extra missing dependencies.
Really your problem is more fundamental... Not knowing what a project
depends on just isn't good. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
