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. 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. > 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 > 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. 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. 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. 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. 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. ;-) > 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. 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 > 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 "just be Ant tasks" => implementation detail Take a peek at: http://jakarta.apache.org/gump/usage.html 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. 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). > 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? 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 > 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 -------- prepare: static: compile: [javac] Compiling 18 source files to D:\jakarta\jakarta-alexandria\proposal\vindico\target\classes [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\util\XMLHelper.java:67: cannot resolve symbol [javac] symbol : class ArrayStack [javac] location: package collections [javac] import org.apache.commons.collections.ArrayStack; [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\util\XMLHelper.java:93: cannot resolve symbol [javac] symbol : class ArrayStack [javac] location: class org.apache.alexandria.util.XMLHelper [javac] private ArrayStack elementStack = new ArrayStack(); [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\Project.java:69: cannot resolve symbol [javac] symbol : class FileUtils [javac] location: package io [javac] import org.apache.commons.io.FileUtils; [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\Workspace.java:69: cannot resolve symbol [javac] symbol : class FileUtils [javac] location: package io [javac] import org.apache.commons.io.FileUtils; [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\WorkspaceLoader.java:66: cannot resolve symbol [javac] symbol : class Digester [javac] location: package digester [javac] import org.apache.commons.digester.Digester; [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\WorkspaceLoader.java:67: cannot resolve symbol [javac] symbol : class ExtendedBaseRules [javac] location: package digester [javac] import org.apache.commons.digester.ExtendedBaseRules; [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\WorkspaceLoader.java:122: cannot resolve symbol [javac] symbol : class Digester [javac] location: class org.apache.alexandria.om.WorkspaceLoader [javac] private static void configure(Digester digester) { [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\util\XMLHelper.java:93: cannot resolve symbol [javac] symbol : class ArrayStack [javac] location: class org.apache.alexandria.util.XMLHelper [javac] private ArrayStack elementStack = new ArrayStack(); [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\Project.java:294: cannot resolve symbol [javac] symbol : variable FileUtils [javac] location: class org.apache.alexandria.om.Project [javac] FileUtils.fileWrite(filename, helper.toString()); [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\Workspace.java:136: cannot resolve symbol [javac] symbol : variable FileUtils [javac] location: class org.apache.alexandria.om.Workspace [javac] selfBaseDir = FileUtils.dirname(filename); [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\Workspace.java:216: cannot resolve symbol [javac] symbol : variable FileUtils [javac] location: class org.apache.alexandria.om.Workspace [javac] FileUtils.fileWrite(buildPath + "/build.xml", vindicoBuild.toString()); [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\WorkspaceLoader.java:105: cannot resolve symbol [javac] symbol : class Digester [javac] location: class org.apache.alexandria.om.WorkspaceLoader [javac] Digester digester = new Digester(); [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\WorkspaceLoader.java:105: cannot resolve symbol [javac] symbol : class Digester [javac] location: class org.apache.alexandria.om.WorkspaceLoader [javac] Digester digester = new Digester(); [javac] ^ [javac] D:\jakarta\jakarta-alexandria\proposal\vindico\src\java\org\apache\alexandria\om\WorkspaceLoader.java:106: cannot resolve symbol [javac] symbol : class ExtendedBaseRules [javac] location: class org.apache.alexandria.om.WorkspaceLoader [javac] digester.setRules(new ExtendedBaseRules()); [javac] ^ [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 > 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. > 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? 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. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
