Great question! I see a couple of approaches:
1) Technical solution: I think you are on the right track to use the maven-shade-plugin. But you shouldn't need the maven-dependency-plugin. The shade plugin is pretty powerful. Why not just make your single-module library artifact an "uber-JAR" consisting only of its own sources plus the relocated+minimized fastutil classes, using <minimizeJar>true</minimizeJar>? 2) Social solution: start a discussion with the fastutil team about modularizing their library for a future (breaking) release. Right now the packages are divided by primitive type, which seems backwards to me. Better would be to divide by data structure, with all primitive types in each data structure package. Then you could cherry pick only the needed data structure(s) of interest. Obviously this is a longer-term solution. 3) Punt. Just depend on fastutil and make no apologies. 16MB is really not that big of a deal these days. Is slimming ~10MB from your footprint really worth the developer time investment of mucking around with shade etc.? Regards, Curtis On Tue, Dec 1, 2015 at 10:16 AM, <org.apache.maven.u...@io7m.com> wrote: > Hello. > > I'm intending to use some classes from the fastutil package[0]. Due > to the size of the artifact(s), it's assumed that anyone using the > package will use ProGuard on their application to remove unneeded > classes. However: > > 1. I'm writing a library. > 2. I'm using the fastutil classes in a way that does not expose them > in the public API of the library. > 3. I do not want everyone that uses my library to have to use something > like ProGuard to reduce the resulting size increases caused by > a dependency on fastutil. > > Therefore, I feel like the correct way to proceed is to create > a module in my project that solely exists to extract a few classes > from fastutil an expose them to the other modules that need them. > > One way to do this would be to use the maven-dependency-plugin to > extract sources from the fastutil package and treat them as "generated > sources" so that they're compiled and packaged as part of the artifact. > > However! This would obviously then result in conflicts (duplicate > classes) if someone using my library also used the fastutil package. > > It seems like the maven-shade-plugin is capable of moving classes > into different packages, but it seems as though it's only capable > of working with compiled classes and therefore may not play nicely > with IDEs. > > Does anyone have a better/preferred way to achieve this? > > M > > [0] http://fastutil.di.unimi.it/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
