Re: Spent time working on Velocity

[Christopher Schultz <ch...@christopherschultz.net>]

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 <fn...@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
>>>> (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 <fn...@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-unsubscribe@velocity.apache.org
>>>>> For additional commands, e-mail: dev-help@velocity.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>
> 
> 

Re: Spent time working on Velocity

[Nathan Bubna <nb...@gmail.com>]

On Thu, Nov 27, 2014 at 5:55 AM, Christopher Schultz <
chris@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

[Christopher Schultz <ch...@christopherschultz.net>]

Nathan,

On 11/26/14 4:55 PM, Nathan Bubna wrote:
> On Wed, Nov 26, 2014 at 1:41 PM, Christopher Schultz <
> chris@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

Re: Spent time working on Velocity

[Nathan Bubna <nb...@gmail.com>]

On Wed, Nov 26, 2014 at 1:41 PM, Christopher Schultz <
chris@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 <fn...@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
> >>>> (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 <
> fnbrier@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-unsubscribe@velocity.apache.org
> >>>>> For additional commands, e-mail: dev-help@velocity.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
> >
>
>