Cayenne own template renderer to replace Velocity

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Cayenne own template renderer to replace Velocity

Nikita Timofeev
Hi all,

I've opened a PR [1] just now with new SQLTemplateProcessor
implementation based on new Cayenne own parser (instead of Velocity).

It doesn't support all features of Velocity but it's enough to
seamlessly replace Velocity in all core and test code in Cayenne, plus
it's faster (up to x15 in case of cache hit) and should have less
memory footprint (though I've only checked speed and memory is my
guess as new parser smaller and have no runtime).

Plus cayenne-server now free of velocity and commons-lang
dependencies, next step will be removing of commons-collections (it
will be the last one).

VelocitySQLTemplateProcessor now comes in optional auto-loaded module
(cayenne-velocity), so if you relied on some advanced features of
Velocity in your SQLTemplates you still can use it. And Velocity is
still used for cgen templates.

See PR [1] and Jira ticket [2] for details.

Any thoughts or concerns?

[1] https://github.com/apache/cayenne/pull/238
[2] https://issues.apache.org/jira/browse/CAY-2345

--
Best regards,
Nikita Timofeev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Michael Gentry
I haven't looked into the details, but I like the idea of reducing
dependencies upon external libraries, which can cause headaches with
applications using Cayenne.

I'm assuming the template engine will be injectable so that you can choose
Velocity, Freemarker, etc if you'd like?  (Of course, you might have to
create a bridge to your template engine of choice, but be able to inject
that bridge into Cayenne.)

Thanks,

mrg


On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <[hidden email]>
wrote:

> Hi all,
>
> I've opened a PR [1] just now with new SQLTemplateProcessor
> implementation based on new Cayenne own parser (instead of Velocity).
>
> It doesn't support all features of Velocity but it's enough to
> seamlessly replace Velocity in all core and test code in Cayenne, plus
> it's faster (up to x15 in case of cache hit) and should have less
> memory footprint (though I've only checked speed and memory is my
> guess as new parser smaller and have no runtime).
>
> Plus cayenne-server now free of velocity and commons-lang
> dependencies, next step will be removing of commons-collections (it
> will be the last one).
>
> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
> (cayenne-velocity), so if you relied on some advanced features of
> Velocity in your SQLTemplates you still can use it. And Velocity is
> still used for cgen templates.
>
> See PR [1] and Jira ticket [2] for details.
>
> Any thoughts or concerns?
>
> [1] https://github.com/apache/cayenne/pull/238
> [2] https://issues.apache.org/jira/browse/CAY-2345
>
> --
> Best regards,
> Nikita Timofeev
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Andrus Adamchik
> I'm assuming the template engine will be injectable

Yes, and even better. With module auto-loading, you simply put your template engine jar on classpath, and you get it installed automatically. This is how backwards-compatible cayenne-velocity will operate.

Andrus


> On Aug 11, 2017, at 2:21 PM, Michael Gentry <[hidden email]> wrote:
>
> I haven't looked into the details, but I like the idea of reducing
> dependencies upon external libraries, which can cause headaches with
> applications using Cayenne.
>
> I'm assuming the template engine will be injectable so that you can choose
> Velocity, Freemarker, etc if you'd like?  (Of course, you might have to
> create a bridge to your template engine of choice, but be able to inject
> that bridge into Cayenne.)
>
> Thanks,
>
> mrg
>
>
> On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <[hidden email]>
> wrote:
>
>> Hi all,
>>
>> I've opened a PR [1] just now with new SQLTemplateProcessor
>> implementation based on new Cayenne own parser (instead of Velocity).
>>
>> It doesn't support all features of Velocity but it's enough to
>> seamlessly replace Velocity in all core and test code in Cayenne, plus
>> it's faster (up to x15 in case of cache hit) and should have less
>> memory footprint (though I've only checked speed and memory is my
>> guess as new parser smaller and have no runtime).
>>
>> Plus cayenne-server now free of velocity and commons-lang
>> dependencies, next step will be removing of commons-collections (it
>> will be the last one).
>>
>> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
>> (cayenne-velocity), so if you relied on some advanced features of
>> Velocity in your SQLTemplates you still can use it. And Velocity is
>> still used for cgen templates.
>>
>> See PR [1] and Jira ticket [2] for details.
>>
>> Any thoughts or concerns?
>>
>> [1] https://github.com/apache/cayenne/pull/238
>> [2] https://issues.apache.org/jira/browse/CAY-2345
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Michael Gentry
Awesome!


On Fri, Aug 11, 2017 at 7:23 AM, Andrus Adamchik <[hidden email]>
wrote:

> > I'm assuming the template engine will be injectable
>
> Yes, and even better. With module auto-loading, you simply put your
> template engine jar on classpath, and you get it installed automatically.
> This is how backwards-compatible cayenne-velocity will operate.
>
> Andrus
>
>
> > On Aug 11, 2017, at 2:21 PM, Michael Gentry <[hidden email]> wrote:
> >
> > I haven't looked into the details, but I like the idea of reducing
> > dependencies upon external libraries, which can cause headaches with
> > applications using Cayenne.
> >
> > I'm assuming the template engine will be injectable so that you can
> choose
> > Velocity, Freemarker, etc if you'd like?  (Of course, you might have to
> > create a bridge to your template engine of choice, but be able to inject
> > that bridge into Cayenne.)
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <
> [hidden email]>
> > wrote:
> >
> >> Hi all,
> >>
> >> I've opened a PR [1] just now with new SQLTemplateProcessor
> >> implementation based on new Cayenne own parser (instead of Velocity).
> >>
> >> It doesn't support all features of Velocity but it's enough to
> >> seamlessly replace Velocity in all core and test code in Cayenne, plus
> >> it's faster (up to x15 in case of cache hit) and should have less
> >> memory footprint (though I've only checked speed and memory is my
> >> guess as new parser smaller and have no runtime).
> >>
> >> Plus cayenne-server now free of velocity and commons-lang
> >> dependencies, next step will be removing of commons-collections (it
> >> will be the last one).
> >>
> >> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
> >> (cayenne-velocity), so if you relied on some advanced features of
> >> Velocity in your SQLTemplates you still can use it. And Velocity is
> >> still used for cgen templates.
> >>
> >> See PR [1] and Jira ticket [2] for details.
> >>
> >> Any thoughts or concerns?
> >>
> >> [1] https://github.com/apache/cayenne/pull/238
> >> [2] https://issues.apache.org/jira/browse/CAY-2345
> >>
> >> --
> >> Best regards,
> >> Nikita Timofeev
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Michael Gentry
In reply to this post by Andrus Adamchik
Won't a compile scope pull in a version of Velocity we specify?

https://github.com/apache/cayenne/pull/238/files#diff-e286320b0b1da27d2621bf787ddd75b1R48


On Fri, Aug 11, 2017 at 7:23 AM, Andrus Adamchik <[hidden email]>
wrote:

> > I'm assuming the template engine will be injectable
>
> Yes, and even better. With module auto-loading, you simply put your
> template engine jar on classpath, and you get it installed automatically.
> This is how backwards-compatible cayenne-velocity will operate.
>
> Andrus
>
>
> > On Aug 11, 2017, at 2:21 PM, Michael Gentry <[hidden email]> wrote:
> >
> > I haven't looked into the details, but I like the idea of reducing
> > dependencies upon external libraries, which can cause headaches with
> > applications using Cayenne.
> >
> > I'm assuming the template engine will be injectable so that you can
> choose
> > Velocity, Freemarker, etc if you'd like?  (Of course, you might have to
> > create a bridge to your template engine of choice, but be able to inject
> > that bridge into Cayenne.)
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <
> [hidden email]>
> > wrote:
> >
> >> Hi all,
> >>
> >> I've opened a PR [1] just now with new SQLTemplateProcessor
> >> implementation based on new Cayenne own parser (instead of Velocity).
> >>
> >> It doesn't support all features of Velocity but it's enough to
> >> seamlessly replace Velocity in all core and test code in Cayenne, plus
> >> it's faster (up to x15 in case of cache hit) and should have less
> >> memory footprint (though I've only checked speed and memory is my
> >> guess as new parser smaller and have no runtime).
> >>
> >> Plus cayenne-server now free of velocity and commons-lang
> >> dependencies, next step will be removing of commons-collections (it
> >> will be the last one).
> >>
> >> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
> >> (cayenne-velocity), so if you relied on some advanced features of
> >> Velocity in your SQLTemplates you still can use it. And Velocity is
> >> still used for cgen templates.
> >>
> >> See PR [1] and Jira ticket [2] for details.
> >>
> >> Any thoughts or concerns?
> >>
> >> [1] https://github.com/apache/cayenne/pull/238
> >> [2] https://issues.apache.org/jira/browse/CAY-2345
> >>
> >> --
> >> Best regards,
> >> Nikita Timofeev
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Nikita Timofeev
Cayenne-velocity module should use version of Velocity we specify, the
main point is that cayenne-server won't use it anymore.
As for explicit "compile" scope that's just copy-past, it can be
omitted as it's default anyway.

On Mon, Aug 14, 2017 at 2:16 PM, Michael Gentry <[hidden email]> wrote:

> Won't a compile scope pull in a version of Velocity we specify?
>
> https://github.com/apache/cayenne/pull/238/files#diff-e286320b0b1da27d2621bf787ddd75b1R48
>
>
> On Fri, Aug 11, 2017 at 7:23 AM, Andrus Adamchik <[hidden email]>
> wrote:
>
>> > I'm assuming the template engine will be injectable
>>
>> Yes, and even better. With module auto-loading, you simply put your
>> template engine jar on classpath, and you get it installed automatically.
>> This is how backwards-compatible cayenne-velocity will operate.
>>
>> Andrus
>>
>>
>> > On Aug 11, 2017, at 2:21 PM, Michael Gentry <[hidden email]> wrote:
>> >
>> > I haven't looked into the details, but I like the idea of reducing
>> > dependencies upon external libraries, which can cause headaches with
>> > applications using Cayenne.
>> >
>> > I'm assuming the template engine will be injectable so that you can
>> choose
>> > Velocity, Freemarker, etc if you'd like?  (Of course, you might have to
>> > create a bridge to your template engine of choice, but be able to inject
>> > that bridge into Cayenne.)
>> >
>> > Thanks,
>> >
>> > mrg
>> >
>> >
>> > On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <
>> [hidden email]>
>> > wrote:
>> >
>> >> Hi all,
>> >>
>> >> I've opened a PR [1] just now with new SQLTemplateProcessor
>> >> implementation based on new Cayenne own parser (instead of Velocity).
>> >>
>> >> It doesn't support all features of Velocity but it's enough to
>> >> seamlessly replace Velocity in all core and test code in Cayenne, plus
>> >> it's faster (up to x15 in case of cache hit) and should have less
>> >> memory footprint (though I've only checked speed and memory is my
>> >> guess as new parser smaller and have no runtime).
>> >>
>> >> Plus cayenne-server now free of velocity and commons-lang
>> >> dependencies, next step will be removing of commons-collections (it
>> >> will be the last one).
>> >>
>> >> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
>> >> (cayenne-velocity), so if you relied on some advanced features of
>> >> Velocity in your SQLTemplates you still can use it. And Velocity is
>> >> still used for cgen templates.
>> >>
>> >> See PR [1] and Jira ticket [2] for details.
>> >>
>> >> Any thoughts or concerns?
>> >>
>> >> [1] https://github.com/apache/cayenne/pull/238
>> >> [2] https://issues.apache.org/jira/browse/CAY-2345
>> >>
>> >> --
>> >> Best regards,
>> >> Nikita Timofeev
>> >>
>>
>>



--
Best regards,
Nikita Timofeev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Michael Gentry
Yes, but that's us kind of forcing a version of Velocity upon our users
rather than them choosing the version that works with their environment.
Sure, they can do dependency exclusions, etc, in the POM, but that's a
slight hassle.  If we choose a 'provided' scope, won't that work and be
better?  It'll be up to them to include the version of Velocity they want
in their POM and there won't be multiple versions provided, at least not
due to us.

Thanks,

mrg


On Mon, Aug 14, 2017 at 7:35 AM, Nikita Timofeev <[hidden email]>
wrote:

> Cayenne-velocity module should use version of Velocity we specify, the
> main point is that cayenne-server won't use it anymore.
> As for explicit "compile" scope that's just copy-past, it can be
> omitted as it's default anyway.
>
> On Mon, Aug 14, 2017 at 2:16 PM, Michael Gentry <[hidden email]>
> wrote:
> > Won't a compile scope pull in a version of Velocity we specify?
> >
> > https://github.com/apache/cayenne/pull/238/files#diff-
> e286320b0b1da27d2621bf787ddd75b1R48
> >
> >
> > On Fri, Aug 11, 2017 at 7:23 AM, Andrus Adamchik <[hidden email]
> >
> > wrote:
> >
> >> > I'm assuming the template engine will be injectable
> >>
> >> Yes, and even better. With module auto-loading, you simply put your
> >> template engine jar on classpath, and you get it installed
> automatically.
> >> This is how backwards-compatible cayenne-velocity will operate.
> >>
> >> Andrus
> >>
> >>
> >> > On Aug 11, 2017, at 2:21 PM, Michael Gentry <[hidden email]>
> wrote:
> >> >
> >> > I haven't looked into the details, but I like the idea of reducing
> >> > dependencies upon external libraries, which can cause headaches with
> >> > applications using Cayenne.
> >> >
> >> > I'm assuming the template engine will be injectable so that you can
> >> choose
> >> > Velocity, Freemarker, etc if you'd like?  (Of course, you might have
> to
> >> > create a bridge to your template engine of choice, but be able to
> inject
> >> > that bridge into Cayenne.)
> >> >
> >> > Thanks,
> >> >
> >> > mrg
> >> >
> >> >
> >> > On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <
> >> [hidden email]>
> >> > wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> I've opened a PR [1] just now with new SQLTemplateProcessor
> >> >> implementation based on new Cayenne own parser (instead of Velocity).
> >> >>
> >> >> It doesn't support all features of Velocity but it's enough to
> >> >> seamlessly replace Velocity in all core and test code in Cayenne,
> plus
> >> >> it's faster (up to x15 in case of cache hit) and should have less
> >> >> memory footprint (though I've only checked speed and memory is my
> >> >> guess as new parser smaller and have no runtime).
> >> >>
> >> >> Plus cayenne-server now free of velocity and commons-lang
> >> >> dependencies, next step will be removing of commons-collections (it
> >> >> will be the last one).
> >> >>
> >> >> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
> >> >> (cayenne-velocity), so if you relied on some advanced features of
> >> >> Velocity in your SQLTemplates you still can use it. And Velocity is
> >> >> still used for cgen templates.
> >> >>
> >> >> See PR [1] and Jira ticket [2] for details.
> >> >>
> >> >> Any thoughts or concerns?
> >> >>
> >> >> [1] https://github.com/apache/cayenne/pull/238
> >> >> [2] https://issues.apache.org/jira/browse/CAY-2345
> >> >>
> >> >> --
> >> >> Best regards,
> >> >> Nikita Timofeev
> >> >>
> >>
> >>
>
>
>
> --
> Best regards,
> Nikita Timofeev
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Andrus Adamchik
> If we choose a 'provided' scope, won't that work and be better?

I think it will be worse. Velocity is not like servlet spec jar or something that comes from a container (and less and less ppl are using containers anyways nowadays). The result of making it "provided" will be that our library will no longer work out of the box, forcing the user to actively do something about it. First they will need to realize that Velocity is required in the first place, then they need to figure out which version to use.

Only the users who already have Velocity in their system would care to override the version. And they can either user the exclude, or just import Velocity explicitly, which would take precedence over transient dependency.

Nobody reads the docs these days, things need to work out of the box :)

Andrus


> On Aug 14, 2017, at 3:07 PM, Michael Gentry <[hidden email]> wrote:
>
> Yes, but that's us kind of forcing a version of Velocity upon our users
> rather than them choosing the version that works with their environment.
> Sure, they can do dependency exclusions, etc, in the POM, but that's a
> slight hassle.  If we choose a 'provided' scope, won't that work and be
> better?  It'll be up to them to include the version of Velocity they want
> in their POM and there won't be multiple versions provided, at least not
> due to us.
>
> Thanks,
>
> mrg
>
>
> On Mon, Aug 14, 2017 at 7:35 AM, Nikita Timofeev <[hidden email]>
> wrote:
>
>> Cayenne-velocity module should use version of Velocity we specify, the
>> main point is that cayenne-server won't use it anymore.
>> As for explicit "compile" scope that's just copy-past, it can be
>> omitted as it's default anyway.
>>
>> On Mon, Aug 14, 2017 at 2:16 PM, Michael Gentry <[hidden email]>
>> wrote:
>>> Won't a compile scope pull in a version of Velocity we specify?
>>>
>>> https://github.com/apache/cayenne/pull/238/files#diff-
>> e286320b0b1da27d2621bf787ddd75b1R48
>>>
>>>
>>> On Fri, Aug 11, 2017 at 7:23 AM, Andrus Adamchik <[hidden email]
>>>
>>> wrote:
>>>
>>>>> I'm assuming the template engine will be injectable
>>>>
>>>> Yes, and even better. With module auto-loading, you simply put your
>>>> template engine jar on classpath, and you get it installed
>> automatically.
>>>> This is how backwards-compatible cayenne-velocity will operate.
>>>>
>>>> Andrus
>>>>
>>>>
>>>>> On Aug 11, 2017, at 2:21 PM, Michael Gentry <[hidden email]>
>> wrote:
>>>>>
>>>>> I haven't looked into the details, but I like the idea of reducing
>>>>> dependencies upon external libraries, which can cause headaches with
>>>>> applications using Cayenne.
>>>>>
>>>>> I'm assuming the template engine will be injectable so that you can
>>>> choose
>>>>> Velocity, Freemarker, etc if you'd like?  (Of course, you might have
>> to
>>>>> create a bridge to your template engine of choice, but be able to
>> inject
>>>>> that bridge into Cayenne.)
>>>>>
>>>>> Thanks,
>>>>>
>>>>> mrg
>>>>>
>>>>>
>>>>> On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <
>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've opened a PR [1] just now with new SQLTemplateProcessor
>>>>>> implementation based on new Cayenne own parser (instead of Velocity).
>>>>>>
>>>>>> It doesn't support all features of Velocity but it's enough to
>>>>>> seamlessly replace Velocity in all core and test code in Cayenne,
>> plus
>>>>>> it's faster (up to x15 in case of cache hit) and should have less
>>>>>> memory footprint (though I've only checked speed and memory is my
>>>>>> guess as new parser smaller and have no runtime).
>>>>>>
>>>>>> Plus cayenne-server now free of velocity and commons-lang
>>>>>> dependencies, next step will be removing of commons-collections (it
>>>>>> will be the last one).
>>>>>>
>>>>>> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
>>>>>> (cayenne-velocity), so if you relied on some advanced features of
>>>>>> Velocity in your SQLTemplates you still can use it. And Velocity is
>>>>>> still used for cgen templates.
>>>>>>
>>>>>> See PR [1] and Jira ticket [2] for details.
>>>>>>
>>>>>> Any thoughts or concerns?
>>>>>>
>>>>>> [1] https://github.com/apache/cayenne/pull/238
>>>>>> [2] https://issues.apache.org/jira/browse/CAY-2345
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Nikita Timofeev
>>>>>>
>>>>
>>>>
>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cayenne own template renderer to replace Velocity

Mike Kienenberger
Just a note that Velocity 2.0 is finally released.
If I remember right, lots of dependency fixes there too.

On Mon, Aug 14, 2017 at 8:21 AM, Andrus Adamchik <[hidden email]> wrote:

>> If we choose a 'provided' scope, won't that work and be better?
>
> I think it will be worse. Velocity is not like servlet spec jar or something that comes from a container (and less and less ppl are using containers anyways nowadays). The result of making it "provided" will be that our library will no longer work out of the box, forcing the user to actively do something about it. First they will need to realize that Velocity is required in the first place, then they need to figure out which version to use.
>
> Only the users who already have Velocity in their system would care to override the version. And they can either user the exclude, or just import Velocity explicitly, which would take precedence over transient dependency.
>
> Nobody reads the docs these days, things need to work out of the box :)
>
> Andrus
>
>
>> On Aug 14, 2017, at 3:07 PM, Michael Gentry <[hidden email]> wrote:
>>
>> Yes, but that's us kind of forcing a version of Velocity upon our users
>> rather than them choosing the version that works with their environment.
>> Sure, they can do dependency exclusions, etc, in the POM, but that's a
>> slight hassle.  If we choose a 'provided' scope, won't that work and be
>> better?  It'll be up to them to include the version of Velocity they want
>> in their POM and there won't be multiple versions provided, at least not
>> due to us.
>>
>> Thanks,
>>
>> mrg
>>
>>
>> On Mon, Aug 14, 2017 at 7:35 AM, Nikita Timofeev <[hidden email]>
>> wrote:
>>
>>> Cayenne-velocity module should use version of Velocity we specify, the
>>> main point is that cayenne-server won't use it anymore.
>>> As for explicit "compile" scope that's just copy-past, it can be
>>> omitted as it's default anyway.
>>>
>>> On Mon, Aug 14, 2017 at 2:16 PM, Michael Gentry <[hidden email]>
>>> wrote:
>>>> Won't a compile scope pull in a version of Velocity we specify?
>>>>
>>>> https://github.com/apache/cayenne/pull/238/files#diff-
>>> e286320b0b1da27d2621bf787ddd75b1R48
>>>>
>>>>
>>>> On Fri, Aug 11, 2017 at 7:23 AM, Andrus Adamchik <[hidden email]
>>>>
>>>> wrote:
>>>>
>>>>>> I'm assuming the template engine will be injectable
>>>>>
>>>>> Yes, and even better. With module auto-loading, you simply put your
>>>>> template engine jar on classpath, and you get it installed
>>> automatically.
>>>>> This is how backwards-compatible cayenne-velocity will operate.
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>>> On Aug 11, 2017, at 2:21 PM, Michael Gentry <[hidden email]>
>>> wrote:
>>>>>>
>>>>>> I haven't looked into the details, but I like the idea of reducing
>>>>>> dependencies upon external libraries, which can cause headaches with
>>>>>> applications using Cayenne.
>>>>>>
>>>>>> I'm assuming the template engine will be injectable so that you can
>>>>> choose
>>>>>> Velocity, Freemarker, etc if you'd like?  (Of course, you might have
>>> to
>>>>>> create a bridge to your template engine of choice, but be able to
>>> inject
>>>>>> that bridge into Cayenne.)
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> mrg
>>>>>>
>>>>>>
>>>>>> On Thu, Aug 10, 2017 at 5:35 AM, Nikita Timofeev <
>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've opened a PR [1] just now with new SQLTemplateProcessor
>>>>>>> implementation based on new Cayenne own parser (instead of Velocity).
>>>>>>>
>>>>>>> It doesn't support all features of Velocity but it's enough to
>>>>>>> seamlessly replace Velocity in all core and test code in Cayenne,
>>> plus
>>>>>>> it's faster (up to x15 in case of cache hit) and should have less
>>>>>>> memory footprint (though I've only checked speed and memory is my
>>>>>>> guess as new parser smaller and have no runtime).
>>>>>>>
>>>>>>> Plus cayenne-server now free of velocity and commons-lang
>>>>>>> dependencies, next step will be removing of commons-collections (it
>>>>>>> will be the last one).
>>>>>>>
>>>>>>> VelocitySQLTemplateProcessor now comes in optional auto-loaded module
>>>>>>> (cayenne-velocity), so if you relied on some advanced features of
>>>>>>> Velocity in your SQLTemplates you still can use it. And Velocity is
>>>>>>> still used for cgen templates.
>>>>>>>
>>>>>>> See PR [1] and Jira ticket [2] for details.
>>>>>>>
>>>>>>> Any thoughts or concerns?
>>>>>>>
>>>>>>> [1] https://github.com/apache/cayenne/pull/238
>>>>>>> [2] https://issues.apache.org/jira/browse/CAY-2345
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Nikita Timofeev
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Nikita Timofeev
>>>
>
Loading...