Hi Holger,
I support making those changes. In fact I planned a similar restructuring
myself, just never got enough time. Please send me zipped up version, I will
take a look (this will probably happen sometime this weekend when I finally
get an internet connection in my new apartment). I can cleanup ant stuff and
check in the whole thing. See my notes below.
Holger Hoffstätte writes:
> OK, here we go. I reorganized the tree for my own CVS repository so that
> the whole thing cleanly checks in, out and builds in eclipse.
>
> - the most significant change is moving the source files into their own
> subdirectory 'java' (as with other Apache projects); this prevents
> duplicate resources (build.xml) in the new /build/classes output folder.
+1
> - the old src is now called src/cayenne, with its .java files in
> src/cayenne/java; performance and test also moved into src, and got their
> individual java source dirs. These are used as eclipse source folders. Why
> not a single unified tree? Good question - separating core sources from
> unit testing suites and other stuff (examples..) sounds like a good idea
> to me.
+1
>
> - the new structure also allows us to move the old src/resources/(images,
> gui.properties) into src/cayenne/java/org/cayenne/gui, so that rebuilding
> the editor doesn't require unnecesary copying of resources - just run it
> from eclipse, this is much faster and works fine, except for the
> non-expanded version strings in gui.properties, but this should not matter
> for development. Alternatively the whole resources folder could move into
> java/org/cayenne/gui; this would require adapting
> CayenneAction.RESOURCE_PATH - IMHO more a matter of taste.
I need to take a look at that. I don't remember the details.
> - jar references point into /otherlib; there are no outbound references,
> so checkout and rebuild should work for anybody else with eclipse as well.
>
> One definite problem is the JavaCC pass for generating the wocompat parser
> classes. I admit I had to cheat on this - I just removed the .cvsignore
> and checked in the generated classes. Do we really have to rebuild them
> every time? The .plist format doesn't change that often, and as long as
> there's a way (non-default) to trigger ant to re-create them from the .jj
> this shouldn't matter.
+1 (I am for anything that speeds up the build process ;-))
> So far I have not started to convert the ant files to use the new paths, I
> wanted to ask for feedback on these ideas first. I could send you the
> zipped tree for inspection, so that you can import it into your own
> eclipse and see how it works. Since I'm not too familiar with ant and the
> finer details of the build rules I could use some help there..
If it doesn't interfere much with your work, wait till weekend, I can do the
ant stuff myself.
Andrus
This archive was generated by hypermail 2.0.0 : Tue Sep 03 2002 - 13:40:46 EDT