On 02/12/2014 09:50 AM, David M. Lloyd wrote:
In addition, I want to discuss a few cases where modules are using
message bundles and loggers from neighboring modules. This is going to
become a problem when we do the distribution split-up.
I want to elaborate on this a little bit.
The original commits here place log message interfaces and their
generated classes into a separated packages, and, in most cases, then
hides that package from importers, which decreases coupling. However,
when one module uses another's messages, we cannot do this as it would
break the linkage of the consuming classes.
Looking at the code itself, there are a couple of sub-cases:
1) A module is really small and mostly just provides some new aspect of
some existing thing, (see org.jboss.as.management.client.content.*)
2) The module in question has its own IDs, but an ID from a different
module seems more relevant, e.g. connector and ejb3 using several EE
messages (see commit titled '[WFLY-2864] WildFly EE module')
3) The module in question has no IDs and defining one doesn't seem worth
it, given there are other modules that have the same one or two messages
that it needs and they seem relevant enough (see CLI module, using
messages from controller)
For all of these cases, I think the right thing to do (assuming we don't
simply solve these cases in some trivial way) may be to factor the log
messages out into a separate, shared maven module which contains only
these messages. When we split the distribution, a key question will be
"how do we divide the modules along dependency-sane lines, and what
dependencies then exist between them?" The answer to this question may
be simpler to ascertain if logging messages are factored out this way,
especially if this would allow us to break some circularity in the case
where the log messages are the only reason for a dependency.