Re: Spent time working on Velocity
On Thu, Nov 27, 2014 at 5:55 AM, Christopher Schultz ch...@christopherschultz.net wrote: ... If all logging could be replaced by using commons-logging, then all will be well. commons-logging is just a pass-through for whatever logger is really being used... log4j, slf4j, java.util.logging, etc. Most ASF projects use it already as the logging framework just to make things easier for everyone. It's super lightweight and nobody has to fight over which logging framework is best since it plugs into all of them. I'm ok with either. Whoever wants to do the work can pick, AFAIC. Agreed. I'm certainly not motivated to rip-out any logging in 1.x, but 2.x seems ripe for such things if they haven't already happened. I think 1.x still uses Avalon, which has been abandoned (right?). ... Yeah, Avalon is long abandoned.
Re: Spent time working on Velocity
Nathan, On 11/26/14 4:55 PM, Nathan Bubna wrote: On Wed, Nov 26, 2014 at 1:41 PM, Christopher Schultz ch...@christopherschultz.net wrote: ... If all logging could be replaced by using commons-logging, then all will be well. commons-logging is just a pass-through for whatever logger is really being used... log4j, slf4j, java.util.logging, etc. Most ASF projects use it already as the logging framework just to make things easier for everyone. It's super lightweight and nobody has to fight over which logging framework is best since it plugs into all of them. I'm ok with either. Whoever wants to do the work can pick, AFAIC. Agreed. I'm certainly not motivated to rip-out any logging in 1.x, but 2.x seems ripe for such things if they haven't already happened. I think 1.x still uses Avalon, which has been abandoned (right?). I seem to recall having a bear of a time building the 2.x branch, but my Maven-fu is not strong. I admit having a fear of Maven because I don't understand how it works and prefer Ant's ability to do exactly what I tell it to do, instead of what it thinks is best for me ;) The only thing you have to fear is fear itself. And dependency hell, of course. Yes. And builds that take way longer than necessary. One of our projects at $work uses Maven to build and that part of the build (which represents maybe 5% of the total Java code to compile) takes roughly 90% of the build time of the rest of the code, not including actually fetching those dependencies. :( I'm interested to hear about the fixes to the core library, though, and the unit tests that weren't being invoked and that were failing. Perhaps there is a reason they had been avoided. If there are legitimate fixes available from Frederick, we should be looking at those primarily, especially from a potential back-porting perspective. That is, if 1.7 is in fact broken, let's fix it. As long as 1.x stays relatively stable, fixes for it are a great thing. +1 My feeling is that 1.x is totally in maintenance mode: we should only be fixing things that are actually broken. New features, etc. should all go into 2.x. -chris signature.asc Description: OpenPGP digital signature
Re: Spent time working on Velocity
All, On 9/26/14 12:22 PM, Sergiu Dumitriu wrote: On 09/25/2014 11:27 PM, Nathan Bubna wrote: https://github.com/apache/velocity-engine https://github.com/apache/velocity-engine/tree/2.0_Exp Now, that said, i've not used the git mirror. The Subversion repository may still be considered the primary one by the infrastructure guys, but i assume they work together well enough. AFAIK, subversion is the only place where commits happen, the GitHub repos are read-only mirrors, but they're good for getting contributions in. Committers have to get the GitHub patches and push them to the Apache SVN repo. As far as Anakia/Texen, i'm not sure anyone still uses those. Don't bother with them, for now. If slf4j works better for Android, that seems like a fine log adaptor to me. +1 for slf4j, it's a generic enough abstraction of logging frameworks, so LogChute is really not needed. Very late to the party... If all logging could be replaced by using commons-logging, then all will be well. commons-logging is just a pass-through for whatever logger is really being used... log4j, slf4j, java.util.logging, etc. Most ASF projects use it already as the logging framework just to make things easier for everyone. It's super lightweight and nobody has to fight over which logging framework is best since it plugs into all of them. I seem to recall having a bear of a time building the 2.x branch, but my Maven-fu is not strong. I admit having a fear of Maven because I don't understand how it works and prefer Ant's ability to do exactly what I tell it to do, instead of what it thinks is best for me ;) I'm interested to hear about the fixes to the core library, though, and the unit tests that weren't being invoked and that were failing. Perhaps there is a reason they had been avoided. If there are legitimate fixes available from Frederick, we should be looking at those primarily, especially from a potential back-porting perspective. That is, if 1.7 is in fact broken, let's fix it. -chris Here's the CLA: http://www.apache.org/licenses/icla.txt On Thu, Sep 25, 2014 at 7:19 PM, Frederick N. Brier fnbr...@gmail.com wrote: Hi Nathan, I looked for the Velocity Git repo and could not find it on the Apache Git page. I just started with the 1.7 source code and initialized my own git repo and was making changes there. If you can post the git URL, I could clone it and try and meld my changes on to a branch and push the repo to Github so everyone could see it and evaluate it. While I am not familiar with Anakia/Texen, my thought was that if others were interested, the single module Maven project would become a multi-module project with at least 3 child modules: velocity-core, velocity-anakia, and velocity-texen. I would recommend working on top of the 2.0 branch, it already has a good starting point for a module-based Maven build. Anakia and Texen have already been moved out of the engine (their repos are not mirrored on GitHub). I didn't start my current project using Velocity. My background is more enterprise systems and not Android. So I started writing an XML schema to represent my domain objects and started bumping my head on a number of Android limitations, specific to XML. BTW, Android development tools rock, but I quickly found out that I couldn't use JAXB, Thymeleaf, or XMLBeans https://code.google.com/p/android/issues/detail?id=76265. There are several options out there for template engines, but all the ones that would work on Android seemed very limited. As mentioned, I'd used Velocity several times, years ago. So I figured I'd give it a whirl. Log4j can apparently work on Android, but enough posts were out there that made me nervous. Having already experienced problems with libraries, I decided to pare down Velocity to its minimum. That is the reason for trimming out the LogChute, Commons-Logging, Log4J, etc. It's amazing how much code could be eliminated. With IoC, the tests might even get leaner. SLF4J http://www.slf4j.org/ is a real thin facade for logging and there are adapters to all the other logging frameworks. It is lightweight and there is an slf4j-android http://www.slf4j.org/android/ project. What are your plans for IoC? Will you be using JSR-299? Any framework in mind? I was not even aware of a 2.x branch, what its goals are, or what has been done. I can sign a CLA. Could you please post me the git repo that has the 2.x code? BTW, my middle name is Nathan :). Fred On 09/25/2014 05:49 PM, Nathan Bubna wrote: Hi Frederick! Thanks for posting this here. Currently, we have a 1.x branch that is stable and in a long-term maintenance mode and a 2.x branch that is not really ready for consumption yet. To be honest, it's been so long since i worked on 2.x that i can't remember what changes we did get done (i could go look). Most of the core committers are, for one reason or another, focusing their development energies
Re: Spent time working on Velocity
On Wed, Nov 26, 2014 at 1:41 PM, Christopher Schultz ch...@christopherschultz.net wrote: ... If all logging could be replaced by using commons-logging, then all will be well. commons-logging is just a pass-through for whatever logger is really being used... log4j, slf4j, java.util.logging, etc. Most ASF projects use it already as the logging framework just to make things easier for everyone. It's super lightweight and nobody has to fight over which logging framework is best since it plugs into all of them. I'm ok with either. Whoever wants to do the work can pick, AFAIC. I seem to recall having a bear of a time building the 2.x branch, but my Maven-fu is not strong. I admit having a fear of Maven because I don't understand how it works and prefer Ant's ability to do exactly what I tell it to do, instead of what it thinks is best for me ;) The only thing you have to fear is fear itself. And dependency hell, of course. I'm interested to hear about the fixes to the core library, though, and the unit tests that weren't being invoked and that were failing. Perhaps there is a reason they had been avoided. If there are legitimate fixes available from Frederick, we should be looking at those primarily, especially from a potential back-porting perspective. That is, if 1.7 is in fact broken, let's fix it. As long as 1.x stays relatively stable, fixes for it are a great thing. -chris Here's the CLA: http://www.apache.org/licenses/icla.txt On Thu, Sep 25, 2014 at 7:19 PM, Frederick N. Brier fnbr...@gmail.com wrote: Hi Nathan, I looked for the Velocity Git repo and could not find it on the Apache Git page. I just started with the 1.7 source code and initialized my own git repo and was making changes there. If you can post the git URL, I could clone it and try and meld my changes on to a branch and push the repo to Github so everyone could see it and evaluate it. While I am not familiar with Anakia/Texen, my thought was that if others were interested, the single module Maven project would become a multi-module project with at least 3 child modules: velocity-core, velocity-anakia, and velocity-texen. I would recommend working on top of the 2.0 branch, it already has a good starting point for a module-based Maven build. Anakia and Texen have already been moved out of the engine (their repos are not mirrored on GitHub). I didn't start my current project using Velocity. My background is more enterprise systems and not Android. So I started writing an XML schema to represent my domain objects and started bumping my head on a number of Android limitations, specific to XML. BTW, Android development tools rock, but I quickly found out that I couldn't use JAXB, Thymeleaf, or XMLBeans https://code.google.com/p/android/issues/detail?id=76265. There are several options out there for template engines, but all the ones that would work on Android seemed very limited. As mentioned, I'd used Velocity several times, years ago. So I figured I'd give it a whirl. Log4j can apparently work on Android, but enough posts were out there that made me nervous. Having already experienced problems with libraries, I decided to pare down Velocity to its minimum. That is the reason for trimming out the LogChute, Commons-Logging, Log4J, etc. It's amazing how much code could be eliminated. With IoC, the tests might even get leaner. SLF4J http://www.slf4j.org/ is a real thin facade for logging and there are adapters to all the other logging frameworks. It is lightweight and there is an slf4j-android http://www.slf4j.org/android/ project. What are your plans for IoC? Will you be using JSR-299? Any framework in mind? I was not even aware of a 2.x branch, what its goals are, or what has been done. I can sign a CLA. Could you please post me the git repo that has the 2.x code? BTW, my middle name is Nathan :). Fred On 09/25/2014 05:49 PM, Nathan Bubna wrote: Hi Frederick! Thanks for posting this here. Currently, we have a 1.x branch that is stable and in a long-term maintenance mode and a 2.x branch that is not really ready for consumption yet. To be honest, it's been so long since i worked on 2.x that i can't remember what changes we did get done (i could go look). Most of the core committers are, for one reason or another, focusing their development energies elsewhere, with little intention to get back into it. That said, we do still actively oversee the project and are more than willing to help mentor any newcomers in navigating the ASF processes for contributing and working on new releases. It sounds to me like the work you have done thus far is largely non-compatible with the 1.x branch. In particular, the removal of Texen/Anakia and LogChute. I'm not especially familiar with SLF4J, so i would love to hear your reasons for yanking the LogChute
Re: Spent time working on Velocity
On 09/25/2014 11:27 PM, Nathan Bubna wrote: https://github.com/apache/velocity-engine https://github.com/apache/velocity-engine/tree/2.0_Exp Now, that said, i've not used the git mirror. The Subversion repository may still be considered the primary one by the infrastructure guys, but i assume they work together well enough. AFAIK, subversion is the only place where commits happen, the GitHub repos are read-only mirrors, but they're good for getting contributions in. Committers have to get the GitHub patches and push them to the Apache SVN repo. As far as Anakia/Texen, i'm not sure anyone still uses those. Don't bother with them, for now. If slf4j works better for Android, that seems like a fine log adaptor to me. +1 for slf4j, it's a generic enough abstraction of logging frameworks, so LogChute is really not needed. Here's the CLA: http://www.apache.org/licenses/icla.txt On Thu, Sep 25, 2014 at 7:19 PM, Frederick N. Brier fnbr...@gmail.com wrote: Hi Nathan, I looked for the Velocity Git repo and could not find it on the Apache Git page. I just started with the 1.7 source code and initialized my own git repo and was making changes there. If you can post the git URL, I could clone it and try and meld my changes on to a branch and push the repo to Github so everyone could see it and evaluate it. While I am not familiar with Anakia/Texen, my thought was that if others were interested, the single module Maven project would become a multi-module project with at least 3 child modules: velocity-core, velocity-anakia, and velocity-texen. I would recommend working on top of the 2.0 branch, it already has a good starting point for a module-based Maven build. Anakia and Texen have already been moved out of the engine (their repos are not mirrored on GitHub). I didn't start my current project using Velocity. My background is more enterprise systems and not Android. So I started writing an XML schema to represent my domain objects and started bumping my head on a number of Android limitations, specific to XML. BTW, Android development tools rock, but I quickly found out that I couldn't use JAXB, Thymeleaf, or XMLBeans https://code.google.com/p/android/issues/detail?id=76265. There are several options out there for template engines, but all the ones that would work on Android seemed very limited. As mentioned, I'd used Velocity several times, years ago. So I figured I'd give it a whirl. Log4j can apparently work on Android, but enough posts were out there that made me nervous. Having already experienced problems with libraries, I decided to pare down Velocity to its minimum. That is the reason for trimming out the LogChute, Commons-Logging, Log4J, etc. It's amazing how much code could be eliminated. With IoC, the tests might even get leaner. SLF4J http://www.slf4j.org/ is a real thin facade for logging and there are adapters to all the other logging frameworks. It is lightweight and there is an slf4j-android http://www.slf4j.org/android/ project. What are your plans for IoC? Will you be using JSR-299? Any framework in mind? I was not even aware of a 2.x branch, what its goals are, or what has been done. I can sign a CLA. Could you please post me the git repo that has the 2.x code? BTW, my middle name is Nathan :). Fred On 09/25/2014 05:49 PM, Nathan Bubna wrote: Hi Frederick! Thanks for posting this here. Currently, we have a 1.x branch that is stable and in a long-term maintenance mode and a 2.x branch that is not really ready for consumption yet. To be honest, it's been so long since i worked on 2.x that i can't remember what changes we did get done (i could go look). Most of the core committers are, for one reason or another, focusing their development energies elsewhere, with little intention to get back into it. That said, we do still actively oversee the project and are more than willing to help mentor any newcomers in navigating the ASF processes for contributing and working on new releases. It sounds to me like the work you have done thus far is largely non-compatible with the 1.x branch. In particular, the removal of Texen/Anakia and LogChute. I'm not especially familiar with SLF4J, so i would love to hear your reasons for yanking the LogChute adaptor instead of just providing an SLF4J bridge for it. That said, if you are interested in jumping in on a 2.x branch, i would help you regardless of your decisions. People around here may have opinions on changes, but the apache way is that those who do the work should make the decisions. :) So, yes, we are interested in your work! Do you have it public anywhere we can look at it? Are you working on a fork of our git mirror? Or did you check it out of the subversion repo? The next question is whether you are interested in working through Apache's contribution/committer process. If so, you should take a look at the 2.x branch and consider putting a CLA
Re: Spent time working on Velocity
Hi Frederick! Thanks for posting this here. Currently, we have a 1.x branch that is stable and in a long-term maintenance mode and a 2.x branch that is not really ready for consumption yet. To be honest, it's been so long since i worked on 2.x that i can't remember what changes we did get done (i could go look). Most of the core committers are, for one reason or another, focusing their development energies elsewhere, with little intention to get back into it. That said, we do still actively oversee the project and are more than willing to help mentor any newcomers in navigating the ASF processes for contributing and working on new releases. It sounds to me like the work you have done thus far is largely non-compatible with the 1.x branch. In particular, the removal of Texen/Anakia and LogChute. I'm not especially familiar with SLF4J, so i would love to hear your reasons for yanking the LogChute adaptor instead of just providing an SLF4J bridge for it. That said, if you are interested in jumping in on a 2.x branch, i would help you regardless of your decisions. People around here may have opinions on changes, but the apache way is that those who do the work should make the decisions. :) So, yes, we are interested in your work! Do you have it public anywhere we can look at it? Are you working on a fork of our git mirror? Or did you check it out of the subversion repo? The next question is whether you are interested in working through Apache's contribution/committer process. If so, you should take a look at the 2.x branch and consider putting a CLA (contributor's license agreement) on file with the ASF secretary, as that is needed for both large contributions and new committers (which you would hopefully become). -nathan On Thu, Sep 25, 2014 at 5:20 PM, Frederick N. Brier fnbr...@gmail.com wrote: Dear Velocity Team Members, I was looking for a template engine that would work on Android, and had used Velocity a couple of times, years ago. The latest version is 1.7. There haven't been any code changes in 4 years, although there were some recent bug reports. Log4j has some issues on Android and I shifted to Maven from Ant back in its 2.x days. So I restructured the codebase to use Maven, moved the Texen and Anakia code to the side, stripped out the custom LogChute code and changed it to use SLF4J. There are some minor problems just getting the 1.7 source distribution to build. I found a number of bugs along the way and a number of the unit tests were not even being run by the Ant build. I managed to get all but one of the unit tests to work (UberSpect related) that had been working before, and several that were not, are now. Several unit tests depended on the LogChute architecture, which with great difficulty, I changed. Having unit tests depend on logging feels like a hack, is very fragile, and difficult to understand because it isn't clear where the logging statement is being executed. It would be much better to restructure the code to use the more contemporary IoC design patterns, so mock objects could be injected. Injecting the MockIntrospectorCacheImpl was painful. Another unit test motivated me to add an initial implementation of an EventListener for the Velocity engine. The rewritten library works under Android, but would still need a lot of love before I'd be call it ready for a new release. What are Apache and the Velocity team's plans for the project? Velocity is the template engine used by Maven's Site component, so the project is still needed. My priorities are to deliver my Android application, but if Apache is interested, I could keep working and polishing it. Thank you for your time. Sincerely yours, Frederick N. Brier - To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org For additional commands, e-mail: dev-h...@velocity.apache.org
Re: Spent time working on Velocity
https://github.com/apache/velocity-engine https://github.com/apache/velocity-engine/tree/2.0_Exp Now, that said, i've not used the git mirror. The Subversion repository may still be considered the primary one by the infrastructure guys, but i assume they work together well enough. As far as Anakia/Texen, i'm not sure anyone still uses those. Don't bother with them, for now. If slf4j works better for Android, that seems like a fine log adaptor to me. Here's the CLA: http://www.apache.org/licenses/icla.txt On Thu, Sep 25, 2014 at 7:19 PM, Frederick N. Brier fnbr...@gmail.com wrote: Hi Nathan, I looked for the Velocity Git repo and could not find it on the Apache Git page. I just started with the 1.7 source code and initialized my own git repo and was making changes there. If you can post the git URL, I could clone it and try and meld my changes on to a branch and push the repo to Github so everyone could see it and evaluate it. While I am not familiar with Anakia/Texen, my thought was that if others were interested, the single module Maven project would become a multi-module project with at least 3 child modules: velocity-core, velocity-anakia, and velocity-texen. I didn't start my current project using Velocity. My background is more enterprise systems and not Android. So I started writing an XML schema to represent my domain objects and started bumping my head on a number of Android limitations, specific to XML. BTW, Android development tools rock, but I quickly found out that I couldn't use JAXB, Thymeleaf, or XMLBeans https://code.google.com/p/android/issues/detail?id=76265. There are several options out there for template engines, but all the ones that would work on Android seemed very limited. As mentioned, I'd used Velocity several times, years ago. So I figured I'd give it a whirl. Log4j can apparently work on Android, but enough posts were out there that made me nervous. Having already experienced problems with libraries, I decided to pare down Velocity to its minimum. That is the reason for trimming out the LogChute, Commons-Logging, Log4J, etc. It's amazing how much code could be eliminated. With IoC, the tests might even get leaner. SLF4J http://www.slf4j.org/ is a real thin facade for logging and there are adapters to all the other logging frameworks. It is lightweight and there is an slf4j-android http://www.slf4j.org/android/ project. I was not even aware of a 2.x branch, what its goals are, or what has been done. I can sign a CLA. Could you please post me the git repo that has the 2.x code? BTW, my middle name is Nathan :). Fred On 09/25/2014 05:49 PM, Nathan Bubna wrote: Hi Frederick! Thanks for posting this here. Currently, we have a 1.x branch that is stable and in a long-term maintenance mode and a 2.x branch that is not really ready for consumption yet. To be honest, it's been so long since i worked on 2.x that i can't remember what changes we did get done (i could go look). Most of the core committers are, for one reason or another, focusing their development energies elsewhere, with little intention to get back into it. That said, we do still actively oversee the project and are more than willing to help mentor any newcomers in navigating the ASF processes for contributing and working on new releases. It sounds to me like the work you have done thus far is largely non-compatible with the 1.x branch. In particular, the removal of Texen/Anakia and LogChute. I'm not especially familiar with SLF4J, so i would love to hear your reasons for yanking the LogChute adaptor instead of just providing an SLF4J bridge for it. That said, if you are interested in jumping in on a 2.x branch, i would help you regardless of your decisions. People around here may have opinions on changes, but the apache way is that those who do the work should make the decisions. :) So, yes, we are interested in your work! Do you have it public anywhere we can look at it? Are you working on a fork of our git mirror? Or did you check it out of the subversion repo? The next question is whether you are interested in working through Apache's contribution/committer process. If so, you should take a look at the 2.x branch and consider putting a CLA (contributor's license agreement) on file with the ASF secretary, as that is needed for both large contributions and new committers (which you would hopefully become). -nathan On Thu, Sep 25, 2014 at 5:20 PM, Frederick N. Brier fnbr...@gmail.com wrote: Dear Velocity Team Members, I was looking for a template engine that would work on Android, and had used Velocity a couple of times, years ago. The latest version is 1.7. There haven't been any code changes in 4 years, although there were some recent bug reports. Log4j has some issues on Android and I shifted to Maven from Ant back in its 2.x days. So I restructured the codebase to use Maven, moved the Texen and Anakia
Re: Spent time working on Velocity
Hmm. Yeah, i just looked through the commit history for the 2.0 branch. It has a LOT of removed deprecations, upgrades, important fixes, etc. I'd recommend that as a great starting point, if it's at all possible to merge your changes into it... I'd forgotten how far we'd gotten on that branch. I think the only reason we stalled out on it was because there was a feeling that it needed some bigger feature-ish changes (e.g. improved whitespace handling). We probably should have released it regardless... On Thu, Sep 25, 2014 at 8:28 PM, Nathan Bubna nbu...@gmail.com wrote: I should clarify that you shouldn't necessarily feel compelled to use that 2.0_Exp branch. I think it has some good fixes in there, though, so you may want to check out the commit history on it. On Thu, Sep 25, 2014 at 8:27 PM, Nathan Bubna nbu...@gmail.com wrote: https://github.com/apache/velocity-engine https://github.com/apache/velocity-engine/tree/2.0_Exp Now, that said, i've not used the git mirror. The Subversion repository may still be considered the primary one by the infrastructure guys, but i assume they work together well enough. As far as Anakia/Texen, i'm not sure anyone still uses those. Don't bother with them, for now. If slf4j works better for Android, that seems like a fine log adaptor to me. Here's the CLA: http://www.apache.org/licenses/icla.txt On Thu, Sep 25, 2014 at 7:19 PM, Frederick N. Brier fnbr...@gmail.com wrote: Hi Nathan, I looked for the Velocity Git repo and could not find it on the Apache Git page. I just started with the 1.7 source code and initialized my own git repo and was making changes there. If you can post the git URL, I could clone it and try and meld my changes on to a branch and push the repo to Github so everyone could see it and evaluate it. While I am not familiar with Anakia/Texen, my thought was that if others were interested, the single module Maven project would become a multi-module project with at least 3 child modules: velocity-core, velocity-anakia, and velocity-texen. I didn't start my current project using Velocity. My background is more enterprise systems and not Android. So I started writing an XML schema to represent my domain objects and started bumping my head on a number of Android limitations, specific to XML. BTW, Android development tools rock, but I quickly found out that I couldn't use JAXB, Thymeleaf, or XMLBeans https://code.google.com/p/android/issues/detail?id=76265. There are several options out there for template engines, but all the ones that would work on Android seemed very limited. As mentioned, I'd used Velocity several times, years ago. So I figured I'd give it a whirl. Log4j can apparently work on Android, but enough posts were out there that made me nervous. Having already experienced problems with libraries, I decided to pare down Velocity to its minimum. That is the reason for trimming out the LogChute, Commons-Logging, Log4J, etc. It's amazing how much code could be eliminated. With IoC, the tests might even get leaner. SLF4J http://www.slf4j.org/ is a real thin facade for logging and there are adapters to all the other logging frameworks. It is lightweight and there is an slf4j-android http://www.slf4j.org/android/ project. I was not even aware of a 2.x branch, what its goals are, or what has been done. I can sign a CLA. Could you please post me the git repo that has the 2.x code? BTW, my middle name is Nathan :). Fred On 09/25/2014 05:49 PM, Nathan Bubna wrote: Hi Frederick! Thanks for posting this here. Currently, we have a 1.x branch that is stable and in a long-term maintenance mode and a 2.x branch that is not really ready for consumption yet. To be honest, it's been so long since i worked on 2.x that i can't remember what changes we did get done (i could go look). Most of the core committers are, for one reason or another, focusing their development energies elsewhere, with little intention to get back into it. That said, we do still actively oversee the project and are more than willing to help mentor any newcomers in navigating the ASF processes for contributing and working on new releases. It sounds to me like the work you have done thus far is largely non-compatible with the 1.x branch. In particular, the removal of Texen/Anakia and LogChute. I'm not especially familiar with SLF4J, so i would love to hear your reasons for yanking the LogChute adaptor instead of just providing an SLF4J bridge for it. That said, if you are interested in jumping in on a 2.x branch, i would help you regardless of your decisions. People around here may have opinions on changes, but the apache way is that those who do the work should make the decisions. :) So, yes, we are interested in your work! Do you have it public anywhere we can look at it? Are you working on a fork of our git mirror? Or did you check it out of the subversion repo? The next question
