On 07/04/2020 10:54, Emmanuel Bourg wrote: > Hi, > > So I've started working on the Jakarta EE migration tool. I've some > enhancements in mind but I'd like to ensure there is a consensus before > proceeding. > > Here are my suggestions: > > - Turn the tool into a plugin for the main build systems (Maven, Gradle, > Ant) to easily post process the jar/war files generated by a project. > I've some experience on this side with my jsign project > (https://github.com/ebourg/jsign) and I suggest adopting a similar multi > module structure with separate artifacts.
Build time solutions (or at least pre-deployment solutions) strike me as a better option than converting at deploy time (meaning deployment takes longer) or on-the-fly conversion (which just makes me nervous) so +1 to this approach. > - 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? 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. > - Parallel processing of directories, and maybe of archives too but > that's trickier. For speed of conversion I assume. There is always the "unpack, convert, repack" option for archives as a quick(ish) and dirty solution. Parallel processing of archives looks like a fun problem. First impressions are it would involve a lot of in-memory caching. > - 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. > - 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? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
