[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OPP patch and new build.xml file...

> > 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 ;)
>

Will get on the Ant task for OPP hacking this weekend. 

> I checked this again and found that you didn't change the start scripts to
> reflect the new place for the classes.
> 

Actually, I did. I forgot to include it in the patch. 

> 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?
> 

The following is how I typically arrange my source tree.

Foo +--- bin (for scripts)
    +--- lib (additional jars needed to compile source)
    +--- doc (documents, except javadoc)
    +--- src (for source)
    +--- build +--- classes (for generated classes)
               +--- src (for generated source)
               +--- javadoc (for javadoc, I think apidoc is a better
name)
               +--- bin (for converted scripts)
               +--- lib (for generated jars from source)

Typically, for the scripts in the bin directory, it will includes
build/class and all jars in top level bin directory in its class path.
This makes it easier for the developers to get the latest compiled
classes.

The build/bin will contained fixed scripts ready to go into a binary
distribution. There is a 'dist.bin' target in my build.xml which is an
example of how the binary distibuion is created. 

Also, there is a dist.src directory that create a source code
distribution. Basically, including everything other than the build
directory.

This is the advantage I see putting all generated files under one build
directory. It makes it easier to create clean distribution.

> 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.

Sounds good to me.

> > 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?

OK. I will send you the codes later.

> > > 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!
> 

Probably not that early. However, I do have ozone 0.2.4 dist in my disk.
;)

David Li
DigitalSesame