Well, since none of your example changes jump out and scream I am a much clearer packaging model, I would say this is a matter of style and as such, not really that important.
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 07, 2002 5:33 PM Subject: [JBoss-dev] Package organization > I have been putting off writing this email for a while... mostly because I > am lazy. > > Any ways, I am concerned about the current trend for packaging which is > being employed in JBoss. By packaging I mean the way in which we organize > our classes into packages. I believe the current "package by type" scheme > is a poor choice for large (and rapidly growing) projects. > > By "package by type", I mean that we are organizing different functional > components by the type of "thing" it is, rather by the functional group in > which it belongs. > > How about an example, that always seems to explain this issue. At one > company I used to work at (which I will leave unnamed to protect the > innocent... or rather the stupid... or both), they were building a webapp > based on servlets. These servlets talked to databases via objects (written > poorly and completely non-j2ee like). The app was big and had lots of > different functions, but there staff of "senior" engineers (degrees and > all) chose to organize *every* servlet and *every* db object into two > packages: some.dumb.company.servlets and some.dumb.company.db. > > Needless to say this approach is not very manageable. Imagine you are a > new employee trying to get up to speed fast on one function of the > system. There isn't any good documentation or class naming scheme to tell > which classes are for what and all of your coworkers are too busy making > sense out of the spaghetti they have written (poorly) to be of much help. > > It would have been much better if they had packaged by function, such that > all of the login servlets got a package, and then all of the user > management servlets got another and so on. > > * * * > > I would like to avoid this for JBoss. Granted we are not in the same > situation as the folks I mentioned above (we actually know how to write > Java code), but I think we have overlooked some of the organization > required to make a large software project truly effective and easy to manage. > > One example of this is the org.jboss.metadata package. There is metadata > classes from all aspects of the system here, rather than closer to the > functional groups in which they are used. This package only really makes > sense if there are helper, abstract or type classes which are used by > cocreate metadata implementations. > > Another is the org.jboss.deployment package. This guy has j2ee stuff, sar > stuff and more. Why not put those in the packages which deal with those > areas? Leaving this again for abstract impls and such. > > Lastly take a look at the ejb proxy's. This is a different case, but still > a little backwards (IMHO). org.jboss.proxy.ejb, contains the ejb container > proxies. This is a sub-package inside of the package by type > methodology. It would make more sense to put them into > org.jboss.ejb.proxy, and leave org.jboss.proxy for abstracts and the like. > > Any ways, I wanted to get this off my chest. I hope that some (or most) of > you understand what I am trying to get at... avoiding the spaghetti (tastes > good, but I don't want to clean it up off the floor). If we spend a little > effort in optimizing the organization of our codebase, it will be easier to > manage, maintain and much easier for newbies/learners to get up to speed > faster to help make the system even better. > > --jason > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
