On 10/9/05, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > Hi, > > I took some spare time this weekend to go over the build files for ant > and reworking them according to the discussion that we had a few days > ago. The ant build now builds only two targets: jar and jar-dep. Both > jars contain all class files if built on an JDK 1.4+. It will report > big warnings if either the JDBC or the logging dependency are missing. > > I also did the following things: > > * This is now ant 1.5+ only. No one should really use an older ant. > * The parser part is still ant 1.6+ only > * ant help is gone. Run ant -projecthelp > * New default target: world. Builds the jar, the javadocs and the docs > * Everything is built under bin/. Everything (*). If you nuke out the > bin dir, your distribution is pristine again. Even better, run > "ant clean" > (*) Not really. The examples still put their class files into the > examples directory. ant clean cleans that out, though. > * "ant package" now builds .zip and .tar.gz distribution files. > CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF > endings for Unix/Linux. > > Please _TEST_! I know that all targets work independently for Linux > using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or > whatever. Report problems!
all sounds very cool. though as the tiniest of "bikeshed painting" things, i would have called the default-catch-all target "all". :) i don't really care though. > TODOs: > > 1) Add automatic download of the jar dependencies from ibiblio, thus allowing > the .jar files to be removed from Subversion. Would reduce the download size > for people pulling the tree from Subversion. (And if you can do that, you > will > also have a network connection to pull the jars from ibiblio.org). Similar > to the download targets built by the maven-generated build.xml file +1 as long as the bundled distribution(s) have the jars with them. and then i can copy/hack your ant code for this into velocity-tools. :) > 2) move the auto-generated parser tree (.../runtime/parser) out of the main > source tree. This would allow a complete separation of the auto-generated > code. > Would also help the various maven reports +1 this would have kept me from some pointless tweaking of generated files when making my logging patch. i often do search-then-jump-to-line stuff when editing code. i'm much more likely to notice that a file is generated if it is in a different directory than if it merely says (or even screams) that it is generated in its headers. i also like increasing the usefulness of the "free" reports we get from maven. > 3) alternatively: Don't build the parser sources inside src/java. Build into > bin/parser and require manual interaction to copy the changed files back. > More > work (however, the parser isn't changed that often... :-) ) but allows us to > keep everything inside bin/ -0 i could live with it, but i prefer #2 > 4) Bikeshed painting: Rework the examples to compile and run from bin/examples > > I'd really like to put 1) in (if no one objects loudly I will anyway > later this week), would like to see some discussion about 2)/3) > whether this would be sensible and if yes what way to go. > > I let 4) to anyone who wants to start contributing to Velocity. This > is an easy thing to do and will help you familiarize with the Velocity > build system. > > Best regards > Henning > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire > Linux, Java, perl, Solaris -- Consulting, Training, Development > > 4 - 8 - 15 - 16 - 23 - 42 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
