> > 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.
I'd vote for -base as well. > > It is no place where we swiftly drop some > > nice and convenient utils stuff and the API is nothing to play around > > with. > > > +1 we already have a very raw starting point in the current commons, not yet finished, but it's there ;-) > > > 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) yeah, base11, base12, base20 what about a base, for those things that are independent from the spec diffs ? > FacesContextWrapper. But there is no need for that, we can't forsee any > future change e.g. in JSF 2.0 :-) True, all this is discussed behind closed doors -M > > Ciao, > Mario > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
