[
https://issues.apache.org/jira/browse/VELTOOLS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude Brisson updated VELTOOLS-180:
------------------------------------
Description:
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...
was:
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...
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 other projects that I publish on maven
central in the com.republicate group id, like
[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...
> 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]
