>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 9/18/06, Gary VanMatre wrote: > > > > > > > >> BTW, I'm going to take a try at moving commons valiator out of the > > core. > > > > I might need some help with the clean up. Does > > "shale-commons-validator" > > > > sound ok for the project under "framework"? > > > > > > > > > I'd think shale-validator would be better, unless we contemplate > > alternative > > > validation strategies. > > > > > > > That name would also work if we wanted to add other types of validators to > > the > > project. > > > > I almost had this done and realized that we really need to change the > > package names. > > I started moving the validator stuff out into corresponding packages but > > realized that > > that wouldn't work for "resources/Bundle.properties". > > > > What about moving these packages under "validator". > > > > shale/component > > shale/resource > > shale/taglib > > shale/renderer > > shale/faces > > shale/view > > > > shale/validator/component > > shale/validator/resource > > shale/validator/taglib > > shale/validator/renderer > > shale/validator/faces > > shale/validator/view > > > > Any thoughts? > > > I presume you're thinking only of moving the "validator" related classes, > right? Among other things, the token component would need to stay. >
Ya, I was only going to move the validator related artifacts. But, that alone amounts to about 1/4 of the core jar. Some folder can be moved (svn mv) into another jar project. The folder that only contain validator code. The other would have to be moved at a source file level. In addition, the property files and config files would need to be copied and content removed from both core and the new project. > Doing this means a new tag library for the validator stuff (as well as its > own faces-config.xml file). > > What do anticipate is the endgame? Would we pull the validator stuff out of > the release, or try to label it as something not release quality? > This is in reference to your request to simplify dependencies in the maven builds. That's my motivation. It was a bullet point in your plan. > I'm not sure I am game for all of this ... if we're willing to label this > API as not being stable, I don't see the point in doing the separation. If > we are not going to ship it at all, this might be OK. But any existing > users would still want the functionality available from the sandbox -- and > they would probably prefer it to not require any changes. > Well, it will require a lot of effort and I kind of agree. If we have the maven dependencies under control, I think our efforts are better spent elsewhere. After looking into what it would take, I'm not sure I have the courage right now anyway. > Hmm.... > > Craig > > > > > > >> Gary > > > > > > > > > Craig > > > > > > > Gary > >
