Scott Sanders wrote: > >> Since you have a digester, I think the design of the module definitions >> should be as intuitive as possible. Based on input from Jason, the module >> specific stuff was factored out of projects. I see moving this back in as >> a step backwards. > > What would you suggest. Are you saying that a Module is really a subclass > of Project, with its own dependencies that must also be resolved? So the > cvs definition in jakarta-ant would be implicitly depended on by > bootstrap-ant, jakarta-ant, mutant, myrmidon, etc.?
I prefer updates and builds to be separate scripts, but even if they are one.... ...Modules can be subclasses of Projects, or they both can be subclasses of targets... In neither case is there a reason to change the DTD. Digester can populate the objects however you structure your class hierarchy. And the scripts can be generated either way. So my recommendation is to design the XML files based on what makes sense to people. In the real world, cvs modules and projects are distinct objects. It's vindico's responsibility to map the real world onto Ant targets. > I think down the road, once I fully understand it, I would like to come up > with some better names for some things, but I really like the Gump DTD, > just want to add things that were not there already for right now. +1. Many of the names *I* don't like. ;-) Any suggestions you have along the way, let me know (or fix it yourself, if you feel so inclined). It may be easier to address this incrementally instead of facing a massive conversion down the road. > As for the 'build environment suspect' comment, I know you have much more > experience in this than I do, so can you elaborate on this for me? Is > there a problem invoking java from ant in that the environment gets > screwed up somehow? I read the pages on the Gump website, but I honestly > didn't really understand the buildclasspath comments, and why the Ant > team changed things from under you, and why that mattered. I think I may > be a bit in the dark on this one. Class loaders are black magic. No matter how hard you try, there are some cases that bleed through. People better than I have tried and failed to solve some rather basic problems, like pluggable XML compilers. Vindico, like Gump, appears to be split into two phases. There is the script generation, and then there is the script execution. The amount of Java in the script generation phase is not a concern. It is that second phase where I would like to avoid having other things loaded. The buildclasspath comments are another issue. While I believe that authors of the various build.xml files out there should have the first say over what dependencies are used, I firmly believe that the developer running the build should have the final say. I can elaborate, if you like, or you can find more background here: http://jakarta.apache.org/gump/why.html . >> Additional comment on the "build environment itself is not suspect". In >> the generated build script, the actual invoking of any particular build >> step is rather small. One a few lines for things with few dependencies - >> at most a few dozen for something like cocoon. When I'm not sure of what >> is going on, I cut and paste these lines to the command line and execute >> them directly. > > Sure. I should be able to do the same thing, right? I am just much more > comforable in Ant than in Bash or BAT. If the problem is in the <classpath> set up by Ant, how do you cut and paste this? >> There are ways to deal with classloaders. But this always introduces some >> uncertainty. Ask Craig some time why Tomcat now ships Xerces. I would >> hate to see vindico make use an existing version of digester and be asked >> to compile a new version of digester. While I realize that some people >> will say that this problem is solvable, there still are too many dark >> corners which are unexplored for me. > > So there is a problem in using Ant to do a java exec, and keeping cruft around? I don't know if that is an issue, but that's not the issue I am discussing. If you notice, Ant has almost no dependencies, and there are some subtle bootstrapping issues that have come up from time to time, but mostly have been addressed. Vindico has considerably more dependencies. This won't be a problem if used by third parties, but is a concern if vindico is used to build those dependencies. Of course, any dependencies which exist only at generation time are not a concern. >> Also note that this is the reason that I use JAXP in compiling Xerces and >> Xerces for compiling Crimson. I found a number of bugs in Xerces2 along >> the way because the developers didn't realize that they were calling into >> Xerces1 classes. ;-) > > I would like to do this as well. What is the problem that I will run into? No problems. >> > and 2) if my python skill were better (read more productive), >> > this would be ALL-Python! But my skills aren't there, so I >> > use Java instead. Which leads me to Ant to get the system >> > interaction that I so desire. >> >> My Python skills are up to the task. > > But you see no problem with the current system, no? You have > started on Jenny in java, so how would the python stuff fit in? > When I say ALL-python, I mean wholesale replacement of everything, > because of my basic wariness of using java to bootstrap java as > you have said. If we keep a split between the generation of the scripts and the execution of the scripts, then we can pick the best tool for each job. I originally went XSLT as I was thinking in terms of no Java, but eventually I realized that this isn't an issue at the generation portion of the cycle. I eventually even built an Ant script to do the generation which I use for my daily work as it is must faster than the bootstrap. >> My perception is that there is a much richer set of XML manipulation >> components in Java than in any non-Microsoft language. And I've limited >> myself to core standards, like DOM and XSLT. If you include digester and >> other goodies, then > > I agree with the java being richer comment, as not only is it richer, > but I am richer in it. Agreed. That's why I've been migrating the script generation portion to Java. >> "just be Ant tasks" => implementation detail > > Sure. But at some point I have to implement, correct? Hmmm. The original question was "why Ant". Your third reason was "because I want Ant tasks". The reasoning seems kinda circular to me. In any case, I've amply explained why I think the invocation of Ant should be done from a non-Java language. You can accept my explanation, or you can try to prove me wrong. ;-) [ and if you do try to prove me wrong, I will be rooting for you! ] > I am not sold on the BlameLogic either when doing the Gump thing, I am not sold on the BlameLogic when not doing the Gump thing, but again, I hope you prove me wrong here too. > I would, but I feel that I actually need to implement something to > have an idea of what to implement so that I can implement it. > See my dilemma? My head is spinning. I'll trust you on this one. ;-) >> Anyway, my point is that once you realizat that vindico's job is to >> generate scripts, the question is what is the most appropriate scripting >> language for the task at hand. It is not clear to me that this question >> will have a single answer, so an approach which makes the scripting >> language pluggable > > Which is what I suppose you are suggesting. Yup. > OK, to be more precise, you need to download and point to the necessary > dependicies, stated in build.properties, which include: > commons-collections > commons-beanutils > commons-io > commons-digester ;-) Do I need to download them, or can I simply use the ones that I already have? ;-) Again, I believe that you should have the first say in what versions I use, but I should always have the last say... Again, I have no concern of the number of jars used during the generation process. > Yes. I understand the lack of excitement. Jason is doing the Maven > thing to replace the DOM Logic, no? I know that I am duplicating, > but I hope to have an all-java replacement for Aleandria that includes > Gump functionality. I love Gump, it is a large part of my inspiration. > The fact that you have done so much with it has made me want to help > extend the reach, so to speak. For the record, I have no concern over how you chose to invest your time. Duplicate my work, steal from it, pursue what I think are blind alleys. Whatever you do, I am confident that you will surprise me, and I am closely watching. Surprise me in a small way, and I will steal from you. Surprise me in a big way, and I will graft what I think is missing onto what you have built. > I would like to see the scripting pluggable. I think that is a great idea. > I would also like to see the skinning of the logs pluggable, in fact, I would > like to see everything pluggable. At the moment, both are pluggable in Gump. I may have the points where these should plug in or the mechanism of the plug in all wrong, but jakarta.xsl and bash.xsl are where each are controlled. Care to collaborate on a python.xsl? - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
