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 that. 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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
