In a similar boat. I think #1 is a feature we need regardless, though I agree with JL that the default should be as it is now.
I have a small hope that we could find a way to make managing shaded dependencies a bit easier. If we could find a cleaner way to do it than we do now, might be more realistic to try. It's a bit of a project though. -David On May 13, 2013, at 1:31 PM, Romain Manni-Bucau <[email protected]> wrote: > i'm playing with 1 ATM, 2 would be the best but we'd need to maintain > it...impossible today > > a shade will not work without custom clever transformer (never a good > solution) > > so basically i'm for 1/ too if my tests show it works fine enough > > *Romain Manni-Bucau* > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > *Github: https://github.com/rmannibucau* > > > > 2013/5/13 Jean-Louis MONTEIRO <[email protected]> > >> 1/ just adding a property for an app with values like parent-first (default >> - today) and parent-last (new value). >> 2/ that usually the way other apps servers are used to do (IBM Websphere AS >> IIR) >> 3/Don't know >> 4/No >> >> The first one looks the more simple to implement (at first glance) and the >> one which produce less impacts and possible side effects for users. >> The second is something which can be studied furthermore and implement as a >> cherry on the cake. >> >> Then, if I had to choose, I would choose 1/ >> >> Jean-Louis >> >> >> >> >> 2013/5/13 Romain Manni-Bucau <[email protected]> >> >>> Hi >>> >>> as you probably know we changed quite often the classloading these last >>> versions. >>> >>> We still have regularly issues with tomee provided libs (mainly because >> of >>> cxf/amq/... transitive deps) >>> >>> I would like to go further and use an URLClassLoaderFirst for lib part of >>> ear to allow apps to not rely on tomee libs first. >>> >>> The alternative is to shade/repackage all deps. >>> >>> PS: i want to avoid OSGi >>> >>> So basically here is the question: to solve conflict lib issue what your >>> preferred solution: >>> 1) URLClassLoaderFirst even for ear lib part - if this one please say if >>> you would like a property to switch back to old behavior >>> (openejb.ear.lib.classloader.first=false?) >>> 2) repackage all deps >>> 3) other >>> 4) OSGi/OSGi like >>> ? >>> >>> If nothing moves in the following days i'll go for 1 (then we can still >>> discuss ;). >>> >>> *Romain Manni-Bucau* >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >>> *Blog: **http://rmannibucau.wordpress.com/*< >>> http://rmannibucau.wordpress.com/> >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >>> *Github: https://github.com/rmannibucau* >>> >> >> >> >> -- >> Jean-Louis >>
