Well, since no one jumped in with an opinion, I'll share our methodology...
> i am currently programming a jsf application and i found out > that i have > 2 different things in every package > > .beans (jsf beans) > .action(jsf action) > > Now how should i structure my packages. First, we're not splitting beans from actions, but that's because we're accepting the fact that the actions are really tied to the beans and vice-versa. In our environment, a managed bean represents a form, and the actions are truly tied to that form also, so there is no real reason to separate the two. Your architecture could be different, so I'd assume that you must have some reason to separate them. Since we are building portlets, we've structured our packages to be based upon the portlet rather than scoped on some other concept. So for portlet A, the objects fall under com.mycom.portlet.a.*, etc. Portlets typically have much finer scope than a generic app, so the number of objects we end up with is pretty small, so the this organization does not become overwhelming. The basic answer to your question is that there is no real answer, it is all going to be based upon your project and the structure should represent something applicable to the project, whether it is based on workflow, page structure, object graph structure, whatever.
