Makes a lot of sense! Thanks for the explanation :) On Wed, 16 Sep 2020 at 20:56, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> Hi Maxim, > > IMHO, each dependency must be justified by a significant gain in terms of > coding and algorithm. > It is to compare to: > 1. the cost to check the dep against last one (mitigate the later upgrade) > 2. the cost to scan and test the dep against vulnerability (secure > software/lib) > 3. the cost to integrate the stack in all supported environments (flat > classpath, standalone, webapps, OSGi at least for us - and here any dep can > break an integration, in particular OSGi part which is not that greatly > tested yet) > 4. the bytes cost (not everybody care but I do care to have 10M to have an > entity manager when 4 or even less are enough, don't forget it ends in > docker layers or archives and this means network transfer costs + scanning > time in some env at the end). To give you an idea, if you take geronimo > microprofile stack (a subpart but the same in the comparison to be fair) > you will end up around 25M whereas the same done at smallrye in a "open bar > dependency" mode ends up at around 65M. I'd like us to be clean to enable > users to have clean stacks and not hesitate to import us. JPA by itself > requires already several code so better to not add a ton for nothing > ([collections4] is around 750k, with the import we get ~200k so we gain > 1/2M with less conflicts, and work/management to do). > 5. the conflict resolution (with some other libs developed like us, you > must resolve the version manually to enforce one compatible with both in > flat classpath env - ie not OSGi). > 6. the cost to do it ourselves, here java 8 (guess 6) > superseded [collections4] in our usage for a lot and the remaning parts are > very thin so bringing [collections] is only a drawback today IMHO > > Add to that our codebase is pretty stable and I dont see us using > collections4 anymore in the future, it means it is safe to cut it today > IMHO. > > Current import can look a lot but compared to collections4 it is not and if > you drop most of the abstraction without any real logic (abstractX, > decorators, interfaces, emptyX) it is almost nothing so IMO we gain way > more dropping it than keeping it hanging at the risk to keep depending on > it. > > Hope it makes sense. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le mer. 16 sept. 2020 à 12:59, Maxim Solodovnik <solomax...@gmail.com> a > écrit : > > > Hello Romain, > > > > why is it so important not to have dependencies? > > > > On Wed, 16 Sep 2020 at 17:20, Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > > > > > HI everyone, > > > > > > we talked of it a lot but i only took some time to work on it this > > morning: > > > https://issues.apache.org/jira/browse/OPENJPA-2831 > > > > > > Dropped commons-collections4 from our stack (for now just copying the > few > > > classes we use but it enables more easily drop code and abstractions we > > > don't use). > > > > > > I suspect the next dependencies we can drop are serp and > commons-logging, > > > then we would be "pure" (ie only depend on jpa spec and asm - not sure > > this > > > one can be dropped). Serp is "frozen" and should be replaced by direct > > asm > > > code but it requires some investment. Commons logging is easier to drop > > but > > > is a breaking change (in terms of config) we can desire to avoid so > maybe > > > for next round ;). > > > > > > Hope it makes sense. > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > -- > > Best regards, > > Maxim > > > -- Best regards, Maxim
