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? (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
