Re: Looking for contributors as part of Apache incubation

Improving IDE support is a very efficient way of making Freemarker a
better alternative for the users. It's possibly related to how
Freemarer parses for itself, because ideally, the IDE should just use
the real parser. I'm not sure if how feasible that is, though. An IDE
parser need to be incremental, be able to go on after errors to at
least continue syntax highlighting, etc. (Not to mention, that the IDE
should somehow mix an FTL parser with a HTML/CSS parser, or whatever
it is that you write a template for.) Even if it's not feasible to do
in a single parse, it would better if the IDE-centric parser is
maintained at the Freemarker project (in a separate artifact), rather
than each plugin tries to roll its own. (Especially as the FTL parser
has, well, quirks, if you look into the details...) So developing a
common IDE-centric parser would be a big help for plugin authors. And
indeed, I suspect that many other task could be implemented without
depending on a concrete IDE, like outline tree building or
auto-completion.

Seems you are an exceptionally good fit for this, as you have
experience with both major Java IDE-s, and also with parsers. So if
you feel like figuring these out... don't hold yourself back. (;

BTW, another long term goal with the parser is separating the
expression syntax from the "top-level syntax" (as I call it). Thus one
or the other could be replaced.

-- 
Thanks,
 Daniel Dekany


Wednesday, June 3, 2015, 10:46:01 AM, marijan milicevic wrote:

> Hi Daniel,
>
> On Mon, Jun 1, 2015 at 10:00 PM, Daniel Dekany <[email protected]> wrote:
> So, Marijan and Woonasan. I'm especially interested in what Hippo
> needs, what FM features you miss the most there, and what existing
> "features" you hate the most.
>
> Also, if in what topics you feel like contributing to. (Like Woonasan
> has mentioned Spring MVC integration. That would be very useful to
> improve.)
>
> (And again, there will be a TODO list to pick from.)
>
>
> beside number of things Woonsan already mentioned, 
> I would also like  to see better IDE support...
> Currently I am quite familiar with Intellij plugin API and in the past I built Eclipse plugin
> for custom language so I have some experience with Eclipse plugin
> API, although this was long ago...
>
> Other than that, on a personal level, I would be interested to
> learn (and do) more about grammar/parsers/AST building 
> (I see freemarker is using javacc, I have some experience with antlr),
>
>
> cheers,
> marijan
>
>
>  
> --
> Thanks,
>  Daniel Dekany
>
>
> Monday, June 1, 2015, 2:33:52 PM, marijan milicevic wrote:
>
>> Hi Daniel,
>>
>> I would also be interested in contributing..I am (we are) using freemarker
>> extensively and I would really like it to become an Apache project.
>>
>> My apache "handle" is marijan (@apache.org) if you need more information.
>>
>> cheers
>> marijan
>>
>> PS:  I am one of the Woonasan colleagues
>>
>>
>> Daniel Dekany wrote
>>> We are (or mostly, I'm) trying to move FreeMarker over to the Apache
>>> Software Foundation. So far the reaction is mostly positive on
>>> Apache's side, but, the major concern is the low number of active
>>> contributors. If everything goes well, there will be a voting about
>>> letting FreeMarker in into the Apache *Incubator*, where it will have
>>> to build up some kind of community or else it will fail. OTOH the main
>>> reason I want FM to be an Apache project is exactly to improve chances
>>> of finding contributors, especially long term ones like myself.
>>> Obviously, one man (me) is not very safe for the users (like what if
>>> something happens with me, or I just move on).
>>>
>>> So, I just wonder if I can expect anyone to join the incubation when
>>> and if it will be started. There's lot of interesting but difficult
>>> tasks to do. Like better automatic escaping, a new parser that's more
>>> IDE friendly and faster and has better error messages, proper support
>>> of Map-s with non-string keys, better null handling, advanced
>>> white-space removal, better caching, better i18n, supporting custom
>>> "dialects" (i.e., changing the set of built-ins and built-in
>>> directives), public template introspection API, better debugging,
>>> Android support, and many more. It was just a glimpse. There's a lot
>>> of space for advancement.
>>>
>>> --
>>> Best regards,
>>>  Daniel Dekany


------------------------------------------------------------------------------