ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <hol...@yahoo.com>
Subject RE: Couple of mods to <javac>
Date Wed, 13 Sep 2000 07:15:26 GMT
Hi Conor,

Sorry this turned into a bigger thing than I'd thought it would. All I can
say is that these particular files don't depend on any others, other than
the "library" classes (if that's the right term for Java) from the
classpath -- and no others depend on them. They're just these little
entities unto themselves. They live where they do in the source tree
because, like any source-tree structure, the subdir they live in says
something about what they are. And also because there are other
(non-compiler) utilities that garner information about them, based on
that.

The java compiler doesn't require these source files live any particular
place, and where they live does serve a purpose, so they are where they
are -- and if I'm going to be able to use Ant as a build tool, then I need
<javac> to be able to handle that (I can't have files re-compiling every
time thru for no reason). I wouldn't want to have to recreate ant.jar
everytime I pick up a new release or latest nightly, but if my change
isn't valid enough to go in, then I guess I'll have to live with that.
(Actually, come to think of it, I'll need to anyway, if my suggestion to
get rid of the extra line of space between the target-names in the logging
output doesn't get picked up either, and since I never heard anything back
from anyone about that one, I'm guessing it won't be. So, oh well...)

Thanks for thinking about it as much as you did,
Diane

--- Conor MacNeill <conor@m64.com> wrote:
> Diane,
> 
> > but it doesn't work for files that aren't part of a package.
> > Those files should be able to live in the source tree wherever it
> makes
> > sense for them to, since the compilers don't require they live any
> > particular place -- but currently, <javac> does.
> 
> Well, actually the compilers will assume that classes in the default
> package
> live at the root of the source tree. When that is the case it can handle
> dependencies which involve those classes. In other words, from my point
> of
> view, the only place that makes sense for classes in the default package
> to
> reside is at the root of the source tree. Of course, I don't know what
> other
> considerations come into play in your environment but I wonder why
> classes
> in the default package exist in other parts of your tree. You say that
> makes
> sense, but I'm not sure how.
> 
> >
> > Since the behaviour I added is only turned on when the "flatten"
> attribute
> > is set to true, it's something you'd have to specifically ask for in
> order
> > to get. So presumably, people would only ever do that when it was the
> > right thing to do.
> 
> To me it would allow people to adopt what I feel is a bad practice. I
> guess
> I'd like to see if anyone else wants it before we would go ahead.
> 
> 
> >
> > On the subject of the other change I made: Did you have any feelings
> about
> > the "listfiles" stuff? It's also behaviour you'd specifically have to
> ask
> > for, so it seems pretty safe to include.
> 
> well verbose IS verbose so I see no real harm in it.
> 
> Conor
> 


=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

Mime
View raw message