Re: Modularization of components
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, It's a multi-module project, sure, but the modules are split along technical boundaries rather than functional. I didn't explain this well enough in my original message, so let me try that again. I thought VFS was an appropriate example because it contains *a lot* of functionality. This is by design, of course, and it's a useful thing. But most people who use VFS don't use all of the file system types (called Providers in VFS). There's FTP, SFTP, HTTP, and a bunch of others. My hypothetical suggestion was that if each of those providers were their own module, the dependency footprint would go down for many projects which use some but not all VFS Providers. IMO this would be a good thing for a variety of reasons. I don't know whether VFS is an appropriate example from a technical/feasibility perspective, and sure, backwards compatibility is a concern. But this was intended as an example to start a discussion about modularization within commons. (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". Is this a fundamental maven issue which is hard to solve? I haven't had too many issues with multi-module maven projects in the past, but I admit that my builds are a lot less complex than commons projects. (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). I imagine that some (many?) projects aren't designed with modularization or pluginification in mind, and they end up doing something like Providers.register(FTP.class, HTTP.class, SFTP.class) to register all known implementations. Inverting that relationship isn't always easy to do after the fact. So I understand that this isn't necessarily a quick and easy project. Supporting JPMS is orthogonal to a modular (Maven) project (see [RNG], for example). True. I think in the long term both are desirable. One to reduce size & dependencies & build times; the other to better isolate components & implementation details. But if I had to choose one or the other, maven modularization would certainly be first on the list. 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. Thanks for the +1 on that, Gilles. I'm certainly not expecting any overnight changes on this. My goal was merely to start a discussion and see whether there's any interest for this in the community. Commons components are used incredibly widely. Which is obviously a great thing. But I see WARs getting fatter and fatter with transitive dependencies, and lots of classes remaining unused at runtime. In the age of continuous deployments and fast container startup times, making it easier to keep things slim seems like a useful goal. Best, Elric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Modularization of components
Hello. Le lun. 29 avr. 2024 à 14:07, Gary Gregory 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 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
Re: Modularization of components
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 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
Modularization of components
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
