[lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Benedikt Ritter-4
Hi,

2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <[hidden email]>:

<snip>

>
> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
> needs [lang] + [lang3] where actually it only needs [lang] features,
> ie suppose package didn't change then we wouldn't have had any issue.
> So it means you tend to import multiple versions of the same lib just
> cause few parts were broken even if it doesn't affect you. That's a
> bit sad IMO.
>

If there is anything missing in lang3 that blocks you from migrating
completely, can you tell us what that is? Maybe we can fix that...

Benedikt


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:

> Hi,
>
> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
>
> <snip>
>
>>
>> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
>> needs [lang] + [lang3] where actually it only needs [lang] features,
>> ie suppose package didn't change then we wouldn't have had any issue.
>> So it means you tend to import multiple versions of the same lib just
>> cause few parts were broken even if it doesn't affect you. That's a
>> bit sad IMO.
>>
>
> If there is anything missing in lang3 that blocks you from migrating
> completely, can you tell us what that is? Maybe we can fix that...
>

Issue is not in [commons] but in dependencies. The code we own
migrated but not all our deps.

> Benedikt
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

garydgregory
On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > Hi,
> >
> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
> >
> > <snip>
> >
> >>
> >> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
> >> needs [lang] + [lang3] where actually it only needs [lang] features,
> >> ie suppose package didn't change then we wouldn't have had any issue.
> >> So it means you tend to import multiple versions of the same lib just
> >> cause few parts were broken even if it doesn't affect you. That's a
> >> bit sad IMO.
> >>
> >
> > If there is anything missing in lang3 that blocks you from migrating
> > completely, can you tell us what that is? Maybe we can fix that...
> >
>
> Issue is not in [commons] but in dependencies. The code we own
> migrated but not all our deps.
>


I suggest you ask/Jira each dep to update their [lang] to the latest. That
has worked for me in the past with different FOSS projects I've made the
request about this and that libraries.

Some projects will be receptive and at least reply to you right away,
others won't. Patches help of course since will require at least import
changes.

Gary


>
> > Benedikt
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:

> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <[hidden email]>
> wrote:
>
>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
>> > Hi,
>> >
>> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
>> >
>> > <snip>
>> >
>> >>
>> >> In TomEE the stack uses [lang], then [lang3] was created and now TomEE
>> >> needs [lang] + [lang3] where actually it only needs [lang] features,
>> >> ie suppose package didn't change then we wouldn't have had any issue.
>> >> So it means you tend to import multiple versions of the same lib just
>> >> cause few parts were broken even if it doesn't affect you. That's a
>> >> bit sad IMO.
>> >>
>> >
>> > If there is anything missing in lang3 that blocks you from migrating
>> > completely, can you tell us what that is? Maybe we can fix that...
>> >
>>
>> Issue is not in [commons] but in dependencies. The code we own
>> migrated but not all our deps.
>>
>
>
> I suggest you ask/Jira each dep to update their [lang] to the latest. That
> has worked for me in the past with different FOSS projects I've made the
> request about this and that libraries.
>
> Some projects will be receptive and at least reply to you right away,
> others won't. Patches help of course since will require at least import
> changes.
>

yep, main issue ATM is some can't or doesn't maitain the version we
use - excepted for security issues (we are bound to a EE version for
instance). It meanse it will be forgotten in few years but it also
means we can get the same with [lang3] and [lang4] so clearly
something to tackle at [commons] level. We can't just ask everybody to
update each time IMHO.

> Gary
>
>
>>
>> > Benedikt
>> >
>> >
>> > --
>> > http://people.apache.org/~britter/
>> > http://www.systemoutprintln.de/
>> > http://twitter.com/BenediktRitter
>> > http://github.com/britter
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Benedikt Ritter-4
2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:

> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
> > On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> [hidden email]>
> > wrote:
> >
> >> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
> >> > Hi,
> >> >
> >> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <[hidden email]
> >:
> >> >
> >> > <snip>
> >> >
> >> >>
> >> >> In TomEE the stack uses [lang], then [lang3] was created and now
> TomEE
> >> >> needs [lang] + [lang3] where actually it only needs [lang] features,
> >> >> ie suppose package didn't change then we wouldn't have had any issue.
> >> >> So it means you tend to import multiple versions of the same lib just
> >> >> cause few parts were broken even if it doesn't affect you. That's a
> >> >> bit sad IMO.
> >> >>
> >> >
> >> > If there is anything missing in lang3 that blocks you from migrating
> >> > completely, can you tell us what that is? Maybe we can fix that...
> >> >
> >>
> >> Issue is not in [commons] but in dependencies. The code we own
> >> migrated but not all our deps.
> >>
> >
> >
> > I suggest you ask/Jira each dep to update their [lang] to the latest.
> That
> > has worked for me in the past with different FOSS projects I've made the
> > request about this and that libraries.
> >
> > Some projects will be receptive and at least reply to you right away,
> > others won't. Patches help of course since will require at least import
> > changes.
> >
>
> yep, main issue ATM is some can't or doesn't maitain the version we
> use - excepted for security issues (we are bound to a EE version for
> instance). It meanse it will be forgotten in few years but it also
> means we can get the same with [lang3] and [lang4] so clearly
> something to tackle at [commons] level. We can't just ask everybody to
> update each time IMHO.
>

The alternative is, that TomEE won't run at all because of incompatible API
changes. I would vote for the lesser evil ;-)


>
> > Gary
> >
> >
> >>
> >> > Benedikt
> >> >
> >> >
> >> > --
> >> > http://people.apache.org/~britter/
> >> > http://www.systemoutprintln.de/
> >> > http://twitter.com/BenediktRitter
> >> > http://github.com/britter
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > E-Mail: [hidden email] | [hidden email]
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:

> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
>
>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
>> > On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>> [hidden email]>
>> > wrote:
>> >
>> >> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
>> >> > Hi,
>> >> >
>> >> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <[hidden email]
>> >:
>> >> >
>> >> > <snip>
>> >> >
>> >> >>
>> >> >> In TomEE the stack uses [lang], then [lang3] was created and now
>> TomEE
>> >> >> needs [lang] + [lang3] where actually it only needs [lang] features,
>> >> >> ie suppose package didn't change then we wouldn't have had any issue.
>> >> >> So it means you tend to import multiple versions of the same lib just
>> >> >> cause few parts were broken even if it doesn't affect you. That's a
>> >> >> bit sad IMO.
>> >> >>
>> >> >
>> >> > If there is anything missing in lang3 that blocks you from migrating
>> >> > completely, can you tell us what that is? Maybe we can fix that...
>> >> >
>> >>
>> >> Issue is not in [commons] but in dependencies. The code we own
>> >> migrated but not all our deps.
>> >>
>> >
>> >
>> > I suggest you ask/Jira each dep to update their [lang] to the latest.
>> That
>> > has worked for me in the past with different FOSS projects I've made the
>> > request about this and that libraries.
>> >
>> > Some projects will be receptive and at least reply to you right away,
>> > others won't. Patches help of course since will require at least import
>> > changes.
>> >
>>
>> yep, main issue ATM is some can't or doesn't maitain the version we
>> use - excepted for security issues (we are bound to a EE version for
>> instance). It meanse it will be forgotten in few years but it also
>> means we can get the same with [lang3] and [lang4] so clearly
>> something to tackle at [commons] level. We can't just ask everybody to
>> update each time IMHO.
>>
>
> The alternative is, that TomEE won't run at all because of incompatible API
> changes. I would vote for the lesser evil ;-)
>

No, if broken part are provided in a -legacy.jar or a
-compatibility.jar there would be no issue.

>
>>
>> > Gary
>> >
>> >
>> >>
>> >> > Benedikt
>> >> >
>> >> >
>> >> > --
>> >> > http://people.apache.org/~britter/
>> >> > http://www.systemoutprintln.de/
>> >> > http://twitter.com/BenediktRitter
>> >> > http://github.com/britter
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>> >
>> > --
>> > E-Mail: [hidden email] | [hidden email]
>> > Java Persistence with Hibernate, Second Edition
>> > <http://www.manning.com/bauer3/>
>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > Spring Batch in Action <http://www.manning.com/templier/>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Matt Benson-2
It's not just the broken parts that your dependencies may be using. The
strategy Commons uses is the only way any of us know to permit forward
movement while avoiding jar hell.

Matt
On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <[hidden email]> wrote:

> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
> >
> >> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
> >> > On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> >> [hidden email]>
> >> > wrote:
> >> >
> >> >> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
> >> >> > Hi,
> >> >> >
> >> >> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> [hidden email]
> >> >:
> >> >> >
> >> >> > <snip>
> >> >> >
> >> >> >>
> >> >> >> In TomEE the stack uses [lang], then [lang3] was created and now
> >> TomEE
> >> >> >> needs [lang] + [lang3] where actually it only needs [lang]
> features,
> >> >> >> ie suppose package didn't change then we wouldn't have had any
> issue.
> >> >> >> So it means you tend to import multiple versions of the same lib
> just
> >> >> >> cause few parts were broken even if it doesn't affect you. That's
> a
> >> >> >> bit sad IMO.
> >> >> >>
> >> >> >
> >> >> > If there is anything missing in lang3 that blocks you from
> migrating
> >> >> > completely, can you tell us what that is? Maybe we can fix that...
> >> >> >
> >> >>
> >> >> Issue is not in [commons] but in dependencies. The code we own
> >> >> migrated but not all our deps.
> >> >>
> >> >
> >> >
> >> > I suggest you ask/Jira each dep to update their [lang] to the latest.
> >> That
> >> > has worked for me in the past with different FOSS projects I've made
> the
> >> > request about this and that libraries.
> >> >
> >> > Some projects will be receptive and at least reply to you right away,
> >> > others won't. Patches help of course since will require at least
> import
> >> > changes.
> >> >
> >>
> >> yep, main issue ATM is some can't or doesn't maitain the version we
> >> use - excepted for security issues (we are bound to a EE version for
> >> instance). It meanse it will be forgotten in few years but it also
> >> means we can get the same with [lang3] and [lang4] so clearly
> >> something to tackle at [commons] level. We can't just ask everybody to
> >> update each time IMHO.
> >>
> >
> > The alternative is, that TomEE won't run at all because of incompatible
> API
> > changes. I would vote for the lesser evil ;-)
> >
>
> No, if broken part are provided in a -legacy.jar or a
> -compatibility.jar there would be no issue.
>
> >
> >>
> >> > Gary
> >> >
> >> >
> >> >>
> >> >> > Benedikt
> >> >> >
> >> >> >
> >> >> > --
> >> >> > http://people.apache.org/~britter/
> >> >> > http://www.systemoutprintln.de/
> >> >> > http://twitter.com/BenediktRitter
> >> >> > http://github.com/britter
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > E-Mail: [hidden email] | [hidden email]
> >> > Java Persistence with Hibernate, Second Edition
> >> > <http://www.manning.com/bauer3/>
> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> > Spring Batch in Action <http://www.manning.com/templier/>
> >> > Blog: http://garygregory.wordpress.com
> >> > Home: http://garygregory.com/
> >> > Tweet! http://twitter.com/GaryGregory
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Paul Benedict
I think some people find it unseemly to have both commons 2 and 3 jars in
the classpath. It's OK. This is how a project can make major improvements
and not affect previous clients -- because the package names are different.
The two can live together just fine.


Cheers,
Paul

On Fri, Oct 17, 2014 at 8:51 AM, Matt Benson <[hidden email]> wrote:

> It's not just the broken parts that your dependencies may be using. The
> strategy Commons uses is the only way any of us know to permit forward
> movement while avoiding jar hell.
>
> Matt
> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <[hidden email]>
> wrote:
>
> > 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > > 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
> > >
> > >> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
> > >> > On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> > >> [hidden email]>
> > >> > wrote:
> > >> >
> > >> >> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > >> >> > Hi,
> > >> >> >
> > >> >> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> > [hidden email]
> > >> >:
> > >> >> >
> > >> >> > <snip>
> > >> >> >
> > >> >> >>
> > >> >> >> In TomEE the stack uses [lang], then [lang3] was created and now
> > >> TomEE
> > >> >> >> needs [lang] + [lang3] where actually it only needs [lang]
> > features,
> > >> >> >> ie suppose package didn't change then we wouldn't have had any
> > issue.
> > >> >> >> So it means you tend to import multiple versions of the same lib
> > just
> > >> >> >> cause few parts were broken even if it doesn't affect you.
> That's
> > a
> > >> >> >> bit sad IMO.
> > >> >> >>
> > >> >> >
> > >> >> > If there is anything missing in lang3 that blocks you from
> > migrating
> > >> >> > completely, can you tell us what that is? Maybe we can fix
> that...
> > >> >> >
> > >> >>
> > >> >> Issue is not in [commons] but in dependencies. The code we own
> > >> >> migrated but not all our deps.
> > >> >>
> > >> >
> > >> >
> > >> > I suggest you ask/Jira each dep to update their [lang] to the
> latest.
> > >> That
> > >> > has worked for me in the past with different FOSS projects I've made
> > the
> > >> > request about this and that libraries.
> > >> >
> > >> > Some projects will be receptive and at least reply to you right
> away,
> > >> > others won't. Patches help of course since will require at least
> > import
> > >> > changes.
> > >> >
> > >>
> > >> yep, main issue ATM is some can't or doesn't maitain the version we
> > >> use - excepted for security issues (we are bound to a EE version for
> > >> instance). It meanse it will be forgotten in few years but it also
> > >> means we can get the same with [lang3] and [lang4] so clearly
> > >> something to tackle at [commons] level. We can't just ask everybody to
> > >> update each time IMHO.
> > >>
> > >
> > > The alternative is, that TomEE won't run at all because of incompatible
> > API
> > > changes. I would vote for the lesser evil ;-)
> > >
> >
> > No, if broken part are provided in a -legacy.jar or a
> > -compatibility.jar there would be no issue.
> >
> > >
> > >>
> > >> > Gary
> > >> >
> > >> >
> > >> >>
> > >> >> > Benedikt
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > http://people.apache.org/~britter/
> > >> >> > http://www.systemoutprintln.de/
> > >> >> > http://twitter.com/BenediktRitter
> > >> >> > http://github.com/britter
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: [hidden email]
> > >> >> For additional commands, e-mail: [hidden email]
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > E-Mail: [hidden email] | [hidden email]
> > >> > Java Persistence with Hibernate, Second Edition
> > >> > <http://www.manning.com/bauer3/>
> > >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > >> > Spring Batch in Action <http://www.manning.com/templier/>
> > >> > Blog: http://garygregory.wordpress.com
> > >> > Home: http://garygregory.com/
> > >> > Tweet! http://twitter.com/GaryGregory
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
In reply to this post by Matt Benson-2
Well maven showed the opposite. And this is clearly a theory vs practise
topic so not sure it does worth allimenting this thread since well not agree
Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a écrit :

> It's not just the broken parts that your dependencies may be using. The
> strategy Commons uses is the only way any of us know to permit forward
> movement while avoiding jar hell.
>
> Matt
> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <[hidden email]>
> wrote:
>
> > 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > > 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
> > >
> > >> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
> > >> > On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> > >> [hidden email]>
> > >> > wrote:
> > >> >
> > >> >> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > >> >> > Hi,
> > >> >> >
> > >> >> > 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> > [hidden email]
> > >> >:
> > >> >> >
> > >> >> > <snip>
> > >> >> >
> > >> >> >>
> > >> >> >> In TomEE the stack uses [lang], then [lang3] was created and now
> > >> TomEE
> > >> >> >> needs [lang] + [lang3] where actually it only needs [lang]
> > features,
> > >> >> >> ie suppose package didn't change then we wouldn't have had any
> > issue.
> > >> >> >> So it means you tend to import multiple versions of the same lib
> > just
> > >> >> >> cause few parts were broken even if it doesn't affect you.
> That's
> > a
> > >> >> >> bit sad IMO.
> > >> >> >>
> > >> >> >
> > >> >> > If there is anything missing in lang3 that blocks you from
> > migrating
> > >> >> > completely, can you tell us what that is? Maybe we can fix
> that...
> > >> >> >
> > >> >>
> > >> >> Issue is not in [commons] but in dependencies. The code we own
> > >> >> migrated but not all our deps.
> > >> >>
> > >> >
> > >> >
> > >> > I suggest you ask/Jira each dep to update their [lang] to the
> latest.
> > >> That
> > >> > has worked for me in the past with different FOSS projects I've made
> > the
> > >> > request about this and that libraries.
> > >> >
> > >> > Some projects will be receptive and at least reply to you right
> away,
> > >> > others won't. Patches help of course since will require at least
> > import
> > >> > changes.
> > >> >
> > >>
> > >> yep, main issue ATM is some can't or doesn't maitain the version we
> > >> use - excepted for security issues (we are bound to a EE version for
> > >> instance). It meanse it will be forgotten in few years but it also
> > >> means we can get the same with [lang3] and [lang4] so clearly
> > >> something to tackle at [commons] level. We can't just ask everybody to
> > >> update each time IMHO.
> > >>
> > >
> > > The alternative is, that TomEE won't run at all because of incompatible
> > API
> > > changes. I would vote for the lesser evil ;-)
> > >
> >
> > No, if broken part are provided in a -legacy.jar or a
> > -compatibility.jar there would be no issue.
> >
> > >
> > >>
> > >> > Gary
> > >> >
> > >> >
> > >> >>
> > >> >> > Benedikt
> > >> >> >
> > >> >> >
> > >> >> > --
> > >> >> > http://people.apache.org/~britter/
> > >> >> > http://www.systemoutprintln.de/
> > >> >> > http://twitter.com/BenediktRitter
> > >> >> > http://github.com/britter
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: [hidden email]
> > >> >> For additional commands, e-mail: [hidden email]
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >> > --
> > >> > E-Mail: [hidden email] | [hidden email]
> > >> > Java Persistence with Hibernate, Second Edition
> > >> > <http://www.manning.com/bauer3/>
> > >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > >> > Spring Batch in Action <http://www.manning.com/templier/>
> > >> > Blog: http://garygregory.wordpress.com
> > >> > Home: http://garygregory.com/
> > >> > Tweet! http://twitter.com/GaryGregory
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> > >
> > > --
> > > http://people.apache.org/~britter/
> > > http://www.systemoutprintln.de/
> > > http://twitter.com/BenediktRitter
> > > http://github.com/britter
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Phil Steitz
On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> Well maven showed the opposite. And this is clearly a theory vs practise
> topic so not sure it does worth allimenting this thread since well not agree

Top-posting this kind of statement does no good.  If you have a
better approach, please describe it.  

Phil

> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a écrit :
>
>> It's not just the broken parts that your dependencies may be using. The
>> strategy Commons uses is the only way any of us know to permit forward
>> movement while avoiding jar hell.
>>
>> Matt
>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <[hidden email]>
>> wrote:
>>
>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
>>>>
>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
>>> [hidden email]
>>>>>> :
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created and now
>>>>> TomEE
>>>>>>>>> needs [lang] + [lang3] where actually it only needs [lang]
>>> features,
>>>>>>>>> ie suppose package didn't change then we wouldn't have had any
>>> issue.
>>>>>>>>> So it means you tend to import multiple versions of the same lib
>>> just
>>>>>>>>> cause few parts were broken even if it doesn't affect you.
>> That's
>>> a
>>>>>>>>> bit sad IMO.
>>>>>>>>>
>>>>>>>> If there is anything missing in lang3 that blocks you from
>>> migrating
>>>>>>>> completely, can you tell us what that is? Maybe we can fix
>> that...
>>>>>>> Issue is not in [commons] but in dependencies. The code we own
>>>>>>> migrated but not all our deps.
>>>>>>>
>>>>>>
>>>>>> I suggest you ask/Jira each dep to update their [lang] to the
>> latest.
>>>>> That
>>>>>> has worked for me in the past with different FOSS projects I've made
>>> the
>>>>>> request about this and that libraries.
>>>>>>
>>>>>> Some projects will be receptive and at least reply to you right
>> away,
>>>>>> others won't. Patches help of course since will require at least
>>> import
>>>>>> changes.
>>>>>>
>>>>> yep, main issue ATM is some can't or doesn't maitain the version we
>>>>> use - excepted for security issues (we are bound to a EE version for
>>>>> instance). It meanse it will be forgotten in few years but it also
>>>>> means we can get the same with [lang3] and [lang4] so clearly
>>>>> something to tackle at [commons] level. We can't just ask everybody to
>>>>> update each time IMHO.
>>>>>
>>>> The alternative is, that TomEE won't run at all because of incompatible
>>> API
>>>> changes. I would vote for the lesser evil ;-)
>>>>
>>> No, if broken part are provided in a -legacy.jar or a
>>> -compatibility.jar there would be no issue.
>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>>> Benedikt
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://people.apache.org/~britter/
>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>> http://github.com/britter
>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: [hidden email] | [hidden email]
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
I did it twice or more. it is not magic but the goal is to put
removed/changed classes outside the core project (yes it implies some
modules). this way the core part (what i call core here is what
doesn't change) stays the same with same packages and only what moves
changes.

I know it is easier to just change everything but then you can't cry
cause the war does 200M to pring hello ;).

Using maven pom dependencies can also make it smoother using the pom
dependency as an aggregator.

it wouldn't be commons which is (are actually) everywhere I wouldn't
care that much but commons is so widely spread that it is a bit harder
to manage (it is comparable to asm if it speaks to anyone).



Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau


2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:

> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
>> Well maven showed the opposite. And this is clearly a theory vs practise
>> topic so not sure it does worth allimenting this thread since well not agree
>
> Top-posting this kind of statement does no good.  If you have a
> better approach, please describe it.
>
> Phil
>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a écrit :
>>
>>> It's not just the broken parts that your dependencies may be using. The
>>> strategy Commons uses is the only way any of us know to permit forward
>>> movement while avoiding jar hell.
>>>
>>> Matt
>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <[hidden email]>
>>> wrote:
>>>
>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
>>>>>
>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>>>>>> [hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
>>>> [hidden email]
>>>>>>> :
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created and now
>>>>>> TomEE
>>>>>>>>>> needs [lang] + [lang3] where actually it only needs [lang]
>>>> features,
>>>>>>>>>> ie suppose package didn't change then we wouldn't have had any
>>>> issue.
>>>>>>>>>> So it means you tend to import multiple versions of the same lib
>>>> just
>>>>>>>>>> cause few parts were broken even if it doesn't affect you.
>>> That's
>>>> a
>>>>>>>>>> bit sad IMO.
>>>>>>>>>>
>>>>>>>>> If there is anything missing in lang3 that blocks you from
>>>> migrating
>>>>>>>>> completely, can you tell us what that is? Maybe we can fix
>>> that...
>>>>>>>> Issue is not in [commons] but in dependencies. The code we own
>>>>>>>> migrated but not all our deps.
>>>>>>>>
>>>>>>>
>>>>>>> I suggest you ask/Jira each dep to update their [lang] to the
>>> latest.
>>>>>> That
>>>>>>> has worked for me in the past with different FOSS projects I've made
>>>> the
>>>>>>> request about this and that libraries.
>>>>>>>
>>>>>>> Some projects will be receptive and at least reply to you right
>>> away,
>>>>>>> others won't. Patches help of course since will require at least
>>>> import
>>>>>>> changes.
>>>>>>>
>>>>>> yep, main issue ATM is some can't or doesn't maitain the version we
>>>>>> use - excepted for security issues (we are bound to a EE version for
>>>>>> instance). It meanse it will be forgotten in few years but it also
>>>>>> means we can get the same with [lang3] and [lang4] so clearly
>>>>>> something to tackle at [commons] level. We can't just ask everybody to
>>>>>> update each time IMHO.
>>>>>>
>>>>> The alternative is, that TomEE won't run at all because of incompatible
>>>> API
>>>>> changes. I would vote for the lesser evil ;-)
>>>>>
>>>> No, if broken part are provided in a -legacy.jar or a
>>>> -compatibility.jar there would be no issue.
>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>>>> Benedikt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>> http://github.com/britter
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: [hidden email] | [hidden email]
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> http://people.apache.org/~britter/
>>>>> http://www.systemoutprintln.de/
>>>>> http://twitter.com/BenediktRitter
>>>>> http://github.com/britter
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

sebb-2-2
On 17 October 2014 19:08, Romain Manni-Bucau <[hidden email]> wrote:
> I did it twice or more. it is not magic but the goal is to put
> removed/changed classes outside the core project (yes it implies some
> modules). this way the core part (what i call core here is what
> doesn't change) stays the same with same packages and only what moves
> changes.

I still don't get it.

Suppose you have the following method in the Item class:

public int getLength()

You want to change it to

public long getLength()

This is not binary compatible.

Suppose I move the int version into a legacy jar.
The long version is in the core jar.
Both are in the same class.

Now assume that appA uses the int version, and appB has been updated
to use the long version.

I don't see how one can make this work with Maven.
The JVM classloader can only load a single version of the Item class.

However appA needs one version, and appB needs the other.

Note: I know that this can be made to work with OSGI (it uses multiple
class-loaders) but that is a separate issue.

> I know it is easier to just change everything but then you can't cry
> cause the war does 200M to pring hello ;).
>
> Using maven pom dependencies can also make it smoother using the pom
> dependency as an aggregator.
>
> it wouldn't be commons which is (are actually) everywhere I wouldn't
> care that much but commons is so widely spread that it is a bit harder
> to manage (it is comparable to asm if it speaks to anyone).


>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:
>> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
>>> Well maven showed the opposite. And this is clearly a theory vs practise
>>> topic so not sure it does worth allimenting this thread since well not agree
>>
>> Top-posting this kind of statement does no good.  If you have a
>> better approach, please describe it.
>>
>> Phil
>>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a écrit :
>>>
>>>> It's not just the broken parts that your dependencies may be using. The
>>>> strategy Commons uses is the only way any of us know to permit forward
>>>> movement while avoiding jar hell.
>>>>
>>>> Matt
>>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <[hidden email]>
>>>> wrote:
>>>>
>>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
>>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <[hidden email]>:
>>>>>>
>>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
>>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>>>>>>> [hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
>>>>> [hidden email]
>>>>>>>> :
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created and now
>>>>>>> TomEE
>>>>>>>>>>> needs [lang] + [lang3] where actually it only needs [lang]
>>>>> features,
>>>>>>>>>>> ie suppose package didn't change then we wouldn't have had any
>>>>> issue.
>>>>>>>>>>> So it means you tend to import multiple versions of the same lib
>>>>> just
>>>>>>>>>>> cause few parts were broken even if it doesn't affect you.
>>>> That's
>>>>> a
>>>>>>>>>>> bit sad IMO.
>>>>>>>>>>>
>>>>>>>>>> If there is anything missing in lang3 that blocks you from
>>>>> migrating
>>>>>>>>>> completely, can you tell us what that is? Maybe we can fix
>>>> that...
>>>>>>>>> Issue is not in [commons] but in dependencies. The code we own
>>>>>>>>> migrated but not all our deps.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I suggest you ask/Jira each dep to update their [lang] to the
>>>> latest.
>>>>>>> That
>>>>>>>> has worked for me in the past with different FOSS projects I've made
>>>>> the
>>>>>>>> request about this and that libraries.
>>>>>>>>
>>>>>>>> Some projects will be receptive and at least reply to you right
>>>> away,
>>>>>>>> others won't. Patches help of course since will require at least
>>>>> import
>>>>>>>> changes.
>>>>>>>>
>>>>>>> yep, main issue ATM is some can't or doesn't maitain the version we
>>>>>>> use - excepted for security issues (we are bound to a EE version for
>>>>>>> instance). It meanse it will be forgotten in few years but it also
>>>>>>> means we can get the same with [lang3] and [lang4] so clearly
>>>>>>> something to tackle at [commons] level. We can't just ask everybody to
>>>>>>> update each time IMHO.
>>>>>>>
>>>>>> The alternative is, that TomEE won't run at all because of incompatible
>>>>> API
>>>>>> changes. I would vote for the lesser evil ;-)
>>>>>>
>>>>> No, if broken part are provided in a -legacy.jar or a
>>>>> -compatibility.jar there would be no issue.
>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>>
>>>>>>>>>> Benedikt
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> http://people.apache.org/~britter/
>>>>>>>>>> http://www.systemoutprintln.de/
>>>>>>>>>> http://twitter.com/BenediktRitter
>>>>>>>>>> http://github.com/britter
>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> E-Mail: [hidden email] | [hidden email]
>>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://people.apache.org/~britter/
>>>>>> http://www.systemoutprintln.de/
>>>>>> http://twitter.com/BenediktRitter
>>>>>> http://github.com/britter
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
Yes, that what i said we were not impacted even if the stack is big.

Once again in theory you are right but in practise that's boring and
creates averhead  for nothing.
Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :

> On 17 October 2014 19:08, Romain Manni-Bucau <[hidden email]>
> wrote:
> > I did it twice or more. it is not magic but the goal is to put
> > removed/changed classes outside the core project (yes it implies some
> > modules). this way the core part (what i call core here is what
> > doesn't change) stays the same with same packages and only what moves
> > changes.
>
> I still don't get it.
>
> Suppose you have the following method in the Item class:
>
> public int getLength()
>
> You want to change it to
>
> public long getLength()
>
> This is not binary compatible.
>
> Suppose I move the int version into a legacy jar.
> The long version is in the core jar.
> Both are in the same class.
>
> Now assume that appA uses the int version, and appB has been updated
> to use the long version.
>
> I don't see how one can make this work with Maven.
> The JVM classloader can only load a single version of the Item class.
>
> However appA needs one version, and appB needs the other.
>
> Note: I know that this can be made to work with OSGI (it uses multiple
> class-loaders) but that is a separate issue.
>
> > I know it is easier to just change everything but then you can't cry
> > cause the war does 200M to pring hello ;).
> >
> > Using maven pom dependencies can also make it smoother using the pom
> > dependency as an aggregator.
> >
> > it wouldn't be commons which is (are actually) everywhere I wouldn't
> > care that much but commons is so widely spread that it is a bit harder
> > to manage (it is comparable to asm if it speaks to anyone).
>
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:
> >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> >>> Well maven showed the opposite. And this is clearly a theory vs
> practise
> >>> topic so not sure it does worth allimenting this thread since well not
> agree
> >>
> >> Top-posting this kind of statement does no good.  If you have a
> >> better approach, please describe it.
> >>
> >> Phil
> >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a écrit :
> >>>
> >>>> It's not just the broken parts that your dependencies may be using.
> The
> >>>> strategy Commons uses is the only way any of us know to permit forward
> >>>> movement while avoiding jar hell.
> >>>>
> >>>> Matt
> >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <[hidden email]>
> >>>> wrote:
> >>>>
> >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
> >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> [hidden email]>:
> >>>>>>
> >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]>:
> >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> >>>>>>> [hidden email]>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]>:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> >>>>> [hidden email]
> >>>>>>>> :
> >>>>>>>>>> <snip>
> >>>>>>>>>>
> >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created and
> now
> >>>>>>> TomEE
> >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs [lang]
> >>>>> features,
> >>>>>>>>>>> ie suppose package didn't change then we wouldn't have had any
> >>>>> issue.
> >>>>>>>>>>> So it means you tend to import multiple versions of the same
> lib
> >>>>> just
> >>>>>>>>>>> cause few parts were broken even if it doesn't affect you.
> >>>> That's
> >>>>> a
> >>>>>>>>>>> bit sad IMO.
> >>>>>>>>>>>
> >>>>>>>>>> If there is anything missing in lang3 that blocks you from
> >>>>> migrating
> >>>>>>>>>> completely, can you tell us what that is? Maybe we can fix
> >>>> that...
> >>>>>>>>> Issue is not in [commons] but in dependencies. The code we own
> >>>>>>>>> migrated but not all our deps.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I suggest you ask/Jira each dep to update their [lang] to the
> >>>> latest.
> >>>>>>> That
> >>>>>>>> has worked for me in the past with different FOSS projects I've
> made
> >>>>> the
> >>>>>>>> request about this and that libraries.
> >>>>>>>>
> >>>>>>>> Some projects will be receptive and at least reply to you right
> >>>> away,
> >>>>>>>> others won't. Patches help of course since will require at least
> >>>>> import
> >>>>>>>> changes.
> >>>>>>>>
> >>>>>>> yep, main issue ATM is some can't or doesn't maitain the version we
> >>>>>>> use - excepted for security issues (we are bound to a EE version
> for
> >>>>>>> instance). It meanse it will be forgotten in few years but it also
> >>>>>>> means we can get the same with [lang3] and [lang4] so clearly
> >>>>>>> something to tackle at [commons] level. We can't just ask
> everybody to
> >>>>>>> update each time IMHO.
> >>>>>>>
> >>>>>> The alternative is, that TomEE won't run at all because of
> incompatible
> >>>>> API
> >>>>>> changes. I would vote for the lesser evil ;-)
> >>>>>>
> >>>>> No, if broken part are provided in a -legacy.jar or a
> >>>>> -compatibility.jar there would be no issue.
> >>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> Benedikt
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> http://people.apache.org/~britter/
> >>>>>>>>>> http://www.systemoutprintln.de/
> >>>>>>>>>> http://twitter.com/BenediktRitter
> >>>>>>>>>> http://github.com/britter
> >>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: [hidden email]
> >>>>>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> E-Mail: [hidden email] | [hidden email]
> >>>>>>>> Java Persistence with Hibernate, Second Edition
> >>>>>>>> <http://www.manning.com/bauer3/>
> >>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/
> >
> >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >>>>>>>> Blog: http://garygregory.wordpress.com
> >>>>>>>> Home: http://garygregory.com/
> >>>>>>>> Tweet! http://twitter.com/GaryGregory
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: [hidden email]
> >>>>>>> For additional commands, e-mail: [hidden email]
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> http://people.apache.org/~britter/
> >>>>>> http://www.systemoutprintln.de/
> >>>>>> http://twitter.com/BenediktRitter
> >>>>>> http://github.com/britter
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Duncan Jones-3
On 17 Oct 2014 21:11, "Romain Manni-Bucau" <[hidden email]> wrote:
>
> Yes, that what i said we were not impacted even if the stack is big.
>
> Once again in theory you are right but in practise that's boring and
> creates averhead  for nothing.

You're not making a lot of sense here. Sebb explained a problem with your
approach, but your response is that he's right in theory, but that's boring?

I don't see how a multiple jar approach could work. Can you explain?

Duncan

> Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :
>
> > On 17 October 2014 19:08, Romain Manni-Bucau <[hidden email]>
> > wrote:
> > > I did it twice or more. it is not magic but the goal is to put
> > > removed/changed classes outside the core project (yes it implies some
> > > modules). this way the core part (what i call core here is what
> > > doesn't change) stays the same with same packages and only what moves
> > > changes.
> >
> > I still don't get it.
> >
> > Suppose you have the following method in the Item class:
> >
> > public int getLength()
> >
> > You want to change it to
> >
> > public long getLength()
> >
> > This is not binary compatible.
> >
> > Suppose I move the int version into a legacy jar.
> > The long version is in the core jar.
> > Both are in the same class.
> >
> > Now assume that appA uses the int version, and appB has been updated
> > to use the long version.
> >
> > I don't see how one can make this work with Maven.
> > The JVM classloader can only load a single version of the Item class.
> >
> > However appA needs one version, and appB needs the other.
> >
> > Note: I know that this can be made to work with OSGI (it uses multiple
> > class-loaders) but that is a separate issue.
> >
> > > I know it is easier to just change everything but then you can't cry
> > > cause the war does 200M to pring hello ;).
> > >
> > > Using maven pom dependencies can also make it smoother using the pom
> > > dependency as an aggregator.
> > >
> > > it wouldn't be commons which is (are actually) everywhere I wouldn't
> > > care that much but commons is so widely spread that it is a bit harder
> > > to manage (it is comparable to asm if it speaks to anyone).
> >
> >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau
> > > http://www.tomitribe.com
> > > http://rmannibucau.wordpress.com
> > > https://github.com/rmannibucau
> > >
> > >
> > > 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:
> > >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> > >>> Well maven showed the opposite. And this is clearly a theory vs
> > practise
> > >>> topic so not sure it does worth allimenting this thread since well
not
> > agree
> > >>
> > >> Top-posting this kind of statement does no good.  If you have a
> > >> better approach, please describe it.
> > >>
> > >> Phil
> > >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a écrit
:
> > >>>
> > >>>> It's not just the broken parts that your dependencies may be using.
> > The
> > >>>> strategy Commons uses is the only way any of us know to permit
forward
> > >>>> movement while avoiding jar hell.
> > >>>>
> > >>>> Matt
> > >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <
[hidden email]>

> > >>>> wrote:
> > >>>>
> > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> > [hidden email]>:
> > >>>>>>
> > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <[hidden email]
>:
> > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> > >>>>>>> [hidden email]>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <[hidden email]
>:
> > >>>>>>>>>> Hi,
> > >>>>>>>>>>
> > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> > >>>>> [hidden email]
> > >>>>>>>> :
> > >>>>>>>>>> <snip>
> > >>>>>>>>>>
> > >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created and
> > now
> > >>>>>>> TomEE
> > >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs [lang]
> > >>>>> features,
> > >>>>>>>>>>> ie suppose package didn't change then we wouldn't have had
any

> > >>>>> issue.
> > >>>>>>>>>>> So it means you tend to import multiple versions of the same
> > lib
> > >>>>> just
> > >>>>>>>>>>> cause few parts were broken even if it doesn't affect you.
> > >>>> That's
> > >>>>> a
> > >>>>>>>>>>> bit sad IMO.
> > >>>>>>>>>>>
> > >>>>>>>>>> If there is anything missing in lang3 that blocks you from
> > >>>>> migrating
> > >>>>>>>>>> completely, can you tell us what that is? Maybe we can fix
> > >>>> that...
> > >>>>>>>>> Issue is not in [commons] but in dependencies. The code we own
> > >>>>>>>>> migrated but not all our deps.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> I suggest you ask/Jira each dep to update their [lang] to the
> > >>>> latest.
> > >>>>>>> That
> > >>>>>>>> has worked for me in the past with different FOSS projects I've
> > made
> > >>>>> the
> > >>>>>>>> request about this and that libraries.
> > >>>>>>>>
> > >>>>>>>> Some projects will be receptive and at least reply to you right
> > >>>> away,
> > >>>>>>>> others won't. Patches help of course since will require at
least
> > >>>>> import
> > >>>>>>>> changes.
> > >>>>>>>>
> > >>>>>>> yep, main issue ATM is some can't or doesn't maitain the
version we
> > >>>>>>> use - excepted for security issues (we are bound to a EE version
> > for
> > >>>>>>> instance). It meanse it will be forgotten in few years but it
also

> > >>>>>>> means we can get the same with [lang3] and [lang4] so clearly
> > >>>>>>> something to tackle at [commons] level. We can't just ask
> > everybody to
> > >>>>>>> update each time IMHO.
> > >>>>>>>
> > >>>>>> The alternative is, that TomEE won't run at all because of
> > incompatible
> > >>>>> API
> > >>>>>> changes. I would vote for the lesser evil ;-)
> > >>>>>>
> > >>>>> No, if broken part are provided in a -legacy.jar or a
> > >>>>> -compatibility.jar there would be no issue.
> > >>>>>
> > >>>>>>>> Gary
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>> Benedikt
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>> http://people.apache.org/~britter/
> > >>>>>>>>>> http://www.systemoutprintln.de/
> > >>>>>>>>>> http://twitter.com/BenediktRitter
> > >>>>>>>>>> http://github.com/britter
> > >>>>>>>>>
> > >>>>
---------------------------------------------------------------------

> > >>>>>>>>> To unsubscribe, e-mail: [hidden email]
> > >>>>>>>>> For additional commands, e-mail: [hidden email]
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> E-Mail: [hidden email] | [hidden email]
> > >>>>>>>> Java Persistence with Hibernate, Second Edition
> > >>>>>>>> <http://www.manning.com/bauer3/>
> > >>>>>>>> JUnit in Action, Second Edition <
http://www.manning.com/tahchiev/

> > >
> > >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> > >>>>>>>> Blog: http://garygregory.wordpress.com
> > >>>>>>>> Home: http://garygregory.com/
> > >>>>>>>> Tweet! http://twitter.com/GaryGregory
> > >>>>>>>
> > ---------------------------------------------------------------------
> > >>>>>>> To unsubscribe, e-mail: [hidden email]
> > >>>>>>> For additional commands, e-mail: [hidden email]
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> http://people.apache.org/~britter/
> > >>>>>> http://www.systemoutprintln.de/
> > >>>>>> http://twitter.com/BenediktRitter
> > >>>>>> http://github.com/britter
> > >>>>>
---------------------------------------------------------------------

> > >>>>> To unsubscribe, e-mail: [hidden email]
> > >>>>> For additional commands, e-mail: [hidden email]
> > >>>>>
> > >>>>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
Each time you break an api extract this part in compatibility (deprecated)
n-1 jar and export new one in the v n jar. Grabbing pom dependecy you get
by default n jars but if you want you can exclude include jars to get n-1
apis and moreover you didnt break anything for 80% of users.

I know it is far from being perfect but lang, collections...are often twice
in apps. A maybe better alternative is to do smaller modules this way you
get less impacted.
Le 17 oct. 2014 22:21, "Duncan Jones" <[hidden email]> a écrit :

> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <[hidden email]> wrote:
> >
> > Yes, that what i said we were not impacted even if the stack is big.
> >
> > Once again in theory you are right but in practise that's boring and
> > creates averhead  for nothing.
>
> You're not making a lot of sense here. Sebb explained a problem with your
> approach, but your response is that he's right in theory, but that's
> boring?
>
> I don't see how a multiple jar approach could work. Can you explain?
>
> Duncan
>
> > Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :
> >
> > > On 17 October 2014 19:08, Romain Manni-Bucau <[hidden email]>
> > > wrote:
> > > > I did it twice or more. it is not magic but the goal is to put
> > > > removed/changed classes outside the core project (yes it implies some
> > > > modules). this way the core part (what i call core here is what
> > > > doesn't change) stays the same with same packages and only what moves
> > > > changes.
> > >
> > > I still don't get it.
> > >
> > > Suppose you have the following method in the Item class:
> > >
> > > public int getLength()
> > >
> > > You want to change it to
> > >
> > > public long getLength()
> > >
> > > This is not binary compatible.
> > >
> > > Suppose I move the int version into a legacy jar.
> > > The long version is in the core jar.
> > > Both are in the same class.
> > >
> > > Now assume that appA uses the int version, and appB has been updated
> > > to use the long version.
> > >
> > > I don't see how one can make this work with Maven.
> > > The JVM classloader can only load a single version of the Item class.
> > >
> > > However appA needs one version, and appB needs the other.
> > >
> > > Note: I know that this can be made to work with OSGI (it uses multiple
> > > class-loaders) but that is a separate issue.
> > >
> > > > I know it is easier to just change everything but then you can't cry
> > > > cause the war does 200M to pring hello ;).
> > > >
> > > > Using maven pom dependencies can also make it smoother using the pom
> > > > dependency as an aggregator.
> > > >
> > > > it wouldn't be commons which is (are actually) everywhere I wouldn't
> > > > care that much but commons is so widely spread that it is a bit
> harder
> > > > to manage (it is comparable to asm if it speaks to anyone).
> > >
> > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau
> > > > http://www.tomitribe.com
> > > > http://rmannibucau.wordpress.com
> > > > https://github.com/rmannibucau
> > > >
> > > >
> > > > 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:
> > > >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> > > >>> Well maven showed the opposite. And this is clearly a theory vs
> > > practise
> > > >>> topic so not sure it does worth allimenting this thread since well
> not
> > > agree
> > > >>
> > > >> Top-posting this kind of statement does no good.  If you have a
> > > >> better approach, please describe it.
> > > >>
> > > >> Phil
> > > >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a
> écrit
> :
> > > >>>
> > > >>>> It's not just the broken parts that your dependencies may be
> using.
> > > The
> > > >>>> strategy Commons uses is the only way any of us know to permit
> forward
> > > >>>> movement while avoiding jar hell.
> > > >>>>
> > > >>>> Matt
> > > >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <
> [hidden email]>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> > > [hidden email]>:
> > > >>>>>>
> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
> [hidden email]
> >:
> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> > > >>>>>>> [hidden email]>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
> [hidden email]
> >:
> > > >>>>>>>>>> Hi,
> > > >>>>>>>>>>
> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> > > >>>>> [hidden email]
> > > >>>>>>>> :
> > > >>>>>>>>>> <snip>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created
> and
> > > now
> > > >>>>>>> TomEE
> > > >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs [lang]
> > > >>>>> features,
> > > >>>>>>>>>>> ie suppose package didn't change then we wouldn't have had
> any
> > > >>>>> issue.
> > > >>>>>>>>>>> So it means you tend to import multiple versions of the
> same
> > > lib
> > > >>>>> just
> > > >>>>>>>>>>> cause few parts were broken even if it doesn't affect you.
> > > >>>> That's
> > > >>>>> a
> > > >>>>>>>>>>> bit sad IMO.
> > > >>>>>>>>>>>
> > > >>>>>>>>>> If there is anything missing in lang3 that blocks you from
> > > >>>>> migrating
> > > >>>>>>>>>> completely, can you tell us what that is? Maybe we can fix
> > > >>>> that...
> > > >>>>>>>>> Issue is not in [commons] but in dependencies. The code we
> own
> > > >>>>>>>>> migrated but not all our deps.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> I suggest you ask/Jira each dep to update their [lang] to the
> > > >>>> latest.
> > > >>>>>>> That
> > > >>>>>>>> has worked for me in the past with different FOSS projects
> I've
> > > made
> > > >>>>> the
> > > >>>>>>>> request about this and that libraries.
> > > >>>>>>>>
> > > >>>>>>>> Some projects will be receptive and at least reply to you
> right
> > > >>>> away,
> > > >>>>>>>> others won't. Patches help of course since will require at
> least
> > > >>>>> import
> > > >>>>>>>> changes.
> > > >>>>>>>>
> > > >>>>>>> yep, main issue ATM is some can't or doesn't maitain the
> version we
> > > >>>>>>> use - excepted for security issues (we are bound to a EE
> version
> > > for
> > > >>>>>>> instance). It meanse it will be forgotten in few years but it
> also
> > > >>>>>>> means we can get the same with [lang3] and [lang4] so clearly
> > > >>>>>>> something to tackle at [commons] level. We can't just ask
> > > everybody to
> > > >>>>>>> update each time IMHO.
> > > >>>>>>>
> > > >>>>>> The alternative is, that TomEE won't run at all because of
> > > incompatible
> > > >>>>> API
> > > >>>>>> changes. I would vote for the lesser evil ;-)
> > > >>>>>>
> > > >>>>> No, if broken part are provided in a -legacy.jar or a
> > > >>>>> -compatibility.jar there would be no issue.
> > > >>>>>
> > > >>>>>>>> Gary
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>>> Benedikt
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>> http://people.apache.org/~britter/
> > > >>>>>>>>>> http://www.systemoutprintln.de/
> > > >>>>>>>>>> http://twitter.com/BenediktRitter
> > > >>>>>>>>>> http://github.com/britter
> > > >>>>>>>>>
> > > >>>>
> ---------------------------------------------------------------------
> > > >>>>>>>>> To unsubscribe, e-mail: [hidden email]
> > > >>>>>>>>> For additional commands, e-mail: [hidden email]
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> E-Mail: [hidden email] | [hidden email]
> > > >>>>>>>> Java Persistence with Hibernate, Second Edition
> > > >>>>>>>> <http://www.manning.com/bauer3/>
> > > >>>>>>>> JUnit in Action, Second Edition <
> http://www.manning.com/tahchiev/
> > > >
> > > >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> > > >>>>>>>> Blog: http://garygregory.wordpress.com
> > > >>>>>>>> Home: http://garygregory.com/
> > > >>>>>>>> Tweet! http://twitter.com/GaryGregory
> > > >>>>>>>
> > > ---------------------------------------------------------------------
> > > >>>>>>> To unsubscribe, e-mail: [hidden email]
> > > >>>>>>> For additional commands, e-mail: [hidden email]
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> http://people.apache.org/~britter/
> > > >>>>>> http://www.systemoutprintln.de/
> > > >>>>>> http://twitter.com/BenediktRitter
> > > >>>>>> http://github.com/britter
> > > >>>>>
> ---------------------------------------------------------------------
> > > >>>>> To unsubscribe, e-mail: [hidden email]
> > > >>>>> For additional commands, e-mail: [hidden email]
> > > >>>>>
> > > >>>>>
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

sebb-2-2
On 17 October 2014 21:37, Romain Manni-Bucau <[hidden email]> wrote:
> Each time you break an api extract this part in compatibility (deprecated)
> n-1 jar and export new one in the v n jar. Grabbing pom dependecy you get
> by default n jars but if you want you can exclude include jars to get n-1
> apis and moreover you didnt break anything for 80% of users.

Moving deprecated classes to a separate jar is a very different issue.
That will work provided that the whole deprecated class is moved to
the compatibility jar.
A new class will need to be created for the new code.
In this case, there is no binary compatibility issue.

In my earlier example, one would deprecate the Item class, and create
Item2, or change its package.

But this can start to get quite messy quickly.

> I know it is far from being perfect but lang, collections...are often twice
> in apps. A maybe better alternative is to do smaller modules this way you
> get less impacted.
> Le 17 oct. 2014 22:21, "Duncan Jones" <[hidden email]> a écrit :
>
>> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <[hidden email]> wrote:
>> >
>> > Yes, that what i said we were not impacted even if the stack is big.
>> >
>> > Once again in theory you are right but in practise that's boring and
>> > creates averhead  for nothing.
>>
>> You're not making a lot of sense here. Sebb explained a problem with your
>> approach, but your response is that he's right in theory, but that's
>> boring?
>>
>> I don't see how a multiple jar approach could work. Can you explain?
>>
>> Duncan
>>
>> > Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :
>> >
>> > > On 17 October 2014 19:08, Romain Manni-Bucau <[hidden email]>
>> > > wrote:
>> > > > I did it twice or more. it is not magic but the goal is to put
>> > > > removed/changed classes outside the core project (yes it implies some
>> > > > modules). this way the core part (what i call core here is what
>> > > > doesn't change) stays the same with same packages and only what moves
>> > > > changes.
>> > >
>> > > I still don't get it.
>> > >
>> > > Suppose you have the following method in the Item class:
>> > >
>> > > public int getLength()
>> > >
>> > > You want to change it to
>> > >
>> > > public long getLength()
>> > >
>> > > This is not binary compatible.
>> > >
>> > > Suppose I move the int version into a legacy jar.
>> > > The long version is in the core jar.
>> > > Both are in the same class.
>> > >
>> > > Now assume that appA uses the int version, and appB has been updated
>> > > to use the long version.
>> > >
>> > > I don't see how one can make this work with Maven.
>> > > The JVM classloader can only load a single version of the Item class.
>> > >
>> > > However appA needs one version, and appB needs the other.
>> > >
>> > > Note: I know that this can be made to work with OSGI (it uses multiple
>> > > class-loaders) but that is a separate issue.
>> > >
>> > > > I know it is easier to just change everything but then you can't cry
>> > > > cause the war does 200M to pring hello ;).
>> > > >
>> > > > Using maven pom dependencies can also make it smoother using the pom
>> > > > dependency as an aggregator.
>> > > >
>> > > > it wouldn't be commons which is (are actually) everywhere I wouldn't
>> > > > care that much but commons is so widely spread that it is a bit
>> harder
>> > > > to manage (it is comparable to asm if it speaks to anyone).
>> > >
>> > >
>> > > >
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau
>> > > > http://www.tomitribe.com
>> > > > http://rmannibucau.wordpress.com
>> > > > https://github.com/rmannibucau
>> > > >
>> > > >
>> > > > 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:
>> > > >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
>> > > >>> Well maven showed the opposite. And this is clearly a theory vs
>> > > practise
>> > > >>> topic so not sure it does worth allimenting this thread since well
>> not
>> > > agree
>> > > >>
>> > > >> Top-posting this kind of statement does no good.  If you have a
>> > > >> better approach, please describe it.
>> > > >>
>> > > >> Phil
>> > > >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a
>> écrit
>> :
>> > > >>>
>> > > >>>> It's not just the broken parts that your dependencies may be
>> using.
>> > > The
>> > > >>>> strategy Commons uses is the only way any of us know to permit
>> forward
>> > > >>>> movement while avoiding jar hell.
>> > > >>>>
>> > > >>>> Matt
>> > > >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <
>> [hidden email]>
>> > > >>>> wrote:
>> > > >>>>
>> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <[hidden email]>:
>> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
>> > > [hidden email]>:
>> > > >>>>>>
>> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
>> [hidden email]
>> >:
>> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>> > > >>>>>>> [hidden email]>
>> > > >>>>>>>> wrote:
>> > > >>>>>>>>
>> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
>> [hidden email]
>> >:
>> > > >>>>>>>>>> Hi,
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
>> > > >>>>> [hidden email]
>> > > >>>>>>>> :
>> > > >>>>>>>>>> <snip>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created
>> and
>> > > now
>> > > >>>>>>> TomEE
>> > > >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs [lang]
>> > > >>>>> features,
>> > > >>>>>>>>>>> ie suppose package didn't change then we wouldn't have had
>> any
>> > > >>>>> issue.
>> > > >>>>>>>>>>> So it means you tend to import multiple versions of the
>> same
>> > > lib
>> > > >>>>> just
>> > > >>>>>>>>>>> cause few parts were broken even if it doesn't affect you.
>> > > >>>> That's
>> > > >>>>> a
>> > > >>>>>>>>>>> bit sad IMO.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>> If there is anything missing in lang3 that blocks you from
>> > > >>>>> migrating
>> > > >>>>>>>>>> completely, can you tell us what that is? Maybe we can fix
>> > > >>>> that...
>> > > >>>>>>>>> Issue is not in [commons] but in dependencies. The code we
>> own
>> > > >>>>>>>>> migrated but not all our deps.
>> > > >>>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> I suggest you ask/Jira each dep to update their [lang] to the
>> > > >>>> latest.
>> > > >>>>>>> That
>> > > >>>>>>>> has worked for me in the past with different FOSS projects
>> I've
>> > > made
>> > > >>>>> the
>> > > >>>>>>>> request about this and that libraries.
>> > > >>>>>>>>
>> > > >>>>>>>> Some projects will be receptive and at least reply to you
>> right
>> > > >>>> away,
>> > > >>>>>>>> others won't. Patches help of course since will require at
>> least
>> > > >>>>> import
>> > > >>>>>>>> changes.
>> > > >>>>>>>>
>> > > >>>>>>> yep, main issue ATM is some can't or doesn't maitain the
>> version we
>> > > >>>>>>> use - excepted for security issues (we are bound to a EE
>> version
>> > > for
>> > > >>>>>>> instance). It meanse it will be forgotten in few years but it
>> also
>> > > >>>>>>> means we can get the same with [lang3] and [lang4] so clearly
>> > > >>>>>>> something to tackle at [commons] level. We can't just ask
>> > > everybody to
>> > > >>>>>>> update each time IMHO.
>> > > >>>>>>>
>> > > >>>>>> The alternative is, that TomEE won't run at all because of
>> > > incompatible
>> > > >>>>> API
>> > > >>>>>> changes. I would vote for the lesser evil ;-)
>> > > >>>>>>
>> > > >>>>> No, if broken part are provided in a -legacy.jar or a
>> > > >>>>> -compatibility.jar there would be no issue.
>> > > >>>>>
>> > > >>>>>>>> Gary
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>>>> Benedikt
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> --
>> > > >>>>>>>>>> http://people.apache.org/~britter/
>> > > >>>>>>>>>> http://www.systemoutprintln.de/
>> > > >>>>>>>>>> http://twitter.com/BenediktRitter
>> > > >>>>>>>>>> http://github.com/britter
>> > > >>>>>>>>>
>> > > >>>>
>> ---------------------------------------------------------------------
>> > > >>>>>>>>> To unsubscribe, e-mail: [hidden email]
>> > > >>>>>>>>> For additional commands, e-mail: [hidden email]
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> --
>> > > >>>>>>>> E-Mail: [hidden email] | [hidden email]
>> > > >>>>>>>> Java Persistence with Hibernate, Second Edition
>> > > >>>>>>>> <http://www.manning.com/bauer3/>
>> > > >>>>>>>> JUnit in Action, Second Edition <
>> http://www.manning.com/tahchiev/
>> > > >
>> > > >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>> > > >>>>>>>> Blog: http://garygregory.wordpress.com
>> > > >>>>>>>> Home: http://garygregory.com/
>> > > >>>>>>>> Tweet! http://twitter.com/GaryGregory
>> > > >>>>>>>
>> > > ---------------------------------------------------------------------
>> > > >>>>>>> To unsubscribe, e-mail: [hidden email]
>> > > >>>>>>> For additional commands, e-mail: [hidden email]
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>
>> > > >>>>>> --
>> > > >>>>>> http://people.apache.org/~britter/
>> > > >>>>>> http://www.systemoutprintln.de/
>> > > >>>>>> http://twitter.com/BenediktRitter
>> > > >>>>>> http://github.com/britter
>> > > >>>>>
>> ---------------------------------------------------------------------
>> > > >>>>> To unsubscribe, e-mail: [hidden email]
>> > > >>>>> For additional commands, e-mail: [hidden email]
>> > > >>>>>
>> > > >>>>>
>> > > >>
>> > > >>
>> > > >>
>> ---------------------------------------------------------------------
>> > > >> To unsubscribe, e-mail: [hidden email]
>> > > >> For additional commands, e-mail: [hidden email]
>> > > >>
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: [hidden email]
>> > > > For additional commands, e-mail: [hidden email]
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Paul Benedict
FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
breeze. I did a wholesale replacement of the package name and then fixed
any compiler problems due to API differences.


Cheers,
Paul

On Fri, Oct 17, 2014 at 3:51 PM, sebb <[hidden email]> wrote:

> On 17 October 2014 21:37, Romain Manni-Bucau <[hidden email]>
> wrote:
> > Each time you break an api extract this part in compatibility
> (deprecated)
> > n-1 jar and export new one in the v n jar. Grabbing pom dependecy you get
> > by default n jars but if you want you can exclude include jars to get n-1
> > apis and moreover you didnt break anything for 80% of users.
>
> Moving deprecated classes to a separate jar is a very different issue.
> That will work provided that the whole deprecated class is moved to
> the compatibility jar.
> A new class will need to be created for the new code.
> In this case, there is no binary compatibility issue.
>
> In my earlier example, one would deprecate the Item class, and create
> Item2, or change its package.
>
> But this can start to get quite messy quickly.
>
> > I know it is far from being perfect but lang, collections...are often
> twice
> > in apps. A maybe better alternative is to do smaller modules this way you
> > get less impacted.
> > Le 17 oct. 2014 22:21, "Duncan Jones" <[hidden email]> a écrit :
> >
> >> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <[hidden email]>
> wrote:
> >> >
> >> > Yes, that what i said we were not impacted even if the stack is big.
> >> >
> >> > Once again in theory you are right but in practise that's boring and
> >> > creates averhead  for nothing.
> >>
> >> You're not making a lot of sense here. Sebb explained a problem with
> your
> >> approach, but your response is that he's right in theory, but that's
> >> boring?
> >>
> >> I don't see how a multiple jar approach could work. Can you explain?
> >>
> >> Duncan
> >>
> >> > Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :
> >> >
> >> > > On 17 October 2014 19:08, Romain Manni-Bucau <[hidden email]
> >
> >> > > wrote:
> >> > > > I did it twice or more. it is not magic but the goal is to put
> >> > > > removed/changed classes outside the core project (yes it implies
> some
> >> > > > modules). this way the core part (what i call core here is what
> >> > > > doesn't change) stays the same with same packages and only what
> moves
> >> > > > changes.
> >> > >
> >> > > I still don't get it.
> >> > >
> >> > > Suppose you have the following method in the Item class:
> >> > >
> >> > > public int getLength()
> >> > >
> >> > > You want to change it to
> >> > >
> >> > > public long getLength()
> >> > >
> >> > > This is not binary compatible.
> >> > >
> >> > > Suppose I move the int version into a legacy jar.
> >> > > The long version is in the core jar.
> >> > > Both are in the same class.
> >> > >
> >> > > Now assume that appA uses the int version, and appB has been updated
> >> > > to use the long version.
> >> > >
> >> > > I don't see how one can make this work with Maven.
> >> > > The JVM classloader can only load a single version of the Item
> class.
> >> > >
> >> > > However appA needs one version, and appB needs the other.
> >> > >
> >> > > Note: I know that this can be made to work with OSGI (it uses
> multiple
> >> > > class-loaders) but that is a separate issue.
> >> > >
> >> > > > I know it is easier to just change everything but then you can't
> cry
> >> > > > cause the war does 200M to pring hello ;).
> >> > > >
> >> > > > Using maven pom dependencies can also make it smoother using the
> pom
> >> > > > dependency as an aggregator.
> >> > > >
> >> > > > it wouldn't be commons which is (are actually) everywhere I
> wouldn't
> >> > > > care that much but commons is so widely spread that it is a bit
> >> harder
> >> > > > to manage (it is comparable to asm if it speaks to anyone).
> >> > >
> >> > >
> >> > > >
> >> > > >
> >> > > > Romain Manni-Bucau
> >> > > > @rmannibucau
> >> > > > http://www.tomitribe.com
> >> > > > http://rmannibucau.wordpress.com
> >> > > > https://github.com/rmannibucau
> >> > > >
> >> > > >
> >> > > > 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:
> >> > > >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> >> > > >>> Well maven showed the opposite. And this is clearly a theory vs
> >> > > practise
> >> > > >>> topic so not sure it does worth allimenting this thread since
> well
> >> not
> >> > > agree
> >> > > >>
> >> > > >> Top-posting this kind of statement does no good.  If you have a
> >> > > >> better approach, please describe it.
> >> > > >>
> >> > > >> Phil
> >> > > >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a
> >> écrit
> >> :
> >> > > >>>
> >> > > >>>> It's not just the broken parts that your dependencies may be
> >> using.
> >> > > The
> >> > > >>>> strategy Commons uses is the only way any of us know to permit
> >> forward
> >> > > >>>> movement while avoiding jar hell.
> >> > > >>>>
> >> > > >>>> Matt
> >> > > >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <
> >> [hidden email]>
> >> > > >>>> wrote:
> >> > > >>>>
> >> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <
> [hidden email]>:
> >> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> >> > > [hidden email]>:
> >> > > >>>>>>
> >> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
> >> [hidden email]
> >> >:
> >> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> >> > > >>>>>>> [hidden email]>
> >> > > >>>>>>>> wrote:
> >> > > >>>>>>>>
> >> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
> >> [hidden email]
> >> >:
> >> > > >>>>>>>>>> Hi,
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> >> > > >>>>> [hidden email]
> >> > > >>>>>>>> :
> >> > > >>>>>>>>>> <snip>
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created
> >> and
> >> > > now
> >> > > >>>>>>> TomEE
> >> > > >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs
> [lang]
> >> > > >>>>> features,
> >> > > >>>>>>>>>>> ie suppose package didn't change then we wouldn't have
> had
> >> any
> >> > > >>>>> issue.
> >> > > >>>>>>>>>>> So it means you tend to import multiple versions of the
> >> same
> >> > > lib
> >> > > >>>>> just
> >> > > >>>>>>>>>>> cause few parts were broken even if it doesn't affect
> you.
> >> > > >>>> That's
> >> > > >>>>> a
> >> > > >>>>>>>>>>> bit sad IMO.
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>> If there is anything missing in lang3 that blocks you
> from
> >> > > >>>>> migrating
> >> > > >>>>>>>>>> completely, can you tell us what that is? Maybe we can
> fix
> >> > > >>>> that...
> >> > > >>>>>>>>> Issue is not in [commons] but in dependencies. The code we
> >> own
> >> > > >>>>>>>>> migrated but not all our deps.
> >> > > >>>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>> I suggest you ask/Jira each dep to update their [lang] to
> the
> >> > > >>>> latest.
> >> > > >>>>>>> That
> >> > > >>>>>>>> has worked for me in the past with different FOSS projects
> >> I've
> >> > > made
> >> > > >>>>> the
> >> > > >>>>>>>> request about this and that libraries.
> >> > > >>>>>>>>
> >> > > >>>>>>>> Some projects will be receptive and at least reply to you
> >> right
> >> > > >>>> away,
> >> > > >>>>>>>> others won't. Patches help of course since will require at
> >> least
> >> > > >>>>> import
> >> > > >>>>>>>> changes.
> >> > > >>>>>>>>
> >> > > >>>>>>> yep, main issue ATM is some can't or doesn't maitain the
> >> version we
> >> > > >>>>>>> use - excepted for security issues (we are bound to a EE
> >> version
> >> > > for
> >> > > >>>>>>> instance). It meanse it will be forgotten in few years but
> it
> >> also
> >> > > >>>>>>> means we can get the same with [lang3] and [lang4] so
> clearly
> >> > > >>>>>>> something to tackle at [commons] level. We can't just ask
> >> > > everybody to
> >> > > >>>>>>> update each time IMHO.
> >> > > >>>>>>>
> >> > > >>>>>> The alternative is, that TomEE won't run at all because of
> >> > > incompatible
> >> > > >>>>> API
> >> > > >>>>>> changes. I would vote for the lesser evil ;-)
> >> > > >>>>>>
> >> > > >>>>> No, if broken part are provided in a -legacy.jar or a
> >> > > >>>>> -compatibility.jar there would be no issue.
> >> > > >>>>>
> >> > > >>>>>>>> Gary
> >> > > >>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>>>> Benedikt
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>> --
> >> > > >>>>>>>>>> http://people.apache.org/~britter/
> >> > > >>>>>>>>>> http://www.systemoutprintln.de/
> >> > > >>>>>>>>>> http://twitter.com/BenediktRitter
> >> > > >>>>>>>>>> http://github.com/britter
> >> > > >>>>>>>>>
> >> > > >>>>
> >> ---------------------------------------------------------------------
> >> > > >>>>>>>>> To unsubscribe, e-mail:
> [hidden email]
> >> > > >>>>>>>>> For additional commands, e-mail:
> [hidden email]
> >> > > >>>>>>>>>
> >> > > >>>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>> --
> >> > > >>>>>>>> E-Mail: [hidden email] | [hidden email]
> >> > > >>>>>>>> Java Persistence with Hibernate, Second Edition
> >> > > >>>>>>>> <http://www.manning.com/bauer3/>
> >> > > >>>>>>>> JUnit in Action, Second Edition <
> >> http://www.manning.com/tahchiev/
> >> > > >
> >> > > >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >> > > >>>>>>>> Blog: http://garygregory.wordpress.com
> >> > > >>>>>>>> Home: http://garygregory.com/
> >> > > >>>>>>>> Tweet! http://twitter.com/GaryGregory
> >> > > >>>>>>>
> >> > >
> ---------------------------------------------------------------------
> >> > > >>>>>>> To unsubscribe, e-mail: [hidden email]
> >> > > >>>>>>> For additional commands, e-mail:
> [hidden email]
> >> > > >>>>>>>
> >> > > >>>>>>>
> >> > > >>>>>>
> >> > > >>>>>> --
> >> > > >>>>>> http://people.apache.org/~britter/
> >> > > >>>>>> http://www.systemoutprintln.de/
> >> > > >>>>>> http://twitter.com/BenediktRitter
> >> > > >>>>>> http://github.com/britter
> >> > > >>>>>
> >> ---------------------------------------------------------------------
> >> > > >>>>> To unsubscribe, e-mail: [hidden email]
> >> > > >>>>> For additional commands, e-mail: [hidden email]
> >> > > >>>>>
> >> > > >>>>>
> >> > > >>
> >> > > >>
> >> > > >>
> >> ---------------------------------------------------------------------
> >> > > >> To unsubscribe, e-mail: [hidden email]
> >> > > >> For additional commands, e-mail: [hidden email]
> >> > > >>
> >> > > >
> >> > > >
> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: [hidden email]
> >> > > > For additional commands, e-mail: [hidden email]
> >> > > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: [hidden email]
> >> > > For additional commands, e-mail: [hidden email]
> >> > >
> >> > >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

sebb-2-2
On 17 October 2014 21:57, Paul Benedict <[hidden email]> wrote:
> FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
> breeze. I did a wholesale replacement of the package name and then fixed
> any compiler problems due to API differences.

Which is why we do it that way, rather than renaming individual classes.

>
> Cheers,
> Paul
>
> On Fri, Oct 17, 2014 at 3:51 PM, sebb <[hidden email]> wrote:
>
>> On 17 October 2014 21:37, Romain Manni-Bucau <[hidden email]>
>> wrote:
>> > Each time you break an api extract this part in compatibility
>> (deprecated)
>> > n-1 jar and export new one in the v n jar. Grabbing pom dependecy you get
>> > by default n jars but if you want you can exclude include jars to get n-1
>> > apis and moreover you didnt break anything for 80% of users.
>>
>> Moving deprecated classes to a separate jar is a very different issue.
>> That will work provided that the whole deprecated class is moved to
>> the compatibility jar.
>> A new class will need to be created for the new code.
>> In this case, there is no binary compatibility issue.
>>
>> In my earlier example, one would deprecate the Item class, and create
>> Item2, or change its package.
>>
>> But this can start to get quite messy quickly.
>>
>> > I know it is far from being perfect but lang, collections...are often
>> twice
>> > in apps. A maybe better alternative is to do smaller modules this way you
>> > get less impacted.
>> > Le 17 oct. 2014 22:21, "Duncan Jones" <[hidden email]> a écrit :
>> >
>> >> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <[hidden email]>
>> wrote:
>> >> >
>> >> > Yes, that what i said we were not impacted even if the stack is big.
>> >> >
>> >> > Once again in theory you are right but in practise that's boring and
>> >> > creates averhead  for nothing.
>> >>
>> >> You're not making a lot of sense here. Sebb explained a problem with
>> your
>> >> approach, but your response is that he's right in theory, but that's
>> >> boring?
>> >>
>> >> I don't see how a multiple jar approach could work. Can you explain?
>> >>
>> >> Duncan
>> >>
>> >> > Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :
>> >> >
>> >> > > On 17 October 2014 19:08, Romain Manni-Bucau <[hidden email]
>> >
>> >> > > wrote:
>> >> > > > I did it twice or more. it is not magic but the goal is to put
>> >> > > > removed/changed classes outside the core project (yes it implies
>> some
>> >> > > > modules). this way the core part (what i call core here is what
>> >> > > > doesn't change) stays the same with same packages and only what
>> moves
>> >> > > > changes.
>> >> > >
>> >> > > I still don't get it.
>> >> > >
>> >> > > Suppose you have the following method in the Item class:
>> >> > >
>> >> > > public int getLength()
>> >> > >
>> >> > > You want to change it to
>> >> > >
>> >> > > public long getLength()
>> >> > >
>> >> > > This is not binary compatible.
>> >> > >
>> >> > > Suppose I move the int version into a legacy jar.
>> >> > > The long version is in the core jar.
>> >> > > Both are in the same class.
>> >> > >
>> >> > > Now assume that appA uses the int version, and appB has been updated
>> >> > > to use the long version.
>> >> > >
>> >> > > I don't see how one can make this work with Maven.
>> >> > > The JVM classloader can only load a single version of the Item
>> class.
>> >> > >
>> >> > > However appA needs one version, and appB needs the other.
>> >> > >
>> >> > > Note: I know that this can be made to work with OSGI (it uses
>> multiple
>> >> > > class-loaders) but that is a separate issue.
>> >> > >
>> >> > > > I know it is easier to just change everything but then you can't
>> cry
>> >> > > > cause the war does 200M to pring hello ;).
>> >> > > >
>> >> > > > Using maven pom dependencies can also make it smoother using the
>> pom
>> >> > > > dependency as an aggregator.
>> >> > > >
>> >> > > > it wouldn't be commons which is (are actually) everywhere I
>> wouldn't
>> >> > > > care that much but commons is so widely spread that it is a bit
>> >> harder
>> >> > > > to manage (it is comparable to asm if it speaks to anyone).
>> >> > >
>> >> > >
>> >> > > >
>> >> > > >
>> >> > > > Romain Manni-Bucau
>> >> > > > @rmannibucau
>> >> > > > http://www.tomitribe.com
>> >> > > > http://rmannibucau.wordpress.com
>> >> > > > https://github.com/rmannibucau
>> >> > > >
>> >> > > >
>> >> > > > 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]>:
>> >> > > >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
>> >> > > >>> Well maven showed the opposite. And this is clearly a theory vs
>> >> > > practise
>> >> > > >>> topic so not sure it does worth allimenting this thread since
>> well
>> >> not
>> >> > > agree
>> >> > > >>
>> >> > > >> Top-posting this kind of statement does no good.  If you have a
>> >> > > >> better approach, please describe it.
>> >> > > >>
>> >> > > >> Phil
>> >> > > >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]> a
>> >> écrit
>> >> :
>> >> > > >>>
>> >> > > >>>> It's not just the broken parts that your dependencies may be
>> >> using.
>> >> > > The
>> >> > > >>>> strategy Commons uses is the only way any of us know to permit
>> >> forward
>> >> > > >>>> movement while avoiding jar hell.
>> >> > > >>>>
>> >> > > >>>> Matt
>> >> > > >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <
>> >> [hidden email]>
>> >> > > >>>> wrote:
>> >> > > >>>>
>> >> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <
>> [hidden email]>:
>> >> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
>> >> > > [hidden email]>:
>> >> > > >>>>>>
>> >> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
>> >> [hidden email]
>> >> >:
>> >> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
>> >> > > >>>>>>> [hidden email]>
>> >> > > >>>>>>>> wrote:
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
>> >> [hidden email]
>> >> >:
>> >> > > >>>>>>>>>> Hi,
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
>> >> > > >>>>> [hidden email]
>> >> > > >>>>>>>> :
>> >> > > >>>>>>>>>> <snip>
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was created
>> >> and
>> >> > > now
>> >> > > >>>>>>> TomEE
>> >> > > >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs
>> [lang]
>> >> > > >>>>> features,
>> >> > > >>>>>>>>>>> ie suppose package didn't change then we wouldn't have
>> had
>> >> any
>> >> > > >>>>> issue.
>> >> > > >>>>>>>>>>> So it means you tend to import multiple versions of the
>> >> same
>> >> > > lib
>> >> > > >>>>> just
>> >> > > >>>>>>>>>>> cause few parts were broken even if it doesn't affect
>> you.
>> >> > > >>>> That's
>> >> > > >>>>> a
>> >> > > >>>>>>>>>>> bit sad IMO.
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>> If there is anything missing in lang3 that blocks you
>> from
>> >> > > >>>>> migrating
>> >> > > >>>>>>>>>> completely, can you tell us what that is? Maybe we can
>> fix
>> >> > > >>>> that...
>> >> > > >>>>>>>>> Issue is not in [commons] but in dependencies. The code we
>> >> own
>> >> > > >>>>>>>>> migrated but not all our deps.
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> I suggest you ask/Jira each dep to update their [lang] to
>> the
>> >> > > >>>> latest.
>> >> > > >>>>>>> That
>> >> > > >>>>>>>> has worked for me in the past with different FOSS projects
>> >> I've
>> >> > > made
>> >> > > >>>>> the
>> >> > > >>>>>>>> request about this and that libraries.
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> Some projects will be receptive and at least reply to you
>> >> right
>> >> > > >>>> away,
>> >> > > >>>>>>>> others won't. Patches help of course since will require at
>> >> least
>> >> > > >>>>> import
>> >> > > >>>>>>>> changes.
>> >> > > >>>>>>>>
>> >> > > >>>>>>> yep, main issue ATM is some can't or doesn't maitain the
>> >> version we
>> >> > > >>>>>>> use - excepted for security issues (we are bound to a EE
>> >> version
>> >> > > for
>> >> > > >>>>>>> instance). It meanse it will be forgotten in few years but
>> it
>> >> also
>> >> > > >>>>>>> means we can get the same with [lang3] and [lang4] so
>> clearly
>> >> > > >>>>>>> something to tackle at [commons] level. We can't just ask
>> >> > > everybody to
>> >> > > >>>>>>> update each time IMHO.
>> >> > > >>>>>>>
>> >> > > >>>>>> The alternative is, that TomEE won't run at all because of
>> >> > > incompatible
>> >> > > >>>>> API
>> >> > > >>>>>> changes. I would vote for the lesser evil ;-)
>> >> > > >>>>>>
>> >> > > >>>>> No, if broken part are provided in a -legacy.jar or a
>> >> > > >>>>> -compatibility.jar there would be no issue.
>> >> > > >>>>>
>> >> > > >>>>>>>> Gary
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>>> Benedikt
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>> --
>> >> > > >>>>>>>>>> http://people.apache.org/~britter/
>> >> > > >>>>>>>>>> http://www.systemoutprintln.de/
>> >> > > >>>>>>>>>> http://twitter.com/BenediktRitter
>> >> > > >>>>>>>>>> http://github.com/britter
>> >> > > >>>>>>>>>
>> >> > > >>>>
>> >> ---------------------------------------------------------------------
>> >> > > >>>>>>>>> To unsubscribe, e-mail:
>> [hidden email]
>> >> > > >>>>>>>>> For additional commands, e-mail:
>> [hidden email]
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> --
>> >> > > >>>>>>>> E-Mail: [hidden email] | [hidden email]
>> >> > > >>>>>>>> Java Persistence with Hibernate, Second Edition
>> >> > > >>>>>>>> <http://www.manning.com/bauer3/>
>> >> > > >>>>>>>> JUnit in Action, Second Edition <
>> >> http://www.manning.com/tahchiev/
>> >> > > >
>> >> > > >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>> >> > > >>>>>>>> Blog: http://garygregory.wordpress.com
>> >> > > >>>>>>>> Home: http://garygregory.com/
>> >> > > >>>>>>>> Tweet! http://twitter.com/GaryGregory
>> >> > > >>>>>>>
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > >>>>>>> To unsubscribe, e-mail: [hidden email]
>> >> > > >>>>>>> For additional commands, e-mail:
>> [hidden email]
>> >> > > >>>>>>>
>> >> > > >>>>>>>
>> >> > > >>>>>>
>> >> > > >>>>>> --
>> >> > > >>>>>> http://people.apache.org/~britter/
>> >> > > >>>>>> http://www.systemoutprintln.de/
>> >> > > >>>>>> http://twitter.com/BenediktRitter
>> >> > > >>>>>> http://github.com/britter
>> >> > > >>>>>
>> >> ---------------------------------------------------------------------
>> >> > > >>>>> To unsubscribe, e-mail: [hidden email]
>> >> > > >>>>> For additional commands, e-mail: [hidden email]
>> >> > > >>>>>
>> >> > > >>>>>
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> ---------------------------------------------------------------------
>> >> > > >> To unsubscribe, e-mail: [hidden email]
>> >> > > >> For additional commands, e-mail: [hidden email]
>> >> > > >>
>> >> > > >
>> >> > > >
>> ---------------------------------------------------------------------
>> >> > > > To unsubscribe, e-mail: [hidden email]
>> >> > > > For additional commands, e-mail: [hidden email]
>> >> > > >
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: [hidden email]
>> >> > > For additional commands, e-mail: [hidden email]
>> >> > >
>> >> > >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Romain Manni-Bucau
Le 17 oct. 2014 23:09, "sebb" <[hidden email]> a écrit :
>
> On 17 October 2014 21:57, Paul Benedict <[hidden email]> wrote:
> > FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
> > breeze. I did a wholesale replacement of the package name and then fixed
> > any compiler problems due to API differences.
>

When you own the code sure, that's the only issue.

> Which is why we do it that way, rather than renaming individual classes.
>
> >
> > Cheers,
> > Paul
> >
> > On Fri, Oct 17, 2014 at 3:51 PM, sebb <[hidden email]> wrote:
> >
> >> On 17 October 2014 21:37, Romain Manni-Bucau <[hidden email]>
> >> wrote:
> >> > Each time you break an api extract this part in compatibility
> >> (deprecated)
> >> > n-1 jar and export new one in the v n jar. Grabbing pom dependecy
you get
> >> > by default n jars but if you want you can exclude include jars to
get n-1

> >> > apis and moreover you didnt break anything for 80% of users.
> >>
> >> Moving deprecated classes to a separate jar is a very different issue.
> >> That will work provided that the whole deprecated class is moved to
> >> the compatibility jar.
> >> A new class will need to be created for the new code.
> >> In this case, there is no binary compatibility issue.
> >>
> >> In my earlier example, one would deprecate the Item class, and create
> >> Item2, or change its package.
> >>
> >> But this can start to get quite messy quickly.
> >>
> >> > I know it is far from being perfect but lang, collections...are often
> >> twice
> >> > in apps. A maybe better alternative is to do smaller modules this
way you
> >> > get less impacted.
> >> > Le 17 oct. 2014 22:21, "Duncan Jones" <[hidden email]> a écrit :
> >> >
> >> >> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <[hidden email]>
> >> wrote:
> >> >> >
> >> >> > Yes, that what i said we were not impacted even if the stack is
big.
> >> >> >
> >> >> > Once again in theory you are right but in practise that's boring
and

> >> >> > creates averhead  for nothing.
> >> >>
> >> >> You're not making a lot of sense here. Sebb explained a problem with
> >> your
> >> >> approach, but your response is that he's right in theory, but that's
> >> >> boring?
> >> >>
> >> >> I don't see how a multiple jar approach could work. Can you explain?
> >> >>
> >> >> Duncan
> >> >>
> >> >> > Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :
> >> >> >
> >> >> > > On 17 October 2014 19:08, Romain Manni-Bucau <
[hidden email]
> >> >
> >> >> > > wrote:
> >> >> > > > I did it twice or more. it is not magic but the goal is to put
> >> >> > > > removed/changed classes outside the core project (yes it
implies
> >> some
> >> >> > > > modules). this way the core part (what i call core here is
what
> >> >> > > > doesn't change) stays the same with same packages and only
what

> >> moves
> >> >> > > > changes.
> >> >> > >
> >> >> > > I still don't get it.
> >> >> > >
> >> >> > > Suppose you have the following method in the Item class:
> >> >> > >
> >> >> > > public int getLength()
> >> >> > >
> >> >> > > You want to change it to
> >> >> > >
> >> >> > > public long getLength()
> >> >> > >
> >> >> > > This is not binary compatible.
> >> >> > >
> >> >> > > Suppose I move the int version into a legacy jar.
> >> >> > > The long version is in the core jar.
> >> >> > > Both are in the same class.
> >> >> > >
> >> >> > > Now assume that appA uses the int version, and appB has been
updated

> >> >> > > to use the long version.
> >> >> > >
> >> >> > > I don't see how one can make this work with Maven.
> >> >> > > The JVM classloader can only load a single version of the Item
> >> class.
> >> >> > >
> >> >> > > However appA needs one version, and appB needs the other.
> >> >> > >
> >> >> > > Note: I know that this can be made to work with OSGI (it uses
> >> multiple
> >> >> > > class-loaders) but that is a separate issue.
> >> >> > >
> >> >> > > > I know it is easier to just change everything but then you
can't
> >> cry
> >> >> > > > cause the war does 200M to pring hello ;).
> >> >> > > >
> >> >> > > > Using maven pom dependencies can also make it smoother using
the
> >> pom
> >> >> > > > dependency as an aggregator.
> >> >> > > >
> >> >> > > > it wouldn't be commons which is (are actually) everywhere I
> >> wouldn't
> >> >> > > > care that much but commons is so widely spread that it is a
bit

> >> >> harder
> >> >> > > > to manage (it is comparable to asm if it speaks to anyone).
> >> >> > >
> >> >> > >
> >> >> > > >
> >> >> > > >
> >> >> > > > Romain Manni-Bucau
> >> >> > > > @rmannibucau
> >> >> > > > http://www.tomitribe.com
> >> >> > > > http://rmannibucau.wordpress.com
> >> >> > > > https://github.com/rmannibucau
> >> >> > > >
> >> >> > > >
> >> >> > > > 2014-10-17 20:02 GMT+02:00 Phil Steitz <[hidden email]
>:
> >> >> > > >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> >> >> > > >>> Well maven showed the opposite. And this is clearly a
theory vs
> >> >> > > practise
> >> >> > > >>> topic so not sure it does worth allimenting this thread
since
> >> well
> >> >> not
> >> >> > > agree
> >> >> > > >>
> >> >> > > >> Top-posting this kind of statement does no good.  If you
have a
> >> >> > > >> better approach, please describe it.
> >> >> > > >>
> >> >> > > >> Phil
> >> >> > > >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]>
a
> >> >> écrit
> >> >> :
> >> >> > > >>>
> >> >> > > >>>> It's not just the broken parts that your dependencies may
be
> >> >> using.
> >> >> > > The
> >> >> > > >>>> strategy Commons uses is the only way any of us know to
permit

> >> >> forward
> >> >> > > >>>> movement while avoiding jar hell.
> >> >> > > >>>>
> >> >> > > >>>> Matt
> >> >> > > >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <
> >> >> [hidden email]>
> >> >> > > >>>> wrote:
> >> >> > > >>>>
> >> >> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <
> >> [hidden email]>:
> >> >> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> >> >> > > [hidden email]>:
> >> >> > > >>>>>>
> >> >> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
> >> >> [hidden email]
> >> >> >:
> >> >> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> >> >> > > >>>>>>> [hidden email]>
> >> >> > > >>>>>>>> wrote:
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
> >> >> [hidden email]
> >> >> >:
> >> >> > > >>>>>>>>>> Hi,
> >> >> > > >>>>>>>>>>
> >> >> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> >> >> > > >>>>> [hidden email]
> >> >> > > >>>>>>>> :
> >> >> > > >>>>>>>>>> <snip>
> >> >> > > >>>>>>>>>>
> >> >> > > >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was
created
> >> >> and
> >> >> > > now
> >> >> > > >>>>>>> TomEE
> >> >> > > >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs
> >> [lang]
> >> >> > > >>>>> features,
> >> >> > > >>>>>>>>>>> ie suppose package didn't change then we wouldn't
have
> >> had
> >> >> any
> >> >> > > >>>>> issue.
> >> >> > > >>>>>>>>>>> So it means you tend to import multiple versions of
the
> >> >> same
> >> >> > > lib
> >> >> > > >>>>> just
> >> >> > > >>>>>>>>>>> cause few parts were broken even if it doesn't
affect
> >> you.
> >> >> > > >>>> That's
> >> >> > > >>>>> a
> >> >> > > >>>>>>>>>>> bit sad IMO.
> >> >> > > >>>>>>>>>>>
> >> >> > > >>>>>>>>>> If there is anything missing in lang3 that blocks you
> >> from
> >> >> > > >>>>> migrating
> >> >> > > >>>>>>>>>> completely, can you tell us what that is? Maybe we
can
> >> fix
> >> >> > > >>>> that...
> >> >> > > >>>>>>>>> Issue is not in [commons] but in dependencies. The
code we
> >> >> own
> >> >> > > >>>>>>>>> migrated but not all our deps.
> >> >> > > >>>>>>>>>
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>> I suggest you ask/Jira each dep to update their [lang]
to
> >> the
> >> >> > > >>>> latest.
> >> >> > > >>>>>>> That
> >> >> > > >>>>>>>> has worked for me in the past with different FOSS
projects
> >> >> I've
> >> >> > > made
> >> >> > > >>>>> the
> >> >> > > >>>>>>>> request about this and that libraries.
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>> Some projects will be receptive and at least reply to
you
> >> >> right
> >> >> > > >>>> away,
> >> >> > > >>>>>>>> others won't. Patches help of course since will
require at

> >> >> least
> >> >> > > >>>>> import
> >> >> > > >>>>>>>> changes.
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>> yep, main issue ATM is some can't or doesn't maitain the
> >> >> version we
> >> >> > > >>>>>>> use - excepted for security issues (we are bound to a EE
> >> >> version
> >> >> > > for
> >> >> > > >>>>>>> instance). It meanse it will be forgotten in few years
but
> >> it
> >> >> also
> >> >> > > >>>>>>> means we can get the same with [lang3] and [lang4] so
> >> clearly
> >> >> > > >>>>>>> something to tackle at [commons] level. We can't just
ask
> >> >> > > everybody to
> >> >> > > >>>>>>> update each time IMHO.
> >> >> > > >>>>>>>
> >> >> > > >>>>>> The alternative is, that TomEE won't run at all because
of

> >> >> > > incompatible
> >> >> > > >>>>> API
> >> >> > > >>>>>> changes. I would vote for the lesser evil ;-)
> >> >> > > >>>>>>
> >> >> > > >>>>> No, if broken part are provided in a -legacy.jar or a
> >> >> > > >>>>> -compatibility.jar there would be no issue.
> >> >> > > >>>>>
> >> >> > > >>>>>>>> Gary
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>>>> Benedikt
> >> >> > > >>>>>>>>>>
> >> >> > > >>>>>>>>>>
> >> >> > > >>>>>>>>>> --
> >> >> > > >>>>>>>>>> http://people.apache.org/~britter/
> >> >> > > >>>>>>>>>> http://www.systemoutprintln.de/
> >> >> > > >>>>>>>>>> http://twitter.com/BenediktRitter
> >> >> > > >>>>>>>>>> http://github.com/britter
> >> >> > > >>>>>>>>>
> >> >> > > >>>>
> >> >>
---------------------------------------------------------------------

> >> >> > > >>>>>>>>> To unsubscribe, e-mail:
> >> [hidden email]
> >> >> > > >>>>>>>>> For additional commands, e-mail:
> >> [hidden email]
> >> >> > > >>>>>>>>>
> >> >> > > >>>>>>>>>
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>> --
> >> >> > > >>>>>>>> E-Mail: [hidden email] | [hidden email]
> >> >> > > >>>>>>>> Java Persistence with Hibernate, Second Edition
> >> >> > > >>>>>>>> <http://www.manning.com/bauer3/>
> >> >> > > >>>>>>>> JUnit in Action, Second Edition <
> >> >> http://www.manning.com/tahchiev/
> >> >> > > >
> >> >> > > >>>>>>>> Spring Batch in Action <
http://www.manning.com/templier/>
> >> >> > > >>>>>>>> Blog: http://garygregory.wordpress.com
> >> >> > > >>>>>>>> Home: http://garygregory.com/
> >> >> > > >>>>>>>> Tweet! http://twitter.com/GaryGregory
> >> >> > > >>>>>>>
> >> >> > >
> >> ---------------------------------------------------------------------
> >> >> > > >>>>>>> To unsubscribe, e-mail:
[hidden email]

> >> >> > > >>>>>>> For additional commands, e-mail:
> >> [hidden email]
> >> >> > > >>>>>>>
> >> >> > > >>>>>>>
> >> >> > > >>>>>>
> >> >> > > >>>>>> --
> >> >> > > >>>>>> http://people.apache.org/~britter/
> >> >> > > >>>>>> http://www.systemoutprintln.de/
> >> >> > > >>>>>> http://twitter.com/BenediktRitter
> >> >> > > >>>>>> http://github.com/britter
> >> >> > > >>>>>
> >> >>
---------------------------------------------------------------------
> >> >> > > >>>>> To unsubscribe, e-mail: [hidden email]
> >> >> > > >>>>> For additional commands, e-mail:
[hidden email]
> >> >> > > >>>>>
> >> >> > > >>>>>
> >> >> > > >>
> >> >> > > >>
> >> >> > > >>
> >> >>
---------------------------------------------------------------------

> >> >> > > >> To unsubscribe, e-mail: [hidden email]
> >> >> > > >> For additional commands, e-mail: [hidden email]
> >> >> > > >>
> >> >> > > >
> >> >> > > >
> >> ---------------------------------------------------------------------
> >> >> > > > To unsubscribe, e-mail: [hidden email]
> >> >> > > > For additional commands, e-mail: [hidden email]
> >> >> > > >
> >> >> > >
> >> >> > >
> >> ---------------------------------------------------------------------
> >> >> > > To unsubscribe, e-mail: [hidden email]
> >> >> > > For additional commands, e-mail: [hidden email]
> >> >> > >
> >> >> > >
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Differences in commons-lang (2.x) and commons-lang3 prevent TomEE project from migrating completely (Was: Re: [JCS] release?)

Paul Benedict
I don't understand the point your making. Because the two libraries have
their code in completely separate packages, there will never be a conflict
at compile time or runtime.


Cheers,
Paul

On Sat, Oct 18, 2014 at 2:21 AM, Romain Manni-Bucau <[hidden email]>
wrote:

> Le 17 oct. 2014 23:09, "sebb" <[hidden email]> a écrit :
> >
> > On 17 October 2014 21:57, Paul Benedict <[hidden email]> wrote:
> > > FWIW, I have found no difficulty moving code from lang2 to lang3. It's
> a
> > > breeze. I did a wholesale replacement of the package name and then
> fixed
> > > any compiler problems due to API differences.
> >
>
> When you own the code sure, that's the only issue.
>
> > Which is why we do it that way, rather than renaming individual classes.
> >
> > >
> > > Cheers,
> > > Paul
> > >
> > > On Fri, Oct 17, 2014 at 3:51 PM, sebb <[hidden email]> wrote:
> > >
> > >> On 17 October 2014 21:37, Romain Manni-Bucau <[hidden email]>
> > >> wrote:
> > >> > Each time you break an api extract this part in compatibility
> > >> (deprecated)
> > >> > n-1 jar and export new one in the v n jar. Grabbing pom dependecy
> you get
> > >> > by default n jars but if you want you can exclude include jars to
> get n-1
> > >> > apis and moreover you didnt break anything for 80% of users.
> > >>
> > >> Moving deprecated classes to a separate jar is a very different issue.
> > >> That will work provided that the whole deprecated class is moved to
> > >> the compatibility jar.
> > >> A new class will need to be created for the new code.
> > >> In this case, there is no binary compatibility issue.
> > >>
> > >> In my earlier example, one would deprecate the Item class, and create
> > >> Item2, or change its package.
> > >>
> > >> But this can start to get quite messy quickly.
> > >>
> > >> > I know it is far from being perfect but lang, collections...are
> often
> > >> twice
> > >> > in apps. A maybe better alternative is to do smaller modules this
> way you
> > >> > get less impacted.
> > >> > Le 17 oct. 2014 22:21, "Duncan Jones" <[hidden email]> a écrit :
> > >> >
> > >> >> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <[hidden email]>
> > >> wrote:
> > >> >> >
> > >> >> > Yes, that what i said we were not impacted even if the stack is
> big.
> > >> >> >
> > >> >> > Once again in theory you are right but in practise that's boring
> and
> > >> >> > creates averhead  for nothing.
> > >> >>
> > >> >> You're not making a lot of sense here. Sebb explained a problem
> with
> > >> your
> > >> >> approach, but your response is that he's right in theory, but
> that's
> > >> >> boring?
> > >> >>
> > >> >> I don't see how a multiple jar approach could work. Can you
> explain?
> > >> >>
> > >> >> Duncan
> > >> >>
> > >> >> > Le 17 oct. 2014 22:08, "sebb" <[hidden email]> a écrit :
> > >> >> >
> > >> >> > > On 17 October 2014 19:08, Romain Manni-Bucau <
> [hidden email]
> > >> >
> > >> >> > > wrote:
> > >> >> > > > I did it twice or more. it is not magic but the goal is to
> put
> > >> >> > > > removed/changed classes outside the core project (yes it
> implies
> > >> some
> > >> >> > > > modules). this way the core part (what i call core here is
> what
> > >> >> > > > doesn't change) stays the same with same packages and only
> what
> > >> moves
> > >> >> > > > changes.
> > >> >> > >
> > >> >> > > I still don't get it.
> > >> >> > >
> > >> >> > > Suppose you have the following method in the Item class:
> > >> >> > >
> > >> >> > > public int getLength()
> > >> >> > >
> > >> >> > > You want to change it to
> > >> >> > >
> > >> >> > > public long getLength()
> > >> >> > >
> > >> >> > > This is not binary compatible.
> > >> >> > >
> > >> >> > > Suppose I move the int version into a legacy jar.
> > >> >> > > The long version is in the core jar.
> > >> >> > > Both are in the same class.
> > >> >> > >
> > >> >> > > Now assume that appA uses the int version, and appB has been
> updated
> > >> >> > > to use the long version.
> > >> >> > >
> > >> >> > > I don't see how one can make this work with Maven.
> > >> >> > > The JVM classloader can only load a single version of the Item
> > >> class.
> > >> >> > >
> > >> >> > > However appA needs one version, and appB needs the other.
> > >> >> > >
> > >> >> > > Note: I know that this can be made to work with OSGI (it uses
> > >> multiple
> > >> >> > > class-loaders) but that is a separate issue.
> > >> >> > >
> > >> >> > > > I know it is easier to just change everything but then you
> can't
> > >> cry
> > >> >> > > > cause the war does 200M to pring hello ;).
> > >> >> > > >
> > >> >> > > > Using maven pom dependencies can also make it smoother using
> the
> > >> pom
> > >> >> > > > dependency as an aggregator.
> > >> >> > > >
> > >> >> > > > it wouldn't be commons which is (are actually) everywhere I
> > >> wouldn't
> > >> >> > > > care that much but commons is so widely spread that it is a
> bit
> > >> >> harder
> > >> >> > > > to manage (it is comparable to asm if it speaks to anyone).
> > >> >> > >
> > >> >> > >
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > Romain Manni-Bucau
> > >> >> > > > @rmannibucau
> > >> >> > > > http://www.tomitribe.com
> > >> >> > > > http://rmannibucau.wordpress.com
> > >> >> > > > https://github.com/rmannibucau
> > >> >> > > >
> > >> >> > > >
> > >> >> > > > 2014-10-17 20:02 GMT+02:00 Phil Steitz <
> [hidden email]
> >:
> > >> >> > > >> On 10/17/14 6:57 AM, Romain Manni-Bucau wrote:
> > >> >> > > >>> Well maven showed the opposite. And this is clearly a
> theory vs
> > >> >> > > practise
> > >> >> > > >>> topic so not sure it does worth allimenting this thread
> since
> > >> well
> > >> >> not
> > >> >> > > agree
> > >> >> > > >>
> > >> >> > > >> Top-posting this kind of statement does no good.  If you
> have a
> > >> >> > > >> better approach, please describe it.
> > >> >> > > >>
> > >> >> > > >> Phil
> > >> >> > > >>> Le 17 oct. 2014 15:52, "Matt Benson" <[hidden email]
> >
> a
> > >> >> écrit
> > >> >> :
> > >> >> > > >>>
> > >> >> > > >>>> It's not just the broken parts that your dependencies may
> be
> > >> >> using.
> > >> >> > > The
> > >> >> > > >>>> strategy Commons uses is the only way any of us know to
> permit
> > >> >> forward
> > >> >> > > >>>> movement while avoiding jar hell.
> > >> >> > > >>>>
> > >> >> > > >>>> Matt
> > >> >> > > >>>> On Oct 17, 2014 8:35 AM, "Romain Manni-Bucau" <
> > >> >> [hidden email]>
> > >> >> > > >>>> wrote:
> > >> >> > > >>>>
> > >> >> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <
> > >> [hidden email]>:
> > >> >> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> > >> >> > > [hidden email]>:
> > >> >> > > >>>>>>
> > >> >> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
> > >> >> [hidden email]
> > >> >> >:
> > >> >> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> > >> >> > > >>>>>>> [hidden email]>
> > >> >> > > >>>>>>>> wrote:
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
> > >> >> [hidden email]
> > >> >> >:
> > >> >> > > >>>>>>>>>> Hi,
> > >> >> > > >>>>>>>>>>
> > >> >> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> > >> >> > > >>>>> [hidden email]
> > >> >> > > >>>>>>>> :
> > >> >> > > >>>>>>>>>> <snip>
> > >> >> > > >>>>>>>>>>
> > >> >> > > >>>>>>>>>>> In TomEE the stack uses [lang], then [lang3] was
> created
> > >> >> and
> > >> >> > > now
> > >> >> > > >>>>>>> TomEE
> > >> >> > > >>>>>>>>>>> needs [lang] + [lang3] where actually it only needs
> > >> [lang]
> > >> >> > > >>>>> features,
> > >> >> > > >>>>>>>>>>> ie suppose package didn't change then we wouldn't
> have
> > >> had
> > >> >> any
> > >> >> > > >>>>> issue.
> > >> >> > > >>>>>>>>>>> So it means you tend to import multiple versions of
> the
> > >> >> same
> > >> >> > > lib
> > >> >> > > >>>>> just
> > >> >> > > >>>>>>>>>>> cause few parts were broken even if it doesn't
> affect
> > >> you.
> > >> >> > > >>>> That's
> > >> >> > > >>>>> a
> > >> >> > > >>>>>>>>>>> bit sad IMO.
> > >> >> > > >>>>>>>>>>>
> > >> >> > > >>>>>>>>>> If there is anything missing in lang3 that blocks
> you
> > >> from
> > >> >> > > >>>>> migrating
> > >> >> > > >>>>>>>>>> completely, can you tell us what that is? Maybe we
> can
> > >> fix
> > >> >> > > >>>> that...
> > >> >> > > >>>>>>>>> Issue is not in [commons] but in dependencies. The
> code we
> > >> >> own
> > >> >> > > >>>>>>>>> migrated but not all our deps.
> > >> >> > > >>>>>>>>>
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>> I suggest you ask/Jira each dep to update their [lang]
> to
> > >> the
> > >> >> > > >>>> latest.
> > >> >> > > >>>>>>> That
> > >> >> > > >>>>>>>> has worked for me in the past with different FOSS
> projects
> > >> >> I've
> > >> >> > > made
> > >> >> > > >>>>> the
> > >> >> > > >>>>>>>> request about this and that libraries.
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>> Some projects will be receptive and at least reply to
> you
> > >> >> right
> > >> >> > > >>>> away,
> > >> >> > > >>>>>>>> others won't. Patches help of course since will
> require at
> > >> >> least
> > >> >> > > >>>>> import
> > >> >> > > >>>>>>>> changes.
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>> yep, main issue ATM is some can't or doesn't maitain
> the
> > >> >> version we
> > >> >> > > >>>>>>> use - excepted for security issues (we are bound to a
> EE
> > >> >> version
> > >> >> > > for
> > >> >> > > >>>>>>> instance). It meanse it will be forgotten in few years
> but
> > >> it
> > >> >> also
> > >> >> > > >>>>>>> means we can get the same with [lang3] and [lang4] so
> > >> clearly
> > >> >> > > >>>>>>> something to tackle at [commons] level. We can't just
> ask
> > >> >> > > everybody to
> > >> >> > > >>>>>>> update each time IMHO.
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>> The alternative is, that TomEE won't run at all because
> of
> > >> >> > > incompatible
> > >> >> > > >>>>> API
> > >> >> > > >>>>>> changes. I would vote for the lesser evil ;-)
> > >> >> > > >>>>>>
> > >> >> > > >>>>> No, if broken part are provided in a -legacy.jar or a
> > >> >> > > >>>>> -compatibility.jar there would be no issue.
> > >> >> > > >>>>>
> > >> >> > > >>>>>>>> Gary
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>>>> Benedikt
> > >> >> > > >>>>>>>>>>
> > >> >> > > >>>>>>>>>>
> > >> >> > > >>>>>>>>>> --
> > >> >> > > >>>>>>>>>> http://people.apache.org/~britter/
> > >> >> > > >>>>>>>>>> http://www.systemoutprintln.de/
> > >> >> > > >>>>>>>>>> http://twitter.com/BenediktRitter
> > >> >> > > >>>>>>>>>> http://github.com/britter
> > >> >> > > >>>>>>>>>
> > >> >> > > >>>>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> > > >>>>>>>>> To unsubscribe, e-mail:
> > >> [hidden email]
> > >> >> > > >>>>>>>>> For additional commands, e-mail:
> > >> [hidden email]
> > >> >> > > >>>>>>>>>
> > >> >> > > >>>>>>>>>
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>> --
> > >> >> > > >>>>>>>> E-Mail: [hidden email] | [hidden email]
> > >> >> > > >>>>>>>> Java Persistence with Hibernate, Second Edition
> > >> >> > > >>>>>>>> <http://www.manning.com/bauer3/>
> > >> >> > > >>>>>>>> JUnit in Action, Second Edition <
> > >> >> http://www.manning.com/tahchiev/
> > >> >> > > >
> > >> >> > > >>>>>>>> Spring Batch in Action <
> http://www.manning.com/templier/>
> > >> >> > > >>>>>>>> Blog: http://garygregory.wordpress.com
> > >> >> > > >>>>>>>> Home: http://garygregory.com/
> > >> >> > > >>>>>>>> Tweet! http://twitter.com/GaryGregory
> > >> >> > > >>>>>>>
> > >> >> > >
> > >> ---------------------------------------------------------------------
> > >> >> > > >>>>>>> To unsubscribe, e-mail:
> [hidden email]
> > >> >> > > >>>>>>> For additional commands, e-mail:
> > >> [hidden email]
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>>
> > >> >> > > >>>>>> --
> > >> >> > > >>>>>> http://people.apache.org/~britter/
> > >> >> > > >>>>>> http://www.systemoutprintln.de/
> > >> >> > > >>>>>> http://twitter.com/BenediktRitter
> > >> >> > > >>>>>> http://github.com/britter
> > >> >> > > >>>>>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> > > >>>>> To unsubscribe, e-mail:
> [hidden email]
> > >> >> > > >>>>> For additional commands, e-mail:
> [hidden email]
> > >> >> > > >>>>>
> > >> >> > > >>>>>
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> > > >> To unsubscribe, e-mail: [hidden email]
> > >> >> > > >> For additional commands, e-mail:
> [hidden email]
> > >> >> > > >>
> > >> >> > > >
> > >> >> > > >
> > >> ---------------------------------------------------------------------
> > >> >> > > > To unsubscribe, e-mail: [hidden email]
> > >> >> > > > For additional commands, e-mail: [hidden email]
> > >> >> > > >
> > >> >> > >
> > >> >> > >
> > >> ---------------------------------------------------------------------
> > >> >> > > To unsubscribe, e-mail: [hidden email]
> > >> >> > > For additional commands, e-mail: [hidden email]
> > >> >> > >
> > >> >> > >
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
12