2012/6/5 ceki <c...@qos.ch>: > On 05.06.2012 14:53, Antonio Petrelli wrote: >> >> 2012/6/5 ceki<c...@qos.ch>: >>> >>> On 01.06.2012 04:41, Ralph Goers wrote: >>>> >>>> >>>> If you don't do that then you end up with a bunch of optional >>>> dependencies that you will forget to include or a bunch of required >>>> dependencies that you may not really need. >>>> >>>> Separating the API from the impl is useful as it keeps users from >>>> accessing stuff that wasn't meant to be public - which is one of the >>>> more serious problems in 1.x. >>>> >>>> Ralph >>> >>> >>> >>> Agreed. Separating chainsaw and lf5 into new modules is most >>> reasonable. However, modularization can be easily overdone. Assuming >>> the code in org.apache.log4j.net has not changed much since the last >>> time I looked, I would recommend that the org.apache.log4j.net be part >>> of the core module, not separate. >> >> >> It's not a question of the module themselves, but a question about the >> dependency they carry with them. >> In this case, "net" module carries the javax.mail dependency, that you >> need only if you want to use it. > > > Good point regarding javax.mail. > > Dependencies is one criteria for modularizing. Another criteria is the > release cycle. If the log4j-net module is always released at the same > time as log4j-core, then it *may* make sense to merge them. Note that > the release cycles for chainsaw and respectively lf5 are radically > different. As for the javax.mail dependency, documenting javax.mail as > dependency for SMTPAppender may suffice. > > Lumping all modules into one in addition to the smaller modules > creates two separate packaging branches which must be maintained and > documented separately. It's just not a valid option for such a widely > used project such as log4j.
You are confusing modules with projects. A modular project, i.e. a "pom" parent project with submodules, is going to be released altogether. They won't be maintained separately, only code is separated. Probably lf5 and chainsaw need a different *project* on their own. > > >> IOW, you should put yourself in the shoes of the Maven users: if >> he/she does not want to use mail, he/she has to exclude it. If you >> flag it as optional, it is not obvious for the user that he/she has to >> include it. > > > Including java.mail as a non-optional transitive dependency is out of > question. Is anyone suggesting that approach? This is in fact how now it works, see the dependencies: http://mvnrepository.com/artifact/log4j/log4j/1.2.16 So in my project I have to exclude dependencies. > As for flagging it as > optional, well, just document the dependency. If the o.a.log4j.net > module is separate, then you still have to document the existence fo > the log4j-net module (obviously). Compare that to documenting the > javax.mail dependency. I am not sure the former approach compares that > favorably from the user's point of view. Maven repositories come with search engines. What I usually do when I need an artifact is using a search engine, like Jarvana, MVNRepository etc. For example, I have a "NoClassDefFoundError" or a "ClassNotFoundException", pick the class and put it in the search engine and, et voilà, you have your artifact. >> So guess what is the solution? Right, modules :-) > > > As should be apparent from the above, it's not so clear cut to me. :-) I think that, clearing the difference between a module and a project, you will be convinced. Antonio --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
