Re: [logging] Commons Logging 2.0?
On Mon, Dec 1, 2014, at 00:50, sebb wrote:
But it would be interesting to know why the Spring dev thought a new
version would be useful.
The team seemed to discuss moving to slf4j, but he mentioned they were
happy not doing it since the learned about bc breaks within slf4j
versions. In general he was totally enjoying that CL just works.
However he appeared to miss some things which make logging-lifes easier,
like String substitution in:
log.debug(Hello {} {}, a.getGivenName(), a.getName());
More specifically he mentioned MessageFormat support:
https://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html
This is something all logging frameworks seem to support and which might
be possible to add without breaking things.
Current:
debug(Object message)
debug(Object message, Throwable t)
Addition:
debug(Object o, Object... args) {}
That aside, I would do the following:
- jdk support for at least 7 (varargs need 5, but MessageFormat 7)
- remove AvalonLogger and LogKitLogger
For anything more I would point to log4j 2.
Gary
div Original message /divdivFrom: Christian Grobmeier
grobme...@gmail.com /divdivDate:11/30/2014 16:27 (GMT-05:00)
/divdivTo: Commons Developers List dev@commons.apache.org
/divdivCc: /divdivSubject: [logging] Commons Logging 2.0?
/divdiv
/divHi folks,
I am perfectly aware that I was saying CL needs to be deprecated only
before month.
Tomcat uses CL and that was more or less the reason it would stay - so I
thought.
Recently I talked to a person actively involved in Spring. He explained,
Spring would use
CL and they are quite happy with it. Reason: it's always the same.
He also told me that - rather having a new JSR with new interfaces which
would be difficult to get into the JDK - he would love to have some kind
of CL 2.0.
To be honest, it made me think and reconsider whatever I have thought or
said in the past. I know Mark did say similar things, but maybe it is
the power of a direct conversation.
I am still unsure if a CL 2.0 would be needed or not and thats why I
outreach here to ask for your feelings/opinions whatever.
We have a Log4j2 which is really good. We have a slf4j which is fine.
And we have a CL 1.x which is, well dated.
Would it make sense to have a CL 2.0 which is more or less (maybe with
small adjustments, despite the major version jump) a drop in
replacement? It could just add some methods or things like variable
substitutions, and thats it. Nothing big. Modern JVM support, some more
methods. The rest all the same, except log4j 2 support (which is also
provided by the log4j project).
As mentioned I am still undecided. But CL 2.0 could be a minimal
interface for consumers looking for stability instead of tons of
features. However a bit more modern taste doesn't hurt, as long as it
doesn't break things (too much).
Thoughts?
Christian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Commons Logging 2.0?
On Mon, Dec 1, 2014, at 13:57, Gary Gregory wrote:
MessageFormat? WRT Log4j 2: So there's another thing to compare WRT to
performance and String.format and our own {} support... any thoughts
on that?
No, didn't think about this yet. I just pass on what I was told without
judgement for now
Christian
Gary
On Mon, Dec 1, 2014 at 4:28 AM, Christian Grobmeier grobme...@gmail.com
wrote:
On Mon, Dec 1, 2014, at 00:50, sebb wrote:
But it would be interesting to know why the Spring dev thought a new
version would be useful.
The team seemed to discuss moving to slf4j, but he mentioned they were
happy not doing it since the learned about bc breaks within slf4j
versions. In general he was totally enjoying that CL just works.
However he appeared to miss some things which make logging-lifes easier,
like String substitution in:
log.debug(Hello {} {}, a.getGivenName(), a.getName());
More specifically he mentioned MessageFormat support:
https://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html
This is something all logging frameworks seem to support and which might
be possible to add without breaking things.
Current:
debug(Object message)
debug(Object message, Throwable t)
Addition:
debug(Object o, Object... args) {}
That aside, I would do the following:
- jdk support for at least 7 (varargs need 5, but MessageFormat 7)
- remove AvalonLogger and LogKitLogger
For anything more I would point to log4j 2.
Gary
div Original message /divdivFrom: Christian
Grobmeier grobme...@gmail.com /divdivDate:11/30/2014 16:27
(GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org
/divdivCc: /divdivSubject: [logging] Commons Logging 2.0?
/divdiv
/divHi folks,
I am perfectly aware that I was saying CL needs to be deprecated only
before month.
Tomcat uses CL and that was more or less the reason it would stay - so
I
thought.
Recently I talked to a person actively involved in Spring. He
explained,
Spring would use
CL and they are quite happy with it. Reason: it's always the same.
He also told me that - rather having a new JSR with new interfaces
which
would be difficult to get into the JDK - he would love to have some
kind
of CL 2.0.
To be honest, it made me think and reconsider whatever I have thought
or
said in the past. I know Mark did say similar things, but maybe it is
the power of a direct conversation.
I am still unsure if a CL 2.0 would be needed or not and thats why I
outreach here to ask for your feelings/opinions whatever.
We have a Log4j2 which is really good. We have a slf4j which is fine.
And we have a CL 1.x which is, well dated.
Would it make sense to have a CL 2.0 which is more or less (maybe with
small adjustments, despite the major version jump) a drop in
replacement? It could just add some methods or things like variable
substitutions, and thats it. Nothing big. Modern JVM support, some more
methods. The rest all the same, except log4j 2 support (which is also
provided by the log4j project).
As mentioned I am still undecided. But CL 2.0 could be a minimal
interface for consumers looking for stability instead of tons of
features. However a bit more modern taste doesn't hurt, as long as it
doesn't break things (too much).
Thoughts?
Christian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Commons Logging 2.0?
On Mon, Dec 1, 2014, at 14:31, Gary Gregory wrote:
FWIW, I think a new version of CL would be 'fun' if it included support
for
Log4j 2...
Agreed. :)
Gary
On Mon, Dec 1, 2014 at 7:57 AM, Gary Gregory garydgreg...@gmail.com
wrote:
MessageFormat? WRT Log4j 2: So there's another thing to compare WRT to
performance and String.format and our own {} support... any thoughts on
that?
Gary
On Mon, Dec 1, 2014 at 4:28 AM, Christian Grobmeier grobme...@gmail.com
wrote:
On Mon, Dec 1, 2014, at 00:50, sebb wrote:
But it would be interesting to know why the Spring dev thought a new
version would be useful.
The team seemed to discuss moving to slf4j, but he mentioned they were
happy not doing it since the learned about bc breaks within slf4j
versions. In general he was totally enjoying that CL just works.
However he appeared to miss some things which make logging-lifes easier,
like String substitution in:
log.debug(Hello {} {}, a.getGivenName(), a.getName());
More specifically he mentioned MessageFormat support:
https://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html
This is something all logging frameworks seem to support and which might
be possible to add without breaking things.
Current:
debug(Object message)
debug(Object message, Throwable t)
Addition:
debug(Object o, Object... args) {}
That aside, I would do the following:
- jdk support for at least 7 (varargs need 5, but MessageFormat 7)
- remove AvalonLogger and LogKitLogger
For anything more I would point to log4j 2.
Gary
div Original message /divdivFrom: Christian
Grobmeier grobme...@gmail.com /divdivDate:11/30/2014 16:27
(GMT-05:00) /divdivTo: Commons Developers List
dev@commons.apache.org /divdivCc: /divdivSubject: [logging]
Commons Logging 2.0? /divdiv
/divHi folks,
I am perfectly aware that I was saying CL needs to be deprecated only
before month.
Tomcat uses CL and that was more or less the reason it would stay -
so I
thought.
Recently I talked to a person actively involved in Spring. He
explained,
Spring would use
CL and they are quite happy with it. Reason: it's always the same.
He also told me that - rather having a new JSR with new interfaces
which
would be difficult to get into the JDK - he would love to have some
kind
of CL 2.0.
To be honest, it made me think and reconsider whatever I have thought
or
said in the past. I know Mark did say similar things, but maybe it is
the power of a direct conversation.
I am still unsure if a CL 2.0 would be needed or not and thats why I
outreach here to ask for your feelings/opinions whatever.
We have a Log4j2 which is really good. We have a slf4j which is fine.
And we have a CL 1.x which is, well dated.
Would it make sense to have a CL 2.0 which is more or less (maybe with
small adjustments, despite the major version jump) a drop in
replacement? It could just add some methods or things like variable
substitutions, and thats it. Nothing big. Modern JVM support, some
more
methods. The rest all the same, except log4j 2 support (which is also
provided by the log4j project).
As mentioned I am still undecided. But CL 2.0 could be a minimal
interface for consumers looking for stability instead of tons of
features. However a bit more modern taste doesn't hurt, as long as
it
doesn't break things (too much).
Thoughts?
Christian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [logging] Commons Logging 2.0?
On Mon, Dec 1, 2014, at 18:04, sebb wrote: On 1 December 2014 at 09:28, Christian Grobmeier grobme...@gmail.com wrote: That aside, I would do the following: - jdk support for at least 7 (varargs need 5, but MessageFormat 7) Just saw MessageFormat is even available in jdk 5. So I would opt for this one. -1 if this means that CL no longer works on earlier versions of Java. -1? haha come on, what versions would you like to support? :) Jdk 1.3 is dead. And 1.4.2 is dead too. We speak of a CL 2.0 version, it must be allowed to work with more recent jdks. I can't even install that old versions on my mac. If you want to block any innovation then keep that approach of supporting 1.3. Spring needs Java 6, unarchived Tomcat versions require Java 5. We can discuss Java 5, but I am definitely not doing anything when I need to install a vm to test with 1.3. - remove AvalonLogger and LogKitLogger Why? AFAIK they just work, so why drop them? Why keeping them? The frameworks are dead for ages, it's unlikely users of Avalon might ever tend to upgrade to CL 2.0. Of course, if you would implement these methods for that frameworks, you are welcome. You need touch them to implement the new logging methods. Cheers Christian For anything more I would point to log4j 2. Gary div Original message /divdivFrom: Christian Grobmeier grobme...@gmail.com /divdivDate:11/30/2014 16:27 (GMT-05:00) /divdivTo: Commons Developers List dev@commons.apache.org /divdivCc: /divdivSubject: [logging] Commons Logging 2.0? /divdiv /divHi folks, I am perfectly aware that I was saying CL needs to be deprecated only before month. Tomcat uses CL and that was more or less the reason it would stay - so I thought. Recently I talked to a person actively involved in Spring. He explained, Spring would use CL and they are quite happy with it. Reason: it's always the same. He also told me that - rather having a new JSR with new interfaces which would be difficult to get into the JDK - he would love to have some kind of CL 2.0. To be honest, it made me think and reconsider whatever I have thought or said in the past. I know Mark did say similar things, but maybe it is the power of a direct conversation. I am still unsure if a CL 2.0 would be needed or not and thats why I outreach here to ask for your feelings/opinions whatever. We have a Log4j2 which is really good. We have a slf4j which is fine. And we have a CL 1.x which is, well dated. Would it make sense to have a CL 2.0 which is more or less (maybe with small adjustments, despite the major version jump) a drop in replacement? It could just add some methods or things like variable substitutions, and thats it. Nothing big. Modern JVM support, some more methods. The rest all the same, except log4j 2 support (which is also provided by the log4j project). As mentioned I am still undecided. But CL 2.0 could be a minimal interface for consumers looking for stability instead of tons of features. However a bit more modern taste doesn't hurt, as long as it doesn't break things (too much). Thoughts? Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[logging] Commons Logging 2.0?
Hi folks, I am perfectly aware that I was saying CL needs to be deprecated only before month. Tomcat uses CL and that was more or less the reason it would stay - so I thought. Recently I talked to a person actively involved in Spring. He explained, Spring would use CL and they are quite happy with it. Reason: it's always the same. He also told me that - rather having a new JSR with new interfaces which would be difficult to get into the JDK - he would love to have some kind of CL 2.0. To be honest, it made me think and reconsider whatever I have thought or said in the past. I know Mark did say similar things, but maybe it is the power of a direct conversation. I am still unsure if a CL 2.0 would be needed or not and thats why I outreach here to ask for your feelings/opinions whatever. We have a Log4j2 which is really good. We have a slf4j which is fine. And we have a CL 1.x which is, well dated. Would it make sense to have a CL 2.0 which is more or less (maybe with small adjustments, despite the major version jump) a drop in replacement? It could just add some methods or things like variable substitutions, and thats it. Nothing big. Modern JVM support, some more methods. The rest all the same, except log4j 2 support (which is also provided by the log4j project). As mentioned I am still undecided. But CL 2.0 could be a minimal interface for consumers looking for stability instead of tons of features. However a bit more modern taste doesn't hurt, as long as it doesn't break things (too much). Thoughts? Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JCS] Rework logging
Thanks Romain! On Thu, Aug 21, 2014 at 10:18 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: I did ;) https://issues.apache.org/jira/browse/LOG4J2-658 https://issues.apache.org/jira/browse/LOG4J2-788 didn't create one for PropertyConfigurator since it is surely something to get rid of in near future (i reused tomee log4j1 integration but we need to do a log4j2 integration) Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-08-21 22:04 GMT+02:00 Gary Gregory garydgreg...@gmail.com: On Thu, Aug 21, 2014 at 3:37 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: 2014-08-21 21:15 GMT+02:00 Christian Grobmeier grobme...@gmail.com: On 20 Aug 2014, at 15:47, sebb wrote: On 20 August 2014 14:37, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 20, 2014 at 9:28 AM, sebb seb...@gmail.com wrote: On 20 August 2014 14:04, Gary Gregory garydgreg...@gmail.com wrote: Moving discussion about logging from [JCS-122] to this dev ML. Why not use Log4j 2, uses can redirect logging to other frameworks if needed. Why not use Commons Logging, can redirect logging to other frameworks if needed? I'd like to think that Commons Logging has been deprecated by Log4j 2 can That is not an opinion that is universally shared. yes, I can name a few people from this list who actually know commons-logging exists. do the same thing (in principle) AND provide it's own advanced logging framework. s/it's/its/ ... That may be so, but I don't think that is sufficient reason to choose Log4j2 over any other library. its an advanced logging framework, build by ASF people, with modern API, insane speed and maintained by around 7 competent ASF committers? Its/It's/It is compatible with slf4j, log4j1, and even jcl, so please explain to me what are the reasons to NOT choose Log4j 2.0 but anything else? Not adding a dependency for one line answer. For longer one: take tomee example: we have [logging], slf4j cause of dependencies but as soon as we'll be able we'll drop them *by default*. We use JUL by default since tomcat integration is not that bad and cause it is built in in the JDK. If you add logging dependencies in the container then you need fine integration to let the application override it/use custom configuration. That's why less dependency we take better it is. I never said log4j2 was bad - actually once 2-3 bugs are fixed Please create JIRAs! ;-) https://issues.apache.org/jira/browse/LOG4J2 Gary I think it is really good - but that's really a matter of integration and environment. JCS will not only be used as app lib but also as container component which changes a little bit the constraints. Regards, Christian Gary Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de The Zen Programmer: http://bit.ly/12lC6DL @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [JCS] Rework logging
On 20 Aug 2014, at 19:35, Thomas Vandahl wrote: On 20.08.14 15:37, Gary Gregory wrote: On Wed, Aug 20, 2014 at 9:28 AM, sebb seb...@gmail.com wrote: On 20 August 2014 14:04, Gary Gregory garydgreg...@gmail.com wrote: Moving discussion about logging from [JCS-122] to this dev ML. Why not use Log4j 2, uses can redirect logging to other frameworks if needed. Why not use Commons Logging, can redirect logging to other frameworks if needed? I'd like to think that Commons Logging has been deprecated by Log4j 2 can do the same thing (in principle) AND provide it's own advanced logging framework. Gary, you are PMC chair of which PMC again? Commons-logging 1.2 has been released just in July. With all due respect, this didn't take the label deprecated from commons-logging. Maybe a few exceptions (as Tomcat as I heard) use commons-logging, but this doesn't make a difference. commons-logging lacks of a modern api and with all talks I gave on the logging subject nobody was interested in it. commons-logging is just bug fix release, and any new feature would be a surprise: http://commons.apache.org/proper/commons-logging/changes-report.html For me there are no clear reasons why anybody should use commons-logging and I was pretty much surprised that somebody was willing to cut a bugfix release. Sorry, but this lib is doomed. Cheers, Christian Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de The Zen Programmer: http://bit.ly/12lC6DL @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JCS] Rework logging
On 20 Aug 2014, at 15:47, sebb wrote: On 20 August 2014 14:37, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Aug 20, 2014 at 9:28 AM, sebb seb...@gmail.com wrote: On 20 August 2014 14:04, Gary Gregory garydgreg...@gmail.com wrote: Moving discussion about logging from [JCS-122] to this dev ML. Why not use Log4j 2, uses can redirect logging to other frameworks if needed. Why not use Commons Logging, can redirect logging to other frameworks if needed? I'd like to think that Commons Logging has been deprecated by Log4j 2 can That is not an opinion that is universally shared. yes, I can name a few people from this list who actually know commons-logging exists. do the same thing (in principle) AND provide it's own advanced logging framework. s/it's/its/ ... That may be so, but I don't think that is sufficient reason to choose Log4j2 over any other library. its an advanced logging framework, build by ASF people, with modern API, insane speed and maintained by around 7 competent ASF committers? Its/It's/It is compatible with slf4j, log4j1, and even jcl, so please explain to me what are the reasons to NOT choose Log4j 2.0 but anything else? Regards, Christian Gary Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de The Zen Programmer: http://bit.ly/12lC6DL @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JCS] Rework logging
Romain, On Thu, Aug 21, 2014 at 9:37 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: 2014-08-21 21:15 GMT+02:00 Christian Grobmeier grobme...@gmail.com: Not adding a dependency for one line answer. For longer one: take tomee example: we have [logging], slf4j cause of dependencies but as soon as we'll be able we'll drop them *by default*. We use JUL by default since tomcat integration is not that bad and cause it is built in in the JDK. If you add logging dependencies in the container then you need fine integration to let the application override it/use custom configuration. That's why less dependency we take better it is. I never said log4j2 was bad - actually once 2-3 bugs are fixed I think it is really good - but that's really a matter of integration and environment. actually your arguments were all technical based while i often read we don't need it as counter arguments for many proposed changes in commons. JCS will not only be used as app lib but also as container component which changes a little bit the constraints. I don't like JUL, but your argumentation is good. I also like zero deps libraries. That said, commons-logging is the wrong choice in any case. Cheers, Christian Regards, Christian Gary Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de The Zen Programmer: http://bit.ly/12lC6DL @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Laboratory Toolkit] proposing a new Apache Commons component
On 5 Dec 2013, at 13:44, Valentin Waeselynck wrote: Should I keep answering to the whole ML about this, or only to you? Keep the mailing list in loop. There might be others interested in this. In addition ml do document history which is why we always use the ml. Best regards, Valentin WAESELYNCK Étudiant en 3° année à l'École Polytechnique valentin.waesely...@polytechnique.edu +33 6 80 84 99 54 Le Jeudi 5 décembre 2013 8h53, Benedikt Ritter brit...@apache.org a écrit : Bonjour Valentin, welcome to the ML. Good to hear that you've decided to join the open source movement. First of all, it would really help, if you could elaborate some use cases for your library. You're talking about building algorithms. What kind of algorithms can be build with Laboratory Toolkit? Can you give some code examples (just create some gists at github that show the the use of Laboratory Toolkit)? There is an important requirement for any code to be incorporated into the Apache code base: - the interlectual property (IP) of the code has to be owned completely by the contributor. You said, that you've build the Laboratory Toolkit for a research project. Are you sure that you own the code? Or is it the result of your work and thus is owned by your employer? At commons we have some additinal requirements: - There should be a group of people who is willing to maintain the code - Commons components should in general not depend on any other libraries - Commons uses maven as the main build tool, so there should be a maven build available - The code should have a good test coverage You have to figure the IP issue out on your own first. After that, if the community decides to accept this contribution, we can work on the commons requirements. Best regards and thank you, Benedikt 2013/12/4 Valentin Waeselynck valentinwaesely...@yahoo.fr Hello to all, As part of a small research project (which combined techniques of text-mining, machine-learning and natural language generation, not that it's really relevant) I have come to design a small JavaSE library, which I'm for the moment calling the Laboratory Toolkit, for developing our algorithms in a comfortable and flexible manner. I have found it to be quite generic and reusable, not tied to any application domain, while still being rather accessible, and small enough to comprehend it easily. Therefore, I would like to propose it as a new Apache Commons component. I would be very grateful if one of you could tell me what steps I should follow for that purpose. I have uploaded it on Github : https://github.com/alvalval/Laboratory-Toolkit.git. There you may find the sources, the javadoc, and a small guide I have started to write for it (also attached to this mail). Of course, I am very open to feedback and criticism on your behalf. The last thing I want is to publish an immature or useless component; nor do I take a positive answer from you for granted. If I have failed to follow the proper procedure to propose a new candidate component, it is not on purpose, and I apologize in advance. Whatever your reply, and since I have the chance, I would also like to congratulate you for all your work. The Apache Commons components have really been lifesavers to me, on many occasions. With best wishes, Valentin WAESELYNCK Étudiant en 3° année à l'École Polytechnique valentin.waesely...@polytechnique.edu +33 6 80 84 99 54 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Commons Logging Marketshare (and other commons components)
Hi folks, i found this interesting: http://www.takipiblog.com/2013/11/26/githubs-1-most-popular-java-projects-here-are-the-top-libraries-they-use/ Cheers Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Removing websites of dormant components
No objections or no interest? A few more comments would have been helpful. I am going to remove all dormant javadocs on friday or saturday. Not sure on the branding though. It is the responsibility of the PMC to take care of trademarks. Comments are welcome. On 29 Nov 2013, at 20:37, Christian Grobmeier wrote: On 29 Nov 2013, at 19:21, sebb wrote: I agree that the Javadoc pages could be removed. Although it would not be difficult to fix the individual pages, there's not much point in fixing Javadoc for dormant components. However I'm not sure it makes sense to delete the entire website because of the branding issues. What are the particular branding issues that you think need fixing? Footer is not correct, should be like: Apache Foo, Foo, Apache, the Apache feather logo, and the Apache Foo project logo are either registered trademarks or trademarks of The Apache Software Foundation in the United States and other countries. First mention of a trademark should be with Apache, like Apache xmlio (not only xmlio). There are surely more things. I am not sure if it really helps to remove the website alone. People could refer to their own build when it comes to legal problems and indicate their only source is doing $x. Not really an expert on these things. However I would like to have us compliant to the branding recommendation. Cheers Cheers, Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Removing websites of dormant components
Waste time for javadocs of dormant components? Well, ok... What about the branding issue? On 4 Dec 2013, at 14:55, Gary Gregory wrote: I like Emmanuel's suggestion, a nice first step before we nuke anything. Gary Original message From: Emmanuel Bourg ebo...@apache.org Date:12/04/2013 03:42 (GMT-05:00) To: Commons Developers List dev@commons.apache.org Subject: Re: [all] Removing websites of dormant components Le 04/12/2013 09:35, Christian Grobmeier a écrit : No objections or no interest? A few more comments would have been helpful. I am going to remove all dormant javadocs on friday or saturday. Not sure on the branding though. It is the responsibility of the PMC to take care of trademarks. Comments are welcome. What about running the Javadoc fix tool instead? http://www.oracle.com/technetwork/java/javase/downloads/java-doc-updater-tool-1955731.html Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] Moving to Git?
On 26 Nov 2013, at 14:35, Gary Gregory wrote: On Tue, Nov 26, 2013 at 3:52 AM, Emmanuel Bourg ebo...@apache.org wrote: Le 26/11/2013 08:43, Benedikt Ritter a écrit : I propose [1] as branching model. It looks very complicated at first, but I've found it very useful to always have a release ready version of the code in master. [1] http://nvie.com/posts/a-successful-git-branching-model/ It looks complicated indeed. I prefer having the current developments on the master branch and create topic branches to experiment with more involved changes. I don't think we have enough active developers per component to require a more sophisticated model. I agree with Emmanuel. Let's keep it simple by not mixing a change in VCS and process at the same time. Let's do Git and see how that goes. I disagree. One of great benefits of Git is its branching power. You can work with Git as you did with SVN but this will ultimately lead to problems. If attracting new committers is one of your goals you need to adapt the common way to work with the tool. This in fact means: create a master branch which is stable. create a develop branch which is not so stable. create feature branches from develop where you work out your changes. merge back when done. This all is supported by good clients. In example SourceTreeApp: http://www.sourcetreeapp.com/ makes this all happen with just one click (its called git flow). In my opinion: if we don't adapt the common approach to use git, we should stick with svn. Only if use git as git should be used it makes sense to migrate. If we are not open to learn (or don't have fun doing that or time) then let's not do that. Cheers Christian Gary Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] Removing websites of dormant components
On 19.10. I wrote a mail in response to Henri Yandell. http://markmail.org/message/c63kqyipuy6islib I would like to follow up on the issues i mentioned there. Our dormant components are unmaintained and our dormant websites are broken. Therefore I would like to remove the websites. In example we are having this critical and wellknown security problem: http://www.kb.cert.org/vuls/id/225657 http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html At all these pages: http://commons.apache.org/dormant/cache/apidocs/index.html http://commons.apache.org/dormant/contract/apidocs/index.html http://commons.apache.org/dormant/convert/apidocs/index.html http://commons.apache.org/dormant/events/apidocs/index.html http://commons.apache.org/dormant/feedparser/apidocs/index.html http://commons.apache.org/dormant/jjar/apidocs/index.html http://commons.apache.org/dormant/latka/apidocs/index.html http://commons.apache.org/dormant/mapper/apidocs/index.html http://commons.apache.org/dormant/messenger/apidocs/index.html http://commons.apache.org/dormant/resources/apidocs/index.html http://commons.apache.org/dormant/scaffold/apidocs/index.html http://commons.apache.org/dormant/threadpool/apidocs/index.html http://commons.apache.org/dormant/workflow/apidocs/index.html http://commons.apache.org/dormant/xmlio/apidocs/index.html In addition none of the dormant components are respecting the trademark branding guidelines: http://www.apache.org/foundation/marks/pmcs.html If there is nobody who wants to fix these within a short timeframe I believe we should remove the websites from our server and forwarding it to maybe a wiki page which explains that docs of dormant components can only be retrieved by checking out the source code. Cheers, Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] Moving to Git?
On 29 Nov 2013, at 14:39, Torsten Curdt wrote: This in fact means: create a master branch which is stable. create a develop branch which is not so stable. create feature branches from develop where you work out your changes. We are just swapping the branch names here, in the end your model isn't very different from mine. Let's say the develop branch is named 'master', the stable branch is named '1.x' or 'stable' and we are basically dealing with the same workflow. It's not my model, its the model described here: http://nvie.com/posts/a-successful-git-branching-model/ This is a model many people follow. Having a development branch which is called master will confuse a lot of people. I highly doubt that. In fact master being unstable is kind of the default if you look around on github. We should respect the naming conventions of git as good as possible. There are *many* project that use git that have the master being unstable. Rails is just one example. Aha ok, good to know. Well you are more into that. I have learned it a different way but well, I stand corrected. Please lets not mix one bike shedding topic with the other - that's madness ;) I am not mad! - Nyarlathotep, the mad faceless god from Lovecrafts Cthulhu mythos ;-) Cheers Christian cheers, Torsten --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] Moving to Git?
On 29 Nov 2013, at 14:44, Emmanuel Bourg wrote: Le 29/11/2013 14:28, Christian Grobmeier a écrit : We should respect the naming conventions of git as good as possible. But git is a tool, not a development method, right? As such it doesn't mandate any specific workflow, even if a random blogger chose to name its own popular workflow The Git Flow. Lets say i have had good experiences with that model. I shared this information with you. Developing on the master branch with Git is like working on the trunk for SVN. That's what people are used to do here, and that's the less disruptive option. Do as you please. I am not working on CLI anyway. Cheers Christian Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Removing websites of dormant components
On 29 Nov 2013, at 19:21, sebb wrote: I agree that the Javadoc pages could be removed. Although it would not be difficult to fix the individual pages, there's not much point in fixing Javadoc for dormant components. However I'm not sure it makes sense to delete the entire website because of the branding issues. What are the particular branding issues that you think need fixing? Footer is not correct, should be like: Apache Foo, Foo, Apache, the Apache feather logo, and the Apache Foo project logo are either registered trademarks or trademarks of The Apache Software Foundation in the United States and other countries. First mention of a trademark should be with Apache, like Apache xmlio (not only xmlio). There are surely more things. I am not sure if it really helps to remove the website alone. People could refer to their own build when it comes to legal problems and indicate their only source is doing $x. Not really an expert on these things. However I would like to have us compliant to the branding recommendation. Cheers Cheers, Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] Make use of logging?
On 14 Nov 2013, at 10:01, Emmanuel Bourg wrote: Le 10/11/2013 21:46, Christian Grobmeier a écrit : From all the log4j talks I gave recently there were zero people using commons-logging. For me it is dead. For what it's worth, the install base of commons-logging in Debian is ten times the one of slf4j, and there is no sign of it declining: Not sure how debian users install that package and why. Maybe its indirectly referenced by some widley used software package. I don't know. That statistics doesn't count much to me. Of course my experiences cannot be generalized too. They are subjective. But if you ask your audience who is using what and nobody uses commons-logging it makes you think. This has happened at multiple talks reaching a total of around 1500 persons. We'll soon have an opportunity to improve commons-logging while preserving backward compatibility thanks to the default methods in Java 8. Preserving backwards compatibility? Till when? 2020? Too much backwards compatibility broke Commons. While other projects are not doing enough for bc, we are doing too much. Java 8 is in future. In the meantime other logging frameworks will go on. I have seen people are annoyed of the back and forth of logging. Commons Logging ads just some spice to the problems of logging, but not a real solution. I have had some hard fights with promoting Log4j2. I am not going to put any effort to fix commons-logging as I don't see the value. Instead, I am going to spent my time to Log4j 2 and I am really surprised to hear that some Commons folks prefer to make commons-logging looking modern instead of contributing to Log4j2 which also provides a modern API. Anyway, its up to you folks. Have fun! Cheers Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] Make use of logging?
On 10 Nov 2013, at 18:47, Lukasz Lenart wrote: Ok, so let's leave logging layer for now and we should focus on preparing the first release +1, thanks Lukasz! 2013/11/9 Gary Gregory garydgreg...@gmail.com: Neither does log4j 2 ;) Original message From: henrib hen...@apache.org Date:11/09/2013 12:23 (GMT-05:00) To: dev@commons.apache.org Subject: RE: [OGNL] Make use of logging? IMHO, commons logging is the best choice for this kinds of lib; it does not force the choice of the implementation library. Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/OGNL-Make-use-of-logging-tp4653577p4656625.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] Make use of logging?
On 10 Nov 2013, at 21:24, henrib wrote: Would you share why ? I'm sure it would be beneficial to others (including the commons logging community). Sorry I was short in my reply because I mentioned this a few times already. Didn't find the mails, so here we go: As you probably know, I have an interest in logging in general. Commons Logging doesn't support modern logging features. If you compare it to the Log4j2 API or to slf4j its just outdated. That said, people are already having a lot of problems with their logging dependencies. It's definitely not nice to have commons-logging in path, just because OGNL uses it. From all the log4j talks I gave recently there were zero people using commons-logging. For me it is dead. And I certainly don't recommend anybody to use it. Ok, lets say you have an interest in fixing Commons-Logging and implement modern API features. Why wouldn't you spend the time in Log4j2s API? It serves the same purpose, just with a better API. It's already there. Log4j2 users can use different logging implementations under the hood, if they like. Now why should there be another logging facade which needs a *lot* of work? Before the small maintenance release this year there was a 5 yrs break. Logging went on. Commons Logging did not. It's too late. Even if Commons would put a lot of effort I doubt anybody would accept it. Now we probably need some logging at OGNL. Do I want that outdated, irregulary maintained Commons Logging which seems to be used only at Tomcat? No absolutely not. Instead I am thinking commons logging implementation should stop. We will not win the fight against slf4j anymore. The only way out is unbelievable big marketing effort for the log4j2 api OR a new logging jsr. E-mail went longer than thought, sorry. Hope you understand a bit better why I can't support commons-logging going into OGNL. If any more questions please shout. Cheers Christian -- View this message in context: http://apache-commons.680414.n4.nabble.com/OGNL-Make-use-of-logging-tp4653577p4656667.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] Make use of logging?
On 5 Nov 2013, at 14:29, Lukasz Lenart wrote: So what's the idea here? Should we apply additional logging layer (as Jason proposed)? Or throw it away and start thinking about new release? I have reviewed TODOs and I haven't spotted any urgent task for now. Currently I am sympathizing with just doing a new release. As mentioned there are commented sysouts, but I believe we can deal with that later. It easier to enable logging instead of removing it. Cheers Christian Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2013/9/4 Jason Pyeron jpye...@pdinc.us: -Original Message- From: Benedikt Ritter [mailto:brit...@apache.org] Sent: Wednesday, September 04, 2013 4:28 To: Commons Developers List Subject: Re: [OGNL] Make use of logging? 2013/9/4 Lukasz Lenart lukaszlen...@apache.org 2013/9/3 Christian Grobmeier grobme...@gmail.com: I found 11 uses of e.printStackTrace and think its pretty bad. Including OgnlException overwrites printStackTrace and writes to System.err for some reason. In addition there are a lot of System.out's, but those are all commented and seem to have served debugging purposes. I believe small libs like OGNL should not have logging at all, but it seems some of the logging here might make sense. I am tending to enable slf4j, which is already used in the testing scope. Once done we should use the logging methods for System.out and printStackTrace. Why not Log4j or commons-logging? And it's really annoying to have different logging libs in the same project just because dependency uses that particular one - I like Struts2 way where you can choose what logging library you want to use. I don't know if developing additional thin layer is a huge problem - we can copy paste from S2 ;-) I agree that small libs should not have logging at all. Are you really sure it is needed (sorry don't have the time to dig into the code myself right know)? As someone who has had to modify the code, yes logging should exist. I have a fork of it with util.logging here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CHALLENGE] Move All of Commons to the Dormant
On 18 Oct 2013, at 9:24, Jörg Schaible wrote: Hi Christian, Christian Grobmeier wrote: On 17 Oct 2013, at 18:12, Paul Benedict wrote: I am glad to hear being dormant is not the same thing as being in the attic Why? Because attic means more or less that we not even intend to work on this component anymore. E.g. we decided that we will not put any further effort into oro, because it has been outdated by the JDK. Being in the attic is NOT a permanent thing. Get active developers, leave the attic. If a project doesn't make any sense, stay in the attic. We are having an attic but called it dormant. Unmaintained projects are a potential risk for our users. With having a dormant state we replicate the attic. I don't see a difference between a dormant component and one in the attic - except that the term attic is more established (as in foundation wide) as the term dormant. It simply means that no one is currently actively working on it, but it tells you nothing about its maturity or feature completeness. However, if we get a security report on one of this components, I am quite sure that we will react with a new release in time. Given that normal releases will take a long time at Commons I doubt. There is a security issue for this dormant components JavaDoc: http://commons.apache.org/dormant/clazz/apidocs/index.html Nobody reacted (includes me). And any (Apache) committer with interest can revive development quite immediately. It might be more difficult for users, but if one has interest and starts to bring reasonable patches, we were always quite lenient with committer status. I doubt, that we would see here any development for collections 4.x, if we had moved it into attic. Especially because the term attic and its meaning is more established. Attic components can be revived similar quickly. Nobody said we need to delete any reference from our webpages and prevent any collaboration with others. Cheers Christian That said, I will not fight for removing the dormant-term. If you all like it keep it. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CHALLENGE] Move All of Commons to the Dormant
On 19 Oct 2013, at 17:22, Henri Yandell wrote: On Sat, Oct 19, 2013 at 7:25 AM, Christian Grobmeier grobme...@gmail.comwrote: Being in the attic is NOT a permanent thing. Get active developers, leave the attic. If a project doesn't make any sense, stay in the attic. We are having an attic but called it dormant. The difference is that we have a a piece of code that no one is working on now and call it dormant. We are still here. The attic is when there is no one at Apache being responsible for the code. One of our development patterns is to swarm on different components which means that other, still looked after codebases, receive less attention while we're swarming on another component. Dormant fits nicely here. OK. Let's assume we are just not working on this component for the moment. It simply means that no one is currently actively working on it, but it tells you nothing about its maturity or feature completeness. However, if we get a security report on one of this components, I am quite sure that we will react with a new release in time. Given that normal releases will take a long time at Commons I doubt. There is a security issue for this dormant components JavaDoc: http://commons.apache.org/**dormant/clazz/apidocs/index.**htmlhttp://commons.apache.org/dormant/clazz/apidocs/index.html Nobody reacted (includes me). Sounds like Attic. All of the dormant components are ready for the attic? http://commons.apache.org/dormant/cache/apidocs/index.html http://commons.apache.org/dormant/contract/apidocs/index.html http://commons.apache.org/dormant/convert/apidocs/index.html http://commons.apache.org/dormant/events/apidocs/index.html http://commons.apache.org/dormant/feedparser/apidocs/index.html http://commons.apache.org/dormant/jjar/apidocs/index.html http://commons.apache.org/dormant/latka/apidocs/index.html http://commons.apache.org/dormant/mapper/apidocs/index.html http://commons.apache.org/dormant/messenger/apidocs/index.html http://commons.apache.org/dormant/resources/apidocs/index.html http://commons.apache.org/dormant/scaffold/apidocs/index.html http://commons.apache.org/dormant/threadpool/apidocs/index.html http://commons.apache.org/dormant/workflow/apidocs/index.html http://commons.apache.org/dormant/xmlio/apidocs/index.html The javadoc issue aside I think not a single dormant component fulfills the branding requirements: http://www.apache.org/foundation/marks/pmcs#attributions I have only briefly looked on them, but at least the footer seems to be incorrect in all these cases. These are two serious issues which sound to me that we are not having a good oversight (or interest) of our dormant components. Attic components are marked as read only. We don't take new user reports, they don't have a mailing list, their website has a big banner saying 'attic'. So moving out of the Attic involves the infrastructure changes to make something writeable again. There's also a difference in that dormant components accumulate new issues to work on. Attic: The conversation at Apache has been turned off until such a time as demand returns and we have to find a new place for conversation. Dormant: Things are just quiet, and ready to return as demand returns. The challenge is to not be sloppy and pretend that every component is 'just quiet' and is ready to return when the need is great (the King Arthur pattern :) ). OK :-) Then maybe we are missing the process to finally decide when a component is ready for the attic. Cheers Christian Hen --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CHALLENGE] Move All of Commons to the Dormant
On 17 Oct 2013, at 2:39, Henri Yandell wrote: On Wed, Oct 16, 2013 at 4:59 PM, sebb seb...@gmail.com wrote: On 16 October 2013 12:25, Christian Grobmeier grobme...@gmail.com wrote: If nobody is willing to put a component to dormant state, then the label doesn't make any sense. I would vote to remove the dormant state in general. If we don't have any need of a specific component we can put it to attic.apache.org too. No need to duplicate things. AFAIK, the Attic is for entire TLPs only, not individual components. There are XML subcomponents there. Jakarta ones went dormant iirc, but then moved over as subcomponents and not the overall umbrella. So I don't think there's a reason why a Commons component wouldn't fit. +1 The attic is not only for TLPs. I don't find the mail reference right now. But I was asked to put log4cxx to the attic (sub component of Apache Logging). --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CHALLENGE] Move All of Commons to the Dormant
If nobody is willing to put a component to dormant state, then the label doesn't make any sense. I would vote to remove the dormant state in general. If we don't have any need of a specific component we can put it to attic.apache.org too. No need to duplicate things. If we don't have a dormant, I would like to see the content of CHALLENGE.txt somewhere on the website: people who have dedicated themselves to work active on the component. If no-one signed up, it is unlikely to get issues fixed quickly. In addition I like the last release column. Here is a widget: http://svnsearch.org/svnsearch/repos/ASF/search?view=widgetspath=%2Fcommons%2Fproper It does also work on components level: http://svnsearch.org/svnsearch/repos/ASF/search?view=widgetspath=%2Fcommons%2Fproper%2Flogging Cheers On 15 Oct 2013, at 17:50, Gary Gregory wrote: On Tue, Oct 15, 2013 at 11:30 AM, Ralph Goers ralph.go...@dslextreme.com wrote: Personally, I like the idea of having a last release date AND a list of people who are active in the project. The only problem is that people who go inactive rarely remove themselves from the list. The only to solve that is with automation, like a list of the people who committed over the last month for example. There must be an SVN widget we can add to the site to see some useful stats. Gary Ralph On Oct 15, 2013, at 7:48 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Gary, Gary Gregory wrote: On Tue, Oct 15, 2013 at 2:15 AM, Phil Steitz phil.ste...@gmail.com wrote: On 10/14/13 10:59 PM, Paul Libbrecht wrote: Le 15 oct. 2013 à 07:33, Dave Brosius dbros...@apache.org a écrit : I couldn't disagree more. Dormant/attic means the project has leprosy. I don't know the answer to this, but wondering, has there ever been a commit to an attic'ed project? I personally would never think of doing that. As probably the only person that supports' Jelly, a dormant to be for sure, I find the word leprosy outrageous. I am happy to stay on list, I even read posts regularly, but I cannot find time or motivation to fix bugs or do new releases. I respond to any Jelly question I find. Jelly has gone 1.0 and is in use here and there. I would expect users to be interested to make it advance to come to jira and suggest fixes; I am happy to negotiate them and apply them, and maybe, if things get excited, there might be a release one day. However, moving it to a place where you would never commit would sign its death. The proposal is not to move it anywhere, just designate it as dormant so people know no one is currently working on it. We could avoid labeling a project with any words by simply listing the last release date. Each project in turn could have a section in its overview with a history of releases. This would help users make up their mind. Based on a release date only, vfs is dormant. Therefore I like Hen's approach, since every committer (or even interested user) has now the possibility to make his interest/commitment explicit. Actually we could repeat the this challenge on a yearly base (again with an empty file). A dormant label can get away in an instance if enough people show interest. It would be even better without a dormant section in svn (with Git it is gone anyway). Currently it takes more effort to awake a component. Just because a component is dormant does not mean that its maturity has gone. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB
Re: [VOTE] Release Compress 1.6 based on RC2
Hi, [X] +1 Release these artifacts On 16 Oct 2013, at 15:20, Gary Gregory wrote: Thank you Stefan for the new RC. +1 Maybe I have interpreted the Clirr report wrong. But besides the two buffer fields it doesn't look so bad (just additions). I believe these two fields are acceptable although I understand people might want to discuss the version number again. I will wait what Garys findings are. These are not blockers but I was expecting all of the _new_ 7z code to be warning-free (with my IDE settings that is) in the sense that there should be no missing Javadoc (there are missing @throws tags for example) and no FindBugs issues (there is one, easy to fix), same for PMD, CPD. … IMO, all empty blocks should be commented. Actually I don't see this as urgent enough to block a release. Creating a RC is always time consuming. And I don't consider javadoc as important enough to be completed. Btw, I like this post very much: http://vafer.org/blog/20050323095453/ I agree code *should* be warning free. While this RC is surely not perfect, its not that bad the we need to re-roll the release (I checked the findbugs, pmd, cpd reports) Cheers Christian Gary On Tue, Oct 15, 2013 at 2:26 PM, Stefan Bodewig bode...@apache.org wrote: Hi all, I've addressed most of the issues brought up during the RC1 vote. I'll have limited net time the next three days, but hopefully I won't be needed. Stefan Compress 1.6 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 3272) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-178/org/apache/commons/commons-compress/1.6/ Details of changes since 1.4 are in the release notes: http://people.apache.org/~bodewig/cc-1.6/RELEASE-NOTES.txt http://people.apache.org/~bodewig/cc-1.6/site/changes-report.html The tag is here: http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC2/ (svn revision 1532449) Site: http://people.apache.org/~bodewig/cc-1.6/site/ Clirr Report (compared to 1.5): http://people.apache.org/~bodewig/cc-1.6/site/clirr-report.html RAT Report: http://people.apache.org/~bodewig/cc-1.6/site/rat-report.html KEYS: http://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now, i.e. after 1830 GMT 18-October 2013 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB
Re: [VOTE] Release Compress 1.6 based on RC2
On 16 Oct 2013, at 16:28, Gary Gregory wrote: On Wed, Oct 16, 2013 at 10:05 AM, Christian Grobmeier grobme...@gmail.comwrote: Maybe I have interpreted the Clirr report wrong. But besides the two buffer fields it doesn't look so bad (just additions). I believe these two fields are acceptable although I understand people might want to discuss the version number again. I will wait what Garys findings are. In this case, I was only talking about the removal of the protected fields. Method additions so common as to warrant this note on our site: https://commons.apache.org/releases/versioning.html#note1 I'll have to blog about Extreme Versioning at some point, off topic here. interested to read that These are not blockers but I was expecting all of the _new_ 7z code to be warning-free (with my IDE settings that is) in the sense that there should be no missing Javadoc (there are missing @throws tags for example) and no FindBugs issues (there is one, easy to fix), same for PMD, CPD. IMO, all empty blocks should be commented. Actually I don't see this as urgent enough to block a release. Neither do I which is why I started with These are not blockers but... ;) OK :-) Cheers Gary Creating a RC is always time consuming. And I don't consider javadoc as important enough to be completed. Btw, I like this post very much: http://vafer.org/blog/**20050323095453/http://vafer.org/blog/20050323095453/ I agree code *should* be warning free. While this RC is surely not perfect, its not that bad the we need to re-roll the release (I checked the findbugs, pmd, cpd reports) Cheers Christian Gary On Tue, Oct 15, 2013 at 2:26 PM, Stefan Bodewig bode...@apache.org wrote: Hi all, I've addressed most of the issues brought up during the RC1 vote. I'll have limited net time the next three days, but hopefully I won't be needed. Stefan Compress 1.6 RC2 is available for review here: https://dist.apache.org/repos/**dist/dev/commons/compress/https://dist.apache.org/repos/dist/dev/commons/compress/ (svn revision 3272) Maven artifacts are here: https://repository.apache.org/**content/repositories/** orgapachecommons-178/org/**apache/commons/commons-**compress/1.6/https://repository.apache.org/content/repositories/orgapachecommons-178/org/apache/commons/commons-compress/1.6/ Details of changes since 1.4 are in the release notes: http://people.apache.org/~**bodewig/cc-1.6/RELEASE-NOTES.**txthttp://people.apache.org/~bodewig/cc-1.6/RELEASE-NOTES.txt http://people.apache.org/~**bodewig/cc-1.6/site/changes-**report.htmlhttp://people.apache.org/~bodewig/cc-1.6/site/changes-report.html The tag is here: http://svn.apache.org/repos/**asf/commons/proper/compress/** tags/COMPRESS-1.6-RC2/http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC2/ (svn revision 1532449) Site: http://people.apache.org/~**bodewig/cc-1.6/site/http://people.apache.org/~bodewig/cc-1.6/site/ Clirr Report (compared to 1.5): http://people.apache.org/~**bodewig/cc-1.6/site/clirr-**report.htmlhttp://people.apache.org/~bodewig/cc-1.6/site/clirr-report.html RAT Report: http://people.apache.org/~**bodewig/cc-1.6/site/rat-**report.htmlhttp://people.apache.org/~bodewig/cc-1.6/site/rat-report.html KEYS: http://www.apache.org/dist/**commons/KEYShttp://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now, i.e. after 1830 GMT 18-October 2013 [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... --**--** - To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.**comhttp://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
Re: [VOTE] Move Apache Commons to Git for SCM...
On 14 Oct 2013, at 9:13, Mark Thomas wrote: On 13/10/2013 23:59, sebb wrote: On 13 October 2013 20:47, Phil Steitz phil.ste...@gmail.com wrote: On 10/13/13 8:09 AM, James Carman wrote: Well, it has been 72 hours, so let's tally up the votes. As I see it (counting votes on both lists): +1s James Carman Romain Manni-Bucau Matt Benson Benedikt Ritter Bruno Kinoshita Gary Gregory Luc Maisonobe Oliver Heger Christian Grobmeier Torsten Curdt -1s Mark Thomas Thomas Vandahl Damjan Jovanovic Gilles Sadowski Jorg Schaible +0.5 Olivier Lamy +0 Ralph Goers -0 Emmanuel Bourg The vote passes, so Apache Commons will be moving to Git for SCM. We should begin working on a plan. I propose we set up a wiki page for that. I protest. It is fine for some components to experiment, but if we are going to force all to move, we really need consensus and that is clearly not the case here. I did not vote as I frankly saw the VOTE as premature. We should use VOTEs as a last resort, not a first step or way to avoid getting to consensus on non-release issues. I agree entirely with Phil. I would have voted -1 earlier, but was off-line for a few days. This is a huge change, and should not be bulldozed through. I too challenge the assertion that there is consensus for this change. I also agree with Sebb's characterisation of this being bulldozed through. I disagree. We have discussed it, we had a vote. We have not voted to push a red button on friday and to work with git alone on saturday. This was a vote for a general decision and it is clear (or should be) that changes like that are not made in a single day. Now what are you folks expecting? A full-fleshed out plan how to move? I think we should first decide IF we move and that was was happening here. It was also pretty clear to start with a small step first and move a single component. If that would went wrong we could either go back without bigger loss or discuss what needs to be improved. We are not using experimental bleeding edge technology here. We just wanted to decide if we will follow the git path or not. I really can't see anything bulldozed here. I have no objection to a switch to git for those components where there is consensus to do so amongst the active developers. I continue to strongly recommend that a single component volunteers to be the svn-git guinea pig for Commons and that we allow that component to work out any issues that crop up before any mass switch starts. If there are no issues, great. If there are issues, better to have to deal with one set of them rather than 40+ sets. I have not understood it otherwise. Why did you start to believe we move all components at once? Further, if the consensus amongst the active developers on a component is that they wish to stick to svn, I see no why that component should be forced to switch to git. I had the idea too and support it. Cheers Christian Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Move Apache Commons to Git for SCM...
On 16 Oct 2013, at 22:46, Phil Steitz wrote: On 10/16/13 1:34 PM, Christian Grobmeier wrote: On 14 Oct 2013, at 9:13, Mark Thomas wrote: Further, if the consensus amongst the active developers on a component is that they wish to stick to svn, I see no why that component should be forced to switch to git. I had the idea too and support it. Great. Then the three of us at least all agree. What I was protesting was the conclusion that we had consensus to move all components. Not sure if i was perfectly clear: I voted to move all components sooner or later to git. Not all at once. But to start with one, try things out, learn and finally moving on with the others one by one. BUT if some maintainers of a component really have a problem with git, I am of course accepting they are using svn while others can use git. My impression is that most people who are working as team on a single component have a similar vision on the scm. Usually I would now open a vote to see if we all agree. Phil Cheers Christian Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Apache Commons IRC Channel...
On 14 Oct 2013, at 15:34, Emmanuel Bourg wrote: Thanks to the infra team we now have JIRA and svn commit notifications on the channel. Enjoy :) boah thats cool! Thanks for organizing that! (assuming oyu did!) Emmanuel Bourg Le 10/10/2013 18:15, James Carman a écrit : As a reminder, we do have an IRC channel set up on freenode. It's #asfcommons. Matt Benson and I are usually the only ones hanging out there right now, but some of these discussions would go much faster if we could discuss in real-time. Of course, no decisions are made only on IRC. If anything is discussed that we want to implement, we should take it to the group on the mailing list first for discussion. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB
Re: [VOTE] Moving to Git...
On 10 Oct 2013, at 18:43, Jörg Schaible wrote: Hi James, James Carman wrote: Sorry, didn't understand your question. The Apache Camel team uses Git and they release maintenance versions all the time (I believe about 3 or 4 at a time sometimes when a bug fix gets merged down). Here's a list of the current projects using Git: https://git-wip-us.apache.org/repos/asf https://git-wip-us.apache.org/repos/asf?p=camel.git;a=heads OK, this is an evidence that they are able to release from branch and they use the Maven release plugin. If they can manage, so can we. I use mvn to release from git (branches) in my daily work. In addition I did the same for https://github.com/grobmeier/jjson which is pretty similar to the usual Commons components. I also used Nexus for the latest release, no problems. Cheers - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Moving to Git...
+1 I consider this move to happen step by step and see only little risk if we start with a single component first. As the half of the world works with git meanwhile I see less risk in general too. On 10 Oct 2013, at 16:41, James Carman wrote: All, We have had some great discussions about moving our SCM to Git. I think it's time to put it to a vote. So, here we go: +1 - yes, move to Git -1 - no, do not move to Git The vote will be left open for 72 hours. Go! James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Moving to Git...
On 11 Oct 2013, at 15:28, Ted Dunning wrote: I hate myself a bit for jumping in here, but as much as I prefer git, I really don't think that changing will make that much difference. Well, obviously I think it matters (see my other threads). The problem with commons is that people have much more energy for interminable conversations about things that don't much matter (like this thread). But this is a [VOTE] thread and not meant for discussion ;-) People who do things don't generally want to talk them to death. If half the energy that goes into long debates went into coding for commons there wouldn't be a problem. Long discussions about whether discussions about things that might make coding easier are even worse than a long discussions so I am now part of the problem. Perhaps a good rule of thumb would be no more than 5 email messages about non-code issues per patch that you have posted to a commons component. I am probably at or beyond that limit so I will shut up and not respond further. I don't see the Commons discussions as toxic in a way and can't agree to a mail / patch ratio. Given that the open source community has gradually been re-inventing aspects of scientific society (salons = meetups, RS = ASF and so on) maybe it is time to invent something like peer review to moderate the long conversations. Maybe you should just say -1 or whatever else you think and we tally the votes afterwards. Cheers Christian On Fri, Oct 11, 2013 at 6:01 AM, Christian Grobmeier grobme...@gmail.comwrote: +1 I consider this move to happen step by step and see only little risk if we start with a single component first. As the half of the world works with git meanwhile I see less risk in general too. On 10 Oct 2013, at 16:41, James Carman wrote: All, We have had some great discussions about moving our SCM to Git. I think it's time to put it to a vote. So, here we go: +1 - yes, move to Git -1 - no, do not move to Git The vote will be left open for 72 hours. Go! James --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Move Apache Commons to Git for SCM...
+1 let's move on step by step. On 10 Oct 2013, at 16:50, James Carman wrote: All, We have had some great discussions about moving our SCM to Git. I think it's time to put it to a vote. So, here we go: +1 - yes, move to Git -1 - no, do not move to Git The vote will be left open for 72 hours. Go! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Putting several unmaintained components to dormant
Here is some commit activity: http://svnsearch.org/svnsearch/repos/ASF/search?view=plotfrom=20130101to=20131009path=%2Fcommons%2Fproperplotsort=%24plotsort But we should to exclude typo fixes and such. For example: http://svnsearch.org/svnsearch/repos/ASF/search?view=resultlistfrom=20130101to=20131009path=%2Fcommons%2Fproper%2Fcommons-gpg-pluginplotsort=%24plotsort 22 changes on commons gpg, but not really meaningful changes. I would not consider Commons GPG as maintained. Jira doesn't mean much to me. Users can submit issues, but this doesn't mean a component is maintained. Even when 20 issues were submitted for GPG, it would not consider it maintained. On 9 Oct 2013, at 22:06, Adrian Crum wrote: Can we include commit activity and Jira activity in the analysis? Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 1:04 PM, Benedikt Ritter wrote: I've looked at all the proper components and listed all components where I've seen activity since I'm subscribed to the ML. 2013/10/9 Adrian Crum adrian.c...@sandglass-software.com What criteria are you using to come up with this list? Adrian Crum Sandglass Software www.sandglass-software.com On 10/9/2013 12:17 PM, Benedikt Ritter wrote: Hi, I think Phil came up with the idea to try to focus on the components that we are able to maintain and put all other stuff to dormant. Here is the list of components that I think really are proper: - CLI - Codec - Collections - Compress - Configuration - CSV - Daemon - DBCP (?) - Email - Functor - Imaging (?) - IO - JCI - Lang - Logging - Math - Net - Pool (?) - Proxy - SCXML (after recent interest) - VFS - Weaver All other stuff can go dormant because there is currently nobody who maintains it. Still a pretty long list. Thoughts? Anything missing? Benedikt --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Moving to Git...
On 8 Oct 2013, at 6:53, Romain Manni-Bucau wrote: Hi Not sure svn is the issue. What makes quality and which rules are mandatory is more important IMO. If you want to attract a new generation it is important. Would you contribute to a CVS project? I would if you need it urgently for work. But in my prime time I simply don't have an interest to install an cvs client no matter how cool the software is. I think a projects infrastructure is first entry barrier for contributing. Personally I have learned about git and it took me a while. I am not a super-hero but I enjoy it. Btw, Guava uses Git too: https://code.google.com/p/guava-libraries/source/checkout Following oracle java version (with a single one late - java 6 when java 7 is the current one) is one key i think. Another one would be to remove project from main sources/proper when nobody needs work on it anymore. Separating each projects too...what a noise on commons cause of not following it + which link between csv and math - consistency? NB: no project is too small. Le 8 oct. 2013 04:15, James Ring s...@jdns.org a écrit : Whatever workflow we came up with, if we moved to Git I'd like to see Gerritt (https://code.google.com/p/gerrit/) used for code review. On Mon, Oct 7, 2013 at 7:10 PM, James Carman ja...@carmanconsulting.com wrote: All, If we did want to move to Git, we'd probably have to figure out how we'd manage our workflow (couldn't think of a better word). I suppose we'd have a separate repo for each component? What about proper vs. sandbox? How would we accommodate that paradigm? Has anyone else already gone through this thought process? I must admit, my git fu isn't what it should be. James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Moving to Git...
On 8 Oct 2013, at 11:42, Romain Manni-Bucau wrote: just an habit. svn diff attach diff to a jira is as easy/hard as git push + PR. Tools like GitHub succeed because not everybody agrees with you. svn/diff is stoneage to some. git/pr is the future for them. Maybe you are right about the habit thing, but it doesn't change the fact everybody seems to enjoy with git these days. SVN is on the same road as CVS. It's not that I don't like SVN. It has served me well and I still use it. I know teams which are doing better with SVN. But esp in open source using SVN looks like the code is maintained by dinosaurs who don't want to work with new things. Please note, I am not saying we should move on to Git right now. Moving to Git will be a lot of work and we'll have a lot of questions to answer. For example: how would we deal with pull requests? There are no partial checkouts in git. We would have most likely one repos per component. Would we need to create a super parent component including all proper components as submodule, like we have the svn view? And so on. If we have enough willing folks to push this forward, I am happy to see it happen (unfort i am tight of time at the moment) Cheers If you want to push back your changes you'll do whatever the techno is. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/8 Xavier Detant xavier.det...@gmail.com 2013/10/8 Emmanuel Bourg ebo...@apache.org I don't think using SVN is a barrier to private modifications like this. People just fork the mirror on Github, or import the code with git-svn. I didn't said it was. Of course you'll do your private change, but you won't share it easily (not as easily as with git IMO). -- Xavier DETANT --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
On 8 Oct 2013, at 20:07, Benedikt Ritter wrote: Hey Gary, you are involved in other projects (like log4j2) how do they do it? Is it easier to release log4j2 than it is to release for example [lang]? Check this guide: http://wiki.apache.org/logging/Log4j2ReleaseGuide In fact we have an ASF maven pom: http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml This is extended by tons of plugins and other things and called commons parent pom. The commons parent pom does a lot of things, and all components are more or less required to run the same way. The question is, why should a component not be independent from commons-parent-pom and decide on it's on? With having the ASF-parent only releasing could be: mvn release:prepare release:perform Then everything should be on Nexus. I know this is a controverse question. But as people can download the artifacts directly from nexus if they wish - including source, LICENSE, NOTICE and all that… why are we bothering to put on any other place? One could see at as: we release source code, as we create a tag. For convenience we put it on Nexus. Nothing else. For site: I think components should be free to chose on their own. I was thinking different in the past. But now I believe we should just have a front page listing our components like we have here: http://logging.apache.org …and that site should link to the appropriate sub component site. How it looks or works or how it is build should be decided by the component maintainers independently. Cheers Christian Benedikt Send from my mobile device Am 08.10.2013 um 19:52 schrieb Gary Gregory garydgreg...@gmail.com: IMO the problems are dealing with Nexus, a web site, and a 'dist' directory; that THREE things to get just right, none are 100% automated. With Nexus you have to do some manual steps. If you look at all the instructions for any commons component, it is long, a combo of manual and Maven+Nexus magic and error prone. It is not fun and a barrier. Gary On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter brit...@apache.org wrote: Hi, one of the points that seem to always come up once in a while is the process of releasing components. I've never done it myself so I'm asking people who have done it: What are the problems and how can we make releasing easier? Is the complexity of the parent pom a problem? (Do we really need all the stuff that is declared there?) Is there a way to automate all the stuff that needs to be done in a portable way? Would it be possible to automate release for example on a Jenkins instance? Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
On 7 Oct 2013, at 12:58, Jean-Louis MONTEIRO wrote: Hi Jochen, Well summarized. And I think you figured out what the real problem is. We could work as in Incubator, isn't it? Having one big umbrella and real subprojects. What would be the difference to now? I understand Commons as a project with components which are not big enough to survive as a tlp. A few components have overlapping committers but not all. You can't make sub-pmcs similar to podling-pmcs, otherwise Commons quickly enters Jakarta land. The only thing which we share all is the site build and the release process (both things i personally don't like too much). If stepping in that direction we maybe should think about grouping sets of projects like [Collections, Lang] or [Compress, IO] and make them a TLP on their own. This will show us if there is enough interest in those components on the one hand and reduce the PMC to the really interested people on the other. For example, it is unlikely that I would ask to join the first group but pretty sure that I would ask to join the second. Cheers Christian JLouis 2013/10/7 Jochen Wiedmann jochen.wiedm...@gmail.com I believe that the problem is Commons structure. To have one big project which such a lot of subprojects blocks building a small community. You're not supposed to be a part of the small subproject, but the big community Commons. While the former would be appealing for a newcomer, the latter just doesn't work (too many unknown people). I have no alternatives to offer, but my feeling is we should attempt to build smaller, more centralized parts with separate mailing lists, etc. Obviously, this might lead to a Jakarta-ization, but there are worse things than being split into subprojects. On Sun, Oct 6, 2013 at 8:30 PM, James Carman ja...@carmanconsulting.com wrote: All, The Apache Commons project seems to be languishing as of late and we need some rejuvenation. Perhaps we should try to define our mission as a project. What are our goals? What do we want to accomplish? Who are our users/customers? What non-functional qualities do we want our software to exhibit? How do we want to conduct ourselves? How often do we want to do releases? What else? Sincerely, James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero -- Jean-Louis --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
On 7 Oct 2013, at 13:58, Jochen Wiedmann wrote: On Mon, Oct 7, 2013 at 1:42 PM, Christian Grobmeier grobme...@gmail.comwrote: What would be the difference to now? The difference can be *huge*, emotionally. For example, I felt quite at home at the webservices project when working in JaxMe, XML-RPC, or Axis. OTOH, I feel completely isolated, since ws-commons works like Commons. Let me ask different. I think we already have an incubator like set up (just without podling-pmcs), what needs to be changed? -- That's what prayers are ... it's frightened people trying to make friends with the bully! Terry Pratchett. The Last Hero --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
On 6 Oct 2013, at 20:57, Phil Steitz wrote: On 10/6/13 11:45 AM, James Carman wrote: Collections 4.x, nuff said Huh? Didn't we release a beta? We could say the same thing about math 4.0, pool/dbcp 2.0, etc. These things are in progress. They will get released. There is activity. I don't get the big problem here. When did we start with working on pool/dbcp 2.0? Seriously we are not really releasing early, releasing often. Phil On Sun, Oct 6, 2013 at 2:42 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: I would like to know the metrics for that conclusion. I see plenty of discussions and commits, but I'm not seeing any languishing. Adrian Crum Sandglass Software www.sandglass-software.com On 10/6/2013 11:30 AM, James Carman wrote: All, The Apache Commons project seems to be languishing as of late and we need some rejuvenation. Perhaps we should try to define our mission as a project. What are our goals? What do we want to accomplish? Who are our users/customers? What non-functional qualities do we want our software to exhibit? How do we want to conduct ourselves? How often do we want to do releases? What else? Sincerely, James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DISCUSS] Mission Statement for Commons...
James, thank you. I believe Commons is in a bad shape. Look at Commons Collections. Before 4 years somebody said Guava is more modern, he his answer seems to be widely accepted. http://stackoverflow.com/a/167/690771 This guy said we have no generics. What did we do in the past 4 years? http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22 Nothing. At least nothing visible. Its fine we have a beta. I wonder why we haven't managed to officially release this? The last release is from 2008. I did consider to put my JSON component to Commons. But I didn't. Reason: I really need the component and I calculated how long it would take to release it here. I thought, it's not helping me to develop it here. I simply don't have the time. I thought a long while about it. We had discussions like: do we really need Generics? It works without! Do we really drop an outdated JDK? We might have users who run JDK 1.3! And so on. Finally this led us to the situation where almost all of our users seem to have JDK 1.3 and are not interested in generics - in 2013. The users who want modern features go to Guava. We maintain legacy code. And seriously, a lot of code works without generics. This is no reason to not include them. We discuss magic strings in the sandbox. Why? We don't need to discuss that. Before we release we can simply check Sonar. Safe the time to discuss. Fix it or leave it to Sonar to report it. We seem to think perfect documentation is more valuable then quick releases. Is it? We seem to be proud of our build. I am not. It's complex. It's no fun. Releases should be do-able in a short time, maybe even automated. It is so sad that lot of good features like Collections with Generics were blocked such a long time or drowning in discussions. I agree we should support old users. But if we don't have the manpower, we can't support them. They need to accept we are moving on. We are blocked with our backwards compatible ideas and innovation is far away. When I spoke to young developers about Commons they asked me if it still exists. Nobody of them is interested in our community. For the mission statement I would wish to see things like that: Commons Components… …are released quickly and often …do use modern JDKs and support old JDKs only as long as they are supported by Oracle …we make use of modern Java features when they are available …can be easily released …can be released without having 100% perfect documentation or perfect implementations …are build by Community who wants to learn, experiment and create new features more than by Community which wants to be backwards compatible for a long time …are allowed to release major versions with api breaks as they want Cheers Christian On 6 Oct 2013, at 20:30, James Carman wrote: All, The Apache Commons project seems to be languishing as of late and we need some rejuvenation. Perhaps we should try to define our mission as a project. What are our goals? What do we want to accomplish? Who are our users/customers? What non-functional qualities do we want our software to exhibit? How do we want to conduct ourselves? How often do we want to do releases? What else? Sincerely, James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1528612 - /commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
On 5 Oct 2013, at 14:29, James Carman wrote: On Sat, Oct 5, 2013 at 7:03 AM, Benedikt Ritter benerit...@gmail.com wrote: I'm not sure I agree with all of your points. Yes, the sandbox is a place to try new ideas out. Does this mean certain quality criterions do not apply? I don't think so. This all has to be corrected before promotion, so why not make it correct right from the start? Sometimes it helps people to get their ideas down and working without worrying about correctness. That's why writers have a rough draft, after all. The creative process is best left unencumbered when nurturing a new idea. The sandbox is all about letting folks work on an idea they have. It's a *sandbox*! Yes, it does mean that certain quality criteria do not apply, until the point when the component wishes to graduate to proper. At that point, we can put on our white gloves and go over every last line (or look at Sonar reports) if we wish. Is pointing out that something may be improved nit-picking? Well, I think it depends :-) Just sending a -1 for a commit like this would definitely be. In this case an improvement has been pointed out. I'm more then happy for feedback like this, because it helps me become a better developer. And in the end, discussing commits is part of the game ;-) Yes, in a sandbox environment, pointing out a small magic string infraction is nit-picking. Leave the authors alone and let them work through their ideas. If you want to help out with the code, jump in and help. It takes longer to write an email and participate in the back-and-forth that ensues than it does to just fix it yourself. For issues like this, we really need to be using a tool like Sonar. Sonar will objectively look at the code for infractions such as this (among many others). The author can then look at the Sonar reports and see areas that might need improvement at their leisure (the group will also do so before graduating the component to proper). The other great thing about Sonar is that it has verbiage in there about why the rule is a rule and what can be done to fix the issue, so it's also a teaching tool. Most likely, the author fully understands why it's bad to have magic strings in their code, but just wanted to get their ideas into code and working before worrying about such issues. They can clean it up later (or some of us can jump in and help). This is the exact reason that I personally would *never* start a new project here at Commons again. I would invite certain colleagues to collaborate on github or something and then later bring the code into the organization. I am very sorry to say that I feel pretty similar. Commons is a lot on nit-picking. It once was an innovating place. But often we discuss to many formalities or jdk 1.3 vs 1.5 vs 1.7 instead of just making releases. Working at Commons is pretty much complicated. It starts with a super complicated black magic parent pom and ends with discussing the value magic strings in the sandbox. I see your point Dominik. We need to discuss commits. But not at any time, often not in the sandbox and not at any place. We are slow. Guava isn't slow. That's why more and more people walk over to that place. The way to long discussion on using annotation in Commons Collections is a good example. Just want to say, the topic has changed. If anybody has the energy to change the subject, it's the right time. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[OGNL] Make use of logging?
I found 11 uses of e.printStackTrace and think its pretty bad. Including OgnlException overwrites printStackTrace and writes to System.err for some reason. In addition there are a lot of System.out's, but those are all commented and seem to have served debugging purposes. I believe small libs like OGNL should not have logging at all, but it seems some of the logging here might make sense. I am tending to enable slf4j, which is already used in the testing scope. Once done we should use the logging methods for System.out and printStackTrace. Thoughts? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[OGNL] checkstyle for maven styled code...
I found this in ognl pom: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId version2.7/version configuration configLocationconfig/maven_checks.xml/configLocation headerLocationconfig/maven-header.txt/headerLocation /configuration /plugin I thought I would remember there is something going on with these maven-checks, but couldn't find any information. OGNL is maven styled, are these check files available somewhere? Or is it just a bug in the configuration? Cheers - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] A new release
+1, go for it. Now its time to see if our testcases are good. I also think we should test it in conjunction with struts. On Tue, Mar 26, 2013 at 9:31 AM, Lukasz Lenart lukaszlen...@apache.org wrote: Ok, done. Should I just commit the changes? Or do I have to register an issue first in JIRA? Maybe it will be better... Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2013/3/26 Lukasz Lenart lukaszlen...@apache.org: I'm not sure what API should be removed/renamed/etc as almost everything is public static ;-) Anyway, I'm trying to remove two deprecated classes right now. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2013/3/8 Christian Grobmeier grobme...@gmail.com: On Wed, Mar 6, 2013 at 10:11 AM, sebb seb...@gmail.com wrote: On 6 March 2013 06:49, Lukasz Lenart lukaszlen...@apache.org wrote: Hi, I was checking out what should be solved before releasing a new version and in my opinion most of PMD [1] errors can be omitted, maybe These nested if statements could be combined should be resolved, but the rest I don't see a point instead of just satisfying PMD itself. Some of the Findbugs [2] errors are related to generated classes, should I exclude them? Another thing is Checkstyle [3], especially Missing a Javadoc comment. - I don't know what to put as it without analysing source code deeply. My question is what really should be solved to be ready to release a new version? I don't personally worry too much about PMD or Checkstyle; they depend so much on the rules chosen. Guess we need to decide on a few rules here. If they are somehow connected to method naming et al we should look at them more closely Findbugs is more useful, but it looks like most of the errors are for generated code. Bugs can be fixed by a new release, but future binary compatibility can easily be compromised. Once a bad or broken API is released, it's very difficult to fix it. So I would say the most important aspect to get right is to fix anything that makes it more difficult to maintain binary compatibility in future. For example, if one of the new methods has a name that is non-standard, it is easy to change it now. Likewise, if there is a new public method which should be private or package protected, do it now. Or new non-private mutable variables - they make thread-safety - and testing - much more difficult +1 We should look over all of our methods right now and discuss everything which is public. Speaking of which, there does not seem to be a Clirr report. I have added the clirr report plugin right now. I doesn't report for the first build, as it cannot compare to anything. I am bit confused since there is basically no configuration necessary, just the plugin definition - is it correct? That's very important. Apart from checking for unintended compatibility issues, it is useful in ensuring that new classes and methods etc. are annotated with @since markers. We have moved OGNL to 4.0 and Apache - should we annotate everything with since 4.0.0 then? Imho it doesn't make much sense to annotate with 3.x, as the package has changed and both releases are not fully interchangeable Cheers [1] http://commons.apache.org/proper/commons-ognl/pmd.html [2] http://commons.apache.org/proper/commons-ognl/findbugs.html [3] http://commons.apache.org/proper/commons-ognl/checkstyle.html Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] A new release
On Tue, Mar 26, 2013 at 9:53 AM, Lukasz Lenart lukaszlen...@apache.org wrote: 2013/3/26 Christian Grobmeier grobme...@gmail.com: +1, go for it. Now its time to see if our testcases are good. They are, I made a slight mistake and tests showed that :-) I also think we should test it in conjunction with struts. Not so easy, OGNL 4 is a different beast, but I'll try ;-) You are not alone mate! :-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] A new release
On Tue, Mar 26, 2013 at 10:05 AM, Maurizio Cucchiara mcucchi...@apache.org wrote: I thought that it won't be a piece of cake, but we might make it easier, for example what about to start a new branch on struts to integrate the new version of OGNL? (perhaps this is not the right place, or at least the only place, where this discussion should happen) You are right, lets move it to the struts list. But I like the plan. Twitter :http://www.twitter.com/m_cucchiara G+ :https://plus.google.com/107903711540963855921 Linkedin:http://www.linkedin.com/in/mauriziocucchiara VisualizeMe: http://vizualize.me/maurizio.cucchiara?r=maurizio.cucchiara Maurizio Cucchiara On 26 March 2013 09:53, Lukasz Lenart lukaszlen...@apache.org wrote: 2013/3/26 Christian Grobmeier grobme...@gmail.com: +1, go for it. Now its time to see if our testcases are good. They are, I made a slight mistake and tests showed that :-) I also think we should test it in conjunction with struts. Not so easy, OGNL 4 is a different beast, but I'll try ;-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Commons Wiki] Trivial Update of MarlaQuin by MarlaQuin
Should we move to the AdminGroups with this wiki too? I think yes On Wed, Mar 20, 2013 at 2:37 PM, Apache Wiki wikidi...@apache.org wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Commons Wiki for change notification. The MarlaQuin page has been changed by MarlaQuin: http://wiki.apache.org/commons/MarlaQuin New page: This may be a skin problem which tans or just green discoloration is without question brought in the cheekbones, nostrils, lips, forearms and therefore the temple resulting from overproduction pertaining to coloring.BR This FDA approved therapy for this is more efficient along with designed to fix the illness pertaining to Melasma. This issue happens to be known as crow's feet. Fraxel laser devices has shown that should be very efficient coupled with brings positive end results compared with all the other approaches along the lines of dermabrasion, acidic skins, vintage laser devices not to mention injectable additives. BR [[http://haitiansocialnetwork.com/blog/128264/fraxel-beam-of-light-a-mild-cosmetic-plastic-surgery-management-to-care-for/|coolsculpting by zeltiq reviews]] [[http://social.fbeach.com//index.php?p=blogs/viewstory/544884|fraxel sydney]] [[http://www.eduko.sk/prispevok/around-fraxel-laser-facial-treatment|zeltiq aesthetics]] [[http://cityadslive.com/blogs/viewstory/112210|coolsculpting zeltiq]] [[http://expose.me/index.php?do=/blog/73460/refurbish-surface-of-the-skin-any-way-you-like-due-to-cosmetic-laser-treatm/|coolsculpting treatment cost]] BR How we, when most people are working to actually make more cash when it comes to lifetime snugly during a tremendously status-conscious society-people principally aren't check out their families and also take good care of their own health. In addition to, what is the glaring results of this situation unpredictable existence Nicely, the unpredictable living style brings about various health issues which can on the other hand offer within the many continuous illness and better potentially grant childbirth if you want to fatness worries.BR BR [[http://inforchurch.com/index.php?do=/blog/13341/fraxel-fractional-laser-skin-skin-care-therapy-the-best-choice/|coolsculpting treatment cost]] [[http://www.amishmembers.com/index.php?do=/profile-51079/info/|laserul fraxel]] [[http://www.telanganafb.com/index.php?do=/blog/88682/is-certainly-fraxel-laser-acne-breakout-039-s-scar-extraction-perfect-for-y/|coolsculpting brisbane]] [[http://www.onlinefriends.in/index.php?do=/blog/9754/zeltiq-has-cold-conditions-to-cut-unwanted-fat-material-not-to-mention-cont/|coolsculpting atlanta]] [[http://gonelover.com/wordpress/groups/fraxel-and-so-thermage-options-can-assist-end-up-getting-more-skin-type/|coolsculpting brisbane]]BR BR Feel free to surf to my weblog [[http://ashfun.com/blog/131833/reasons-to-like-looking-for-fraxel-laser-hair-treatment/|http://kubus.garantiert-nett.de/blog/view/448479/finesse-facial-rejuvenation-laser-skin-amp-liposuction-residence-is-now-offering-coolsculpting-through-zeltiq-just-for-noninvasive]] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1459020 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVRecord.java
On Wed, Mar 20, 2013 at 8:53 PM, Benedikt Ritter brit...@apache.org wrote: +/** + * Returns an iterator over the values of this record. + * + * @return an iterator over the values of this record. + */ I had no better idea how to comment this. Any suggestions how to make this less redundant? If you ask me, delete it. A method called iterator() is already docs enough. BTW, I love this post from our fellow Torsten Curdt, who is not often seen here (unfortunately): http://vafer.org/blog/20050323095453/ I know people want it because of checkstyle, but actually this docs are not giving me anything. -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OT] Verifying releases Was: svn commit: r1452037 - /commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
On Sat, Mar 9, 2013 at 10:00 AM, sebb seb...@gmail.com wrote: On 9 March 2013 00:39, Ralph Goers ralph.go...@dslextreme.com wrote: I'm not sure I understand what the big deal is. Sebb vetoed a commit and identified exactly what needed to be changed for him to remove the veto. If the requested change is made then all should be fine with the world again. Sure, he could have said all the same words without the -1 but then it wouldn't be evident that he expected the change to be made. Thanks. Yes, I agree that it was perhaps unnecessary for the -1, but we had already agreed some while ago not to use $Date$ and I did not want to see that creep back in again. This is a discussion which seems to come up from time to time, like the @author tag thing and so on. Should we start a Wiki page with that kind of decisions? I think it would be useful, esp for new people. I think Benedikt has asked for such kind of docs recently. Cheers Christian Ralph On Mar 8, 2013, at 2:15 AM, Mark Thomas wrote: Niall Pemberton niall.pember...@gmail.com wrote: On Thu, Mar 7, 2013 at 11:54 PM, Mark Thomas ma...@apache.org wrote: snip/ One of the primary responsibilities of a PMC member when voting on a release is verifying what is being voted on against the tag. Different client locales and $Date$ combine to make every single source file different from the tag requiring a manual check of the diff of every file to do the verification check properly. Even with good diff tooling the verification process is a lot slower and can't be automated. Its not required for a release - although I would agree its a nice thing to do.Spot check of the files is good enough to see if it has been created from the tag I very strongly disagree. Any PMC member voting on a release should be verifying every single file in the src tarball with the tag. There are plenty of tools available that make this the work of a few seconds - providing the files agree. - otherwise we trust our release managers. Not trusting the release managers is not the primary reason that PMC members should be verifying the tarball agrees with the tag (although if a release manager ever does do anything malicious it will catch that to). The primary reason is to catch errors in build process or mistakes made by the release manager. BeanUtils is likely simpler than Tomcat but the sorts of things a full verification has caught has included: - missing files (usually after some form of code re-org) - extra files (IDE files, intermediate files, .svn/.git files, build.properties etc) - wrong line endings (Tomcat tries to use CRLF for zip and LF for tar.gz) - local edits to the source files Some are minor but missing or edited files are clearly serious issues that should cause the release to fail. BeanUtils has used the $Date$ keyword since 2005 and I cannot remember it ever coming up in a release vote - so it hasn't stopped it being released. If the release manager and the people checking the tarball all have the same locale you won't see the issue. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] A new release
On Wed, Mar 6, 2013 at 10:11 AM, sebb seb...@gmail.com wrote: On 6 March 2013 06:49, Lukasz Lenart lukaszlen...@apache.org wrote: Hi, I was checking out what should be solved before releasing a new version and in my opinion most of PMD [1] errors can be omitted, maybe These nested if statements could be combined should be resolved, but the rest I don't see a point instead of just satisfying PMD itself. Some of the Findbugs [2] errors are related to generated classes, should I exclude them? Another thing is Checkstyle [3], especially Missing a Javadoc comment. - I don't know what to put as it without analysing source code deeply. My question is what really should be solved to be ready to release a new version? I don't personally worry too much about PMD or Checkstyle; they depend so much on the rules chosen. Guess we need to decide on a few rules here. If they are somehow connected to method naming et al we should look at them more closely Findbugs is more useful, but it looks like most of the errors are for generated code. Bugs can be fixed by a new release, but future binary compatibility can easily be compromised. Once a bad or broken API is released, it's very difficult to fix it. So I would say the most important aspect to get right is to fix anything that makes it more difficult to maintain binary compatibility in future. For example, if one of the new methods has a name that is non-standard, it is easy to change it now. Likewise, if there is a new public method which should be private or package protected, do it now. Or new non-private mutable variables - they make thread-safety - and testing - much more difficult +1 We should look over all of our methods right now and discuss everything which is public. Speaking of which, there does not seem to be a Clirr report. I have added the clirr report plugin right now. I doesn't report for the first build, as it cannot compare to anything. I am bit confused since there is basically no configuration necessary, just the plugin definition - is it correct? That's very important. Apart from checking for unintended compatibility issues, it is useful in ensuring that new classes and methods etc. are annotated with @since markers. We have moved OGNL to 4.0 and Apache - should we annotate everything with since 4.0.0 then? Imho it doesn't make much sense to annotate with 3.x, as the package has changed and both releases are not fully interchangeable Cheers [1] http://commons.apache.org/proper/commons-ognl/pmd.html [2] http://commons.apache.org/proper/commons-ognl/findbugs.html [3] http://commons.apache.org/proper/commons-ognl/checkstyle.html Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [BeanUtils] Removing @author tags?
On Wed, Mar 6, 2013 at 1:01 PM, Gary Gregory garydgreg...@gmail.com wrote: Strictly speaking, you do not need his permission AFAIK. IOW, don't bother sending ME an email to tell me you'll moving my @author to pom.xml ;) Out of interest, are you sure there is no permission needed? I am thinking on another project where the author likes to keep the @author tags. (for the record: i am all for removing them) Cheers Gary Gary On Wed, Mar 6, 2013 at 2:50 AM, Benedikt Ritter brit...@apache.org wrote: Thanks for your comments. I have create BEANUTILS-431 [1]. Since Craig McClanahan doesn't seem to follow the ML I will contact him directly to be sure he is okay with this change. Benedikt [1] https://issues.apache.org/jira/browse/BEANUTILS-431 2013/3/5 Romain Manni-Bucau rmannibu...@gmail.com Hi FYI it seems @author is discouraged: http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E Le 5 mars 2013 22:46, Niall Pemberton niall.pember...@gmail.com a écrit : On Sun, Mar 3, 2013 at 10:43 AM, Benedikt Ritter brit...@apache.org wrote: Hi, @author tags are no longer used, because authors are documented in pom.xml. I don't know the history of BeanUtils so I'm asking if there are any arguments against moving authors from source code files to pom.xml. I will wait for 72 hours before I create a JIRA issue for this change. I believe I removed any of my @author tags a couple of years ago - but if I missed any, feel free to remove. Craig McClanahan is author on alot of BeanUtils - he hasn't been around in a long time, but I would take the following post he wrote regarding pool that he doesn't mind them being removed: http://markmail.org/message/7ttwf56tfy4jbexs In case you're interested, the lastest discussion I could find on this is here: http://markmail.org/message/ldexerq46xvwxdkh Niall Regards, Benedikt -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [fileupload] drop JDK1.3 support, update to 1.5 and bump to 2.0.0
+1... jdk1.3... On Tue, Mar 5, 2013 at 4:34 PM, Simone Tripodi simonetrip...@apache.org wrote: Just for the record: I don't intend to do a major rewrite ATM, just update and bugfix. best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Mar 5, 2013 at 4:04 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, since I need [fileupload] @work, I intend to do a major bump that recently involved other commons component. Any objection? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
On Tue, Jan 15, 2013 at 7:43 PM, Thomas Neidhart thomas.neidh...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1432688 - /commons/proper/logging/trunk/pom.xml
On Tue, Jan 15, 2013 at 7:47 PM, Dennis Lundberg denn...@apache.org wrote: On 2013-01-13 19:14, t...@apache.org wrote: Author: tn Date: Sun Jan 13 18:14:24 2013 New Revision: 1432688 URL: http://svn.apache.org/viewvc?rev=1432688view=rev Log: Upgrade test dependencies: log4j 1.2.17, avalong-framework 4.1.5 These are not test dependencies - they are real dependencies used in the implementations of Log4JLogger and AvalonLogger respectively. Do we really want to upgrade these? 1.2.17 does not longer support jdk 1.3, not sure if this is important for commons-logging. I am not sure on the exact changes from 1.2.12 on to now, but there are a few big issues in log4j and so I would think it is a good idea to stick with the most recent version. Modified: commons/proper/logging/trunk/pom.xml Modified: commons/proper/logging/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/logging/trunk/pom.xml?rev=1432688r1=1432687r2=1432688view=diff == --- commons/proper/logging/trunk/pom.xml (original) +++ commons/proper/logging/trunk/pom.xml Sun Jan 13 18:14:24 2013 @@ -444,7 +444,7 @@ under the License. dependency groupIdlog4j/groupId artifactIdlog4j/artifactId - version1.2.12/version + version1.2.17/version optionaltrue/optional /dependency dependency @@ -456,7 +456,7 @@ under the License. dependency groupIdavalon-framework/groupId artifactIdavalon-framework/artifactId - version4.1.3/version + version4.1.5/version optionaltrue/optional /dependency dependency -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
On Sat, Jan 12, 2013 at 3:03 PM, Thomas Neidhart thomas.neidh...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [logging] Cleanup of trunk
On Sat, Jan 12, 2013 at 6:26 PM, Thomas Neidhart thomas.neidh...@gmail.com wrote: On 01/12/2013 05:37 PM, Christian Grobmeier wrote: On Sat, Jan 12, 2013 at 3:03 PM, Thomas Neidhart thomas.neidh...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] A new release
On Tue, Jan 8, 2013 at 7:44 AM, Lukasz Lenart lukaszlen...@apache.org wrote: Another issue, I've noticed that the parent is defined as 28-SNAPSHOT, should it be simple 27 - the latest released version? Not sure about the differences of these 2, but I think we cannot release a stable version with a dependency to a -SNAPSHOT version. I think this is also true for parent poms. I also think it should be 27 stable Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [OGNL] A new release
Do you know how to exclude some files/directories from the rat-plugin scan ? Right now it includes .idea folder in the scan which produces mass of errors :\ have not tried yet, but it supports an exclude option in the configuration: http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
We will not be able to update our websites...
starting from 1. January. Just saw a final reminder from Infra. Commons is surely a LOT of work. I would like to suggest we act immediately. In other terms: let us request a commons-test cms where we can try things out and prepare the new sites. As Ralph Goers has already mentioned, we have a similar structure in logging land (1 main site, several sub sites) which might fit to Commons too. Basically we have the Main-Site under CMS control; the subsites are generated via Maven. The target of this generation is then copied to another svn tree from which it will be taken and published. Obviously we will have to generate sites for each component then, which will be a tough job with x-mas arriving. Thoughts? -- http://www.grobmeier.de https://www.timeandbill.de
Re: We will not be able to update our websites...
On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory garydgreg...@gmail.com wrote: Bah, let's pick one component and start there and skip a test site. But then there is only one component visible under the new commons.a.o? Gary On Dec 10, 2012, at 3:08, Christian Grobmeier grobme...@gmail.com wrote: starting from 1. January. Just saw a final reminder from Infra. Commons is surely a LOT of work. I would like to suggest we act immediately. In other terms: let us request a commons-test cms where we can try things out and prepare the new sites. As Ralph Goers has already mentioned, we have a similar structure in logging land (1 main site, several sub sites) which might fit to Commons too. Basically we have the Main-Site under CMS control; the subsites are generated via Maven. The target of this generation is then copied to another svn tree from which it will be taken and published. Obviously we will have to generate sites for each component then, which will be a tough job with x-mas arriving. Thoughts? -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: We will not be able to update our websites...
On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory garydgreg...@gmail.com wrote: Well, we have to start somewhere. This is going to be a lot of work, we have many components, unless you see a short cut. I thought we would create: commons-test.apache.org move all components to there and then make a switch from commons.apache.org to the new site Gary On Dec 10, 2012, at 7:13, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory garydgreg...@gmail.com wrote: Bah, let's pick one component and start there and skip a test site. But then there is only one component visible under the new commons.a.o? Gary On Dec 10, 2012, at 3:08, Christian Grobmeier grobme...@gmail.com wrote: starting from 1. January. Just saw a final reminder from Infra. Commons is surely a LOT of work. I would like to suggest we act immediately. In other terms: let us request a commons-test cms where we can try things out and prepare the new sites. As Ralph Goers has already mentioned, we have a similar structure in logging land (1 main site, several sub sites) which might fit to Commons too. Basically we have the Main-Site under CMS control; the subsites are generated via Maven. The target of this generation is then copied to another svn tree from which it will be taken and published. Obviously we will have to generate sites for each component then, which will be a tough job with x-mas arriving. Thoughts? -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: We will not be able to update our websites...
On Mon, Dec 10, 2012 at 7:50 PM, Ralph Goers ralph.go...@dslextreme.com wrote: All the sub-sites are hooked off the main site. I would have no idea how to migrate anything without migrating the main site first. I suppose it is possible to point to the sub-sites in their current location but in logging we found it more beneficial to simply copy the content under the main site in the CMS. Are all the sub-sites built with Maven? Yes, but to my knowledge different versions of maven (2 vs 3). Any that are not could move to the CMS as part of the main site. Actually I think it would be good for Commons too. Some projects may keep some old version websites. Therefore it might be nice to maintain the mainsite with the CMS and copy/paste the components to the svn part. Just my 2 cents. Ralph On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote: On 12/10/12 7:55 AM, Ralph Goers wrote: That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing. Do we really have to do it all at once? IIUC (which is quite possibly false), the intent here is to get everyone onto svn pub-sub and kill off the rsync processes from p.a.o to the live site. The stake in the ground is that the rsyncs are going to stop Jan 1. Do I have that right? Why can't we move to svn pub-sub incrementally somehow, understanding that until individual components move, their sites will be read-only? So basically, when you decide to make changes to a site, you get it set up for svn pub-sub? Note I am including the main site in this - i.e., it does not have to move until it needs to be changed. It would seem to me (again, may be missing something critical) that we could build the newly definitive source svn repo incrementally, with publishing always sourced from there, but old directories on the live host remaining until they get clobbered. In the worst case, if the live host *must* include only svn-published files, we could seed the new repo with the old content. But I don't get why that has to be the case; because if it is, we are in worse shape than Christian suggests - come Jan 1 we will be dark if we don't get everything moved to svn pub-sub. Sorry if above is naive. The intent is to avoid a huge amount of fiddling in a short period of time when quite a few component sites have not changed and will not change for some time to come. Phil Ralph On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote: On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory garydgreg...@gmail.com wrote: Well, we have to start somewhere. This is going to be a lot of work, we have many components, unless you see a short cut. I thought we would create: commons-test.apache.org move all components to there and then make a switch from commons.apache.org to the new site Gary On Dec 10, 2012, at 7:13, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory garydgreg...@gmail.com wrote: Bah, let's pick one component and start there and skip a test site. But then there is only one component visible under the new commons.a.o? Gary On Dec 10, 2012, at 3:08, Christian Grobmeier grobme...@gmail.com wrote: starting from 1. January. Just saw a final reminder from Infra. Commons is surely a LOT of work. I would like to suggest we act immediately. In other terms: let us request a commons-test cms where we can try things out and prepare the new sites. As Ralph Goers has already mentioned, we have a similar structure in logging land (1 main site, several sub sites) which might fit to Commons too. Basically we have the Main-Site under CMS control; the subsites are generated via Maven. The target of this generation is then copied to another svn tree from which it will be taken and published. Obviously we will have to generate sites for each component then, which will be a tough job with x-mas arriving. Thoughts? -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: We will not be able to update our websites...
On Mon, Dec 10, 2012 at 8:40 PM, Phil Steitz phil.ste...@gmail.com wrote: On 12/10/12 10:50 AM, Ralph Goers wrote: All the sub-sites are hooked off the main site. I would have no idea how to migrate anything without migrating the main site first. Having now looked at [1], it looks to me like we can solve the immediate problem using svn pub-sub. The docs are not clear and they may not allow it, but in theory, we could in fact do this incrementally - start an svn repo and move the mutable portions there incrementally, understanding that only changes to the svn-migrated stuff will be propagated. If infra barfs on that, then we just commit the whole mess starting at the top level commons site, following the Ant example linked on [1]. Then to make changes, we follow the process that has been in place for the main ASF site for ages - maintain a local checkout of the generated site, re-gen when you want to update and check in. I know playing with the CMS might be fun and interesting; but a) we have no volunteers to do this and b) we do not have time to migrate all of the content. Well, this is basically what we (Logging) did: we used extpath and did care on our sites manually. Everything in extpath is not editable for the CMS and needs to be pushed manually. Example of our svn repo: https://svn.apache.org/repos/infra/websites/production/logging/content/ Still its a lot of work Cheers Therefore, I suggest we just follow the Ant route; possibly moving incrementally if infra allows that. Phil [1] http://www.apache.org/dev/project-site.html I suppose it is possible to point to the sub-sites in their current location but in logging we found it more beneficial to simply copy the content under the main site in the CMS. Are all the sub-sites built with Maven? Any that are not could move to the CMS as part of the main site. Ralph On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote: On 12/10/12 7:55 AM, Ralph Goers wrote: That is what we did in logging. Changing it at the end is fairly easy. However, we don't have much time for testing. Do we really have to do it all at once? IIUC (which is quite possibly false), the intent here is to get everyone onto svn pub-sub and kill off the rsync processes from p.a.o to the live site. The stake in the ground is that the rsyncs are going to stop Jan 1. Do I have that right? Why can't we move to svn pub-sub incrementally somehow, understanding that until individual components move, their sites will be read-only? So basically, when you decide to make changes to a site, you get it set up for svn pub-sub? Note I am including the main site in this - i.e., it does not have to move until it needs to be changed. It would seem to me (again, may be missing something critical) that we could build the newly definitive source svn repo incrementally, with publishing always sourced from there, but old directories on the live host remaining until they get clobbered. In the worst case, if the live host *must* include only svn-published files, we could seed the new repo with the old content. But I don't get why that has to be the case; because if it is, we are in worse shape than Christian suggests - come Jan 1 we will be dark if we don't get everything moved to svn pub-sub. Sorry if above is naive. The intent is to avoid a huge amount of fiddling in a short period of time when quite a few component sites have not changed and will not change for some time to come. Phil Ralph On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote: On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory garydgreg...@gmail.com wrote: Well, we have to start somewhere. This is going to be a lot of work, we have many components, unless you see a short cut. I thought we would create: commons-test.apache.org move all components to there and then make a switch from commons.apache.org to the new site Gary On Dec 10, 2012, at 7:13, Christian Grobmeier grobme...@gmail.com wrote: On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory garydgreg...@gmail.com wrote: Bah, let's pick one component and start there and skip a test site. But then there is only one component visible under the new commons.a.o? Gary On Dec 10, 2012, at 3:08, Christian Grobmeier grobme...@gmail.com wrote: starting from 1. January. Just saw a final reminder from Infra. Commons is surely a LOT of work. I would like to suggest we act immediately. In other terms: let us request a commons-test cms where we can try things out and prepare the new sites. As Ralph Goers has already mentioned, we have a similar structure in logging land (1 main site, several sub sites) which might fit to Commons too. Basically we have the Main-Site under CMS control; the subsites are generated via Maven. The target of this generation is then copied to another svn tree from which it will be taken and published. Obviously we will have to generate sites for each
Re: [all] moving to svnpubsub or CMS?
On Thu, Nov 15, 2012 at 8:25 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Nov 14, 2012, at 2:03 PM, Ted Dunning wrote: On Wed, Nov 14, 2012 at 1:53 PM, Olivier Lamy ol...@apache.org wrote: 2012/11/14 Thomas Vandahl t...@apache.org: On 14.11.2012 08:40, Luc Maisonobe wrote: Please, could someone who knows what to do step up? Just a quick note that sites created by Maven can be published with svnpubsub using the SCM Publish Maven Plugin (http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/). I guess this may keep the effort manageable (no further experience, though). See especially the link http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/examples/importing-maven-site.html for how to do the initial import. IMHO first checkin will be simpler doing a checkin of content from p.a.o If you use this maven plugin and your project doesn't have any sub modules deploying a site is a simple as today: mvm site-deploy (for multi modules it's a different if needed I can help a bit as I have setup that for other asf projects and write some part of this plugin :-) ). The question is more do you want to continue maven site generation for docs or move to asf cms ? This is a false dichotomy. Maven site generation can work with ASF CMS if desired. That is sort of true but doesn't really apply to commons. I created the Flume site using Maven and Maven generates the site from RST source files. This isn't a typical Maven project site. In essence it is a CMS project that happens to invoke Maven whenever content is changed. IMO the Logging project site is a lot closer to what Commons needs. The top level site is managed by the CMS. Each of the project sites is built by Maven and is directly checked into the production area and each is independently managed. See http://wiki.apache.org/logging/ManagingTheWebSite +1 And I suggest we get a testing instance for the CMS pretty soon. Last time infra made it up pretty quickly, but moving all component websites to this place takes a long time. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] apachecon
Hi, I am there too! (referring to ApacheCon EU) Cheers On Tue, Sep 18, 2012 at 9:29 PM, Thomas Neidhart thomas.neidh...@gmail.com wrote: Hi, does anybody plan to go to ApacheCon 2012? Would be nice to meet each other there. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [site] yet another proposal on how to restyle the commons site
Hi, and just to say it clearly: i am very much +1 to finally add this skin. Cheers Christian On Fri, Aug 31, 2012 at 11:09 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi again, Thanks to Christian Grobmeier, we also added the responsive bootstrap css. I re-uploaded the site, can you please have a look at it? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Aug 31, 2012 at 8:58 AM, Simone Tripodi simonetrip...@apache.org wrote: I've uploaded a screenshot of that page taken with my mobile [1]. Doesn't look to well, anything you can do about that? :( Step 1: Make Welcome to the Apache Commons half its current font size. yup, I have no more bullets in my gun that the one Gary suggested, I just re-uploaded the site[1] How does it look? TIA, -Simo [1] http://people.apache.org/~simonetripodi/commons-sidebar/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [site] yet another proposal on how to restyle the commons site
On Thu, Aug 30, 2012 at 4:13 PM, Luc Maisonobe luc.maison...@free.fr wrote: Le 30/08/2012 15:52, Simone Tripodi a écrit : Hi all guys, new Apache Maven Fluido Skin is gonna be released soon, I started experimenting locally how the _main_ commons site would look alike if the new skin would be applied (with some modifications): voilà[1] :) If you think that putting more effort on it would worth, I am glad to continue doing more work on applying also to a component site (with different layout), publish to my local ASF space, and see the result - OTOH I'll become definitively silent and won't bother on that topic anymore :) WDYT? These are good news. Would we be able with this setting to go to svnpubsub? If we would implement it the way like we did in Logging, then yes. Basically we would then generate the site locally, copy the html to another svn repository and commit it. We would be independent of the build system. Cheers Christian Luc Many thanks in advance, all the best! -Simo [1] http://people.apache.org/~simonetripodi/commons/index.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] NSWC and Apache license
On Wed, Aug 8, 2012 at 5:38 PM, Sébastien Brisard sebastien.bris...@m4x.org wrote: Does that mean that porting it into Commons-Math is possible (license-wise?). I would think it does… That seems explicitly restrictive to me. e.g. If I don't claim to be in the general scientific community, the software has not been made available to me. I agree with you. However, scientific community does seem a bit vague to me. Arguably, anyone using Commons-*MATH* could claim to belong to the scientific community... If somebody writes a webbased SPSS or a company like creates statistics on the SO usage with Math? Surely this is commercial use and not really science? Anyway the AL2.0 does not have restrictions who can use it or not; my guess is it is not directly compatible. But you really should ask legal@ in this case. I have not seen this license listed here: http://www.apache.org/legal/3party.html But they might be able to help you anyway. Cheers Christian Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IMAGING]/[SANSELAN] JIRA error
On Wed, Jun 27, 2012 at 1:50 AM, sebb seb...@gmail.com wrote: On 26 June 2012 22:50, sebb seb...@gmail.com wrote: Some new SANSELAN JIRAs have just been raised, however the JIRA was renamed to IMAGING. Looks like something is wrong with JIRA; I'll raise an Infra issue. https://issues.apache.org/jira/browse/INFRA-4970 Looks like it was our fault ... infra can fix things, but want us to confirm that we definitely no longer want SANSELAN as a JIRA project. So please reply to this mail to say [X] OK to delete SANSELAN JIRA project [ ] NO, let's keep it (please say why?) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: which artifact repository to get commons-io from?
On Tue, Jun 19, 2012 at 6:25 PM, sebb seb...@gmail.com wrote: On 19 June 2012 16:30, Christian Grobmeier grobme...@gmail.com wrote: On Tue, Jun 19, 2012 at 4:59 PM, sebb seb...@gmail.com wrote: On 19 June 2012 13:05, Christian Grobmeier grobme...@gmail.com wrote: On Tue, Jun 19, 2012 at 1:56 PM, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Jun 19, 2012 at 7:42 AM, Jochen Wiedmann jochen.wiedm...@gmail.comwrote: On Tue, Jun 19, 2012 at 1:35 PM, Gary Gregory garydgreg...@gmail.com wrote: Commons-IO 2.4 has not made it to a Maven repo yet. I am working on it... Any problems, you could use help with? Well, yes, all the help I can get! I asked for help on repository@a.o [1] I had initially mentioned the issue on this ML [2] and went to repository@a.o at Sebb's suggestion. Gary, just an idea: for log4j I created a so called bundle and uploaded it manually to Nexus. I did it with: jar cf log4j-bundle-1217.jar * for all my artifacts. Then I went over to repository.apache.org and uploaded it there via the web interface. The content gets staged again afterwards. Would this be an option for you in this case? But that would not be something we had voted on. He? Its binary exactly the same? But how can that be proved, without at least the hashes? I wrote artifacts which might look like the jar files only, but actually the bundle jar would contain asc/md5/sha files of course. Cheers Christian I think there are 2 options here: 1) delete the sources jar for which the .asc file was deleted, and release without the sources jar. This will be a nuisance for some users, but the source is still available via the non-Maven dist package. It won't affect run-time usage. Not sure there is a requirement to release source to Maven. This needs to be established first. 2) If the sources file is required, then I think the only solution is to recreate the staging repo. If this can be done without changing the hashes and asc files - and it can be shown that these are the same as the ones voted on - then there is probably no need to re-run the vote. Otherwise, I think there should be a vote, because the Maven release includes source. Obviously option 1 is the simplest, if it is acceptable. AIUI, only releases with a proper PMC vote are official releases, for which the ASF takes responsibility. Cheers Christian Thank you. Gary [1] http://mail-archives.apache.org/mod_mbox/www-repository/201206.mbox/%3CCACZkXPxoQ1nHXqJOLmBJ295Bscjv07Vc5aBqja05ZEWkE9c4YQ%40mail.gmail.com%3E * *[2] http://mail-archives.apache.org/mod_mbox/commons-dev/201206.mbox/%3CCACZkXPwL3UMF2En0tEjiptuK-jMnA=_dgyjdseknwjkqpcx...@mail.gmail.com%3E -- In other words: what could be seen as a socially debilitating failure of character can certainly work to your advantage too. (Linus Torvalds, but the use in the signature tells something about me as well.) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: which artifact repository to get commons-io from?
However, as already mentioned on the respository mailing list, the .asc has been restored to the staging directory, so it should now be possible to release the full set of files. I saw the mail from infra, but he mentioned the checksum is not correct or something like that. Or am I wrong? we should check the checksum/signatures before we hit the release button Cheers ? Gary I think there are 2 options here: 1) delete the sources jar for which the .asc file was deleted, and release without the sources jar. This will be a nuisance for some users, but the source is still available via the non-Maven dist package. It won't affect run-time usage. Not sure there is a requirement to release source to Maven. This needs to be established first. 2) If the sources file is required, then I think the only solution is to recreate the staging repo. If this can be done without changing the hashes and asc files - and it can be shown that these are the same as the ones voted on - then there is probably no need to re-run the vote. Otherwise, I think there should be a vote, because the Maven release includes source. Obviously option 1 is the simplest, if it is acceptable. AIUI, only releases with a proper PMC vote are official releases, for which the ASF takes responsibility. Cheers Christian Thank you. Gary [1] http://mail-archives.apache.org/mod_mbox/www-repository/201206.mbox/%3CCACZkXPxoQ1nHXqJOLmBJ295Bscjv07Vc5aBqja05ZEWkE9c4YQ%40mail.gmail.com%3E * *[2] http://mail-archives.apache.org/mod_mbox/commons-dev/201206.mbox/%3CCACZkXPwL3UMF2En0tEjiptuK-jMnA=_dgyjdseknwjkqpcx...@mail.gmail.com%3E -- In other words: what could be seen as a socially debilitating failure of character can certainly work to your advantage too. (Linus Torvalds, but the use in the signature tells something about me as well.) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: which artifact repository to get commons-io from?
On Tue, Jun 19, 2012 at 1:56 PM, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Jun 19, 2012 at 7:42 AM, Jochen Wiedmann jochen.wiedm...@gmail.comwrote: On Tue, Jun 19, 2012 at 1:35 PM, Gary Gregory garydgreg...@gmail.com wrote: Commons-IO 2.4 has not made it to a Maven repo yet. I am working on it... Any problems, you could use help with? Well, yes, all the help I can get! I asked for help on repository@a.o [1] I had initially mentioned the issue on this ML [2] and went to repository@a.o at Sebb's suggestion. Gary, just an idea: for log4j I created a so called bundle and uploaded it manually to Nexus. I did it with: jar cf log4j-bundle-1217.jar * for all my artifacts. Then I went over to repository.apache.org and uploaded it there via the web interface. The content gets staged again afterwards. Would this be an option for you in this case? Cheers Christian Thank you. Gary [1] http://mail-archives.apache.org/mod_mbox/www-repository/201206.mbox/%3CCACZkXPxoQ1nHXqJOLmBJ295Bscjv07Vc5aBqja05ZEWkE9c4YQ%40mail.gmail.com%3E * *[2] http://mail-archives.apache.org/mod_mbox/commons-dev/201206.mbox/%3CCACZkXPwL3UMF2En0tEjiptuK-jMnA=_dgyjdseknwjkqpcx...@mail.gmail.com%3E -- In other words: what could be seen as a socially debilitating failure of character can certainly work to your advantage too. (Linus Torvalds, but the use in the signature tells something about me as well.) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: which artifact repository to get commons-io from?
On Tue, Jun 19, 2012 at 4:59 PM, sebb seb...@gmail.com wrote: On 19 June 2012 13:05, Christian Grobmeier grobme...@gmail.com wrote: On Tue, Jun 19, 2012 at 1:56 PM, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Jun 19, 2012 at 7:42 AM, Jochen Wiedmann jochen.wiedm...@gmail.comwrote: On Tue, Jun 19, 2012 at 1:35 PM, Gary Gregory garydgreg...@gmail.com wrote: Commons-IO 2.4 has not made it to a Maven repo yet. I am working on it... Any problems, you could use help with? Well, yes, all the help I can get! I asked for help on repository@a.o [1] I had initially mentioned the issue on this ML [2] and went to repository@a.o at Sebb's suggestion. Gary, just an idea: for log4j I created a so called bundle and uploaded it manually to Nexus. I did it with: jar cf log4j-bundle-1217.jar * for all my artifacts. Then I went over to repository.apache.org and uploaded it there via the web interface. The content gets staged again afterwards. Would this be an option for you in this case? But that would not be something we had voted on. He? Its binary exactly the same? I think there are 2 options here: 1) delete the sources jar for which the .asc file was deleted, and release without the sources jar. This will be a nuisance for some users, but the source is still available via the non-Maven dist package. It won't affect run-time usage. Not sure there is a requirement to release source to Maven. This needs to be established first. 2) If the sources file is required, then I think the only solution is to recreate the staging repo. If this can be done without changing the hashes and asc files - and it can be shown that these are the same as the ones voted on - then there is probably no need to re-run the vote. Otherwise, I think there should be a vote, because the Maven release includes source. Obviously option 1 is the simplest, if it is acceptable. AIUI, only releases with a proper PMC vote are official releases, for which the ASF takes responsibility. Cheers Christian Thank you. Gary [1] http://mail-archives.apache.org/mod_mbox/www-repository/201206.mbox/%3CCACZkXPxoQ1nHXqJOLmBJ295Bscjv07Vc5aBqja05ZEWkE9c4YQ%40mail.gmail.com%3E * *[2] http://mail-archives.apache.org/mod_mbox/commons-dev/201206.mbox/%3CCACZkXPwL3UMF2En0tEjiptuK-jMnA=_dgyjdseknwjkqpcx...@mail.gmail.com%3E -- In other words: what could be seen as a socially debilitating failure of character can certainly work to your advantage too. (Linus Torvalds, but the use in the signature tells something about me as well.) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] Old issues....
On Mon, Jun 18, 2012 at 12:47 PM, Łukasz Lenart lukasz.len...@googlemail.com wrote: Finally, the old issues from OpenSymphony were imported :-) You are a true hero and i am impressed by your patience! Thank you so much for following this issue for so long time. I would have done a simple copy, but your solution is much better. Now its back to us devs to make a new release. Lets hope this good news give us enough motivation to ride the new horse again! Cheers Christian Kind regards -- Łukasz mobile +48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Using a Tool Like Sonar...
On Sat, Jun 9, 2012 at 2:26 PM, Gary Gregory garydgreg...@gmail.com wrote: If sonar for snapshots on a.a.o replaces POM requested reports instead of complementing them, you loose the ability to analyze before committing, surely something we do not want. you can use: mvn sonar:sonar before you commit, which should help. Gary On Jun 9, 2012, at 3:52, Mark Struberg strub...@yahoo.de wrote: we have an own Sonar installation at http://analysis.apache.org already. You just need to tell infra that you like to have your project added. LieGrue, strub - Original Message - From: Simone Tripodi simonetrip...@apache.org To: Commons Developers List dev@commons.apache.org Cc: Sent: Saturday, June 9, 2012 8:09 AM Subject: Re: [ALL] Using a Tool Like Sonar... +1 we are using it also in Cocoon and helps a lot - IMHO it should replace public static reports generated and published by mvn... best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Jun 9, 2012 at 12:19 AM, James Carman ja...@carmanconsulting.com wrote: All, I've really become fond of Sonar (http://www.sonarsource.org/) in the past 6 months or so. I install the Sonar plugin in Jenkins and turn on Sonar for my builds and I get Continuous Inspection of my code which helps me find potential issues. It uses tools like Findbugs, PMD, Checkstyle, etc. and aggregates the results into one easy-to-use interface. What would you guys think about introducing something like that into Apache Commons to help us improve our code quality? Thanks, James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [classscan] logging
On Sun, Jun 3, 2012 at 5:59 PM, Gary Gregory garydgreg...@gmail.com wrote: I would rather we eat our own dog food with log4j or commons logging. As classscan is in sandbox... I think it would help the logging team if we would try log4j 2.0 alpha. It is a great framework already and logging-people could learn about problems. The time when classscan is leaving the sandbox and prepares for a proper release we can decide again to switch to th e more stable logback or leave the dependency to the rising log4j 2.0. To learn more on log4j 2.0 please visit: https://people.apache.org/~rgoers/log4j2/ Cheers Christian Gary On Jun 3, 2012, at 11:42, Ralph Goers ralph.go...@dslextreme.com wrote: Well, you might want the logging to be silent during normal testing but to be enabled if problems arise. Ralph On Jun 3, 2012, at 8:27 AM, Matt Benson wrote: Can anyone provide a reason [classscan] should not simply use slf4j-simple in the test scope rather than logback? It's a small change, but any reduction in complexity... Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Compress 1.4.1 based on RC1
+1 On Tue, May 22, 2012 at 9:00 AM, Stefan Bodewig bode...@apache.org wrote: Hi all, I'd like to release Compress 1.4.1. Compress 1.4.1 RC1 is available for review here: http://people.apache.org/~bodewig/cc/ Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-111/org/apache/commons/commons-compress/1.4.1/ Details of changes since 1.4 are in the release notes: https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.4.1_RC1/RELEASE-NOTES.txt http://people.apache.org/~bodewig/cc/site/changes-report.html#a1.4.1 I have tested this with JDK 1.6 and 1.7 using maven2 and maven3. The tag is here: https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.4.1_RC1/ Site: http://people.apache.org/~bodewig/cc/site/ (this is not the site that's going to go online, I know the title page contains a bunch of 1.4s where it should read 1.4.1) Clirr Report (compared to 1.4): http://people.apache.org/~bodewig/cc/site/clirr-report.html RAT Report: http://people.apache.org/~bodewig/cc/site/rat-report.html Votes, please. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Git support?
On Sun, May 20, 2012 at 12:43 AM, James Carman ja...@carmanconsulting.com wrote: Perhaps classscan? :) makes perfect sense to me :-) On Sat, May 19, 2012 at 5:38 PM, Christian Grobmeier grobme...@gmail.com wrote: On May 19, 2012 10:13 PM, Gary Gregory garydgreg...@gmail.com wrote: A one component test drive seems reasonable. +1 Not everybody is fluent with git. One component gives us the chance to document some best practices. Maybe it would be good to start with a sandbox comp. But i am afraid those are not active enough. Gary On May 19, 2012, at 4:08, Luc Maisonobe luc.maison...@free.fr wrote: Le 16/05/2012 15:41, Jochen Wiedmann a écrit : Well, with our multitude of projects, it might make sense to ask for one or two of them being migrated, so that we gather the experience. (I've got none so far.) Would anyone volunteer for the job of being involved? I was wondering if we should switch all components at the same time when everything is ready or as you propose switch one or two components early and use them as a template for other components. I am really interested in using Git access, as I already uses it for non-Apache projects and am really happy with it. In fact, for Apache projects I use git-svn. If we propose to switch one component first, I would be happy to volunteer for switching [math]. What do other developers think about Jochen idea ? Luc Thanks, Jochen On Wed, May 16, 2012 at 9:52 AM, Christian Grobmeier grobme...@gmail.com wrote: Its still in development. I have asked to switch to git with log4php before a few weeks and the answer was it is possible, if one of us gets involved in the git@apache project. I assume it is the the here. Its definitely not GA at the moment. On Wed, May 16, 2012 at 9:39 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: Completely OT: Is Git supported now? https://issues.apache.org/jira/browse/INFRA-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId276416#comment-13276416 -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Git support?
On May 19, 2012 10:13 PM, Gary Gregory garydgreg...@gmail.com wrote: A one component test drive seems reasonable. +1 Not everybody is fluent with git. One component gives us the chance to document some best practices. Maybe it would be good to start with a sandbox comp. But i am afraid those are not active enough. Gary On May 19, 2012, at 4:08, Luc Maisonobe luc.maison...@free.fr wrote: Le 16/05/2012 15:41, Jochen Wiedmann a écrit : Well, with our multitude of projects, it might make sense to ask for one or two of them being migrated, so that we gather the experience. (I've got none so far.) Would anyone volunteer for the job of being involved? I was wondering if we should switch all components at the same time when everything is ready or as you propose switch one or two components early and use them as a template for other components. I am really interested in using Git access, as I already uses it for non-Apache projects and am really happy with it. In fact, for Apache projects I use git-svn. If we propose to switch one component first, I would be happy to volunteer for switching [math]. What do other developers think about Jochen idea ? Luc Thanks, Jochen On Wed, May 16, 2012 at 9:52 AM, Christian Grobmeier grobme...@gmail.com wrote: Its still in development. I have asked to switch to git with log4php before a few weeks and the answer was it is possible, if one of us gets involved in the git@apache project. I assume it is the the here. Its definitely not GA at the moment. On Wed, May 16, 2012 at 9:39 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: Completely OT: Is Git supported now? https://issues.apache.org/jira/browse/INFRA-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId276416#comment-13276416 -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Git support?
Its still in development. I have asked to switch to git with log4php before a few weeks and the answer was it is possible, if one of us gets involved in the git@apache project. I assume it is the the here. Its definitely not GA at the moment. On Wed, May 16, 2012 at 9:39 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: Completely OT: Is Git supported now? https://issues.apache.org/jira/browse/INFRA-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276416#comment-13276416 -- Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung. Dieter Hildebrandt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] BeanShell incubation?
I read the thread and thought BeanShell would fit to Commons... I think there are only a few committers. OGNL is in the same vein too. I would oppose if the BS developers are not willing to continue the project here. This is not very likely the case here Cheers, Christian On Mon, Apr 2, 2012 at 6:30 PM, sebb seb...@gmail.com wrote: Back in October 2011, there was an Incubator thread about the possibility of BeanShell being moved to the ASF. Reactions were generally positive, but nothing actually happened. I'd like to restart the process, assuming the original authors are still willing. If BeanShell is to be housed at the ASF, it needs somewhere to live. I suspect it would be too small to be a standalone TLP. Commons could be a good place, as we already have JEXL (and Jelly). What do others think? Would Commons be a suitable home? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Releasing 1.4
On Sun, Apr 1, 2012 at 7:01 AM, Stefan Bodewig bode...@apache.org wrote: On 2012-03-31, Christian Grobmeier wrote: Before ages when I wrote the ChangeSet stuff I have marked them as experimental. Have not heard any complains yet... we should discuss if we remove that label or if need some more tweaks there. Probably after 1.4? I must admit I've never used that API, so I don't know whether it could use some tweaks. OTOH I don't recall any JIRA raised against it in the three years they are part of Compress. Either nobody uses the classes or the API looks good as it is. Personally I intend (but you know what happens to good intentions when time is limited) to kick off a Compress 2.0 API discussion after the 1.4 release - generics, some improvements as well as getting rid of some backwards compatibility baggage. I agree, but whats the conclusion? :-) Wait for 2.0? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Releasing 1.4
+1 Before ages when I wrote the ChangeSet stuff I have marked them as experimental. Have not heard any complains yet... we should discuss if we remove that label or if need some more tweaks there. Probably after 1.4? On Sat, Mar 31, 2012 at 6:48 AM, Stefan Bodewig bode...@apache.org wrote: Hi all, Compress' trunk has been sitting on valuable content for too long now: * XZ compression * BZIP2 now reads streams created by pbzip2 (parallel bzip2) * TAR has been largely improved to support reading and writing big files, old files and files with long names - as well as encodings other than ASCII - in several ways supporting multiple dialects. There is one backwards incompatible change, tar now uses the platform's native encoding for file names (like GNU tar does) rather than ISO-8859-1. I intend to build a release candidate sometime during the next week unless anybody objects. In order to incorporate feedback before I create the RC I've built the site for review at http://people.apache.org/~bodewig/commons-compress/ Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Moving to Java 6 for version 2.3
+1 on the move to java 6 we should consider to go to 3.0... its a breaking change... but i leave it up to you On Fri, Mar 30, 2012 at 12:35 AM, Gary Gregory garydgreg...@gmail.com wrote: On Thu, Mar 29, 2012 at 6:15 PM, Paul Libbrecht p...@hoplahup.net wrote: Will the resulting jars still run on jdk 1.5? I think I would suggest a new major version if not. Hi Paul. No, if we use Java 6 APIs, you'll get errors on Java 5. We have not required major version change in the past for changing Java versions on other Commons components. I happy to make the next release 3.0 instead of 2.3 but I do not see this needed ATM. Thank you, Gary paul Le 29 mars 2012 à 23:55, Gary Gregory a écrit : Hi All: In order to add and use Charset APIs for encodings instead of encoding name Strings with various APIs like String(byte[], Charset) and so on, I plan on moving [io] to Java 6. I have (not committed) changes to the IOUtils class as a start: all APIs that can take a String encoding name (old school) have a sister API that takes a Charset object (new school). The refactoring I have is actually quite nice and gets rid of the odd noise in the implementation if encoding is null then call API1 else call API2. Instead I convert the null to Charset.defaultCharset() in a new API (again, not committed yet until I set the POM to Java 6). Thank you, Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] Moving to Java 6 for version 2.3
Hi, On Fri, Mar 30, 2012 at 1:53 AM, sebb seb...@gmail.com wrot However, a compatibility break would require a major version bump. if my lib does drop support for a specific jdk, isn't that a compatibility break? My argument is it is no longer compatible with jdk5. However, please do not consider my concerns a -1 on the version name, I am fine with 2.3 too. Cheers Christian - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] Old issues....
2012/3/22 Łukasz Lenart lukasz.len...@googlemail.com: 2012/3/21 Christian Grobmeier grobme...@gmail.com: I don't know, maybe this is against ASF law or so ... oh... good question. But maybe copy/paste can be seen as some kind of manual export plugin? :-) and it'll take some time to manually copy all issues with comments and attachments. Maybe some tool ? hm thats right. Maybe exporting it to csv? https://plugins.atlassian.com/plugins/com.atlassian.plugins.jiraexportissuetocsv Google told me it should not be so hard to write an own plugin. Have not done this before. I am willing to look into it (when I have some time, ugh), but need some data... probably it is even easier to generate the csv directly from the jira database... no idea Cheers Regards -- Łukasz http://www.lenart.org.pl/ mobile +48 606 323 122, office +27 11 0838747 Warszawa JUG conference - Confitura http://confitura.pl/ -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] Old issues....
Thanks for following up Lukasz! But... is it worth the trouble? Copy/Paste is an option. 2012/3/9 Łukasz Lenart lukasz.len...@googlemail.com: If you not follow the issue, there is a problem with importing the old issues from OpenSymphony, Tony is working on that, but probably it will take some time 2012/1/19 Christian Grobmeier grobme...@gmail.com: Thanks for all the work Lukasz, I appreciate it!! 2012/1/19 Łukasz Lenart lukasz.len...@googlemail.com: 2012/1/18 Jochen Wiedmann jochen.wiedm...@gmail.com: As I do see that ticket, it is currently properly assigned to and waiting for Tony Stevenson. We must wait for INFRA now Regards -- Łukasz - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1302199 - in /commons/sandbox/graph/branches/exporters-with-mappers/src: main/java/org/apache/commons/graph/ main/java/org/apache/commons/graph/export/ test/java/org/apache/commons/gr
On Sun, Mar 18, 2012 at 8:57 PM, Simone Tripodi
simonetrip...@apache.org wrote:
wrong code style anyway :P
Wow, I have waited for this a long time...!
Welcome to the good side of bracket-life ;-)
congrats!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Mar 18, 2012 at 8:12 PM, c...@apache.org wrote:
Author: cs
Date: Sun Mar 18 19:12:20 2012
New Revision: 1302199
URL: http://svn.apache.org/viewvc?rev=1302199view=rev
Log:
proof of concept with tests using the new proposed API -- the code compiles
but it does not work yet
Modified:
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/CommonsGraph.java
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/AbstractExporter.java
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/DefaultNamedExportSelector.java
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/DefaultToStreamBuilder.java
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/DotExporter.java
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/ExportSelctor.java
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/GraphMLExporter.java
commons/sandbox/graph/branches/exporters-with-mappers/src/test/java/org/apache/commons/graph/export/EdgeLabelMapper.java
commons/sandbox/graph/branches/exporters-with-mappers/src/test/java/org/apache/commons/graph/export/EdgeWeightMapper.java
commons/sandbox/graph/branches/exporters-with-mappers/src/test/java/org/apache/commons/graph/export/ExportTestCase.java
commons/sandbox/graph/branches/exporters-with-mappers/src/test/java/org/apache/commons/graph/export/VertexLabelMapper.java
Modified:
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/CommonsGraph.java
URL:
http://svn.apache.org/viewvc/commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/CommonsGraph.java?rev=1302199r1=1302198r2=1302199view=diff
==
---
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/CommonsGraph.java
(original)
+++
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/CommonsGraph.java
Sun Mar 18 19:12:20 2012
@@ -35,7 +35,9 @@ import org.apache.commons.graph.coloring
import org.apache.commons.graph.coloring.DefaultColorsBuilder;
import org.apache.commons.graph.connectivity.ConnectivityBuilder;
import org.apache.commons.graph.connectivity.DefaultConnectivityBuilder;
+import org.apache.commons.graph.export.DefaultNamedExportSelector;
import org.apache.commons.graph.export.DefaultToStreamBuilder;
+import org.apache.commons.graph.export.ExportSelctor;
import org.apache.commons.graph.export.ToStreamBuilder;
import org.apache.commons.graph.flow.DefaultFlowWeightedEdgesBuilder;
import org.apache.commons.graph.flow.FlowWeightedEdgesBuilder;
@@ -56,10 +58,10 @@ import org.apache.commons.graph.visit.Vi
public final class CommonsGraphV, E, G extends GraphV, E
{
- public static V, E, G extends GraphV, E ToStreamBuilderV, E
export( G graph )
+ public static V, E, G extends GraphV, E ExportSelctorV, E export(
G graph )
{
graph = checkNotNull( graph, Null graph can not be exported );
- return new DefaultToStreamBuilderV, E( graph );
+ return new DefaultNamedExportSelectorV, E( graph );
}
public static V, E, G extends UndirectedGraphV, E ColorsBuilderV,
E coloring( G graph )
Modified:
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/AbstractExporter.java
URL:
http://svn.apache.org/viewvc/commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/AbstractExporter.java?rev=1302199r1=1302198r2=1302199view=diff
==
---
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/AbstractExporter.java
(original)
+++
commons/sandbox/graph/branches/exporters-with-mappers/src/main/java/org/apache/commons/graph/export/AbstractExporter.java
Sun Mar 18 19:12:20 2012
@@ -21,7 +21,9 @@ package org.apache.commons.graph.export;
import static java.lang.String.format;
+import java.io.File;
import java.io.IOException;
+import java.io.OutputStream;
import java.io.Writer;
import java.util.Date;
import java.util.HashMap;
@@ -59,7 +61,41 @@ abstract
Re: [Math] Release mini-howto
On Sun, Mar 18, 2012 at 8:42 PM, Gary Gregory garydgreg...@gmail.com wrote: That's what the wiki is for no? You could make a page for [math] like http://wiki.apache.org/commons/UsingNexus Not to forget the grandfather of release guides: http://commons.apache.org/releases/release.html Cheers Gary On Sun, Mar 18, 2012 at 3:40 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: Hi. In the course of the latest release process, I've taken notes about what to do to make things work for a release manager newbie. Thus, there is a small text file with the step-by-step description, and two minimal maven config files. I'd like to create new directories in trunk to home these files. Would committer_docs/release_howto be OK? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Release mini-howto
On Mon, Mar 19, 2012 at 12:25 AM, Gilles Sadowski gil...@harfang.homelinux.org wrote: Not to forget the grandfather of release guides: http://commons.apache.org/releases/release.html I've just had a brief look at that one; I did not know it existed... not very well linked imho... if it is linked Is it maintained and up-to-date? Same situation like UsingNexus: the guys who use it, should update it. Sometimes it happens. :-) What I noticed with UsingNexus is that people who know how to release certainly did not follow exactly what was described there; otherwise they would have stumbled on the problems which I faced. That is often the problem with such documents: newbies cannot fill in the blanks and experts do not need to read them. Thus they are useless. My document is a step-by-step recipe; it contains the strict minimum, and what needs to be supplied (login, password, GPG key, ssh key, ...) clearly stands out. Hard to judge without looking at it. Anyway good documentation is always welcome. it seems you already made the effort... why don't you put it on the wiki? We can then discuss if we should take yours and pimp it (if necessary), or improve the other docs with your content. [By following it, someone who never prepared a release could do it in a few minutes, not the many hours I spent figuring out why maven did not seem to behave like the UsingNexus document assumed it should...] Sounds good! Lets review your work Cheers Christian My document is not a explanation of maven or svn or nexus or ssh or gpg; it just enumerates the release steps in the correct order, with the correct commands and correct config files samples (as of last week). Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[lang] static methods with final keyword
In langs StringEscapeUtils are some static methods marked with final... it makes no sense to me to do that. I would like to remove the final keywords. Any objections? not sure if this breaks bc (cannot imagine) Cheers -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Performance comparison
On Tue, Mar 13, 2012 at 4:33 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I don't think we should be trying to recode JDK classes. If the implementations suck, why not? +1 -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
+1 on the mentioned plugins, except: -1 on checkstyle. I dont see a benefit in making checkstyle default. If somebody wants to use that tool, he can. What checkstyle-style would be the default? Sun conventions or maven style? I am for sun, Simone is for maven (i guess). Probably there is another component with more specific desires. I really don't want to discuss this issue... We are all grown up here and a small party. And we have commit notifications. And if a component wishes, it can use checkstyle. Just don't make a specific style default... it probably makes a little bit more sense if components would all use the same style. But we don't even manage to agree on a uni-build system, I really see no way to make it uni-styled. On Tue, Mar 13, 2012 at 2:27 PM, Torsten Curdt tcu...@vafer.org wrote: CheckStyle reports should be checked regularly. Only doing so just before a release indeed leads to a lot of tedious work, because coders did not respect the basic, agreed on, style. I guess we are disagreeing here. I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins would not. Our mileage do vary but the end-product (clean code) should not. Then you are probably a vocal minority here. As long as there is someone that can run a code formatter before a release that does not matter though. As said in another post, you can always disable reports that you find unhelpful. Fair enough. But projects that find it useful could also just add the report :) We are discussing about what should be the default here. That said I rather just disable it in the POM that continue with the discussion. The basic code style is like logging - people spent just wait too much time on this. ...because I dont' want to contribute to that time any more. The real problem is that some coders do not do their part of the job when they commit badly formatted code. Those whose spend too much time are the ones who try to clean up the mess afterwards. If you prefer to not use code formatter - that is. But that's your decision. Menu Format Source Code Done. ...plus I am bet there are ways to set up code formatting for vim and friends - if one wanted to. CheckStyle indeed points a finger to the right person, which IMHO helps by making this person aware that he should fix it. And I say - better let's give people the tools and not just point at them. cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
On Tue, Mar 13, 2012 at 5:00 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: Hi. [...] The tools are there, but you have to tell people that they _must_ use them. Commons has already enough rules and process. As long as the releases are have clean code I wouldn't be too anal about the commits in between. I think that the main disagreement is here. Source code must be a clear read for the _developers_. To put it bluntly, I don't care that the releases have cleanly formatted code, as almost nobody is going to read those packaged sources! Nobody objects using Checkstyle. Personally I object a default Checkstyle config, which everybody must override. Nearly every components has specifics, so everybody MUST override. What if you don't want to use Checkstyle? Can you disable it? What, if you use Sun conventions and Maven conventions are the default? Much work! Please leave the checkstyle question to where it belongs, and this is not parent pom, but the individual component. And thats what I meant with: as long as we don't have a common codestyle, i does not make much sense to have a common checkstyle configuration. Secondly, I have not had the feeling in the past years that checkstyle helped me so much (including non open source projects). And so far, my code was readable. [...] Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Commons Parent reports
On Tue, Mar 13, 2012 at 5:40 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: And thats what I meant with: as long as we don't have a common codestyle, i does not make much sense to have a common checkstyle configuration. I thought that the question was whether to generate a CheckStyle report, not whether the configuration should be the same... if you add a checkstyle report without a custom config, it has the default configuration, right? In other terms, everybody would create a report based on this. Or am I wrong? Secondly, I have not had the feeling in the past years that checkstyle helped me so much (including non open source projects). And so far, my code was readable. My code is also readable... Sure, I didn't want to say otherwise :-) I forgot to mention earlier in this thread that a code formatter will not detect missing comments; I've also seen that some people using IDE let the software generate totally useless place-holder Javadoc comments. Hence no tool can afterwards detect that documentation is missing. Right. I really like Torsten old blog post on JavaDoc comments: http://vafer.org/blog/20050323095453/ If you have no good javadoc, leave it out. Sometimes you simply do not have good javadocs checkdoc should not complain about my decisions. Cheers Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] Serializable on CSVFormat
On Mon, Mar 12, 2012 at 5:30 PM, sebb seb...@gmail.com wrote: On 12 March 2012 16:25, James Carman jcar...@carmanconsulting.com wrote: We could say we support short-term storage (or transmission-only) only when it comes to serialization. That would help eliminate some of the burden Perhaps, but why take on any burden without a good use case? Couldn't look in svn (its slow like hell for me at the moment) to look at the class mentioned... but passing around CSV objects in an EJB environment is surely nice. Have not worked with EJB for quite a while, I think Classes must implement serializable when they are sent from one remote bean to another. Any form of serialisation adds extra testing and maintenance overhead. On Mar 12, 2012 11:23 AM, sebb seb...@gmail.com wrote: On 12 March 2012 09:02, Jörg Schaible joerg.schai...@scalaris.com wrote: Emmanuel Bourg wrote: Le 12/03/2012 00:16, Benedikt Ritter a écrit : I just saw that CSVFormat implements Serializable, but neither does it provide a no-arg constructor nor any of the special serialization methods (and it has no custom serialUID). Is this the way it is supposed to be? I wrote a test and it seems the serialization works fine. I think the no-arg constructor is only required if the class is expected to be subclassed, which isn't the case for CSVFormat. The UID is generated automatically by the compiler. Which silently imply that all compilers from all vendors generate the same UUID in all versions ... which is not the case. Indeed, but merely adding a UUID is not enough. The UUID needs to be maintained - when the class is changed, it may need to be changed too. If backwards compatibility is required, extra care needs to be taken to make this work; if compatibility is not desired, the UUID needs to be changed when appropriate to prevent incompatible versions causing runtime failures. Adding Serializable effectively puts (some) implementation details into the public API, and increases the maintenance burden. So unless there is a strong use case which cannot be solved in other ways it's best to avoid using serialisation. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
