logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Petrelli <antonio.petre...@gmail.com>
Subject Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Date Tue, 05 Jun 2012 15:13:05 GMT
2012/6/5 ceki <ceki@qos.ch>:
> On 05.06.2012 14:53, Antonio Petrelli wrote:
>>
>> 2012/6/5 ceki<ceki@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message