I agree with this approach. One thing, I think that it was your intention, just wanted to verify it, the separate module is required only for providers who required third part that are not already part of Wink. New provider that do not required additional third party can be added to common/server.
Regarding distribution, I rather that all wink modules have a single lifecycle and single version, this simplifies things and discharged one from maintaining compatibility matrix. If we decide to keep on distributing all in a single distribution zip the fallowing structure can help us (small updates to Bryant suggestion): wink -wink-providers --wink-jettison ---libs ---License(file) --wink-... -License(file) We should also add reference from the Wink license file to the providers licenses file with a comment. -Eli -----Original Message----- From: Bryant Luk [mailto:[email protected]] Sent: Monday, August 24, 2009 2:28 AM To: [email protected] Subject: Re: Proposal: wink-providers module Regarding creating a submodule for each third party library, I agree. Something like: wink -wink-providers --wink-jettison --wink-... is what I had in mind. I'll try to see how feasible this is and what the end user experience should be like. I also don't think we should be the distributor of every single library that is possibly supported. On Sun, Aug 23, 2009 at 1:01 AM, Michael Elman<[email protected]> wrote: > In general I agree that it would be nice idea to separate optional providers > from the common module. > IMO, we should create a submodule for each third party library, so the user > will be able to bring only the relevant sub modules with their third > parties. The third parties of different libraries very often have conflicts. > This rise additional question regarding the distribution: should these > modules be included in wink-<version>.jar and all the third-parties in the > lib? I guess not. > > > On Sat, Aug 22, 2009 at 12:50 AM, Bryant Luk <[email protected]> wrote: > >> Hi, >> >> I was wondering if we could add a new module/submodules for optional >> providers (like wink-providers). I think there are a number of >> potential libraries that exist today that do not provide their own >> JAX-RS MessageBodyReader/MessageBodyWriter. It would speed up the >> users' development time and would give them options for different >> media types. This should also be easy code for users to contribute >> back if they wish. >> >> -- >> >> - Bryant Luk >> > -- - Bryant Luk
