Use simplified version of classmate to detect type parameter
trustin opened this issue · 12 comments
We are currently using our own crude version of type parameter detector to generate the default implementation of acceptInbound/OutboundMessage() method in ChannelInbound/OutboundMessageHandlerAdapter().
It turns out that @cowtowncoder wrote an awesome library called 'classmate' that does this job really well. However, we neither want all its features nor want to have a non-optional dependency. We need to use some portion of his code with proper credit message in our distribution.
I would rather have @cowtowncoder maintain that for netty.
@carrot-garden sure that would be the best but we want to keep netty zero-dependency ;)
re: zero-dependency
- why
- it is not zero already
- Because it is really nice for users to not need to have anything else on the classpath
- All it dependencies are optional, at least in the core and I'm talking about the core.
I see. I guess for me these are more important then minimal classpath:
- modularity
- specialization
- maintainability
We discussed about zero-dependency a couple times since the beginning of the project and we decided to keep the project zero-dependency as much as possible. Of course, it doesn't mean we will fork everything. At least, a user who wants to play with Netty first time should be able to play with it with a single JAR.
Closed by mistake.
re: " user who wants to play with Netty first time should be able to play with it with a single JAR"
that seems is a separate concern.
why not produce for this purpose netty-all-bundle which will have ALL dependencies baked in?
How about this: if Netty is built using Maven (or can use similar tasks), why not use Shade plug-in to import classmate code under different Java package? This is done by some projects (jDBI I think), and I do this for other libs (Asm) myself, for things like Jackson extension modules. I think there is some value in zero-dependency.
It is most useful for small libraries, and classmate is quite compact and unlikely to significantly grow.
And I can obviously help with integration if need be. I have also used jarjar to do the same thing with Ant builds; bit more work, but for stable libs not a big problem.
I am not against code contribution if that is the chosen path. And it should work, as classmate is quite mature. But there is still possibility of bug fixes, and forks are pain in that way.
Using shade plugin sounds like a great idea.. I even did this in the past for some other project, should have remember this :)
@trustin what about to import it to our internal package?
Sent from my iPhone. Excuse any typos....
Am 11.02.2013 um 19:33 schrieb Tatu Saloranta notifications@github.com:
How about this: if Netty is built using Maven (or can use similar tasks), why not use Shade plug-in to import classmate code under different Java package? This is done by some projects (jDBI I think), and I do this for other libs (Asm) myself, for things like Jackson extension modules. I think there is some value in zero-dependency.
It is most useful for small libraries, and classmate is quite compact and unlikely to significantly grow.
And I can obviously help with integration if need be.I am not against code contribution if that is the chosen path. And it should work, as classmate is quite mature. But there is still possibility of bug fixes, and forks are pain in that way.
—
Reply to this email directly or view it on GitHub.
see #1043
@trustin optimized our class so we will not shade classmate in.. closing