logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: [ANN] Deleting receivers and components 'companions'
Date Fri, 07 Oct 2011 04:41:36 GMT
I used Nexus for the last release of log4j and struggled with it. If I remember correctly there
were issues with our Maven group ID not starting with org.apache that prevented the release
from being mirrored to Maven central, but think we finally worked through all the issues.

I would not be in favor of moving components into log4j-core. Moving the tests into core would
be a chore and users would have the expectation that anything in core would be supported in
some manner with log4j 2.0. There will be disappointment anyway, but we shouldn't pile anything
more into log4j-core that we can't carry over into log4j 2.0. 

It looks like the receivers and companions source code was moved into chainsaw with copy and
then svn add. Unfortunately that loses all history behind the code. Using svn cp would preserve

I'd suggest creating logging/attic, svn mv'ing component and receivers there. It may be good
to delete the recent copy and pasted code checked into Chainsaw with svn cp's so the code
history is preserved.

On Webstart, there have been discussions over several years about providing a code signing
facility for Apache binaries specifically for the web server so that crashes can be collected
from Microsoft's crash reporting systems. I do not know if that ever progressed.

While Webstart is attractive, it may be hard to bring it into line with Apache release policy.
I'm pretty sure that it is not mirrored or GPG signed for example. If it is mirrored, then
I'm sure users will not be checking signatures to make sure that they are getting the legitimate
ASF Chainsaw and not some other Chainsaw.
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message