+1 The NonFacesRequestServlet is also a candidate for myfaces-commons.
Should we start a myfaces-common-fileupload project, too? Regards Bernd Manfred Geiler wrote:
+1 But to avoid common design mistakes I propose some additional issues/prerequisites: 1. Clear separation of API and IMPL (at least on package level, better by separate artifacts). Mind that the idea behind these commons classes is that many other projects use them - and therefore depend on them. So a clear and stable API is essential. 2. Let's start to name svn folders the same as the artifacts. This seems to be best practice in many other maven projects. And there are good reasons to do this. So, the new project should be located in a folder named like "myfaces-commons" with two sub folders "myfaces-commons-api" and "myfaces-commons-impl". BTW, some other candidates for commons classes are "trivial" utils like this one: public static void doNavigation(String outcome) { FacesContext facesContext = FacesContext.getCurrentInstance(); NavigationHandler navigationHandler = facesContext.getApplication().getNavigationHandler(); navigationHandler.handleNavigation(facesContext, null, outcome); } Yes, no big deal. But convenient, though, to have this code in one good place instead of inventing a new "JSFUtils" class for every new customer project... ;-) -Manfred On 10/24/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote:Hi! Lets start up the long awaited MyFaces Commons project. The aim of this project will be to contain all stuff which do not belong to a component. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons ..... I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) Ciao, Mario
