Hello. Le ven. 24 juil. 2020 à 14:48, Gary Gregory <garydgreg...@gmail.com> a écrit : > > On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > 2020-07-24 11:25 UTC+02:00, Torsten Curdt <tcu...@vafer.org>: > > > It still needs a person to decide to merge a PR for a new version. > > > So this indeed is just about the dependency upgrade policies. > > > > > > But isn't that what the version definition is for? > > > > Ideally. > > In practice, I think that all we can assume is that the version > > string is a quick-glance summary of changes, for human > > consumption. > > > > > I'd argue that 1.12.4 <-> 1.12.6 should be a compatible upgrade AND > > > downgrade, > > > 1.12.4 -> 1.20.0 not so much. > > > > > > But to avoid all this is why I usually try to inline dependencies for > > > libraries as much as possible. Basically pretending to not have any. > > > This of course depends on whether the dependency can be isolated that > > way. > > > > > > Also a point I made many times. > > > Just wanted to mention it - again :) > > > > I think that it would be great that "Commons" has a common > > policy for dealing with this (so that we don't have to repeat > > ourselves every now and then). > > A long time ago, the "shade" feature seemed the perfect > > answer to that problem. Yet, to avoid dependencies even > > on another Commons component, several of us continue to > > support the copy/paste option. > > > > There are a few items I'd like to address in this thread so I'll start with > the above. > > I would like to offer my view on shading and copy/paste as - to borrow Jeff > Atwood's expression - a "coding horror". While you may think that there are > still edge cases where this may seem to some as necessary or expedient, I > hope to dissuade you from these practices. > > The first and most obvious horror to me is the copying and pasting of bugs > and hard to maintain code. You may also end up taking along supporting > methods and classes to support the code you copy. While this may seem to > follow the YAGNI principle, my claim is that you can end up with an iceberg > of new code, where the new API surface above the water does not end up > exercising all of the supporting code you had to drag along that lies > below. > > The question where I am most curious to hear back from the copy clan is: Do > you also copy the unit tests that cover the code you copied? No? Coding > horror #2. > > The third horror does not affect us within Apache but its general practice > begs its adherents to answer: Did you check the license of the code you > copied? No? Coding horror #3. Again, this is not an issue within Apache > projects, but the question pops up time and time again at Apache (and at > work): Can I copy this code I found outside of Apache? > > The fourth and final copy horror falls in the same category as the first > and deserves its own mention: security; and can be best understood with > this question: How often do you check for CVEs for the library containing > the code you copied? Never? Coding horror #4.
Agreeing on all the above. Yet, every time there is an opportunity to engage in this wise path, the copying/pasting continues and slowly grows the iceberg. A recent example is the issue with pseudo-random numbers generation where maintaining duplicate functionality in [Lang] was preferred even though [RNG] has 100% coverage (and a explicit scope that entails it will never have any dependency of its own). > Shading has its limited use in my view, and I've used it to provide > monolithic versions of applications, but beyond that, I've no use for it; > but the pain it can cause is very real indeed. > > You can imagine all manner of jar-hell created by shading. For instance: > - library L1 shades library ShadedA-1.0 and ShadedB-1.1. > - library L2 shades library ShadedA-1.1 and ShadedB-1.0. > - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it can't no > matter what classpath ordering it uses. > - An app wants to use L1, L2, ShadedA-1.0, and ShadedB-1.0 but it can't no > matter what classpath ordering it uses. I didn't understand how the problem is supposed to arise. Fortunately, Torsten already replied to this point. :-) Unless I'm mistaken, there is one drawback to shading: Since it creates new classes, there will be less shared code, hence one could imagine a potential hit on performance (?). > Lastly, there is a special kind of shading jar hell that deserves its own > section: the copied and re-packaged source/jar. In this lovely planned > development managed by Hades, an entire jar has been copied then repackaged > such that instead of being in its original Java package org.foo.library, it > is now under org.other.bar.org.foo.library. Residents of this charming > cottage have now the proud owners of every bug and CVE for that specific > version of the source jar, without, and this is the kicker, the option of > overriding the jar with a new version (I'll leave aside your option to take > a new version of the jar and repackaging it yourself to put it in front of > the shaded jar.) I've seen this in various libraries that shade > bytecode manipulation libraries that you can't use on new Java versions. I must be missing something: Since shaded classes are supposed to be "internal", if there is an impact on the public API, the only sane solution is a bug-fix release that shades the fixed version of the internal library. No? Gilles > > I hope this helps someone... > > Gary --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
