Re: New log4j-streams Module
Glad to hear it. With the duplicate OSGi modules gone, now it doesn't seem so bad to add more modularity. On 30 April 2014 20:37, Ralph Goers ralph.go...@dslextreme.com wrote: That makes a lot of sense to me Sent from my iPhone On Apr 30, 2014, at 6:05 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: Can we agree to pull out jpa and jms? As for web, I know there was some discussion on how we could not register a shutdown hook. If we broke out log4j-web, maybe we could make it as simple as registering a shutdown hook if log4j-web is not included, but if log4j-web was included, the shutdown hook is not registered. It's just an idea. On Wed, Apr 30, 2014 at 12:22 AM, Matt Sicker boa...@gmail.com wrote: I mean I split off log4j-streams and put it in a branch. It being the streams module. The web stuff actually makes sense to keep in core. JPA and JMS should probably be in their own modules. The syslog stuff could be at least in its own packages but still in log4j-core. I'm unsure about the JSON/YAML ones since they're strictly for configuration and don't really add many classes overall. On 29 April 2014 21:55, Ralph Goers ralph.go...@dslextreme.com wrote: What do you mean “you took care of it?” jpa, jms, web as well as the json and yaml support are still in core. I don’t know that we have agreed to move them out yet. Ralph On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote: I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.com wrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.comwrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.comwrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.comwrote:
Re: New log4j-streams Module
Can we agree to pull out jpa and jms? As for web, I know there was some discussion on how we could not register a shutdown hook. If we broke out log4j-web, maybe we could make it as simple as registering a shutdown hook if log4j-web is not included, but if log4j-web was included, the shutdown hook is not registered. It's just an idea. On Wed, Apr 30, 2014 at 12:22 AM, Matt Sicker boa...@gmail.com wrote: I mean I split off log4j-streams and put it in a branch. It being the streams module. The web stuff actually makes sense to keep in core. JPA and JMS should probably be in their own modules. The syslog stuff could be at least in its own packages but still in log4j-core. I'm unsure about the JSON/YAML ones since they're strictly for configuration and don't really add many classes overall. On 29 April 2014 21:55, Ralph Goers ralph.go...@dslextreme.com wrote: What do you mean “you took care of it?” jpa, jms, web as well as the json and yaml support are still in core. I don’t know that we have agreed to move them out yet. Ralph On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote: I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.comwrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.comwrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.comwrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.comwrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.orgwrote: If you want to retroactively create a branch, and
Re: New log4j-streams Module
That makes a lot of sense to me Sent from my iPhone On Apr 30, 2014, at 6:05 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: Can we agree to pull out jpa and jms? As for web, I know there was some discussion on how we could not register a shutdown hook. If we broke out log4j-web, maybe we could make it as simple as registering a shutdown hook if log4j-web is not included, but if log4j-web was included, the shutdown hook is not registered. It's just an idea. On Wed, Apr 30, 2014 at 12:22 AM, Matt Sicker boa...@gmail.com wrote: I mean I split off log4j-streams and put it in a branch. It being the streams module. The web stuff actually makes sense to keep in core. JPA and JMS should probably be in their own modules. The syslog stuff could be at least in its own packages but still in log4j-core. I'm unsure about the JSON/YAML ones since they're strictly for configuration and don't really add many classes overall. On 29 April 2014 21:55, Ralph Goers ralph.go...@dslextreme.com wrote: What do you mean “you took care of it?” jpa, jms, web as well as the json and yaml support are still in core. I don’t know that we have agreed to move them out yet. Ralph On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote: I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.com wrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker
Re: New log4j-streams Module
Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.comwrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.comwrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL:
Re: New log4j-streams Module
I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.comwrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.comwrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api
Re: New log4j-streams Module
What do you mean “you took care of it?” jpa, jms, web as well as the json and yaml support are still in core. I don’t know that we have agreed to move them out yet. Ralph On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote: I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.com wrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I
Re: New log4j-streams Module
I mean I split off log4j-streams and put it in a branch. It being the streams module. The web stuff actually makes sense to keep in core. JPA and JMS should probably be in their own modules. The syslog stuff could be at least in its own packages but still in log4j-core. I'm unsure about the JSON/YAML ones since they're strictly for configuration and don't really add many classes overall. On 29 April 2014 21:55, Ralph Goers ralph.go...@dslextreme.com wrote: What do you mean “you took care of it?” jpa, jms, web as well as the json and yaml support are still in core. I don’t know that we have agreed to move them out yet. Ralph On Apr 29, 2014, at 4:28 PM, Matt Sicker boa...@gmail.com wrote: I took care of it and added it to the experimental branch in svn (along with a log4j-camel module I was working on). On 29 April 2014 18:18, Bruce Brouwer bruce.brou...@gmail.com wrote: Was there any support in creating any of these new modules? On Fri, Apr 18, 2014 at 5:59 PM, Bruce Brouwer bruce.brou...@gmail.comwrote: I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.comwrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.comwrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers
Re: New log4j-streams Module
I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/
Re: New log4j-streams Module
On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/
Re: New log4j-streams Module
I'll put together a list of things that I think could be pulled out of log4j-core because they are integrations with other tools. Go ahead and throw darts, that's what my list is for. * log4j-jms * log4j-mail * log4j-web * log4j-jpa * log4j-mongodb * log4j-couchdb Some more questionable ones to pull out * log4j-json * log4j-yaml On Fri, Apr 18, 2014 at 12:39 PM, Gary Gregory garydgreg...@gmail.comwrote: On Fri, Apr 18, 2014 at 11:17 AM, Matt Sicker boa...@gmail.com wrote: I agree with all that as well. Part of the no more modules problem comes from all the unnecessary OSGi modules. I'll be deleting those soon as I'm porting over the OSGi metadata to the appropriate modules so that extra parallel modules are unneeded. That will be good :) Gary On 17 April 2014 23:48, Ralph Goers ralph.go...@dslextreme.com wrote: I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.comwrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch.
New log4j-streams Module
Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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
Re: New log4j-streams Module
I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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 -- Matt Sicker boa...@gmail.com
Re: New log4j-streams Module
Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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 -- Matt Sicker boa...@gmail.com
Re: New log4j-streams Module
I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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 -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com
Re: New log4j-streams Module
Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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 -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com
Re: New log4j-streams Module
If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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 -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com -- Cheers, Paul
Re: New log4j-streams Module
Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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 -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com -- Cheers, Paul -- Matt Sicker boa...@gmail.com
Re: New log4j-streams Module
Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedInputStream.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerBufferedReader.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/LoggerInputStream.java (with props) - Message truncated - -- 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 -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com -- Cheers, Paul -- Matt Sicker boa...@gmail.com -- Matt Sicker boa...@gmail.com
Re: New log4j-streams Module
This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/ByteStreamLogger.java (with props) logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/CharStreamLogger.java (with props)
Re: New log4j-streams Module
I agree with you completely. In fact, the items you have specifically identified are where I would start. Are there more? Ralph On Apr 17, 2014, at 3:21 PM, Bruce Brouwer bruce.brou...@gmail.com wrote: This discussion about having modules or not having modules keeps coming up and I see different opinions here on the log4j team. Generally, the argument of please, no more modules has won. I wanted to present my perspective to see if I can sway anyone's opinion. There are plenty of reasons why projects decide to make more modules. Projects like Spring make plenty of modules. As some have noted, this can make it difficult to find things sometimes, and I agree. Although there are ways around this with search.maven.org, it is still a bit of a pain. Some of this can be solved with documentation, some of it is probably not necessary for log4j. The Spring guys like to break out different modules because of the different features (e.g. batch, security, ...). Log4j is probably not big enough to warrant breaking it up across feature lines. However, another very valid reason to break out modules is for integrations. This is where I think log4j should be allowing more modules to be created: log4j-camel, log4j-ng-flume, log4j-jms, log4j-web, log4j-mongodb, ... I think that this could help, rather than hinder, some of the discoverability related to log4j. I do quite frequently find myself seeing what is available in Maven central. If I found myself browsing around log4j, it could definitely spark some extra interest: Oh, they have something specific to JMS?, I'll have to look into that. I might discover aspects of log4j that I had not previously considered. Right now, most of those are buried inside of the code and the pom dependencies where I'm not as likely to investigate further. But having a list of modules named by their integration I may get more people excited to use log4j 2. It's about advertising. Now, maybe my argument doesn't work in my favor regarding log4j-streams, but it might if you consider Java's streams as an integration. In a way it is. In any case, I support the modularization of log4j along integration boundaries, which I think would help with osgi as well. On Thu, Apr 17, 2014 at 2:39 PM, Matt Sicker boa...@gmail.com wrote: Done. Deleted the two modules after branching to branches/experimental. On 17 April 2014 12:33, Matt Sicker boa...@gmail.com wrote: Thanks, Ralph. I'll move the experimental code to a feature branch. On 17 April 2014 12:27, Paul Benedict pbened...@apache.org wrote: If you want to retroactively create a branch, and you're doing Eclipse, simply show the project's SVN history; then select create a branch at the revision you want to split from. On Thu, Apr 17, 2014 at 1:16 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Google “svn move”. Ralph On Apr 17, 2014, at 10:33 AM, Matt Sicker boa...@gmail.com wrote: I know how to create one, but not retroactively. On 17 April 2014 10:11, Ralph Goers ralph.go...@dslextreme.com wrote: Matt, Creating a branch in subversion is trivial. A quick google would give you the answer to that. Everyone - Do we already have a sandbox? Ralph On Apr 17, 2014, at 6:29 AM, Matt Sicker boa...@gmail.com wrote: I'm not very good at subversion. I just put it in the trunk. If someone could move it to a branch, that would be great. Same goes for the experimental log4j-camel module I started yesterday. On 17 April 2014 06:49, Gary Gregory garydgreg...@gmail.com wrote: Now I am confused. I thought we decided to keep this in a branch, I could be wrong since there have been many back and forths. As of now, this means it will be released in 2.0. If so, why is it not in the core or api module? Gary On Mon, Apr 14, 2014 at 11:45 PM, mattsic...@apache.org wrote: Author: mattsicker Date: Tue Apr 15 03:44:59 2014 New Revision: 1587396 URL: http://svn.apache.org/r1587396 Log: Add log4j-streams module. - See LOG4J2-547 - Thanks to Bruce Brouwer for the patch! - Added finals everywhere to said patch. Added: logging/log4j/log4j2/trunk/log4j-streams/ (with props) logging/log4j/log4j2/trunk/log4j-streams/pom.xml (with props) logging/log4j/log4j2/trunk/log4j-streams/src/ logging/log4j/log4j2/trunk/log4j-streams/src/main/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/ logging/log4j/log4j2/trunk/log4j-streams/src/main/java/org/apache/logging/log4j/streams/
