Hi Jeff Turner <[EMAIL PROTECTED]>, On Thu, 22 Nov 2001 10:16:06 +1100, Jeff Turner <[EMAIL PROTECTED]> wrote:
>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? Simple: since we seem to have similar goals, let's find out whether we can turn "yours" and "mine" into "ours", or even better "theirs". I wanted to create something useful for more people than just me and I think I can learn from you. [snip; Jeff on potential goals] >+1 > >One for webapps would be nice. Brian Ewins' Tomcat App Developers >Guide-based system sounds like the right sort of thing. Agreed. I'd propose to have incremental building blocks (jar, war, ear) to support more options. >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. Just depends how many maintainers such a project can attract. Assume a minor change in the no-frills root implying an avalanche of follow-up changes (e.g., renaming due to discovery of a truly ingenious naming scheme). Are we (i.e., not only you and me but all participants) able to maintain the genealogy tree or would we have to fear for dead branches that turn off users by their "outdated" characteristics? My suggestion would be: let's start with a branchless tree, incorporate small suggestions directly and make the addition of major variations depend on the existence of maintainers. The reason for this suggestion is what I observed at www.cetus-links.org - a great collection of categorized OO links, no censorship, but the lack of a sufficient amount of maintainers sometimes makes it really tedious and boring to find what you need. >> 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? Could you provide some links? Maybe I simply missed these FAQs and, personally, I really need an extensive one. Just adding one more FAQ like the others would for sure not be helpful, I agree. [snip] >> 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? Two issues where XSLT helped me a lot so far: * create server-specific EJB deployment descriptors from the standard one (see my ejbproject archive in the Ant Heap file section) * create a HTML help for developers out of build.xml comments (in addition to -projecthelp: parameter documentation, usage examples, etc.) I'm not sure this is sufficient as a justification (only listed to generic uses here, had several other ones not of interest for all developers), but I found XSLT stylesheet transformations considerably faster and easier to use than to write e.g. Ant tasks or use existing ones in strange ways. In the past, I e.g. used property files to compose HTML pages in a single property and write them to files using <echo>, but this was quite tedious and the resulting HTML is not what I'd call human-readable. >> Some "downers" I'd like to avoid, from my perspective: >> >> - unforced Guru-style programming >? To head for showing off one's programming skills instead of investing e.g. two more lines to obtain a solution that can be understood and maintained also by others. [snip] >> - 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. [...snip...] >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. 100% agreement, maintenance being my only concern here. Inspiring discussion! Rolf -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
