Le 07/04/2020 à 12:41, Mark Thomas a écrit : >> - Use a CLI parsing library (picocli, jcommander or commons-cli) to ease >> the addition of command line options. It may also bring help/manpage >> generation, tab completion, colored messages.
> Are we at the point where we need one? The lack of proper command line parsing will quickly become a deterrent to the addition of new features. I hesitated to add the -verbose option due to this. We'll probably need a -force flag to confirm inplace migration, a -quiet flag wouldn't be unusual. The main method will quickly turn into spaghetti code without a library. > I'd opt for Commons CLI if I had to choose but I'm not really familiar > with any of the options to judge relative pros/cons. Having maintained Commons CLI some time ago I know it well, it's quite compact but it shows its age now compared to more recent alternatives. JCommander is annotation based and more concise. Picocli is the most advanced I think, it supports help usage and manpage generation, tab completion and ANSI coloring. But it's a 350K dependency, so harder to sell I guess. >> - Support in-place migration of directories. I've implemented it for >> single files but it looks a bit dangerous for whole directories. I think >> it'd be safer to ask the user to confirm first. > > I'd be happy to allow this for a build system without confirmation. I'm > not sure I'd want to allow it at all outside of that (including single > files). The opportunity for shooting yourself in the foot if the > migration fails is significant. I'd rather the tool forced a safe > approach of writing the migrated content to a new location. What about safe by default, and a command line option to allow it? >> - In memory buffering. The converters read and write directly to the >> disk, writing first to memory and then to the disk speeds up the >> migration (on my system it halved the migration time of the Tomcat >> source tree). > > I'm wondering about buffer size vs performance benefit. Is there a point > where a larger buffer doesn't help much more? I'm thinking about memory > constrained systems and whether there is a sensible fixed buffer size we > can use, or whether the buffer size should be configurable and if so, > with what default? I'm thinking about a mixed approach, with buffering for small files (let's say under 1MB) and direct write for the others, so the heap usage remains moderate. Emmmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
