[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OPP patch and new build.xml file...
On Wed, 18 Apr 2001, David Li wrote:
> > - I'm not crazy about that but can we follow Suns coding conventions for Java?
> > The only problem with your code is that you don't write {} around one liners
> > after if. Again, I'm not crazy about that but would be cool.
> >
>
> Sorry. Sometime I forgot that. Bad habit from the C days. We adapt the
> Sun codeing standard here as well. Thanks for reminding. I will be more
> careful next time.
>
> > - regarding the new build.xml: having all generated classes in a separated dir
> > was also possible with the old build.xml. Anyway, if you really like to use the
> > new Ant (295kb) instead of the old one (85kb) then I'm fine with it.
>
> Well... The fatter Ant actually runs faster. ;)
>
> I am thinking about writting a Ant taskdef for OPP when I have time to
> get arround to that. It's actually not very hard but tedious. There are
> probably a couple minor change needed to be done to OOP to make it a so
> call directory base task in Ant.
>
> Being a directory based task in Ant has an advantage of specify a
> fileset pattern (for example, for all the *Impl.java under src
> directory). It beats manually maintaining the list of Impl file to
> generate the proxy.
ok, ok... I'm convinced ;)
>
> > - I changed build dir to build insead of ant.build this helps me to keep my old
> > Makefils in sunc.
>
> No problem. I am used to name it ant.build because for some of our
> project, there is a build directory for other purposes. I name it
> ant.build just for legacy reason. Personally, I prefer using the build.
I checked this again and found that you didn't change the start scripts to
reflect the new place for the classes.
Basically I don't like this separated build dir because lib,doc,classes dirs
are different dirs in the distrib and self compiled source tree then.
The start scripts have to search both places. Which one first? This may also
lead to situation where you are working on outdated classes because an
ozone.jar is lying around where you don't expect it. Which is the best way to
come around these problems?
>
> > - having generated docs under the build dir looks somewhat strange to me. what
> > are the advantages?
>
> For me, the build directory is for everything generated from the source
> codes including javadocs. I prefer my source tree to be everything
> original. ;) Also, we use CVS here. I prefer not to have generated files
> goes into CVS. It becomes nightmare when it comes to merging changes.
No generated files in CVS, clear. If we don't want them in CVS, then we simply
don't check them in. It makes no difference if they are in the same dir or
somehwhere else.
>
> > - the Log4J LogWriter always prints the entire class name which makes the
> > output somewhat hard to read. Can we change this so that only the raw class
> > name is printed?
>
> Sure. Since we agree on moving the Ozone logging to Log4J, I am going to
> use the PropertyConfigurator instead of BasicConfigurator. There are a
> lot of flexibilty in it.
>
> What do you think of adding a log4j.properties to the ozone's db
> directory? It think it's a good place and logging style can be easily
> change by changing the file.
>
> In the mean time, you can do it with the BasicConfigurator. Check out
> the PatternLayout in Log4J. It has detail document on how to do this
> (and other various of logging formant).
I like the new Log4J logger and the flexibility it gives us but I don't have the
time to play that much with it. ;) So, please can you make us a default
impl/config that does only print raw class names?
>
> > Anyway, your stuff is cool. Thanks for contributing!
> >
>
> Thanks. Ozone is very cool. I have been following it since its release.
Since the very first 0.1 release??? Wow!
Falko
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com