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 <rmannibu...@gmail.com>
wrote:

> Le 17 oct. 2014 23:09, "sebb" <seb...@gmail.com> a écrit :
> >
> > On 17 October 2014 21:57, Paul Benedict <pbened...@apache.org> 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 <seb...@gmail.com> wrote:
> > >
> > >> On 17 October 2014 21:37, Romain Manni-Bucau <rmannibu...@gmail.com>
> > >> 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" <djo...@apache.org> a écrit :
> > >> >
> > >> >> On 17 Oct 2014 21:11, "Romain Manni-Bucau" <rmannibu...@gmail.com>
> > >> 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" <seb...@gmail.com> a écrit :
> > >> >> >
> > >> >> > > On 17 October 2014 19:08, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >> >
> > >> >> > > 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 <
> phil.ste...@gmail.com
> >:
> > >> >> > > >> 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" <gudnabr...@gmail.com
> >
> 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" <
> > >> >> rmannibu...@gmail.com>
> > >> >> > > >>>> wrote:
> > >> >> > > >>>>
> > >> >> > > >>>>> 2014-10-17 15:28 GMT+02:00 Benedikt Ritter <
> > >> brit...@apache.org>:
> > >> >> > > >>>>>> 2014-10-17 14:42 GMT+02:00 Romain Manni-Bucau <
> > >> >> > > rmannibu...@gmail.com>:
> > >> >> > > >>>>>>
> > >> >> > > >>>>>>> 2014-10-17 13:52 GMT+02:00 Gary Gregory <
> > >> >> garydgreg...@gmail.com
> > >> >> >:
> > >> >> > > >>>>>>>> On Fri, Oct 17, 2014 at 6:24 AM, Romain Manni-Bucau <
> > >> >> > > >>>>>>> rmannibu...@gmail.com>
> > >> >> > > >>>>>>>> wrote:
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>>> 2014-10-17 12:23 GMT+02:00 Benedikt Ritter <
> > >> >> brit...@apache.org
> > >> >> >:
> > >> >> > > >>>>>>>>>> Hi,
> > >> >> > > >>>>>>>>>>
> > >> >> > > >>>>>>>>>> 2014-10-16 15:30 GMT+02:00 Romain Manni-Bucau <
> > >> >> > > >>>>> rmannibu...@gmail.com
> > >> >> > > >>>>>>>> :
> > >> >> > > >>>>>>>>>> <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:
> > >> dev-unsubscr...@commons.apache.org
> > >> >> > > >>>>>>>>> For additional commands, e-mail:
> > >> dev-h...@commons.apache.org
> > >> >> > > >>>>>>>>>
> > >> >> > > >>>>>>>>>
> > >> >> > > >>>>>>>>
> > >> >> > > >>>>>>>> --
> > >> >> > > >>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > >> >> > > >>>>>>>> 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:
> dev-unsubscr...@commons.apache.org
> > >> >> > > >>>>>>> For additional commands, e-mail:
> > >> dev-h...@commons.apache.org
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>>>
> > >> >> > > >>>>>>
> > >> >> > > >>>>>> --
> > >> >> > > >>>>>> http://people.apache.org/~britter/
> > >> >> > > >>>>>> http://www.systemoutprintln.de/
> > >> >> > > >>>>>> http://twitter.com/BenediktRitter
> > >> >> > > >>>>>> http://github.com/britter
> > >> >> > > >>>>>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> > > >>>>> To unsubscribe, e-mail:
> dev-unsubscr...@commons.apache.org
> > >> >> > > >>>>> For additional commands, e-mail:
> dev-h...@commons.apache.org
> > >> >> > > >>>>>
> > >> >> > > >>>>>
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> >> > > >> For additional commands, e-mail:
> dev-h...@commons.apache.org
> > >> >> > > >>
> > >> >> > > >
> > >> >> > > >
> > >> ---------------------------------------------------------------------
> > >> >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> >> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >> >> > > >
> > >> >> > >
> > >> >> > >
> > >> ---------------------------------------------------------------------
> > >> >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> >> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >> >> > >
> > >> >> > >
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Reply via email to