On Mon, Jun 19, 2017 at 6:50 AM, Daniel Dekany <[email protected]> wrote: > Monday, June 19, 2017, 7:03:33 AM, Woonsan Ko wrote: > >> On Sat, Jun 3, 2017 at 9:50 AM, Daniel Dekany <[email protected]> wrote: >>> I have created two issues for this. For the non-Web-MVC part: >>> https://issues.apache.org/jira/browse/FREEMARKER-54 >> >> I've opened new PR today. >> In addition to the features described in the JIRA ticket, some minor were >> added: >> - VersionEditor was added in core as Spring allows to set a Version >> property value through a string instead by the PropertyEditor. This is >> convenient in XML bean settings. >> - baseLocation property was added (null by default) in >> SpringResourceTemplateLoader for convenience. If set, baseLocation is >> always prepended to the given template name. For example, when >> baseLocation is set to "classpath:META-INF/templates/", a template by >> name, "foo.ftl", is resolved to >> "classpath:META-INF/templates/foo.ftl". If baseLocation property is >> null, template name must be given as fully qualified resource name >> (e.g, "classpath:META-INF/templates/foo.ftl"). > > Thanks, merged! > > As of logging, I realize just now that we got policy discrepancies > there. What we have now is just FM2 heritage. There we have manually > predefined (and document) log categories; we don't use the class name > of the issuer class. But, FM2 wasn't modular, so it tells nothing > about that. So, what's the more important aspect of > SpringResourceTemplateLoader, for log filtering purposes? That it's in > the freemarker-spring module, or that it's template resolution > related? If the last, then after all your first commit was right to > use the _CoreLogs.TEMPLATE_RESOLVER log category. Or rather, the value > of _SpringLogs.TEMPLATE_RESOLVER should start with > _CoreLogs.TEMPLATE_RESOLVER + ".". But don't change anything for > now... we have no policy for these yet. > > Now, we can find out all kind of logging category policies, but a 3rd > party TemplateLoader certainly won't adhere to that (and BTW that > would require making log category names part of the published API), > and just does what pretty much all Java software nowadays does: use > the class name of the issuer as the log category. So you will miss the > log statements from the 3rd party TemplateLoader if you count on the > category starting with "org.apache.freemarker.templateresolver". So it > can't be counted on anyway. Thus even though FM2 categories are > superior in theory, I thin we should give that up and go with the > flow. It's also easier on contributors. > > What do you think?
IMHO, it should be a lot easier for contributors to follow the most popular convention: "use FQCN of the issuer as the log category". It might be a little bit disadvantageous than FM2's well-organized category grouping, but using the most popular convention might be more helpful in maintenance and participation. Also, we can improve the modularity (e.g, package structure) as a compensation, I guess. Regards, Woonsan > > (As far as we stick to the old ways, instead of _SpringLogs.CORE I > would prefer _SpringLogs.ROOT, because CORE is somewhat reminiscent of > freemarker-core.) > >> Please review the PR, and please let me know if there's anything missed. >> I'll move on to FREEMARKER-55 very soon. >> >> Cheers, >> >> Woonsan >> >>> and the Web MVC part that builds on the first: >>> https://issues.apache.org/jira/browse/FREEMARKER-55 >>> >>> >>> Friday, June 2, 2017, 4:56:38 PM, Woonsan Ko wrote: >>> >>>> On Fri, Jun 2, 2017 at 5:05 AM, Daniel Dekany <[email protected]> wrote: >>>>> Thursday, June 1, 2017, 5:09:07 PM, Woonsan Ko wrote: >>>>> >>>>>> On Wed, May 31, 2017 at 6:39 PM, Daniel Dekany <[email protected]> >>>>>> wrote: >>>>>>> Wednesday, May 31, 2017, 6:09:32 PM, Woonsan Ko wrote: >>>>>>> >>>>>>>> On Tue, May 30, 2017 at 11:38 AM, Daniel Dekany <[email protected]> >>>>>>>> wrote: >>>>>>>>> Tuesday, May 30, 2017, 5:02:43 PM, Woonsan Ko wrote: >>>>>>>> <snip> >>>>>>>>>>>>> Speaking of which, soon there will be one. Anyone is interested >>>>>>>>>>>>> in FM3 >>>>>>>>>>>>> Spring integration? The goal is that FM3's builder-based >>>>>>>>>>>>> configuration >>>>>>>>>>>>> can be used seamlessly for creating the Spring beans. So >>>>>>>>>>>>> certainly a >>>>>>>>>>>>> freemarker-spring module need to be added, which extends some >>>>>>>>>>>>> classes >>>>>>>>>>>>> to implement FactoryBean interface and such. Also some >>>>>>>>>>>>> configuration >>>>>>>>>>>>> defaults, like the TemplateLoader need to be different for sure, >>>>>>>>>>>>> and >>>>>>>>>>>>> we need a TemplateLoader that uses Spring's Resource API. (I will >>>>>>>>>>>>> create an issue for it after I have polished the configuration >>>>>>>>>>>>> API a >>>>>>>>>>>>> bit more.) >>>>>>>>>>>> >>>>>>>>>>>> Yes, I am interested in FM3 spring integration. >>>>>>>>>>>> One question is, are we going to replace spring framework's default >>>>>>>>>>>> freemarker view support [1] by freemarker-spring in FM3? >>>>>>>>>>> >>>>>>>>>>> That would be the idea. And that will be the only possibility at the >>>>>>>>>>> beginning, as they only have FM2 support (and I guess contributing >>>>>>>>>>> to >>>>>>>>>>> ASF/FM makes more sense than contributing to them). >>>>>>>>>> >>>>>>>>>> OK, got it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Anyway, I'll happily help with this as soon as you create an issue. >>>>>>>>>>> >>>>>>>>>>> Great! That will happen in a few days. >>>>>>>>>> >>>>>>>>>> I will try to list features of spring framework support for >>>>>>>>>> compatibility and other possible new features and improvements first. >>>>>>>>>> And, I'll try to discuss those items here soon. >>>>>>>>> >>>>>>>>> Sounds good. >>>>>>>> >>>>>>>> I've reviewed spring online documentation and tried to list all the >>>>>>>> features currently supported. We'll probably need to provide >>>>>>>> compatible solutions or alternatives for FM3. I added some notes on >>>>>>>> some items, too. Prioritization wasn't considered yet. >>>>>>>> >>>>>>>> ----- >>>>>>>> >>>>>>>> 1. Configuration support >>>>>>>> >>>>>>>> 1.1. Generic Configuration Factory bean support (that can be used for >>>>>>>> non web-apps) >>>>>>>> - FreeMarkerConfigurationFactoryBean >>>>>>>> - Note: perhaps the builder should be used internally inside the >>>>>>>> factory bean? >>>>>>> >>>>>>> The FactoryBean should extend Configuration.ExtenableBuilder. So it's >>>>>>> not even some internal stuff; ExtenableBuilder is public and was added >>>>>>> for things like this. >>>>>>> >>>>>>>> 1.2. Web MVC Configurer bean support >>>>>>>> - FreeMarkerConfigurer >>>>>>> >>>>>>> Ah that... whole thing. It's really confusing. It starts there that >>>>>>> it's hard to grasp for the user what a FreeMarkerConfigurer really is. >>>>>>> Because, we already have Configuration, and even a Spring-specific >>>>>>> class, FreeMarkerConfigurationFactoryBean that creates that. To >>>>>>> configure FreeMarker you need a Configuration, so a Configuration is >>>>>>> the real "FreeMarker configurer". But the "FreeMarkerConfigurer" name >>>>>>> suggests the same ("I configure FreeMarker"). So how is it different? >>>>>>> To make it more confusing, it's basically >>>>>>> FreeMarkerConfigurationFactoryBean (which is just a Configuration >>>>>>> Builder) with a few quirks: >>>>>>> >>>>>>> - It's technically not a FactoryBean. So instead of relying on Spring >>>>>>> IoC >>>>>>> injection as usual, the dependent bean (FreeMarkerViewResolver >>>>>>> usually) has to call getConfiguration() on it. >>>>>>> >>>>>>> - getConfiguration() might returns a Configuration that wasn't built by >>>>>>> the FreeMarkerConfigurer! If you call setConfiguration(Configuration), >>>>>>> then that Configuration will be returned, and things you set on >>>>>>> FreeMarkerConfigurer (which is a Configuration Builder) doesn't >>>>>>> mater. Anyway, you would (or just I would?) think that if you want >>>>>>> the Web View stuff to use a specific Configuration, then you just >>>>>>> inject >>>>>>> that Configuration bean into FreeMarkerViewResolver. But no, because >>>>>>> FreeMarkerViewResolver needs a FreeMarkerConfigurer. In fact, >>>>>>> FreeMarkerViewResolver doesn't need that directly. Instead, it just >>>>>>> specifies a class, FreeMarkerView, which in turn "manually" looks up >>>>>>> the FreeMarkerConfigurer bean with BeanFactoryUtils. >>>>>>> >>>>>>> - It provides a TaglibFactory object as well. I have to give that to >>>>>>> it, as that's at least something that Configuration doesn't do. But >>>>>>> if that will be the only obstacle of getting rid of >>>>>>> FreeMarkerConfigurer, then we stuff that into the Configuration, >>>>>>> like as a custom attribute (custom setting, if I have renamed it as >>>>>>> discussed), and as a real JavaBean property in our ExtenableBuilder >>>>>>> subclass. >>>>>>> >>>>>>> BTW Velocity support have the same hard to follow logic. Maybe it's >>>>>>> necessary, I don't know. Still, I wonder if we can make it more >>>>>>> elegant and less confusing for users. (Is it nicer with Thymeleaf for >>>>>>> example?) What I'm hoping for is that we can just use a Configuration >>>>>>> bean instead, and FreeMarkerView looks that up. The tricky part is how >>>>>>> to differentiate that bean from the other Configuration beans. The >>>>>>> natural solution is using a "web" qualifier, which is easy to follow >>>>>>> for the user as well (no magic, it's obvious how it works). But some >>>>>>> may feel it's not very stream lined (because I believe we can't >>>>>>> transparently make a bean qualified, so the user has to add it to its >>>>>>> configuration). So another possibility is subclassing Configuration, >>>>>>> so then we first look for a WebConfiguration (and then of course we >>>>>>> will also need a FreeMarkerWebConfigurationFactoryBean - note the >>>>>>> "Web" in it), and only if that's not found we look for "web" qualified >>>>>>> Configuration. But maybe all this is too different from Spring >>>>>>> tradition... I'm just thinking aloud. >>>>>> >>>>>> I will look into it further. But in general, the current >>>>>> FreeMarkerConfigurer based configuration looks confusing to me, and as >>>>>> you pointed out it's not even a FactoryBean and it's found out by the >>>>>> view resolver, etc. I feel like it could be neater. Let me investigate >>>>>> other things further and come back. >>>>>> >>>>>>> >>>>>>> BTW, I believe e-mail generation and other miscellaneous FreeMarker >>>>>>> applications (report generation, etc.) will be at least as important >>>>>>> as web pages nowadays. >>>>>> >>>>>> +1 >>>>>> >>>>>>> >>>>>>>> and FreeMarkerViewResolver (basically extending UrlBasedViewResolver) >>>>>>>> - Note: the view resolver finds out the configurer bean by type by >>>>>>>> default. >>>>>>> >>>>>>> Well, if we stick to the approach with FreeMarkerConfigurer and all >>>>>>> that, the it's good enough. Otherwise see above. >>>>>>> >>>>>>>> Seems good enough for normal web application to me. Same >>>>>>>> pattern in the configurer by using builder internally? >>>>>>> >>>>>>> (The builders aren't meant to be internal, but it's the same as >>>>>>> earlier.) >>>>>>> >>>>>>>> 1.3. Annotation / XML Schema based configuration support >>>>>>>> (FreeMarkerConfigurer type bean) >>>>>>>> - Note: ViewResolverRegistry#freemarker() finds a bean by exact type >>>>>>>> of FreeMarkerConfigurer. alternative? >>>>>>> >>>>>>> What can we do about this at all? I mean, we can't add methods to this >>>>>>> class. >>>>>> >>>>>> Yeah. We may lose @EnableWebMvc feature since it seems tightly coupled >>>>>> with FreeMarkerConfigurer. Indeed, ViewResolverRegistry is created in >>>>>> a hard-coded way directly by WebMvcConfigurationSupport. >>>>> >>>>> Yet again, it might worth checking out what the Thymeleaf guys did, as >>>>> they focus heavily on Spring integration. >>>> >>>> OK. That sounds right. I'll take a look at how they do. >>>> >>>>> >>>>>>> >>>>>>>> (ref: >>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mvc-config-view-resolvers) >>>>>>>> >>>>>>>> 1.4. XML Schema based configuration support >>>>>>>> - Note: alternative for this? >>>>>>>> <mvc:view-resolvers> >>>>>>>> <!-- SNIP --> >>>>>>>> <mvc:freemarker cache="false"/> >>>>>>>> </mvc:view-resolvers> >>>>>>> >>>>>>> XML config is low priority, I guess. >>>>>> >>>>>> +1 >>>>>> >>>>>>> >>>>>>>> 2. View Resolution support >>>>>>>> - FreeMarkerViewResolver and FreeMarkerView >>>>>>>> >>>>>>>> 3. Tempplating Support >>>>>>>> >>>>>>>> 3.1. JSP Tag Libraries support >>>>>>>> - Spring / Spring form tag libraries and Spring binding macro >>>>>>>> support. >>>>>>>> - Note: It looks like spring macros (spring.ftl) are duplicate >>>>>>>> effort to the JSTL tag libraries, so I'm wondering if the macros were >>>>>>>> originally introduced before freemarker JSTL tag library support >>>>>>>> wasn't there or wasn't good enough. If so, perhaps can we stick to >>>>>>>> using JSTL tag libraries directly without having to rewrite/provide >>>>>>>> the macros? >>>>>>>> Or would it bring huge disruption in spring-mvc/freemarker >>>>>>>> community? >>>>>>>> Need to validate it more... >>>>>>> >>>>>>> So I guess that's where my domain knowledge ends. Which JSTL tags are >>>>>>> these? The Spring macros I have seen in SO questions and such call >>>>>>> Spring-specific functionality, not JSTL... or I just don't know what >>>>>>> JSTL can do. (Basic JSTL tags/functions are often duplicates core >>>>>>> FreeMarker functionality, like c:if, c:forEach, etc.) BTW, many JSTL >>>>>>> tags actually don't work with FreeMarker JSP support (I remember we >>>>>>> have a test case on @Ignore which demonstrates that). Pretty much only >>>>>>> traditional custom JSP tags do. >>>>>> >>>>>> I'm sorry for my confusion. I should have used (spring custom) "JSP >>>>>> tags", not "JSTL tags". >>>>>> >>>>>> Examples of "duplicate efforts" to me: >>>>>> - In Spring JSP Taglibs >>>>>> (https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-tld.html), >>>>>> it has 'message' tag. >>>>>> In spring.ftl, it also has 'message' macro and variants >>>>>> ('messageArgs', 'messageArgsText', ...). >>>>>> Perhaps there is a little to help with the macros, but developers >>>>>> can use jsp tag lib in ftl directly. >>>>>> - In Spring Form Taglibs >>>>>> (https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html), >>>>>> it has 'checkboxes' tag. >>>>>> spring.ftl defines macros too for the same functionality. >>>>>> >>>>>> So, I'm thinking if we can stick with JSP taglibs only, then we might >>>>>> not need to support those macros separately. >>>>> >>>>> I hope (but haven't checked) that Spring has a >>>>> view-technology-independent layer of this, and then the JSP custom >>>>> tags (and FreeMarker macros) are just adapting that to the conventions >>>> >>>> Ah, yes. That's something to check. Good point. >>>> >>>>> of the view technology (JSP, FTL). My concern with simply solving it >>>>> with yet another adapter layer (FTL to JSP) is that the logic of at >>>>> least some of these JSP tags is foreign from (modern) FTL. And the >>>>> same certainly goes for other view technologies as well (here again >>>>> it's might be a good idea to look what they did at Thymeleaf). >>>> >>>> OK. >>>> >>>>> >>>>> Let's take spring:message for example. Why's this a tag at all? It's >>>>> function, or even just a hash. If I had to expose such functionality >>>>> to FTL-s, it would look like `${messages.hello}` and >>>>> `${messages.hello(userName)}` and `${messages.hello(arg1, arg2, >>>>> argN)}`. This also means that you can pass a resolved message as an >>>>> argument to another macro/function: `<@foo messages.hello(userName)>`. >>>>> And what's up with the escaping parameters? Because normally HTML >>>>> autoescaping is ideally on, users has to do nothing to escape, and >>>>> they can write ${messages.thisIsAlreadyHTML?noEsc} otherwise. We >>>>> leverage core FTL functionality here, not need for any extra >>>>> `messages` parameter for that. (Not to mention that in general it's >>>>> not good that the user who inserts the message has to know if it's >>>>> already HTML or not. I mean they can't decide it there, because it's >>>>> already either HTML or plain text in the message data source. So, >>>>> `messages` should know that (the data source should store that >>>>> meta-information somehow). Then, `message.foo` returns an FTL String >>>>> if `foo` is plain text, and FTL HTML markup-output if `foo` is HTML >>>>> message, hence there's no need for ?noEsc in the last case, as >>>>> FreeMarker knows that it needs no further escaping. >>>>> >>>>> In the future we might run into other cases where we can't utilize FTL >>>>> features because the JSP obviously doesn't do that, and hence they >>>>> have duplicated it, or just don't have it. >>>>> >>>>> There are also cases of the opposite of it, i.e., where JSP can do >>>>> something that we can't, or at least it ugly and not idiomatic. Take >>>>> for example the `var` and `scope` attributes of the spring:messages >>>>> tag. Well, FTL has no out-parameters, nor scopes (even if the >>>>> FreemarkerServlet data-model emulates the last to an extent). But if >>>>> we solve this functionality with a function, as we should anyway (see >>>>> above), we return that thing, so we don't need an out-param. If >>>>> instead we just call spring:message with the JSP custom tag support of >>>>> FreeMarker, it won't magically transform it to a function. >>>> >>>> Good point! Sound better with extra ftl macros, not depending only on JSP >>>> tags. >>>> >>>>> >>>>>>>> 3.2. HTML escaping and XHTML compliance?? >>>>>>>> - ref: >>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#views-form-macros-html-escaping, >>>>>>>> >>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/spring-form-tld.html >>>>>>>> >>>>>>>> - Note: If we stick with JSTL tags without any extra macros (3.1), I >>>>>>>> guess we won't need this special variable settings for escaping any >>>>>>>> more.. >>>>>>> >>>>>>> So this is about how Spring (or you are saying, JSTL?) generated HTML >>>>>>> fragments use escaping internally. >>>>>> >>>>>> Sorry again, I should have said 'spring jsp tag libraries' instead. >>>>>> For example, the 'message' tag already has 'htmlEscape' attribute. So, >>>>>> when using the tag, ftl can use that attribute directly. >>>>>> By the way, 'htmlEscape' spring jsp tag wouldn't be used in .ftl, >>>>>> practically speaking as FM provides a better support. >>>>> >>>>> Yip. >>>>> >>>>>>>> 4. Testing support >>>>>>>> - ref: >>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#spring-mvc-test-server-htmlunit >>>>>>>> - Note: Make sure it works... >>>>>>>> >>>>>>>> 5. Micellaneous >>>>>>>> >>>>>>>> 5.1. Sending E-Mail support >>>>>>>> - ref: >>>>>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#mail-templates-example >>>>>>>> - Note: might be a low-hanging fruit by giving an example with >>>>>>>> freemarker instead... >>>>>>> >>>>>>> Yeah... especially if they will ever switch to freaking post-2.3.23 >>>>>>> FreeMarker (they don't upgrade since we are incubating...), because >>>>>>> auto-escaping is missing from that example, and 2.3.24 does it much >>>>>>> better than 2.3.23. >>>>>>> >>>>>>>> ----- >>>>>>>> >>>>>>>> Personally, I wish to have the following in the future too: >>>>>>>> >>>>>>>> 6. More wishes >>>>>>>> >>>>>>>> 6.1. Generic FreeMarker Configuration Factory with JSTL support >>>>>>>> - I have an HMVC web application framework which uses spring >>>>>>>> framework as IoC, not MVC and Freemarker as view templating, but it >>>>>>>> needs to support JSTL tag libraries. So far I have dispatched requests >>>>>>>> to Freemarker servlet. I wish to configure a configuration factory and >>>>>>>> use the service somehow directly without having to use request >>>>>>>> dispatching any more... >>>>>>> >>>>>>> Not sure I follow, but isn't this using JSP support without >>>>>>> FreemarkerServlet? It's not well documented, but possible, like Spring >>>>>>> MVC does that too. >>>>>> >>>>>> Oh yeah? >>>>> >>>>> I'm not entirely sure... It think so as FreeMarkerConfigurer stores a >>>>> TaglibFactory. >>>> >>>> Yeah, I think I took a glance at that. Will look into it further. >>>> >>>> After studying how Thymeleaf guys do further, I can probably share better >>>> ideas. >>>> >>>> Regards, >>>> >>>> Woonsan >>>> >>>>> >>>>>> That's good then. I'll try it later. >>>>> >>>>>> Thanks for all your input! I'll look into more detail and discuss >>>>>> further later. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Woonsan >>>>>> >>>>>>> >>>>>>>> ----- >>>>>>>> >>>>>>>> Folks, if you have experienced with spring + freemarker, please >>>>>>>> review/correct my understandings and chime in here. >>>>>>>> Also, it is probably a good time to speak up if you wish to have in >>>>>>>> the future. ;-) >>>>>>>> >>>>>>>>> >>>>>>>>> I was a bit boggled down with the configuration API polishing, so I >>>>>>>>> haven't yet made the Jira issue. But I belive there's enough things to >>>>>>>>> do with the Spring integration before that becomes a problem. Things >>>>>>>>> will keep changing under it anyway. But that's just how refactoring >>>>>>>>> goes, and the same will happen again and again with freemarker-dom and >>>>>>>>> freemarker-servlet too. >>>>>>>> >>>>>>>> Yes, I think this spring framework support could be started in >>>>>>>> separate feature branch(es). >>>>>>>> I guess the most important ones from the list above are 1.1, 1.2, 2, >>>>>>>> and 3.1. >>>>>>>> Perhaps I can start working for those 4 items first in my github >>>>>>>> branch to merge it later. >>>>>>>> If there are other people who want to contribute to any of those, we >>>>>>>> can consider a shared feature branch instead... >>>>>>>> >>>>>>>>> >>>>>>>>> The goal would be not using the setSetting(String, String) API when >>>>>>>>> configuring under Spring, and work with beans and bean properties >>>>>>>>> cleanly. Ideally, only the builder classes need to be subclassed to >>>>>>>>> add some Spring annotations/interfaces and Spring-specific defaults. >>>>>>>> >>>>>>>> I see. And I saw your builder class is really extensible. That's great! >>>>>>>> >>>>>>>>> >>>>>>>>> One thing that I will surely want to do in FM3 is allowing mixed >>>>>>>>> positional and named parameters in templates, like `f(1, 2, foo=3, >>>>>>>>> bar=4)` or `<@m 1, 2 foo=3 bar=4/>`. That's probably good to know when >>>>>>>>> it comes to calling Spring features from templates. (Of course this >>>>>>>>> will require replacing TemplateMethodModel and TemplateDirectiveModel >>>>>>>>> etc. with something better. Cleaning up the mess around the callable >>>>>>>>> objects is part of FM3 anyway.) >>>>>>>> >>>>>>>> Sounds good. I haven't found a good example of 'calling Spring >>>>>>>> features from templates' yet though. Maybe I'm missing something >>>>>>>> important... >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Woonsan >>>>>>>> >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Woonsan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Woonsan >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> https://docs.spring.io/spring/docs/current/spring-framework-reference/html/view.html#view-velocity-contextconfig >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Michael Brohl >>>>>>>>>>>>>> ecomify GmbH >>>>>>>>>>>>>> www.ecomify.de >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 17.05.17 um 14:29 schrieb Daniel Dekany: >>>>>>>>>>>>>>> Wednesday, May 17, 2017, 2:26:29 AM, Taher Alkhateeb wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yeah I closed it because it was a proposal for a PoC which you >>>>>>>>>>>>>>>> pretty much >>>>>>>>>>>>>>>> got done while I slacked :) Should I re-open? If yes then >>>>>>>>>>>>>>>> perhaps it should >>>>>>>>>>>>>>>> be renamed by removing the "PoC" part? >>>>>>>>>>>>>>> No, then it was right to close it after all. You can create an >>>>>>>>>>>>>>> issue >>>>>>>>>>>>>>> for resolving the TODO-s and polishing the stuff it you think, >>>>>>>>>>>>>>> though >>>>>>>>>>>>>>> honestly FM3 has tons and tons of non-Jiraed things to do... >>>>>>>>>>>>>>> What >>>>>>>>>>>>>>> really counts if someone is interested in actually working on >>>>>>>>>>>>>>> them. >>>>>>>>>>>>>>> (I'm not saying this to point at you or anyone. It's unpaid >>>>>>>>>>>>>>> work etc., >>>>>>>>>>>>>>> and if the project can't attract contributors, it's the fault >>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>> project and of its key persons, like me. The aspect that >>>>>>>>>>>>>>> concerns me >>>>>>>>>>>>>>> is that if I do all the technical stuff, even if I was some >>>>>>>>>>>>>>> kind of >>>>>>>>>>>>>>> superhuman one man army (and BTW I'm not) who can grind through >>>>>>>>>>>>>>> everything in time regardless, that will be a serious problem >>>>>>>>>>>>>>> when it >>>>>>>>>>>>>>> comes to Apache incubation voting...) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, May 16, 2017 at 11:10 PM, Daniel Dekany >>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I saw the Jira issue for migrating to Gradle was closed, but >>>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>>> clear it's far from done. Like, a major TODO is building the >>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>> artifacts; the root project should do that (or should that be >>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>> another sub-project instead?). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The second most important deficiency is producing all the 3 >>>>>>>>>>>>>>>>> Maven >>>>>>>>>>>>>>>>> artifacts for each published module (the usual artifact plus >>>>>>>>>>>>>>>>> src and >>>>>>>>>>>>>>>>> javadoc). Currently we only produce one artifact per module, >>>>>>>>>>>>>>>>> and it's >>>>>>>>>>>>>>>>> not even signed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> BTW, I have factored out Manual generation into >>>>>>>>>>>>>>>>> freemarker-manual >>>>>>>>>>>>>>>>> (non-published module). There's also a TODO there as its >>>>>>>>>>>>>>>>> build doesn't >>>>>>>>>>>>>>>>> produce anything yet. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Daniel Dekany >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Daniel Dekany >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Thanks, >>>>>>>>>>> Daniel Dekany >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thanks, >>>>>>>>> Daniel Dekany >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Daniel Dekany >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Daniel Dekany >>>>> >>>> >>> >>> -- >>> Thanks, >>> Daniel Dekany >>> >> > > -- > Thanks, > Daniel Dekany >
