Hello. Le lun. 29 avr. 2024 à 14:07, Gary Gregory <garydgreg...@gmail.com> a écrit : > > 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,
The OP's question makes sense, even if the example was not appropriate (I didn't look at [VFS]). > > 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". In my experience it was never "simple", as per the long list of things that had to be done manually. Then when steps were automated, the multi-module nature of some components was not taken into account, which led to the issues (AFAICT). > This is why I > tripped over building Commons Email, FileUpload, and VFS recently. I > hope to get back to those ASAP. [RNG], [Numbers], [Geometry], [Math] have been modular for a long time without any more issues than in other components, except for some specialized profiles in order to work around the (too) "simple" way. > (2) Always, always, always keep compatibility in mind How is this related? Any set of functionalities should be amenable to a modular design, unless there are cyclic dependencies (that signal bad design). > (3) Keep users in mind with ease of migration and compatibility (see above) Is this just a matter of a few lines specifying the new dependencies? [Just like with any upgrade.] > (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. Supporting JPMS is orthogonal to a modular (Maven) project (see [RNG], for example). > and also keep in mind the KISS and YAGNI principle. Sure, but the request (for an application to have a minimal set of dependencies) is valid for several reasons: Size (as noted by the OP) but also security (the more so that legal requirements seem on the way in that area). In summary, IMO modularization should be a feature (and a default goal) of any new major release. I know that it is a lot of work (of course, cf. [Math] history) , but we should encourage contributions towards that goal. Regards, Gilles > > 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
