freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <>
Subject Re: [FM3] Opinions about the package structure?
Date Fri, 03 Mar 2017 23:15:30 GMT
On Fri, Mar 3, 2017 at 12:54 AM, Daniel Dekany <> wrote:
> Thursday, March 2, 2017, 6:41:35 PM, Woonsan Ko wrote:
>> On Wed, Mar 1, 2017 at 2:09 PM, Daniel Dekany <> wrote:
>>> You can see the current FM3 package structure here:
>>> Some explanation follows.
>>> As it was discussed earlier, FM2 freemarker.core and FM2
>>> freemarker.template were united under org.apache.freemarker.core, and
>>> then to decrease the size of the resulting package, I have moved out
>>> the aspects that don't depend on core internals into their own
>>> subpackages (model, templateresolver, outputformat, etc.). So we have
>>> ended up with a org.apache.freemarker.core that is actually
>>> substantially smaller than FM2 freemarker.core was, also it has
>>> smaller and more focused public API than FM2 freemarker.template has.
>>> The name directly after org.apache.freemarker denotes the module. So
>>> you can see 3 modules from the current package structure: core, dom,
>>> and servlet (which will be freemarker-core.jar, freemarker-dom.jar,
>>> etc., after we have converted to multi module project, but we haven't
>>> yet). There will be more actually, like "test" for common JUnit test
>>> utilities (not a published API), and core-java8 for Java 8 support,
>>> and who know what else.
>>> Any opinions/insights?
>> Looks good to me! Thanks!
> I wonder if freemarker-dom should be separate, or part of
> freemarker-core under o.a.f.core.model.impl.dom. If freemarker-dom is
> separate, then if the user wants to use it, they will have to plug it
> into the DefaultObjectWrapper manually. Something like:

I would prefer separating dom in a separate jar module from the core.

>   new Configuration.Builder(Configuration.VERSION_3_0_0)
>           ...
>           .objectWrapperBuilder(
>                   new DefaultObjectWrapper.Builder(Configuration.VERSION_3_0_0)
>                           .typeHandlers(DomTypeHandler.INSTANCE))
>           ...
> or with Properties syntax:
>   objectWrapper = DefaultObjectWrapper( \
>      3.0.0, \
>      typeHandlers=[ org.apache.freemarker.dom.DomTypeHandler ])
> That's how users could add special treatment for their
> application/domain specific types too (and if we switch to MOP-s, then
> just replace objectWrapper with mopImplementationProvider or whatever
> it will be called). So we are consistent with the idea that
> freemarker-core only contains (and is aware of!) things that are
> related to the core (minimal) functionality. But then, what are the
> practical implications of the users? They get a freemarker-core.jar
> that's a few kilobytes leaner, but in exchange they have to go through
> the above extra configuring if they want to use the DOM wrapping. I'm
> not sure if it worths it... mostly because I don't now how many
> percentage of the users are using DOM wrapping. Certainly it's a
> minority, a few percentages maybe, but it's just a wild guess.

Could we let the core scan classpath resources from all the jar files
(e.g, classpath:META-INF/org/apache/freemarker/core/TypeHandler) and
register those handlers automatically?
Then users will simply need to add extra dependencies such as dom and
they can use it without any custom registration.
I've seen something similar in Apache Camel. For example, when a
custom Camel component is provided by a new jar file in the classpath,
Camel engine automatically detects all the available component by
scanning a dedicated classpath resource path [1], or it even scans all
the type converters from provided jar files at runtime once [2].
If we can apply the same technique, then I guess users wouldn't have
any difficulty. They can simply drop an optional jar files.




> --
> Thanks,
>  Daniel Dekany

View raw message