Arne Vajh?j<arne@vajhoej.dk> wrote in news:4f4ac151$0$291$14726298
@news.sunsite.dk:
[snip]
I forgot to answer this part of your post in my other reply.
I'm currently grouping mine on a more-or-less functional basis. If
the
class is essentially just a table lookup or enum, then it goes in the
com.novice.common.lookups package. If it is a utility, it goes into
com.novice.common.utilities. And so forth.
That is general question not specific to logging or AOP.
You're absolutely right. This is a bit of a sidetrack. I think I need to
be sure I've structured my packages correctly in order to do a good job
with this.
You need a good structure of your classes and source code.
Agreed. I'm trying to figure out the best approach.
A key factor in the decision between com.novice.common and
com.novice.common.xxxx must be the number of classes.
Do you have so many classes that it makes sense to split up?
I'm not sure what "so many" means in this case ;-)
I actually split my Common project the other day into two parts. I left
only the code that I consider polished and (more or less) correct in
Common and moved all the stuff that is still crude and needs improving to
a new project called Common Candidate. The latter is far bigger!
But Common itself contains 9 classes in package com.novice.common, 8
classes in package com.novice.common.lookups, 3 classes in
com.novice.common.menus, 2 classes in com.novice.common.prefs, and 18
classes in com.novice.common.utilities.
The resource bundles for each package are in separate packages that have
Resources as the last qualifier, e.g.
com.novice.common.utilities.Resources. I have the impression, perhaps
mistaken, that resource bundles are supposed to be in different packages
than the classes they support.I don't remember where I got that; I think
it was a newsgroup post a few years ago but it could have been in one of
the online magazines....
I have no idea if this is a reasonable approach. Maybe this should all be
simplified so that all of those common classes and enums and resource
bundles are in one package together. Or just two, one for classes and
enums and the other for resource bundles.
Everything in the Common project is something I use regularly in various
projects or that I expect to use regularly.
The Commons Candidate project has quite a bit more code than the Common
project and is organized the same way with the same package names (and
maybe an additional package or two where none of the members are ready
for the Common project.) Some of the members of that project don't belong
there because they are just snippets that I've downloaded for learning
purposes or simple sandbox code where I'm trying something out. It needs
to be moved elsewhere but that's not a priority for me right now. But the
bulk of it has the potential to go to the Common project as something I'd
use regularly.
I'd like to start the process of doing things correctly with my current
project and Common so anything you can tell me about organizing things
would be appreciated.