We had this problem with all modules but freemarker-core, where the
actual Javadoc content inherited from other modules aren't shown.
Also, links to classes in other modules weren't translated to HTML
links. So I have added an `aggregateJavadoc` task to the root project
to fix this. That's how uses will see the JavaDoc of freemarker-spring
and others. If we agree in that.
BTW, JavaDoc comments that only contain {@inheridoc} do nothing, as
inheriting is the default behavior of Javadoc.
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").
>
> 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
