Hi Siegfried, thanks for the comments!
If we think about a bulk release of Fulcrums, we should IMO include - upgrade test frameworks to Junit 4 - align dependencies with Turbine M2 Trunk and - probably do a lazy release of parents beforehand. To have a schedule, may be we should - review by end of june the changes? - check then, if it worth the effort to do a bulk release or just a selection of components (JSON should be included) ? BTW: Any thoughts about Atmosphere framework? Best regards, Georg Von: Siegfried Goeschl <[email protected]> An: Turbine Developers List <[email protected]> Datum: 23.03.2015 22:24 Betreff: Re: Concerning Releases / Settings Hi folks, a few thoughts along the line @Turbine Parent POM - there is lazy consensus and there are lazy committers - shame on me - can’t remember the email but I’m fine with the decision @Logging - agreeing with Thomas. Avalon uses it’s own logging facade and the Fulcrum services are not directly dependent on Log4J. If we are planning to change the underlying logging framework this might be tricky and requires some investigation @Releases - I suggest to make a “bulk” release of Fulcrum components - from my POV * I touched “fulcrum-testcontainer” to set the log level manually since I drown in DEBUG output * Did some cosmetic changes to “fulcrum-yaafi” - only really thing is proper closing of file handles when working with decrypting input streams * Synced “fulcrum-commonsemail” with my production code - this is about supporting SSL & TLS and using the latest version of commons-email Any other components which need some care? Thanks in advance Siegfried Goeschl > On 22 Mar 2015, at 12:41, Thomas Vandahl <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
