To the point of conveniences, the convenience is GREAT when I use cxf-bundle, hamcrest-all, activemq-all, jetty-all, mockito-all, and so on, instead of being forced to list out 50 or who-knows-how-many modules. For our big app server, I just use bundles and be done with it unless a specific dependency problem arises.
Gary On Thu, Dec 10, 2015 at 10:28 AM, Ralph Goers <[email protected]> wrote: > My understanding is that most of the people who combine jars like this > also include the classes from their application. For that reason I don’t > think it would be helpful. > > Beyond that, I am not sure combining them makes it “super-convenient”. The > only place this might be helpful is in OSGi, and even then I am not sure as > I don’t really know enough about OSGi. Also, we need to look at the new > module system in Java 9. > > Ralph > > > On Dec 10, 2015, at 11:13 AM, Matt Sicker <[email protected]> wrote: > > Most projects where I use log4j2, I include all the following dependencies > thanks to framework logging divergence: > > log4j-api > log4j-core > log4j-jcl > log4j-jul > log4j-slf4j-impl > log4j-1.2-api > > Shading these together would be super-convenient. Would anyone else be > interested in such a thing? I usually see this sort of thing in testing > frameworks (like mockito-all, hamcrest-all, etc.), but calling this > log4j-all would be incorrect. > > -- > Matt Sicker <[email protected]> > > > -- E-Mail: [email protected] | [email protected] 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
