Split the Guava jar into atomic Maven packages #1329
Comments
|
Original comment posted by cpovirk@google.com on 2013-03-11 at 03:34 PM We're kind of stuck the way we are: If we were to split the package at this point, Maven wouldn't recognize that guava-14.0 and guava-base-15.0 contain the same classes, so it would be more likely that people would end up with conflicting versions in their classpaths. That said, we feel reasonably good about the choice we made. You mention some packages that are more rarely used -- math, eventbus, io. Users might benefit from excluding these, but there's likely to be even more value in stripping out whichever half of common.collect your particular application doesn't need, since common.collect is just so big. There's more discussion on issue 605. Status: |
|
Original comment posted by kak@google.com on 2013-07-09 at 08:17 AM Issue #1471 has been merged into this issue. |
gissuebot
added
migrated
type=enhancement
|
I would be willing to do the work to split up Guava, provided that it would be accepted. We have a small library that could use We prefer to minimize the dependencies of our library. Right now, we're resorting to copying in the Utf8 method implementations in order to avoid pulling in all of Guava, but I would really prefer to depend on a subset of Guava, instead. Perhaps a more modularized Guava would be appropriate for version 20? |
|
We had to remove Guava from the dependencies because in old Android phones (Froyo) the dex merger doesn't work ;( It is probably an edge case nowadays but it's still a case where having separate modules would have probably helped. |
Original issue created by jjzazuet on 2013-03-11 at 03:24 PM
Hello everyone.
I apologize in advance if this has been previously mentioned.
My suggestion is simple.
In the spirit of code minimalism, split guava-XX.X.X.jar into atomic jars, at least when publishing to Maven central.
Most probably almost everyone uses Guava's base classes; but others may not use the math classes, or the event bus, or the I/O classes. I can see a clear advantage in not having to bundle unused classes inside a completed application.
One could use Pro guard or other tools to 'trim' the final jars; but why do this in every project if it could be done inside Guava itself?
I can see an advantage in having a lower application size for example, with mobile applications.
However, I do not have solid facts to back up my suggestion. Therefore it remains only as such. But hopefully I got my point across.
Thank you for your time and help.
The text was updated successfully, but these errors were encountered: