On Wed, Nov 21, 2001 at 06:14:42PM +0100, Rolf Katzenberger wrote: > On Wed, 21 Nov 2001 12:22:42 +1100, Jeff Turner > <[EMAIL PROTECTED]> wrote: > > [snip; Rolf:] > >> Well... ummm... :o) I already started such a sourceforge project a > >> while ago, Ant Heap (http://sourceforge.net/projects/antheap) - > >> currently in pre-alpha, but already a tiny appetizer release is > >> downloadable. > > > >Wohoo :) Would my build system fit in here? > > It is intended to be an OpenSource project, so I prefer not to work in > the cathedral there... ;-)
Hmm? What have ESR cathedrals got to do with it? > >In general, I think both are useful. I suspect many people have a small > >personal collection of build.xml experiments, useful tricks and other snippets. > >I'm sure these could be useful to others (if appropriately documented). But for > >all the reasons outlined above, I think you need to go further and give'em a > >full working system to play with :) > > Ok. So before we start or modify another Sourceforge project, let's > try to fix an agenda. Here are suggestions for the contents of such a > project, at least those which are my top candidates: > > 1. Very basic, no-frills projects for the absolute beginner > (javac, javadoc, java targets; just for the sake of those who like to > copy and paste a little during learning, to motivate them by "instant > gratification"; BTW, this is also useful at least for all of these > quick&dirty "Hello World" tests I do) +1 One for webapps would be nice. Brian Ewins' Tomcat App Developers Guide-based system sounds like the right sort of thing. When someone adopts and improves the 'no-frills' project at the expense of some additional build.xml complexity, what happens? Can they submit their modified build system? How about as a policy, we agree to accept *any* variation on an existing build system, so long as it's differences/advantages/disadvantages are documented. We then put it in a CVS branch. On the website, we have a complete geneaology, so people can choose where on the complexity:functionality axis they want to start from. > 2. FAQ > (It seems this mailing list is a good indicator of what s a FAQ) There are generic Ant FAQs all over the place. What makes this one different? > 3. Reasonable "strategies" for recurring problems > (compatible ad combinable in [build] files, without forcing users to > search the build files and throw out what they don't need; this item > is probably the hardest part, since we need to find good ways to > combine functionality while keeping the files clear; IMHO also > multi-platform issues should be handled in generic manners, wherever > possible) Sounds good. > > 4. Meta-Programming/Unleashing XSLT > > Quite an amount of Ant meta-programming can be done using this, like > creating build scripts you're going to call in the next step and > similar. I'd prefer this kind of transformations over sed/awk-style > stuff. However, I must admit that XSLT is quite complicated for the > beginner and might be considered "downer". I haven't yet needed this. Anyone have a real-world example they'd like to contribute? > Some "downers" I'd like to avoid, from my perspective: > > - unforced Guru-style programming ? > - switching cascades to select platform-dependent binaries and adapt > the command line arguments they need, according to the platform > - enforcing do-it-as-I-do-or-get-out This is what I want to avoid with the above "accept all enhancements, branch freely, document differences" policy. > - assuming 100% identical developer machines > - assuming one's favourite tool is also the darling of others > - ... This sort of forum would naturally be host to discussions on controversial topics such as 'should jars be in CVS?'. Fine; but I think that as a policy, we should make no judgements. Let the offerings from CVS reflect the diversity of opinions. --Jeff > What's your opinion? > Best regards, > Rolf -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
