Right, for instance I'm hoping Shiva's RSS patch in WINK-112 can also be applied soon since I think that's a good thing to have (just haven't had the time). It doesn't add any third party dependencies.
On the other hand, anything like Jettison/Jackson/etc. where 99% of the code is the third party's would have a submodule go under the wink-providers. For now, I think that is the best solution since there are potential conflicts and huge dependencies (I don't want the number of JARs that we're forced to include to grow out of hand). I'd rather us be as lightweight as possible in cases where there are providers users don't want to have to carry. I'd also prefer to use libraries/code licensed under Apache license since I think that makes it more agreeable for certain parties. I'm not entirely sure what single lifecycle refers to "all wink modules have a single lifecycle" but I think that we should have all modules inherit the main pom.xml's version number so that a corresponding version of the provider is published with every release even if the code hasn't changed. Although I think it's the exception to the rule that providers would not work (the only case I imagine is the providers calling internal APIs), it makes it easier. As far as the distribution, I think we only require putting a copy of the license in the LICENSE file, and we don't have separate LICENSE files. I'll let someone with better knowledge and the resolution in [email protected] in recent threads correct me though. Seems there was some debate about that. 2009/8/24 Baram, Eliezer <[email protected]>: > 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 > -- - Bryant Luk
