Tuesday, May 30, 2017, 5:02:43 PM, Woonsan Ko wrote: > On Sat, May 20, 2017 at 4:07 AM, Daniel Dekany <[email protected]> wrote: >> Friday, May 19, 2017, 8:59:54 PM, Woonsan Ko wrote: >> >>> On Fri, May 19, 2017 at 2:22 PM, Daniel Dekany <[email protected]> wrote: >>>> Thursday, May 18, 2017, 10:01:23 PM, Michael Brohl wrote: >>>> >>>>> Hi Daniel, >>>>> >>>>> I think these non-Jiraed issues should be created in Jira. Maybe they >>>>> can attract contributors? >>>> >>>> Currently http://freemarker.org/contribute.html is were tasks for >>>> contributors are listed. But those are FM2 issues. Current FM3 issues >>>> are mostly too involved for casual contributors, as it's mostly FM2 >>>> cleanup and refactoring... hence no issues. But the goal is to get to >>>> a point where more "accessible" issues can be produced. (A more >>>> accessible code base is one of the main goals of FM3 after all.) >>>> >>>> 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 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. 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. 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.) > 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
