Re: Continue Eclipse Freemarker DLTK?

Hi,

Anything with this since then? Last time we were there that it should
be checked if what changes are needed in the current branch of
FreeMarker for it become usable with the DLTK plugin. I know, I could
check that too... it's that I have too much on my plate regarding
FreeMarker already. Lot of core stuff, and I don't think that anybody
can solve them in the foreseeable future but me. OTOH there are
several other critical things for FreeMarker that's much easier to
jump into, and they also need some specific experience that I happen
not to posses (much...):

- Better Eclipse IDE. (I have used the JBoss Tools stuff nowadays, and
  it's not in a good shape at all.)

- Spring integration should be checked by someone. Framework authors
  often just throw in FM, together with Velocity, because it's the
  standard checklist thing to support template engines, and end of
  story. So from the viewpoint of the user it will simply mean that
  FreeMarker sucks.

- Struts integration too.

- Better JSP support. The biggest issue with the current one is that it's
  part of the FreemarkerServlet. People often want to call FreeMarker
  by other means. FreemarkerServlet is rather limiting and ugly anyway...

Anyway... my current priorities are (in the order I plan to do them):

- Fixing overloaded method selection and numerical conversions on method
  calls. This is in progress.

- Allow more configurability with the String-based settings API (as
  this is what most frameworks use in their own configuration XML-s).
  Without this the overloaded method fixes can't be activated...

- Adding stepping to the debug API

- Adding #p and some other advancement in formatting.

But meanwhile if something blocks the DLTK plugin development, I will
try to act quickly.

-- 
Thanks,
 Daniel Dekany


Tuesday, June 11, 2013, 2:11:41 PM, Angelo zerr wrote:

> Hi Greg, Daniel,
>
>> Do you think you could rehost your DLTK plugins onto github?  That will make it easier to collaborate.  
> Sure!
>
> I have pushed Freemarker DLTK on GitHub
> https://github.com/angelozerr/Freemarker-Eclipse-DLTK
> It works with last version of DLTK 4.0 (current is 5.0).
>
> I have written a short dev-guide
> https://github.com/angelozerr/Freemarker-Eclipse-DLTK/wiki/Developer-Guide which explains how to launch it.
> For the features, please read for the moment 
> https://freemarker.svn.sourceforge.net/svnroot/freemarker/sandbox/org.eclipse.dltk.freemarker/docs/
>
> I add you as colaborator in my GitHub project. So I think you can push it.
> @Daniel, if you are interested, I can add you too.
>
>> Then I can install DLTK dependencies in my environment and try to import them in.  
> No needs to install DLTK with classic mean. Just set the Target
> Platform (see explanation at 
> https://github.com/angelozerr/Freemarker-Eclipse-DLTK/wiki/Developer-Guide)
> I like this idea about using Target Platform, because you can
> switch to another version of DLTK without installing it in your Eclipse.
>
>> Which part of the features of the current DLTK editor require FM3.0 and which can work on 2.3?  
> My work doesn't work with FM 2.3 because FM3.0 changes package name
> for instance. But I think it will be easy to switch to 2.3
> the only thing is to create some patches because debugger should be improved.
>
>> If you are interested I could create a GitHub project in my GitHub https://github.com/angelozerr
>
> That's good, I prefer that over sf.net SVN.
>
> Ok, it's done.  https://github.com/angelozerr/Freemarker-Eclipse-DLTK
>  
>
> The FM 3 branch you are talking about (the sf.net SVN trunk) is
> "officially" dead for a long time, and it wont ever yield a release.
> So in theory, you had to build on what's on GitHub (use the "2.3-gae"
> branch now). Of course, 2.3 has virtually no public AST API, so you
> can't use that either. (And I guess some other things will be missing
> too. Can you tell me what?) So for now you will have to work against
> FM 3.
>
> As of what will it work on then when it's released... The AST stuff
> changes will break BC too much for a 2.3 (I guess), so it will have to
> be FM 2.4. But if it's 2.4.0, then of course I will want to put in
> some other minor not-strictly-BC changes too (not to mention new
> features that somehow justifies in the eyes of the average uses the
> 2nd version increase). I will be careful not to be too ambitious with
> it, as I don't want to impede the release of the plugin, or undermine
> the trust on the release of the new 2.4 branch. So as you see, there
> are some difficulties, but if you are going to work on the plugin, I
> will try very hard to clear its way.
>
> I will try to migrate to 2.3 to see if they are a lot of modification to do.
>
>> 3) DBGP Debugger
>>
>> Existing code of Debugger should be modified to support several
>> implementation of Debugger (RMI, DBGP, etc). So I think it's the
>> first step if we decide to develop Freemarker DLTK.
>
> (I see the discussion about that with Greg Amerson has been started .)
>
>> Regards Angelo
> Regards Angelo 
>
> --
> Thanks,
>  Daniel Dekany


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk