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
