Re: [CEDET-devel] How to use JDEE's configuration (prj.el) in CEDET/Ede?

[<jo...@ve...>]

Im interested in improving Cedet java support, so if you could put
together a template, i could have a look.

"Eric M. Ludlam" <er...@si...> writes:

>>>> Daniel Clemente <dcl...@ya...> seems to think that:
>>
>>> 1) A java specific implementation of `semantic-tag-include-filename'
>>>    to turn 'org.slf4j.Logger' into 'org/slf4j/Logger.java' (or whatever)
>>
>>  This can be hard because:
>>1. You have to know the classpath in order to search the directories
>>for classes. This is JDEE's work.
>>
>>2. If the source for a tag is inside a .jar, you can't get a file
>>name that points to the .java file inside. You could uncompress that
>>.jar temporarily, or also use an anonymous new buffer.
>>
>>3. Not all classes from the includes have their source code available.
>
> I think you misunderstand what this function needs to do.  For C, if
> it sees:
>
> #include "moose.h"
>
> then the function returns the lisp string:
>
> "moose.h".
>
> which then refers to EDE's include path to see where moose.h might be.
>
> Thus, I would assume that the Java statement:
>
> import org.slf4j.Logger;
>
> would need to return the lisp string
>
> "org/slf4j/Logger.java"
>
> It doesn't need to find it, only report out a string that represents
> fragments of a filename.  The file is then found in various paths
> later in the system.   For example, the EDE project might specify one
> path at "/home/myself/myproj/src" under which the Logger.java file
> exists, and then it could be found.
>
>   [ ... ]
>>  There has to be code to implement semantic-tag-include-filename for java-mode and call jde-find-class-source-file there. But I don't know what package should do it:
>>- Maybe JDEE can always do it; it depends on CEDET anyway
>>- CEDET should probably not do it by default, since CEDET does not depend on JDEE and this is very Java-specific. (Mmm... although more Java functionality from JDEE could also be integrated into CEDET instead of replicated).
>>- or CEDET could use these JDEE functions just inside that new wrapper you spoke about; something like ede-jde-proj.el. I think this is the best.
>
> I would expect this to be simple, such as:
>
> (concat
>   (mapconcat 'identity (split-string (semantic-tag-name tag) ".") "/")
>   ".java")
>
> and would exist in one of CEDET's java support sources.
>
>>> 2) We need some sort of EDE/JDEE integration wrapper, like
>>>    ede-emacs.el perhaps.
>>>
>>
>>  So this would be the first step, since point 1) depends on this.
>>
>>  If I understand correctly, the wrapper defines a normal EDE project but internally loads the prj.el and translates each value from prj.el to values which EDE understands. In fact not all values from prj.el will be needed. The translation could even be bidirectional (values from EDE could be stored in prj.el).
>>  I imagine that EDE could also include wrappers for other project descriptors: a Maven wrapper, ANT wrapper, Eclipse's .project wrapper, ...
>>
>>  I try to learn the theory but I don't have enough practice with JDEE or EDE or eieio to start this. But now I know the next steps to take; thanks for that.
>   [ ... ]
>
> If the JDEE already knows about project roots, the EDE functions will
> be very simple, and just call over.  I can put a template together if
> someone provides some code for asking of there are any JDE projects
> open for a particular directory.
>
> Eric
-- 
Joakim Verona