Thanks for the clarification. Sounds good. That's why we have discussions on dev, so we're all on the same page :-)
-Donald On 3/31/10 9:23 AM, Simone Tripodi wrote: > Hi Donald, > I'm sorry I'ven't been more precise. In my previous post I ment that > from bval "core" module I'd like to move in it the js303 and all > non-jsr303 components outside in separated modules (rather than > removing) and not fragmenting the code, so users in the proper core > module have just the jsr303 reference implementation. > Optional modules give, IMHO, the added value to our project, providing > nice stuff that "competitors" (like hibernate-validation) don't. > I would just give my +1 to the proposed idea but maybe I created a > misunderstanding, and I'm sorry for that. > Have a nice day, best regards!!! > Simo > > http://people.apache.org/~simonetripodi/ > > > > On Tue, Mar 30, 2010 at 9:16 PM, Donald Woods <[email protected]> wrote: >> I would slightly reword that to - >> jsr303 spec requirements + spi + supporting core code >> >> There is some code in bval-core that is required and some that can be >> refactored or maybe even removed. >> >> >> >> -Donald >> >> >> On 3/29/10 10:07 AM, Gerhard Petracek wrote: >>> +1 that the core only contains jsr 303 + our spi >>> >>> regards, >>> gerhard >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >>> >>> >>> 2010/3/29 Simone Tripodi <[email protected]> >>> >>>> Hi all, >>>> I propose to move non-jsr303 features to separate modules, as "user" >>>> I'd like to download the core module (with a limited number of >>>> dependencies) as the jsr303 implementation, then every add-on is more >>>> than welcome!!! >>>> Just my 2 cents :P >>>> All the best, >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> >>>> >>>> >>>> On Mon, Mar 29, 2010 at 3:27 PM, Roman Stumm <[email protected]> wrote: >>>>> Hi, >>>>> >>>>> good point. one dependency to a XML framework is enough. we can keep JAXB >>>>> (which is part of the JDK anyway) or use the Apache Digester, which I >>>>> haven't used yet. >>>>> XStream is only required for the non-jsr303 parts. We can remove some >>>> code >>>>> in this area (e.g. dependencies to freemarker, xstream) or do we want to >>>>> keep these non-jsr303 functionality? >>>>> >>>>> Roman >>>>> >>>>>> --- Simone Tripodi<[email protected]> schrieb am Mo, 29.3.2010: >>>>>> >>>>>> >>>>>>> >>>>>>> Von: Simone Tripodi<[email protected]> >>>>>>> Betreff: [DISCUSS] conversion utilities >>>>>>> An: [email protected] >>>>>>> Datum: Montag, 29. März, 2010 14:27 Uhr >>>>>>> Hi all guys, >>>>>>> during the package move, I noticed few minor points I'd >>>>>>> like to >>>>>>> discuss with you all: >>>>>>> >>>>>>> 1) a conversion utility has been (re)implemented, so I >>>>>>> wonder why we >>>>>>> don't reuse the Apache Commons BeanUtils (already in the >>>>>>> dependencies) >>>>>>> built in ConverterUtils instead of reimplementing stuff. >>>>>>> What do you think about it? >>>>>>> >>>>>>> 2) about the XML libraries: I noticed we've JAXB and >>>>>>> XStream >>>>>>> dependencies, since our scope AFAIK is just parsing XML, >>>>>>> wouldn't more >>>>>>> convenient, with the objective of reducing the number of >>>>>>> dependencies, >>>>>>> just use the Apache Commons Digester instead? The only big >>>>>>> dependency >>>>>>> it has is the Apache Commons BeanUtils (already in the >>>>>>> dependencies).... >>>>>>> >>>>>>> Sorry for the silly questions and thanks in advance for >>>>>>> your reply :) >>>>>>> All the best! >>>>>>> Simo >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> >>>>>>> >>>>>> >>>>>> __________________________________________________ >>>>>> Do You Yahoo!? >>>>>> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz >>>>>> gegen Massenmails. >>>>>> http://mail.yahoo.com >>>>>> >>>>> >>>>> >>>> >>> >> >
