[
https://issues.apache.org/jira/browse/VELTOOLS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823969#comment-16823969
]
Claude Brisson commented on VELTOOLS-180:
-----------------------------------------
Not by themselves. They are mostly thin exception catching wrappers, plus an
uberspector.
Sorry, here's another long post.
I don't mind either publishing the ORM elsewhere, I already created recently a
[webapp-velocity-tools|https://github.com/arkanovicz/velocity-tools-webapp]
project for stuff that looked too far away from templating preoccupations like
authentication filters. Everything can land here.
But I was under the impression that in a lightweight framework-free bottom-up
pull MVC approach, proposing a configurable minimalistic ORM is the next
logical step after the view tools, and that it could dynamize the tools.
The engine subproject is slowly recovering from hibernation, looks like Java
templating still has some pertinence. But the tools subproject did not get all
the attention it deserves, IMO. Here is the count of reverse dependencies on
mvnrepository.com (internal dependencies filtered out) :
||Module||Version||Reverse dependencies count||
|velocity-engine-core|1.7|996|
| |2.0|90|
| |2.1|2 (well it just got out)|
|velocity-engine-scripting|2.0|4|
| |2.1|0|
|velocity-tools|2.0|199 (gen+view+struts)|
|velocity-tools-generic|3.0|0|
|velocity-tools-view|3.0|0|
|velocity-tools-view-jsp|3.0|0|
Introducing a model tool beside the last ones could give some momentum to the
tools tribe. But how to do this without introducing an external dependency or
binding the ORM itself to the templating ? That doesn't seem quite feasible.
Your question made me think of another option, which is to host the ORM as a
new velocity-model subproject. This implies:
- either a change of perspective for the Velocity project itself, which would
from now on propose some MVC's M stuff together with its V stuff, both of them
staying independent.
- either to state upfront that velocity-model *isn't* related to templating but
just grew here and may move elsewhere.
That's the only proper way of doing things *if* we want a velocity-tools-model
with just the VTL-related objects.
Otherwise, let's us just forget it. I'll just publish everything elsewhere and
maybe make another project proposal at the ASF one day if some people are
motivated to do so with me.
> New velocity-tools-model architecture
> -------------------------------------
>
> Key: VELTOOLS-180
> URL: https://issues.apache.org/jira/browse/VELTOOLS-180
> Project: Velocity Tools
> Issue Type: New Feature
> Components: Misc
> Affects Versions: 3.1
> Reporter: Claude Brisson
> Assignee: Claude Brisson
> Priority: Major
>
> The new data access layer (or persistence-less ORM) module that constitutes
> the Model Tool, and which once was the
> [Velosurf|https://github.com/arkanovicz/velosurf] library but rewritten at
> 90%, sits in the [model
> branch|http://svn.apache.org/viewvc/velocity/tools/branches/model/velocity-tools-model/].
> But I started having second thoughts while coding. If you look at [this class
> diagram|https://republicate.com/class_diagram.svg], you'll see that there are
> only 5/6 objects that will appear in VTL contexts. The remaining of the
> library is about 40 classes, and offers by itself an ORM which I tried to
> keep simple and efficient also on the Java side.
> So I'm starting to think that I should just publish here the VTL related
> objects and host the ORM library elsewhere. It's more in the spirit of
> VelocityTools to keep things lightweight, and separate projects are the best
> guaranty of code isolation.
> For instance, I can publish it along with other projects that I publish on
> maven central in the com.republicate group id, like the
> [webapp-slf4j-logger|https://github.com/arkanovicz/webapp-slf4j-logger].
> It makes velocity-tools-model rely on a project external to apache, but it's
> not a problem per se. Or the ORM library can find its way to the apache
> codebase through, like, a commons-model project. Or start at com.republicate
> and then migrate. Or start here then migrate elsewhere...
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
