Hi Georg, On 19.03.15 20:09, Georg Kallidis wrote: > Hi list, > > concerning upcoming releases of Turbine: > > - Turbine parent release should be either done without voting or not - we > still have not concluded IMO or have we? I think, it should be released this > year to enable up-to-date releases (including current reference to Apache > parent pom, ..).
I thought I proposed a lazy consensus vote and nobody objected. > > - The next Turbine RC is waiting for Torque 4.1 (which is not yet released), > right? It should have the scheduler removed or replaced. What are the other > goals for this release or the release after this? May be, we should make a > clear cut and explicitely support only Java 8? If we decide to do so, the > same should be true for the Fulcrum components to be consistent. Should we do > it by allowing 1.x releases (Java 5) and 2.x (Java 8)? And Http/2-support is > coming (in browsers is and in Java 9).. I started to do some work on the scheduler. It's supposed to use fulcrum-quartz when it's ready but I face some backward compatibility issues (ScheduledJob is a module) > - Logging: Turbine Trunk had log4j as logging framework and has currently > slf4j with default log4j, cft.http://www.slf4j.org/legacy.html. This should > conform with Avalog default logging behaviour. May be logback would be even > better instead of log4j (same for the Fulcrum components)? But log4j 2.x > would be an alternative, too. I am happy with each one of them. Which way we > should go? My view: As Fulcrum components are Avalon services by (current) definition, they should use Avalon logging only. All components I touched have been modified to use Avalon logging if at all possible and unless some dependency pulls in log4j or similar. Turbine is supposed to use commons-logging for the time being. I'm completely aware that the manual initialization of log4j in the Turbine class contradicts with this statement and my suggestion would be to get rid of that special handling. If logging in a certain environment were an issue, it would be no big deal to create a simple logging stub on our own that can be attached to different logging backends. Many frameworks do this. Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
