I've got a few topics to mention. 1. Should we consider making a 2.0 release branch so that trunk can continue to be the active development branch? That way we can work on new things while just ironing out the remaining issues for 2.0 GA in the 2.0 branch. Unless you guys prefer a different branching workflow like trunk being the stable branch, and then using feature branches.
2. OSGi support. What I'm thinking will be the easiest way to get this working correctly without having to worry so much about duplicating bundles would be to simply drop the log4j-osgi modules and just add the OSGi MANIFEST.MF metadata to our normal releases. This would effectively be good enough for supporting OSGi bundles in that regard. We can figure out how to trim down log4j-core independently of anything OSGi. I've already began work on this by updating the poms for log4j, log4j-api, and log4j-1.2-api. I'll update the other smaller modules to reflect the updated build process as well. There may be a slight issue with the log4j-slf4j-impl module due to how SLF4J expects implementations to be packaged, so I'll take a look into that as well (and possibly go complain to them if necessary). In fact, supporting OSGi for some of these modules might not be possible due to package splits and backwards compatibility. 3. Essentially, I'm thinking that we could separate out all the parts of log4j-core that use external dependencies with the exception of AsyncLogger (we could potentially fork lmax-disruptor into our own repository similar to how Tomcat handles some of their dependencies). That way, we don't need to worry about optional dependencies, either, because when they're split up, the new modules can have required dependencies instead (whether it be an API or a concrete library). If there are any other parts of log4j-core that rely on external dependencies that we think are popular enough to keep in log4j-core, please share. 4. Due to how new these modules are, I'm proposing that log4j-streams and log4j-camel both be slated for release in 2.1 or some future release. Otherwise, these might hold back our 2.0 release a little bit. Where we place the code depends on (1) (keep in trunk or make feature branches). Of course, both modules are independently up for vote on whether to include them in 2.0. Since I added the log4j-camel module as a sort of experimental module largely based on the log module in camel-core (which uses SLF4J instead), I'd like to see this part in 2.1, but not in 2.0 since I've barely tested it yet (and still need to port more tests to it along with some integration testing). 5. After addressing the modules thing from (3), we should probably vote on an RC2 release sometime soon. I'd propose releasing RC2 in the beginning of May, but I'm open for whenever. 6. What else is left for 2.0? The updated Marker API is almost complete (we have our own code that needs to be updated to not use the deprecated APIs, but that might only be unit tests at this point). -- Matt Sicker <[email protected]>
