On Sat, May 20, 2017 at 4:07 AM, Daniel Dekany <ddek...@apache.org> wrote: > Friday, May 19, 2017, 8:59:54 PM, Woonsan Ko wrote: > >> On Fri, May 19, 2017 at 2:22 PM, Daniel Dekany <ddek...@apache.org> 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. 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 <ddek...@apache.org> >>>>>> 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 >