Re: Continue Eclipse Freemarker DLTK?

Monday, June 10, 2013, 3:46:39 PM, Angelo zerr wrote:

> Hi Daniel,
>
> I have retried my work about Freemarker DLTK with last version of DLTK.
> The good news is that the API of DLTK has a changed a litlle. So it
> was easy to rerun Freemarker DLTK with DLTK 4.0.
>
> I have seen quickly my code and those plugins was based on FM 3.0.0
> and I had changed a lot the Debbuger code to manage DBGP protocol
> (debug protocol supported by DLTK).
>
> I have several questions  : 
>
> 1) Are you really  interested with Freemarker DLTK? To be honest
> with you, I will not really motivated to develop it if nobody test
> and play with it (and it should be fantastic if I find people who help me).

Of course, I will test it. But most of the work that I will have to do
is with improving the living branch (GitHub, 2.3-gae ATM) so that it
will be good for the plugin.

> 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.

> But my big problem is time (as a lot of developpers).
>
> 2) FM 3.0.0?
>
> Is it a good idea to use FM 3.0.0 based on FreeCC if I have understood?

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.

> 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

-- 
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev