On Sat, Feb 02, 2002 at 08:36:47AM -0500, Sam Ruby wrote: > Scott Sanders wrote: > > > > Modifications you can see on my commit of the xml-commons.xml > > project file. Basically just made a cvs project and made the > > two other projects depend on it. Currently, Vindico can only > > handle things at the project level, and I would like to keep > > it that way if possible to be able to just refresh a certain > > build, cvs and all. > > I definately agree with the goal of being able to just refresh a certain > build, cvs and all. >
OK > 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.? > > Modifications to the DTD that I would like to make would be to > > have a <source/> element ala the JavaDoc element so that > > Vindico can go an HTMLify the source code... Things like that. > > I am trying to stay as compatible with the Gump format as possible... > > +1 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) I personally don't like the Bash/Win thing that Gump does > > right now. If I were to do something like this that did not > > use Ant or the shell, I would be building something just like > > Ant, with less functionality and less of a committer base for > > improvement. The combination of Ant and Java is the > > cross-platform posion pill that I am willing to swallow. > > The dislike for the Bash/Win thing is perfectly understandable. > > >From my perspective, Gump has rather modest needs. Mostly it needs to be > able to set a classpath, invoke a java program (99.99% of the time that is > Ant), check return codes, and write to a log. There are also other minor > tasks like creating directories. You know, the types of things one can do > in a script. > Sure. Those modest needs are the basis of Gump. > Quick summary of why I did not use Ant: I want a process that can > bootstrap. And one in which the build environment itself is not suspect. > I want to be able to partially continue on errors. And I love the ability > to view the logs while the build is in progress - try looking at > http://gump.covalent.net/log/index.html or > http://nagoya.apache.org/~rubys/gump/ while a build is in progress. > You always have to bootstrap from something. I am choosing to bootstrap from some jar files, instead of bash or cmd. I intend to try and partially/fully continue on errors, I hope. Viewing the logs while the build is in progress is also very important to me. On that I also agree. And I have watched the logs while they go. It is rather cool. AntGump also had this. 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. > 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. > 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? > 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? > > 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. > > 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. > > > and 3) I should be able to break pieces out to just be Ant > > tasks that anyone can use, regardless of whether they use > > Vindico or not. Like Alexandria's existing BlameLog. > > "Ability to break pieces out" => good requirement > OK > "just be Ant tasks" => implementation detail > Sure. But at some point I have to implement, correct? > Take a peek at: http://jakarta.apache.org/gump/usage.html > OK > The way I have my paths set up... I can type "update xml-commons" from > anywhere. From what I gather, you envision typing "ant xml-commons-cvs" > from within the directory that the vindico generated scripts are. > Yes. Basically the same, correct? > By the way, I've watched a lot of build failures. I'm not sold on > Alexandria's Blame logic. Most people make *some* attempt to compile > before checkin. So an error on a particular line of code is typically > because somebody else changed something that this depends on (often within > the project). I am not sold on the BlameLogic either when doing the Gump thing, but when you are using Vindico in a corporate environment, where most projects will just be packages on the hard drive, it should be pretty easy to pick up the offender. In the Gump world, when building Project A, Project B is a dependency, which has a dependency C, which broke the build. I am not seeing how that is very easy to fix, but if I just want to build the latest Digester using only dependent released jars, then the blamability goes up. Then there could be 'mini-Gumps' that are set up like this to build each project individually based on released deps and not HEAD. Gump has got the HEAD vs. HEAD thing down pat. I just want to grow this. > > > and 4) I want to expirement with the possibilities of a pre-ant > > tool, like the configure -> make toolchain. Maybe these ant > > build scripts can get even easier. I know they can in the Commons. > > Why not consider vindico itself as the pre-ant tool? 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? > > 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. > > Just do a cvs checkout, jump to proposals/vindico and type 'ant run'. > > The only thing required on your machine is a properly installed JRE/JDK > > and a properly installed Ant. > > Buildfile: build.xml > > init: > [echo] -------- vindico 2.0-dev -------- > > [javac] import org.apache.commons.collections.ArrayStack; > [javac] import org.apache.commons.io.FileUtils; > [javac] import org.apache.commons.digester.Digester; > [javac] 14 errors > > BUILD FAILED > D:\jakarta\jakarta-alexandria\proposal\vindico\build.xml:70: Compile failed, >messages should have been provided. > > Total time: 4 seconds > I assume you are doing this for my own good ;-) How can someone participate if they don't now where to start? 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 All of these should be available from http://jakarta.apache.org/commons/ I do want to note, that as soon as I can get Geir to check in the latest and greatest JJAR code, my prior instructions would have been sufficient. Geir, are you listening? WE NEED JJAR NOW! :) > > The build script compiles Vindico, then kicks it off with the > > vindico ant task. > > > > Vindico then uses Digester to load the workspace, which is defined > > by the ant property vindico.build.profile. This is just a Gump > > workspace definition, and the default is vindico.xml. > > > > Digester then recursivley loads profiles, projects, repositories, etc. > > > > The Workspace object then starts spewing ant build files. A master > > to call all the single projects, and each single project gets a > > build file with the necessary cvs and script/ant definitions. > > > > The basic path is: > > > > Get from CVS to a 'pristine' directory (checkout if new, update if > > already existing) Copy cvs files to the build directory and invoke > > the build. The build does it thing, meanwhile everything was > > logged to xml files that can then be styled anyway we want, ala Gump. > > I don't mean to be a downer, but the reason I don't get excited by this is > that I already have something that already does all of that. If you had > wanted to replace gump's DOM logic with digester logic, and make Python a > viable alternative output language, then I would have been more excited. > 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. > > Do stuff like JXR using JavaML to create browsable hyper-linked source > > code, JavaDoc that lists what projects use what class, pretty graphical > > dependency > graphs using something like Graphotron (sp?), and code > > audits and metrics from the output of the JavaML xml files. Maybe even > > source code beautification according to the Elements of Style. BlameLogs > > to help Gump pick who is responsible. And that is just what I have > > thought of so far. But it is a *lot* of work, so I need a *lot* of help, > > that is why I am querying the list for help. Vindico runs right now, > > but only does the basic cvs get and build scenario. I am going to keep > > building, and then we can see where we might end up doewn the road... > > All stuff that is not only fun, but downright useful. So why didn't you > start on that? > I will, as soon as my silly duplication mind control device wears out :) > Any or all of this should be independently runnable. Once it is runnable, > all that is left is the task of generating a script which sets the > classpath and runs the program. Everything else is implementation details: > Ant / Python / Bash / batch files. > I agree. I do want to meet in the middle at some point. I just don't understand why I can't right now :( It is hard to explain. 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. Thank you very much for the input Sam. I do hear you. I will try and force myself to come back around. > - Sam Ruby -- Scott Sanders - [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
