Holger, other Eclipse users,
There is one problem with Eclipse automated builds that I am not sure how
to overcome. To be able to generate separate JAR's for core, tests and
performance subprojects, .class files must be generated under separate
subfolders in "build". This seems to be impossible to achieve within an
Eclipse project.
I guess I will provide such separation at the level of ant scripts
(build/cayenne, build/tests, build/performance), while Eclipse will write
in its own folder (build/classes).
Andrus
At 01:07 PM 9/8/2002 -0400, Andrus wrote:
>Holger,
>
>Ok, I am finally done with the release. After announcement on freshmeat
>the site enjoys a popularity spike...
>
>Anyway. I will start checking in the changes you suggested below. Once
>this is done, you can merge your code and work from the master CVS.
>
>Andrus
>
>
>At 10:47 AM 9/3/2002 +0200, Holger Hoffstätte wrote:
>>I wrote:
>> > Andrus wrote:
>> > > Umm, Eclipse integration is a grey area and I welcome suggestions on
>> that.
>> >
>> > this approach works, kind of. I'll try to come up with better setup
>> > tomorrow, as far as I can tell a little rearranging of the tree could just
>> > make things work out for both ant and eclipse.
>>
>>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.
>>
>>- 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.
>>
>>- 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.
>>
>>- 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. There is no good way to have generated source in
>>eclipse source folders and have it automatically picked up; this comes up
>>often in the eclipse newsgroup and is by design as far as I understand.
>>
>>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..
>>
>>Holger
>
This archive was generated by hypermail 2.0.0 : Sun Sep 08 2002 - 14:04:54 EDT