logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Kjome" <h...@visi.com>
Subject Re: [v2] Where to put appenders with dependency?
Date Thu, 06 Dec 2012 18:07:23 GMT

On Thu, 6 Dec 2012 15:35:58 +0100
 Christian Grobmeier <grobmeier@gmail.com> wrote:
>>
>> I think there is a concept in Ivy and Maven that a dependency is provided
> by
>> a container.
> 
> Oh yes, there is:
> 
> <dependency>
> <groupId>org.testng</groupId>
> <artifactId>testng</artifactId>
> *<scope>provided</scope>*
> </dependency>
> 
> We would need to "solve" that with good docs then. People need to know what
> to include for specific appenders.
> 

This is a bad example.  For test artifacts that would never be deployed 
dependency of another application, you'd use...

<scope>test</scope>

If you were depending on, say..., the servlet API, you could use the 
"provided" scope to prevent it from being a transitive dependency of dependent 
applications (since it would be provided by the container anyway), yet still 
have the servlet API automatically downloaded from the repository for 
compilation of the current application.

See...
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Furthermore, for dependencies where you want to avoid transitive dependence, 
but where the dependency would not necessarily be provided by the container, 
you can use...

<optional>true</optional>

Seems like this would be appropriate for a dependency upon "mongoDB".  While 
it might be provided by a container (if a user placed it in a global lib 
directory), there's no specification saying that JEE containers must provide 
"mongoDB" APIs.  Furthermore, even if a user chooses to use an SMTP appender 
which might be in the same jar as a "mongoDB" appender, they shouldn't be 
unnecessarily forced to depend upon "mongoDB".

See...
http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html


In any case, it seems to me that separate jars should be the norm.  An 
uber-jar can be created for those that want one.  But having an "all" jar be 
the only option simply repeats the mistake of Log4j1.  That jar is nearly 500k 
because it includes chainsaw1 and lf5, which almost no one uses at runtime.  
Without those, it would be closer to 300k (and I'm sure there's some other 
bloat that could be gotten rid).

I'm all for an uber-jar that is created by merging the standard jars with 
minimal dependencies.  But I'm not for the case where everyone is forced to 
deploy a bunch of cruft that they'll never use.  A user should have the choice 
to deploy the minimum set up libraries that suit their needs.

I'd say we could have a "log4j-extensions" jar with more than just one 
extension.  It could either contain all extensions or we could have one jar 
per group of extensions.  Maybe one for database-related extensions and 
another for purely network-protocol-based extensions.  I have no strong 
feelings on this, just a suggestion.


Jake

---------------------------------------------------------------------
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