Re: [wildfly-dev] The Big Log ID Change: https://github.com/wildfly/wildfly/pull/5906

On 02/12/2014 09:50 AM, David M. Lloyd wrote: 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. -- - DML