>Is it really worth having Maverick do this rather than just running a >command-line xslt processor? Ok, probably :-)
I debated this myself before first posting. I think it is. >Maybe instead of writing a file, it would be better to be able to >specify a command (similar to reloadCommand) which dumps the current >config as a page. That way it isn't necessary to worry about where you >can write to the filesystem, should getRealPath() be used, etc. I'm not sure. I'm thinking of situations where a developer who is unfamiliar with maverick inherits a project and has to get up to speed. While the ability to view dump the current config to a page would be useful for one developing a mav project (so yes, I am voting for this), I am not sure it precludes or replaces dumping a file. (If the new developer can find the command to do this, they are probably past the point where they are looking for the file.) As far as where to dump the file, I would say just dump it to the same directory where you found maverick.xml. Just append -processed to the file name (or something similar), so maverick.xml becomes maverick-processed.xml, and if they renamed maverick.xml to foo.xml, then foo-processed.xml would be produced. If there is an IOException or some other problem, just log the exception to System.err or better yet, use Log4J with a warn level. --jim _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
