On 2020-06-12, Xeno Amess wrote: > Hi.
>>> 2. How are commons projects related? >> They are not necessarily related. Usually it is considered >> a feature if a component has zero dependency (as it is was >> easier to avoid "JAR hell"). >> However, there are also drawbacks, e.g. duplicating functionality >> (and work) needed by several components. > Something was not quite right about this. For example, in > commons-vfs, we just use commons-lang3 as a dependency. But in > commons-email, we fork some of utility functions in commons-lang3 as a > java class in commons-email. Which is the right way, or a more > commonly accepted way in commons projects? Neither is right or wrong in general, it all depends on the context. VFS has a bunch of dependencies anyway, so adding a dependency on commons-lang3 is no big deal. Email may have decided to copy a few classes in order to avoid a depencency. Another example I'm aware of is Compress which has copied code from commons-io (basically parts of IOUtils) in order to avoid a dependency. And it has copied classes developed in Comnpress to Codec (some of the more exotic hashes/checksums) because they seemed to fit there - but Compress didn't want to pay for this by adding a dependency. One thing that may not have become clear from Gilles' great answer: many decisions are made by the people who work on a concrete code base while people only active elsewhere get out of the way. There are some common grounds - rules that are common to all Apache projects mostly - but the components operate rather autonomously. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
