Hi! > Mario, you are not alone in hating the shared concept. ;-) > Good!
> 1) has a super stable API > That is true, that might be the hardest part. > 2) is used (ie. shared) by the myfaces core(!) as well as other myfaces > projects > Sure! > 3) may be used by the experienced JSF app developer who wants to write > his own StateManager or ELResolver or some other pluggable/replaceable > JSF thingy (ie. all the things you can replace via faces-config.xml) > Yepp! > Problem here again is the name of such a lib: > "myfaces-commons-base"? > "myfaces-commons-core"? > "myfaces-commons-super"? > "myfaces-commons-commons"? ;-) > I'd opt for myfaces-base, but to say the truth, I do not care about the name, whatever name it has will be good for me as long as the goal is the same. > It is no place where we swiftly drop some > nice and convenient utils stuff and the API is nothing to play around > with. > +1 > I think that if we find a good name and define some strict rules we > could move most (or all?) stuff from myfaces-shared to this lib. And > perhaps even get rid of shard in the long run! > One rule can be to allow only stuff which itself directly implements a JSF API but do not provide any functionality on its own, you see, no enum converter or soo. Probably only abstract classes? > Of course, some well-known issues pop up immediately: which JSF-Spec - > 1.1 and 1.2 or only 1.2? What about JSF 2.0? > I'd like to see one project per version, e.g. myfaces-base11, myfaces-base12, myfaces-base20 (with namespaced package names: org.apache.myfaces.base11, etc) This might lead to code duplication for every new project, but is the only way I can think of making it possible for this project to succeed. It would not be nice if myfaces-base12 has to deal with backward-compatibility. Parts of myfaces-base12 MIGHT be backward-compatible, e.g. like any FacesContextWrapper. But there is no need for that, we can't forsee any future change e.g. in JSF 2.0 Ciao, Mario
