The usual answer to "what is the right way?" or "is this the right way?" is..... it depends.
All I can do is tell you the pros and cons to specific ideas. What follows is 100% my opinion. I don't know of any specific requirements or rules. I'm sure somebody will disagree with me.
Let's work on whether to put JSP's in WEB-INF or not.
Pros of putting JSP's in WEB-INF:
- You control how the JSP's are executed. If you want a JSP to be parameterized and re-usable (which is really hard with a JSP anyway), you can put them into WEB-INF and use a servlet or a Struts action controller or some other front controller to do pre-processing and then pass control to the JSP, passing in the right environment context (like request attributes, any security checks, parameter sanitation, etc.)
- You can programmatically or even at a firewall or IDS level block HTTP requests to *.jsp to reduce the likelihood of somebody uploading a JSP to the web root and then being able to execute code as the web server. They'd have to over-write an existing JSP. Not a huge security gain, but it does make compromise slightly harder.
- Enforces good habits, like MVC, front controller, servlet filters, dependency injection, etc. as opposed to a big monstrous JSP that does all the work itself and is difficult to read/maintain.
Cons of putting JSP's in WEB-INF:
- You cannot access the page directly, even if it is a simple standalone page which needs no upfront processing. This is because files under /WEB-INF are not servable by a servlet container.
As for the overall directory layout, it depends somewhat on your build process. I like storing everything under "src" or "source" because it makes it clear what files are generated by building and which are pure source files.
main lets you separate test code like junit classes from your main source code, which is good too. But if you don't have any unit tests (oh no!), then it's a meaningless distinction.
On the other hand, if you don't manipulate the web root at all during build (like if it's all JSP and static files), then perhaps you keep it at the top level, like
/deploy and copy files in as needed, such as .class or .jar files. It is a habit of human beings (especially developers) to over-organize. A good sign of over-organizing is having lots of folders with only a single sub-folder.
What You've Shown
You've indicated that you are following a convention set by maven, so if you are already using maven, just stick with that layout. There is absolutely nothing wrong with the layout you described.