ls.net
>>
>> Von: Torsten Curdt
>> Gesendet: Saturday, July 25, 2020 8:29:21 PM
>> An: Commons Developers List
>> Betreff: Re: [all] When to update dependencies?
>>
>>>
>>> They’re not
ternal libraries
> functions which don't have such global state it's fine.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
>
> Von: Torsten Curdt
> Gesendet: Saturday, July 25, 2020 8:29:21 PM
> An: Commons Developers
ch global state it's fine.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
>
> Von: Torsten Curdt
> Gesendet: Saturday, July 25, 2020 8:29:21 PM
> An: Commons Developers List
> Betreff: Re: [all] When to update depen
bal state it's fine.
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
>
> Von: Torsten Curdt
> Gesendet: Saturday, July 25, 2020 8:29:21 PM
> An: Commons Developers List
> Betreff: Re: [all] When to update dependencies?
&g
Curdt
Gesendet: Saturday, July 25, 2020 8:29:21 PM
An: Commons Developers List
Betreff: Re: [all] When to update dependencies?
>
> They’re not the same class and that’s the problem. It’s similar to loading
> two versions of the same library in OSGi
Let's say you are dealing with
org.
>
> They’re not the same class and that’s the problem. It’s similar to loading
> two versions of the same library in OSGi
Let's say you are dealing with
org.vafer.Foo
the library relocates this as
org.apache.commons.compress.internal.org.vafer.Foo
The library only deals with
They’re not the same class and that’s the problem. It’s similar to loading
two versions of the same library in OSGi and allowing the two classes to
get mixed up somehow (fun errors like Foo is not type Foo), typically a bug.
On Fri, Jul 24, 2020 at 11:30 Gilles Sadowski wrote:
> Le ven. 24
On 7/24/20 1:04 AM, Stefan Bodewig wrote:
Hi all
here I'd like to explain why I prefer not to update dependencies just
because we can. Maybe you can convince me that I'm wrong. I've tried to
make this point in different threads but either it has been lost or it
just wasn't worth discussing.
>
> > - 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,
>
> The key phrase is "which would be stupid" which you as a consumer have zero
> control over. People do stupid things all the time.
>
If people use a package that is called "internal" or something - there is
nothing anyone can do.
And really beyond the point.
> > To be more explicit. I am
Le ven. 24 juil. 2020 à 17:39, Gary Gregory a écrit :
>
> On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins wrote:
>
> >
> >
> > > On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
> > >
> > >>
> > >> You can imagine all manner of jar-hell created by shading. For
> > instance:
> > >>
> > > -
Le ven. 24 juil. 2020 à 17:46, Matt Sicker a écrit :
>
> Shading also violates a lot of common ClassLoader assumptions like not
> having multiple copies of the same class in the same visible context (even
> if different packages)
How classes in different packages could be the same class?
Gilles
On Fri, Jul 24, 2020 at 12:00 PM Gary Gregory
wrote:
> On Fri, Jul 24, 2020 at 11:43 AM Rob Tompkins wrote:
>
>>
>>
>> > On Jul 24, 2020, at 11:36 AM, Gary Gregory
>> wrote:
>> >
>> > On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins
>> wrote:
>> >
>> >>
>> >>
>> >>> On Jul 24, 2020, at 9:41 AM,
> On Jul 24, 2020, at 12:00 PM, Gary Gregory wrote:
>
> On Fri, Jul 24, 2020 at 11:43 AM Rob Tompkins wrote:
>
>>
>>
>>> On Jul 24, 2020, at 11:36 AM, Gary Gregory
>> wrote:
>>>
>>> On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins
>> wrote:
>>>
> On Jul 24, 2020, at 9:41
On Fri, Jul 24, 2020 at 11:43 AM Rob Tompkins wrote:
>
>
> > On Jul 24, 2020, at 11:36 AM, Gary Gregory
> wrote:
> >
> > On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins
> wrote:
> >
> >>
> >>
> >>> On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
> >>>
>
> You can imagine all manner
Shading also violates a lot of common ClassLoader assumptions like not
having multiple copies of the same class in the same visible context (even
if different packages) and gets more complex as your types do. I’ve seen
this problem when projects tried to shade Avro or Protobuf. As a downstream
> On Jul 24, 2020, at 11:36 AM, Gary Gregory wrote:
>
> On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins wrote:
>
>>
>>
>>> On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
>>>
You can imagine all manner of jar-hell created by shading. For
>> instance:
>>> - library L1
On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins wrote:
>
>
> > On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
> >
> >>
> >> 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
On Fri, Jul 24, 2020 at 10:50 AM Gilles Sadowski
wrote:
> Hello.
>
> Le ven. 24 juil. 2020 à 14:48, Gary Gregory a
> écrit :
> >
> > On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski
> > wrote:
> >
> > > 2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> > > > It still needs a person to decide to
> On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
>
>>
>> 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,
On Fri, Jul 24, 2020 at 10:02 AM Torsten Curdt wrote:
> >
> > 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,
>
> 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 (?).
>
Of course it means some code duplication in the final artifact.
This means slightly bigger artifacts - but
On 2020-07-24, Bernd Eckenfels wrote:
> When it comes to dependencies wie have both problems: if we upgrade
> dependencies to aggressively (or if we don't test with older dependencies)
> then users have the problem that they might not easily be able to upgrade to
> a new commons version since
Hello.
Le ven. 24 juil. 2020 à 14:48, Gary Gregory a écrit :
>
> On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski
> wrote:
>
> > 2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> > > It still needs a person to decide to merge a PR for a new version.
> > > So this indeed is just about the dependency
On 2020-07-24, Xeno Amess wrote:
> how about:
> 1. we force versions of dependencies in commons-parent
> 2. we make every commons repo use commons-parent as parent.
> 3. we make sure no other repos forces versions of dependencies; all of the
> versions number shall be inherited from
Betreff: Re: [all] When to update dependencies?
how about:
1. we force versions of dependencies in commons-parent
2. we make every commons repo use commons-parent as parent.
3. we make sure no other repos forces versions of dependencies; all of the
versions number shall be inherited from commons-parent
4
lp here, however I do
> find it a bit annoying and not needed as I would run the dependency report
> if I have the need to find me something to work on.
>
> Gruss
> Bend
>
>
> --
> http://bernd.eckenfels.net
>
> Von: Stefan Bodew
--
http://bernd.eckenfels.net
Von: Stefan Bodewig
Gesendet: Friday, July 24, 2020 3:36:36 PM
An: Commons Developers List
Betreff: Re: [all] When to update dependencies?
On 2020-07-24, Gary Gregory wrote:
> Now back to our code depending on other dependencies.
>
> 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
On 2020-07-24, Gary Gregory wrote:
> Now back to our code depending on other dependencies. My view is that there
> are bugs, you just have not hit them. If I find one in a dependency and it
> gets fixed, it's going to mean a new version of that dependency.
This either is "we hit a bug that
Hi All:
I'd like to start here by flipping the story around by looking at what we
do.
Ideally, a PR comes in for a bug with its fix and unit test. This is the
best case scenario. If the PR is green, we squash and merge, and tell
folks, yes, it will be in the next release.
At times, a message
On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski
wrote:
> 2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> > 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?
On 2020-07-24, Torsten Curdt wrote:
> 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.
Right.
> But isn't that what the version definition is for?
> I'd argue that 1.12.4 <-> 1.12.6 should be a compatible upgrade
2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> 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
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?
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
Hi all
here I'd like to explain why I prefer not to update dependencies just
because we can. Maybe you can convince me that I'm wrong. I've tried to
make this point in different threads but either it has been lost or it
just wasn't worth discussing.
First of all let me get a few things out of
36 matches
Mail list logo
