Eric, Apache Commons VFS is already broken up into a multi-module project, so I don't know what you're talking about; see https://search.maven.org/search?q=g:org.apache.commons%20AND%20a:commons-vfs2* The next release will be further modularized; see git master,
Modularization depends on: (1) It's painful to build Apache Commons releases with Maven multi-module projects. It's NOT just building a jar file or set of jars. In comparison, building a mono-module is "simple". This is why I tripped over building Commons Email, FileUpload, and VFS recently. I hope to get back to those ASAP. (2) Always, always, always keep compatibility in mind (3) Keep users in mind with ease of migration and compatibility (see above) (4) JPMS is a giant PITA and we rely on the Moditect plugin for metadata generation. That works today, but there has been some growing pains. and also keep in mind the KISS and YAGNI principle. Gary On Mon, Apr 29, 2024 at 7:58 AM Elric V <elri...@melnib.one> wrote: > > Hi folks, > > This is a generic question, but I'll be using VFS as an example. There > are a lot of commons components which have many functionalities, e.g. > VFS can be used for FTP, HDFS, WebDAV, etc. Many times codebases only > use a subset of those. But there's only one VFS module, which includes > all of these functionalities, and thus all of their dependencies. This > increases build times and sizes (e.g. of WAR files). > > It seems to me that it might be useful to split such components into > multiple modules. Is there any particular reason why this couldn't be > done? > > Best, > > Elric > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
