>From Drew McAuliffe <[EMAIL PROTECTED]>: > I've been running into a number of problems with building tapestry (RC1). > The biggest problem I have is that the build structure is completely > interdependent on HiveMind. While I can understand a need to have access to > HiveMind, I don't see why I should need the source of HiveMind, and it's > build structure, to build a dependent library. It should be sufficient (as > it is in many other OS libraries) to simply have the Hivemind jars > available.
It's been a long time since I've set my environment (at work) for building tapestry's betas, and i don't remember if Hivemind's source was indeed needed (so I can't really help on that). But I do remember that when tapestry went from hivemind 1.1 beta to 1.1 final I didn't have to download any source code. The correct jar was automatically downloaded by the ant task. > This has led to a lot of confusion in trying to adjust properties > for my particular environment, and also to debug other issues with the build > process, as listed below: > > 1. Why is it not possible to build Tapestry on Java 1.4? Most app servers do > not support 1.5 at this time, and yet there are compile-time dependencies on > 1.5/5.0 that I have to fix by hand each time I want to do a rebuild. The > biggest one is the reference to "Collections.emptySet()" (as opposed to " > Collections.EMPTY_SET"). I don't know any way around this other than to make > the change myself. AFAIK, 1.5 is only needed for annotations support. I guess if you exclude that package from the build process, then you can build in 1.4 as well. I don't see this as a problem however, since I hace many jdks installed ( including 1.5 ) and I only have to change the JAVA_HOME env variable to switch between those. And also, (apart from the annotations jar) the compile task generates classes for version 1.4 (or 1.3) > > 2. If you've built older versions of tapestry, you can and will run into > problems. Tapestry builds everything into your temp directory, which under > windows is usually not easily accessible (c:/documents and settings/user > name/local settings/temp). Values cached there from building an earlier beta > were causing compile errors. Shouldn't tapestry, like most other OS > libraries, build to a temp directory local to the source path, which can > then safely be completely cleaned before each build? I don't like files > being output to a somewhat hidden directory on my computer and left there to > rot after a build. I've run into that problem too. Usually, my problem had to do with test classes which in later betas where deleted but still remained in the tmp folder (i'm building in linux). This was causing the tests to fail. The simplest way out of it is to do ant clean before ant install. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
