You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Thomas Neidhart <th...@gmail.com> on 2013/01/12 15:03:37 UTC

[logging] Cleanup of trunk

Hi,

I would like to do a similar cleanup as for email also for logging and
aim for a 1.2 release in the coming weeks. The things I have in mind:

 * update to Java 5
 * comply to default maven structure
 * update to Junit 4
 * fix the open issues wrt thread safety
 * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
   LOGGING-119)

What do you think?

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Thomas Neidhart <th...@gmail.com>.
On 01/12/2013 03:34 PM, Gary Gregory wrote:
> Sounds good to me.
> 
> If Java 6 helps in any way, I would be OK with using it.

Well, I wanted to be conservative, but Java 6 is also fine for me if
nobody objects.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Gary Gregory <ga...@gmail.com>.
Sounds good to me.

If Java 6 helps in any way, I would be OK with using it.

Gary

On Jan 12, 2013, at 9:04, Thomas Neidhart <th...@gmail.com> wrote:

> Hi,
>
> I would like to do a similar cleanup as for email also for logging and
> aim for a 1.2 release in the coming weeks. The things I have in mind:
>
> * update to Java 5
> * comply to default maven structure
> * update to Junit 4
> * fix the open issues wrt thread safety
> * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
>   LOGGING-119)
>
> What do you think?
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Jörg Schaible <jo...@gmx.de>.
Hi Thomas,

Thomas Neidhart wrote:

> Hi,
> 
> I would like to do a similar cleanup as for email also for logging and
> aim for a 1.2 release in the coming weeks. The things I have in mind:
> 
>  * update to Java 5

+1, because it also means that we can simplify the code using the stuff from 
the concurrent package. Anyone who needs binaries targeting an older JDK 
might still use 1.x (like he did the last years).

>  * comply to default maven structure

+1

>  * update to Junit 4

+1

>  * fix the open issues wrt thread safety
>  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
>    LOGGING-119)

+1, see above

> What do you think?

It's about time.

- Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Dennis Lundberg <de...@apache.org>.
On 2013-01-15 09:56, Christian Grobmeier wrote:
> On Sat, Jan 12, 2013 at 8:49 PM, Mark Thomas <ma...@apache.org> wrote:
>> On 12/01/2013 19:29, Christian Grobmeier wrote:
>>> On Sat, Jan 12, 2013 at 8:27 PM, Mark Thomas <ma...@apache.org> wrote:
>>>> On 12/01/2013 17:36, Christian Grobmeier wrote:
>>>>
>>>>> Basically I am +1 on moving to newer JDKs. But in this case I just see
>>>>> use for old and older applications.
>>>>> That said, I just checked and saw tomcat is still using commons-logging:
>>>>> http://svn.apache.org/repos/asf/tomcat/trunk/build.xml
>>>>>
>>>>> Maybe Mark will comment here.
>>>>
>>>> Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x
>>>> Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x
>>>> Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever
>>>> the latest version is.
>>>
>>> Just out of interest... why the love with Commons Logging and not for
>>> example slf4j?
>>
>> It was the best choice at the time and no-one has made a good argument
>> for changing.
>>
>> Tomcat used C-L to create JULI which is package renamed (to avoid
>> conflicts if a webapp uses C-L), hard coded to use java.util.logging and
>> has a custom LogManager that actually works properly in a
>> multi-classloader container environment - don't get me started on how
>> bad the default one is.
>>
>> There is an optional package that adds back in the (still package
>> renamed) full version of commons logging and provides an adaptor for log4j.
>>
>> So Tomcat's requirements are:
>> - easy to package rename (technically and legally)
>> - pluggable for multiple back-ends
>> - won't clash with anything a webapp does
>>
>> Commons Logging meets all of those requirements. Other logging
>> frameworks may also meet them but they'd have to offer an awful lot more
>> to justify the work that would be required to refactor JULI to use them.
>> It isn't as if there are any features missing in C-L that Tomcat
>> needs/wants.
> 
> Thanks for the insight.
> 
> Maybe it would be interesting to change the targets of commons-logging.
> 
> Currently it is in direct competition with slf4j (logging facade which
> connects to different other frameworks). And as that its pretty
> outdated and just of use for a few.
> 
> But what if commons-logging would have the target to be minimal, easy
> to repackage and maybe does even provide a basic logging
> implementation.

It already includes a basic logging implementation: SimpleLog.

> The other frameworks come up with a lot of features which often comes
> with a lot of complexity and sometimes a cost in performance.
> commons-logging could solve this.
> 
> Christian
> 
> 
> 
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> 
> 
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Christian Grobmeier <gr...@gmail.com>.
On Sat, Jan 12, 2013 at 8:49 PM, Mark Thomas <ma...@apache.org> wrote:
> On 12/01/2013 19:29, Christian Grobmeier wrote:
>> On Sat, Jan 12, 2013 at 8:27 PM, Mark Thomas <ma...@apache.org> wrote:
>>> On 12/01/2013 17:36, Christian Grobmeier wrote:
>>>
>>>> Basically I am +1 on moving to newer JDKs. But in this case I just see
>>>> use for old and older applications.
>>>> That said, I just checked and saw tomcat is still using commons-logging:
>>>> http://svn.apache.org/repos/asf/tomcat/trunk/build.xml
>>>>
>>>> Maybe Mark will comment here.
>>>
>>> Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x
>>> Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x
>>> Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever
>>> the latest version is.
>>
>> Just out of interest... why the love with Commons Logging and not for
>> example slf4j?
>
> It was the best choice at the time and no-one has made a good argument
> for changing.
>
> Tomcat used C-L to create JULI which is package renamed (to avoid
> conflicts if a webapp uses C-L), hard coded to use java.util.logging and
> has a custom LogManager that actually works properly in a
> multi-classloader container environment - don't get me started on how
> bad the default one is.
>
> There is an optional package that adds back in the (still package
> renamed) full version of commons logging and provides an adaptor for log4j.
>
> So Tomcat's requirements are:
> - easy to package rename (technically and legally)
> - pluggable for multiple back-ends
> - won't clash with anything a webapp does
>
> Commons Logging meets all of those requirements. Other logging
> frameworks may also meet them but they'd have to offer an awful lot more
> to justify the work that would be required to refactor JULI to use them.
> It isn't as if there are any features missing in C-L that Tomcat
> needs/wants.

Thanks for the insight.

Maybe it would be interesting to change the targets of commons-logging.

Currently it is in direct competition with slf4j (logging facade which
connects to different other frameworks). And as that its pretty
outdated and just of use for a few.

But what if commons-logging would have the target to be minimal, easy
to repackage and maybe does even provide a basic logging
implementation.

The other frameworks come up with a lot of features which often comes
with a lot of complexity and sometimes a cost in performance.
commons-logging could solve this.

Christian



> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



--
http://www.grobmeier.de
https://www.timeandbill.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Mark Thomas <ma...@apache.org>.
On 12/01/2013 19:29, Christian Grobmeier wrote:
> On Sat, Jan 12, 2013 at 8:27 PM, Mark Thomas <ma...@apache.org> wrote:
>> On 12/01/2013 17:36, Christian Grobmeier wrote:
>>
>>> Basically I am +1 on moving to newer JDKs. But in this case I just see
>>> use for old and older applications.
>>> That said, I just checked and saw tomcat is still using commons-logging:
>>> http://svn.apache.org/repos/asf/tomcat/trunk/build.xml
>>>
>>> Maybe Mark will comment here.
>>
>> Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x
>> Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x
>> Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever
>> the latest version is.
> 
> Just out of interest... why the love with Commons Logging and not for
> example slf4j?

It was the best choice at the time and no-one has made a good argument
for changing.

Tomcat used C-L to create JULI which is package renamed (to avoid
conflicts if a webapp uses C-L), hard coded to use java.util.logging and
has a custom LogManager that actually works properly in a
multi-classloader container environment - don't get me started on how
bad the default one is.

There is an optional package that adds back in the (still package
renamed) full version of commons logging and provides an adaptor for log4j.

So Tomcat's requirements are:
- easy to package rename (technically and legally)
- pluggable for multiple back-ends
- won't clash with anything a webapp does

Commons Logging meets all of those requirements. Other logging
frameworks may also meet them but they'd have to offer an awful lot more
to justify the work that would be required to refactor JULI to use them.
It isn't as if there are any features missing in C-L that Tomcat
needs/wants.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Gary Gregory <ga...@gmail.com>.
Or log4j 2 for that matter?

Gary

On Jan 12, 2013, at 14:29, Christian Grobmeier <gr...@gmail.com> wrote:

> On Sat, Jan 12, 2013 at 8:27 PM, Mark Thomas <ma...@apache.org> wrote:
>> On 12/01/2013 17:36, Christian Grobmeier wrote:
>>
>>> Basically I am +1 on moving to newer JDKs. But in this case I just see
>>> use for old and older applications.
>>> That said, I just checked and saw tomcat is still using commons-logging:
>>> http://svn.apache.org/repos/asf/tomcat/trunk/build.xml
>>>
>>> Maybe Mark will comment here.
>>
>> Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x
>> Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x
>> Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever
>> the latest version is.
>
> Just out of interest... why the love with Commons Logging and not for
> example slf4j?
>
> Christian
>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Christian Grobmeier <gr...@gmail.com>.
On Sat, Jan 12, 2013 at 8:27 PM, Mark Thomas <ma...@apache.org> wrote:
> On 12/01/2013 17:36, Christian Grobmeier wrote:
>
>> Basically I am +1 on moving to newer JDKs. But in this case I just see
>> use for old and older applications.
>> That said, I just checked and saw tomcat is still using commons-logging:
>> http://svn.apache.org/repos/asf/tomcat/trunk/build.xml
>>
>> Maybe Mark will comment here.
>
> Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x
> Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x
> Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever
> the latest version is.

Just out of interest... why the love with Commons Logging and not for
example slf4j?

Christian

> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



--
http://www.grobmeier.de
https://www.timeandbill.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Mark Thomas <ma...@apache.org>.
On 12/01/2013 17:36, Christian Grobmeier wrote:

> Basically I am +1 on moving to newer JDKs. But in this case I just see
> use for old and older applications.
> That said, I just checked and saw tomcat is still using commons-logging:
> http://svn.apache.org/repos/asf/tomcat/trunk/build.xml
> 
> Maybe Mark will comment here.

Tomcat 6 (min JDK 5) will certainly stick with Commons Logging 1.1.x
Tomcat 7 (min JDK 6) will probably stick with Commons Logging 1.1.x
Tomcat 8 (min JDK 7) will - at the moment - look to upgrade to whatever
the latest version is.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Christian Grobmeier <gr...@gmail.com>.
On Sat, Jan 12, 2013 at 6:26 PM, Thomas Neidhart
<th...@gmail.com> wrote:
> On 01/12/2013 05:37 PM, Christian Grobmeier wrote:
>> On Sat, Jan 12, 2013 at 3:03 PM, Thomas Neidhart
>> <th...@gmail.com> wrote:
>>> Hi,
>>>
>>> I would like to do a similar cleanup as for email also for logging and
>>> aim for a 1.2 release in the coming weeks. The things I have in mind:
>>>
>>>  * update to Java 5
>>>  * comply to default maven structure
>>>  * update to Junit 4
>>>  * fix the open issues wrt thread safety
>>>  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
>>>    LOGGING-119)
>>>
>>> What do you think?
>>
>> from technical point of view +1.
>> But do you really think its worth fixing [logging]?
>> As I see it its just for use of legacy applications. Or are you
>> looking to implement commons-logging 2.0 which supports f.e. logback
>> or log4j2?
>>
>> If you go with java5 it probably does not have use for legacy apps and
>> with the lack of modern logging framework support it does not have use
>> for modern apps.
>
> Well, the main idea is to maintain an old library with useful bugfixes.
> My thought was that *nobody* uses Java < 5 anymore, but this assumption
> may be wrong. In general I am fine with keeping the current java
> compatibility settings.

Basically I am +1 on moving to newer JDKs. But in this case I just see
use for old and older applications.
That said, I just checked and saw tomcat is still using commons-logging:
http://svn.apache.org/repos/asf/tomcat/trunk/build.xml

Maybe Mark will comment here.

That said, if we level up the jdk depedency we should also bump the
major version number

Cheers


> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



--
http://www.grobmeier.de
https://www.timeandbill.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Thomas Neidhart <th...@gmail.com>.
On 01/12/2013 05:37 PM, Christian Grobmeier wrote:
> On Sat, Jan 12, 2013 at 3:03 PM, Thomas Neidhart
> <th...@gmail.com> wrote:
>> Hi,
>>
>> I would like to do a similar cleanup as for email also for logging and
>> aim for a 1.2 release in the coming weeks. The things I have in mind:
>>
>>  * update to Java 5
>>  * comply to default maven structure
>>  * update to Junit 4
>>  * fix the open issues wrt thread safety
>>  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
>>    LOGGING-119)
>>
>> What do you think?
> 
> from technical point of view +1.
> But do you really think its worth fixing [logging]?
> As I see it its just for use of legacy applications. Or are you
> looking to implement commons-logging 2.0 which supports f.e. logback
> or log4j2?
> 
> If you go with java5 it probably does not have use for legacy apps and
> with the lack of modern logging framework support it does not have use
> for modern apps.

Well, the main idea is to maintain an old library with useful bugfixes.
My thought was that *nobody* uses Java < 5 anymore, but this assumption
may be wrong. In general I am fine with keeping the current java
compatibility settings.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Christian Grobmeier <gr...@gmail.com>.
On Sat, Jan 12, 2013 at 3:03 PM, Thomas Neidhart
<th...@gmail.com> wrote:
> Hi,
>
> I would like to do a similar cleanup as for email also for logging and
> aim for a 1.2 release in the coming weeks. The things I have in mind:
>
>  * update to Java 5
>  * comply to default maven structure
>  * update to Junit 4
>  * fix the open issues wrt thread safety
>  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
>    LOGGING-119)
>
> What do you think?

from technical point of view +1.
But do you really think its worth fixing [logging]?
As I see it its just for use of legacy applications. Or are you
looking to implement commons-logging 2.0 which supports f.e. logback
or log4j2?

If you go with java5 it probably does not have use for legacy apps and
with the lack of modern logging framework support it does not have use
for modern apps.

Cheers




>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>



--
http://www.grobmeier.de
https://www.timeandbill.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, Jan 15, 2013 at 7:43 PM, Thomas Neidhart
<th...@gmail.com> wrote:
>> I'm -1 on this change. I don't see any reason to do it. We don't need
>> features from a more recent Java version in commons-logging. As others
>> have said: most users of commons-logging are old and older apps.
>
> In general I am fine with keeping the current JDK compatibility, but
> there are also a few points in favor of such a change:
>
>  * how can we ensure compatibility with such outdated JDKs today?
>    minimum jdk I have installed is JDK 1.5
>
>  * the codebase is at parts quite complex as it has to deal with
>    such a wide range of supported JDKs. Reducing the number for (future)
>    releases would simplify the maintenance (and we could remove some
>    old code for pre-1.4 JDKs).
>
> There are still lots of other (non-legacy) projects that use
> commons-logging, e.g. spring. But maybe we could also keep the 1.x
> branch on java 1.1, and create a 2.x branch which targets java 5.

+1

We (Commons) should more often behave like living in 2013, not like 2004.
If you like to do it and if you see need for it, go and have fun! :-)


--
http://www.grobmeier.de
https://www.timeandbill.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Benedikt Ritter <be...@gmail.com>.
2013/1/15 Thomas Neidhart <th...@gmail.com>

> On 01/15/2013 07:17 PM, Dennis Lundberg wrote:
> > On 2013-01-12 15:03, Thomas Neidhart wrote:
> >> Hi,
> >
> > Hi Thomas
> >
> > A while back I made changes to the Maven build so that it produces the
> > same output as the Ant build. The should mean that we can get rid of the
> > old Ant build if we want to.
>
> I think the ant build script it is used by gump atm.
>
> > One thing that I'd like to do is to restructure the source code into
> > several separate Maven modules, so that there is a specific module for
> > commons-logging-api. The current setup is error prone, as it is
> > extracting certain files from certain archives and then repackaging them
> > again, with the risk of loosing meta data like MANIFEST.MF.
>
> Yes I like that idea, the current packaging and testing is quite odd,
> e.g. one has to run mvn integration-test to do the actual unit tests.
>
> btw. does anybody know how to automatically do a verify phase when doing
> a mvn site, otherwise the results of the integration-tests are not
> published.
>
> >> I would like to do a similar cleanup as for email also for logging and
> >> aim for a 1.2 release in the coming weeks. The things I have in mind:
> >>
> >>  * update to Java 5
> >
> > I'm -1 on this change. I don't see any reason to do it. We don't need
> > features from a more recent Java version in commons-logging. As others
> > have said: most users of commons-logging are old and older apps.
>
> In general I am fine with keeping the current JDK compatibility, but
> there are also a few points in favor of such a change:
>
>  * how can we ensure compatibility with such outdated JDKs today?
>    minimum jdk I have installed is JDK 1.5
>
>  * the codebase is at parts quite complex as it has to deal with
>    such a wide range of supported JDKs. Reducing the number for (future)
>    releases would simplify the maintenance (and we could remove some
>    old code for pre-1.4 JDKs).
>
> There are still lots of other (non-legacy) projects that use
> commons-logging, e.g. spring. But maybe we could also keep the 1.x
> branch on java 1.1, and create a 2.x branch which targets java 5.
>

Maybe we can ask Spring folks, what they would like to see in a new
release, like we did for Tomcat?


>
> >>  * comply to default maven structure
> >
> > +1
>
> already did so.
>
> >>  * update to Junit 4
> >
> > +1
>
> still open.
>
> >>  * fix the open issues wrt thread safety
>
> Sebb created some issues about this topic, and there is one
> (reproducible) deadlock scenario with the WeakHashtable.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [logging] Cleanup of trunk

Posted by Thomas Neidhart <th...@gmail.com>.
On 01/15/2013 07:17 PM, Dennis Lundberg wrote:
> On 2013-01-12 15:03, Thomas Neidhart wrote:
>> Hi,
> 
> Hi Thomas
> 
> A while back I made changes to the Maven build so that it produces the
> same output as the Ant build. The should mean that we can get rid of the
> old Ant build if we want to.

I think the ant build script it is used by gump atm.

> One thing that I'd like to do is to restructure the source code into
> several separate Maven modules, so that there is a specific module for
> commons-logging-api. The current setup is error prone, as it is
> extracting certain files from certain archives and then repackaging them
> again, with the risk of loosing meta data like MANIFEST.MF.

Yes I like that idea, the current packaging and testing is quite odd,
e.g. one has to run mvn integration-test to do the actual unit tests.

btw. does anybody know how to automatically do a verify phase when doing
a mvn site, otherwise the results of the integration-tests are not
published.

>> I would like to do a similar cleanup as for email also for logging and
>> aim for a 1.2 release in the coming weeks. The things I have in mind:
>>
>>  * update to Java 5
> 
> I'm -1 on this change. I don't see any reason to do it. We don't need
> features from a more recent Java version in commons-logging. As others
> have said: most users of commons-logging are old and older apps.

In general I am fine with keeping the current JDK compatibility, but
there are also a few points in favor of such a change:

 * how can we ensure compatibility with such outdated JDKs today?
   minimum jdk I have installed is JDK 1.5

 * the codebase is at parts quite complex as it has to deal with
   such a wide range of supported JDKs. Reducing the number for (future)
   releases would simplify the maintenance (and we could remove some
   old code for pre-1.4 JDKs).

There are still lots of other (non-legacy) projects that use
commons-logging, e.g. spring. But maybe we could also keep the 1.x
branch on java 1.1, and create a 2.x branch which targets java 5.

>>  * comply to default maven structure
> 
> +1

already did so.

>>  * update to Junit 4
> 
> +1

still open.

>>  * fix the open issues wrt thread safety

Sebb created some issues about this topic, and there is one
(reproducible) deadlock scenario with the WeakHashtable.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Gary Gregory <ga...@gmail.com>.
Java 5 or 6 is fine with me as a new req. This is a new version. No one is
forced to upgrade. If a volunteer wants to do the work, that's fine with me.

Gary


On Tue, Jan 15, 2013 at 1:29 PM, Dennis Lundberg <de...@apache.org> wrote:

> On 2013-01-15 19:20, Gary Gregory wrote:
> > On Tue, Jan 15, 2013 at 1:17 PM, Dennis Lundberg <de...@apache.org>
> wrote:
> >
> >> On 2013-01-12 15:03, Thomas Neidhart wrote:
> >>> Hi,
> >>
> >> Hi Thomas
> >>
> >> A while back I made changes to the Maven build so that it produces the
> >> same output as the Ant build. The should mean that we can get rid of the
> >> old Ant build if we want to.
> >>
> >> One thing that I'd like to do is to restructure the source code into
> >> several separate Maven modules, so that there is a specific module for
> >> commons-logging-api. The current setup is error prone, as it is
> >> extracting certain files from certain archives and then repackaging them
> >> again, with the risk of loosing meta data like MANIFEST.MF.
> >>
> >>> I would like to do a similar cleanup as for email also for logging and
> >>> aim for a 1.2 release in the coming weeks. The things I have in mind:
> >>>
> >>>  * update to Java 5
> >>
> >> I'm -1 on this change. I don't see any reason to do it. We don't need
> >> features from a more recent Java version in commons-logging. As others
> >> have said: most users of commons-logging are old and older apps.
> >>
> >>>  * comply to default maven structure
> >>
> >> +1
> >>
> >>>  * update to Junit 4
> >>
> >> +1
> >>
> >
> > You need Java 5 to use JUnit 4 properly. @Test...
>
> Yes, but requiring Java 5 to build is not the same thing as setting the
> minimum runtime Java version to Java 5.
>
> Using something like animal sniffer we can make sure that we don't break
> the compatibility with older JDKs. However we might need to up the
> target version from 1.1 to 1.2 since there are no signatures available
> for Java 1.1.
>
> http://mojo.codehaus.org/animal-sniffer-maven-plugin/
>
> > Gary
> >
> >>
> >>>  * fix the open issues wrt thread safety
> >>
> >> Are there patches available for these issues?
> >> Which issues are we talking about?
> >>
> >>>  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
> >>>    LOGGING-119)
> >>>
> >>> What do you think?
> >>>
> >>> Thomas
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >>
> >> --
> >> Dennis Lundberg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [logging] Cleanup of trunk

Posted by Dennis Lundberg <de...@apache.org>.
On 2013-01-15 19:20, Gary Gregory wrote:
> On Tue, Jan 15, 2013 at 1:17 PM, Dennis Lundberg <de...@apache.org> wrote:
> 
>> On 2013-01-12 15:03, Thomas Neidhart wrote:
>>> Hi,
>>
>> Hi Thomas
>>
>> A while back I made changes to the Maven build so that it produces the
>> same output as the Ant build. The should mean that we can get rid of the
>> old Ant build if we want to.
>>
>> One thing that I'd like to do is to restructure the source code into
>> several separate Maven modules, so that there is a specific module for
>> commons-logging-api. The current setup is error prone, as it is
>> extracting certain files from certain archives and then repackaging them
>> again, with the risk of loosing meta data like MANIFEST.MF.
>>
>>> I would like to do a similar cleanup as for email also for logging and
>>> aim for a 1.2 release in the coming weeks. The things I have in mind:
>>>
>>>  * update to Java 5
>>
>> I'm -1 on this change. I don't see any reason to do it. We don't need
>> features from a more recent Java version in commons-logging. As others
>> have said: most users of commons-logging are old and older apps.
>>
>>>  * comply to default maven structure
>>
>> +1
>>
>>>  * update to Junit 4
>>
>> +1
>>
> 
> You need Java 5 to use JUnit 4 properly. @Test...

Yes, but requiring Java 5 to build is not the same thing as setting the
minimum runtime Java version to Java 5.

Using something like animal sniffer we can make sure that we don't break
the compatibility with older JDKs. However we might need to up the
target version from 1.1 to 1.2 since there are no signatures available
for Java 1.1.

http://mojo.codehaus.org/animal-sniffer-maven-plugin/

> Gary
> 
>>
>>>  * fix the open issues wrt thread safety
>>
>> Are there patches available for these issues?
>> Which issues are we talking about?
>>
>>>  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
>>>    LOGGING-119)
>>>
>>> What do you think?
>>>
>>> Thomas
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [logging] Cleanup of trunk

Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jan 15, 2013 at 1:17 PM, Dennis Lundberg <de...@apache.org> wrote:

> On 2013-01-12 15:03, Thomas Neidhart wrote:
> > Hi,
>
> Hi Thomas
>
> A while back I made changes to the Maven build so that it produces the
> same output as the Ant build. The should mean that we can get rid of the
> old Ant build if we want to.
>
> One thing that I'd like to do is to restructure the source code into
> several separate Maven modules, so that there is a specific module for
> commons-logging-api. The current setup is error prone, as it is
> extracting certain files from certain archives and then repackaging them
> again, with the risk of loosing meta data like MANIFEST.MF.
>
> > I would like to do a similar cleanup as for email also for logging and
> > aim for a 1.2 release in the coming weeks. The things I have in mind:
> >
> >  * update to Java 5
>
> I'm -1 on this change. I don't see any reason to do it. We don't need
> features from a more recent Java version in commons-logging. As others
> have said: most users of commons-logging are old and older apps.
>
> >  * comply to default maven structure
>
> +1
>
> >  * update to Junit 4
>
> +1
>

You need Java 5 to use JUnit 4 properly. @Test...

Gary

>
> >  * fix the open issues wrt thread safety
>
> Are there patches available for these issues?
> Which issues are we talking about?
>
> >  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
> >    LOGGING-119)
> >
> > What do you think?
> >
> > Thomas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [logging] Cleanup of trunk

Posted by Dennis Lundberg <de...@apache.org>.
On 2013-01-12 15:03, Thomas Neidhart wrote:
> Hi,

Hi Thomas

A while back I made changes to the Maven build so that it produces the
same output as the Ant build. The should mean that we can get rid of the
old Ant build if we want to.

One thing that I'd like to do is to restructure the source code into
several separate Maven modules, so that there is a specific module for
commons-logging-api. The current setup is error prone, as it is
extracting certain files from certain archives and then repackaging them
again, with the risk of loosing meta data like MANIFEST.MF.

> I would like to do a similar cleanup as for email also for logging and
> aim for a 1.2 release in the coming weeks. The things I have in mind:
> 
>  * update to Java 5

I'm -1 on this change. I don't see any reason to do it. We don't need
features from a more recent Java version in commons-logging. As others
have said: most users of commons-logging are old and older apps.

>  * comply to default maven structure

+1

>  * update to Junit 4

+1

>  * fix the open issues wrt thread safety

Are there patches available for these issues?
Which issues are we talking about?

>  * replace WeakHashtable with a WeakHashMap or a ConcurrentHashMap (see
>    LOGGING-119)
> 
> What do you think?
> 
> Thomas
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org