On 05.06.2012 17:13, Antonio Petrelli wrote:
2012/6/5 ceki<c...@qos.ch>:
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.
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.
My point about separately documenting lof4j-uber.jar and the log4j-*
jars remains valid though.
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.
I had nothing to do with that decision. Anyway, I don't think anyone
is still advocating non-optional deps for javax.mail.
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. :-)
Antonio
Cheers,
--
Ceki
http://twitter.com/#!/ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
