On Tue, Jun 5, 2012 at 5:35 PM, ceki <c...@qos.ch> wrote: > Right. Lf5 and chainsaw merit to be in different projects. You are also > right to point out that I had module and project confused. If the > modules have different release cycles they should be in different > projects.
There is currently no one working on Lf5 or chainsaw1 to my knowledge. Therefore I'd lets make them modules, as they will most likely not see a release outside log4j1.x > My point about separately documenting lof4j-uber.jar and the log4j-* > jars remains valid though. I don't see a big issue here. Many projects describe how projects can be included on their homepage. It can be seen easily that a new dependency needs to go in. As for the Uber.jar, the shade plugin might help: http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html (not tried) Many people I know complain about the dependency issues in log4j (meaning: using javax.* etc) My guess is that using multiple modules might not do harm to many of them, just ease their life. If we just modularize the things which need the dependencies, like the appender, we have a good chance a lot of people will not reckognize the change (only guessing) >>> 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. > > Yes, but the same argument applies to javax.mail.Session. :-) I think Documentation for maven users which tell them what to include is much more easier than knowing what to exclude. Inclusion is standard, for ecxlusion i always need to google. In fact, since I know about the Shade plugin I am always angry with people who force me make my pom.xml look even more messy with exclusions. That being said, currently I see the following modules below log4j-parent: log4j-parent +--log4j-core +--log4j-chainsaw +--log4j-lf5 +--log4j-smtpappender +--log4j-ee (* contains the code whic uses Geronimo dependencies) +--log4j-ntdll (* pending NAR plugin evaluation) I would like to kick "performance" and "contrib". Ceki mentioned it would be possible without big harm. I have looked a little bit through it and I can't find a reason to keep them. Have I missed something? Did I overdo it? Let me know. In the parent pom of the organization branch: http://svn.apache.org/repos/asf/logging/log4j/branches/log4j12-bz53299/ Is the Geronimo Specs listed as dependency. Anybody knows for what it is? Cheers Christian --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
