You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Georg Kallidis <ge...@cedis.fu-berlin.de> on 2015/03/19 20:09:24 UTC
Concerning Releases / Settings
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, ..).
- 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)..
- 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?
Best regards, Georg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Antwort: Re: Concerning Releases / Settings
Posted by Georg Kallidis <ge...@cedis.fu-berlin.de>.
Hi Siegfried,
- lazy consensus would be nice at least for the parent releases ..
ok, Java 8 lamdas could not used then of course..
@logging: I find the reloading mechanism of logback quite useful...
Best regards, Georg
-----Siegfried Goeschl <si...@it20one.com> schrieb: -----
An: Turbine Developers List <de...@turbine.apache.org>
Von: Siegfried Goeschl <si...@it20one.com>
Datum: 19.03.2015 21:41
Betreff: Re: Concerning Releases / Settings
Hi Georg,
please see my comments below
Cheers,
Siegfried Goeschl
> On 19 Mar 2015, at 20:09, Georg Kallidis <ge...@cedis.fu-berlin.de> 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, ..).
As far as I’m concerned it would be at least a vote with lazy consensus :-)
>
> - 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)..
-1 on explicitly supporting ONLY Java 8. Having said that
* we have to support JDK 8 but there is no need to add Java 8 only features
* I’m sure that some Turbine installation in the wild have not seen a JDK update for years :-)
* I have customer which are stuck to JDK 1.6/1.7 (mostly AS400)
>
> - 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?
The Avalon Framework depends slightly on Log4j
https://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1.pom <https://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1.pom>
and a couple of Fulcrum components are importing log4j as well - what would be the benefits?
>
> Best regards, Georg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
Re: Concerning Releases / Settings
Posted by Siegfried Goeschl <si...@it20one.com>.
Hi Georg,
please see my comments below
Cheers,
Siegfried Goeschl
> On 19 Mar 2015, at 20:09, Georg Kallidis <ge...@cedis.fu-berlin.de> 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, ..).
As far as I’m concerned it would be at least a vote with lazy consensus :-)
>
> - 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)..
-1 on explicitly supporting ONLY Java 8. Having said that
* we have to support JDK 8 but there is no need to add Java 8 only features
* I’m sure that some Turbine installation in the wild have not seen a JDK update for years :-)
* I have customer which are stuck to JDK 1.6/1.7 (mostly AS400)
>
> - 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?
The Avalon Framework depends slightly on Log4j
https://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1.pom <https://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3.1/avalon-framework-impl-4.3.1.pom>
and a couple of Fulcrum components are importing log4j as well - what would be the benefits?
>
> Best regards, Georg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
Re: Re: Concerning Releases / Settings
Posted by Georg Kallidis <gk...@cedis.fu-berlin.de>.
Hi Thomas,
commons-logging is used in many Turbine classes, but
- in conf/test commons-logging.properties has been removed, may be before
2008?
- Turbine initialization is done with log4j as default
To be consistent again I would suggest, that in pom.xml the test resource
should be replaced with the existing Log4j.properties.
Secondly the jcl dependency should be removed/excluded, as commons logging
calls are now delegated to jcl-over-slf4j.
I think, we should for now just reflect this consistently.
To support different logging frameworks (logback, log4j, other
frameworks), this should be done may be in a fulcrum-log component?
Best regards, Georg
Von: Thomas Vandahl <tv...@apache.org>
An: Turbine Developers List <de...@turbine.apache.org>
Datum: 22.03.2015 12:41
Betreff: Re: Concerning Releases / Settings
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: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Re: Concerning Releases / Settings
Posted by Siegfried Goeschl <si...@it20one.com>.
No wonder they call me “Senile Software Engineer” :-(
Sigi
> On 21 Apr 2015, at 19:13, Thomas Vandahl <tv...@apache.org> wrote:
>
> Hi Siegfried,
>
> On 20.04.15 20:27, Siegfried Goeschl wrote:
>> Hi Thomas,
>>
>> I added the snapshot repo to my settings.xml and it worx - but where does the file actually live under SVN? I would assume that building whole Fulcrum would deploy the file into my local repo :-)
>
> It's in fulcrum/parent and IIRC, you were the one who placed it there :-)
>
> Bye, Thomas.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Re: Concerning Releases / Settings
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Siegfried,
On 20.04.15 20:27, Siegfried Goeschl wrote:
> Hi Thomas,
>
> I added the snapshot repo to my settings.xml and it worx - but where does the file actually live under SVN? I would assume that building whole Fulcrum would deploy the file into my local repo :-)
It's in fulcrum/parent and IIRC, you were the one who placed it there :-)
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Re: Concerning Releases / Settings
Posted by Siegfried Goeschl <si...@it20one.com>.
Hi Thomas,
I added the snapshot repo to my settings.xml and it worx - but where does the file actually live under SVN? I would assume that building whole Fulcrum would deploy the file into my local repo :-)
Thanks in advance
Siegfried Goeschl
> On 07 Apr 2015, at 18:46, Thomas Vandahl <tv...@apache.org> wrote:
>
> On 04.04.15 11:21, Siegfried Goeschl wrote:
>> Hi Georg,
>>
>> I just checked the trunk and I can’t compile
>
> Please retry. I deployed fulcrum-parent-2.0-SNAPSHOT to the
> apache.snapshots.https repository, so you should now be able to resolve it.
>
> Bye, Thomas.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Re: Concerning Releases / Settings
Posted by Thomas Vandahl <tv...@apache.org>.
On 04.04.15 11:21, Siegfried Goeschl wrote:
> Hi Georg,
>
> I just checked the trunk and I can’t compile
Please retry. I deployed fulcrum-parent-2.0-SNAPSHOT to the
apache.snapshots.https repository, so you should now be able to resolve it.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Antwort: Re: Concerning Releases / Settings
Posted by Siegfried Goeschl <si...@it20one.com>.
Hi Georg,
I just checked the trunk and I can’t compile
trunk> svn up
Updating '.':
At revision 1671257.
trunk> mvn clean install
[INFO] Scanning for projects...
[ERROR] The build could not read 3 projects -> [Help 1]
[ERROR]
[ERROR] The project org.apache.fulcrum:fulcrum-cache:1.1.1-SNAPSHOT (/Users/sgoeschl/work/asf/fulcrum/trunk/cache/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact org.apache.fulcrum:fulcrum-parent:pom:2-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 19, column 11 -> [Help 2]
[ERROR]
[ERROR] The project org.apache.fulcrum:fulcrum-configuration:1.0.3-SNAPSHOT (/Users/sgoeschl/work/asf/fulcrum/trunk/configuration/impl/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact org.apache.fulcrum:fulcrum-parent:pom:2-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 22, column 11 -> [Help 2]
[ERROR]
[ERROR] The project org.apache.fulcrum:fulcrum-crypto:1.0.8-SNAPSHOT (/Users/sgoeschl/work/asf/fulcrum/trunk/crypto/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact org.apache.fulcrum:fulcrum-parent:pom:2-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 19, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
It seems the fulcrum-parent.pom is missing in my setup ….
Thanks in advance
Siegfried Goeschl
> On 27 Mar 2015, at 08:29, Georg Kallidis <gk...@cedis.fu-berlin.de> wrote:
>
> 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 <si...@it20one.com>
> An: Turbine Developers List <de...@turbine.apache.org>
> 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 <tv...@apache.org> 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: dev-unsubscribe@turbine.apache.org
>> For additional commands, e-mail: dev-help@turbine.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
Antwort: Re: Concerning Releases / Settings
Posted by Georg Kallidis <gk...@cedis.fu-berlin.de>.
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 <si...@it20one.com>
An: Turbine Developers List <de...@turbine.apache.org>
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 <tv...@apache.org> 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: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Concerning Releases / Settings
Posted by Siegfried Goeschl <si...@it20one.com>.
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 <tv...@apache.org> 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: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Concerning Releases / Settings
Posted by Thomas Vandahl <tv...@apache.org>.
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: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Concerning Releases / Settings
Posted by Thomas Vandahl <tv...@apache.org>.
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, ..).
>
> - 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 forgot: Turbine trunk is actually waiting for a release of
fulcrum-security (and fulcrum-intake which I'm currently decomposing)
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org