Hi David,
David Ponce, who did most of the Java support for CEDET used JDEE, so
while there is a lot of Java customizations for Java, they are only
those needed where the JDEE doesn't follow.
Thus, the answer in the support matrix is that no one has taken the path
you are taking now, and then told me about it.
It should be possible to do what you want with Java at the same level of
support that C++ has, which is pretty good. If you are willing to debug
stuff, and then write some Emacs Lisp code to improve the support for
Java, then yes, it is "easy" to do the features you are looking for.
Some items you list, like navigating a type hierarchy has no generic
CEDET solution, but CEDET certainly could do it, as the CORGE UML
generator shows.
If you browse http://cedet.sourceforge.net/addlang.shtml, Java is
missing EDE support, which would supply a place to provide 'project
local' include directories. This could be in the form of an
ede-cpp-root style project, or perhaps the ede-generic project type can
be adapted. ede-generic is in CVS, but not a part of the CEDET project
yet, due to lack of testing. I don't know if jdee has an EDE adapter or
not.
Once Java can successfully identify and use includes (which will require
understanding the import of something with a * in it.) then the smart
completion should be in good shape.
There was a thread on the cedet-devel mailing list a while back about
the difference between java import and C++ include, but no action was
taken. My guess is those concepts need to be revived and some 'new
thing' may need to be implemented, as import like entries are used in
several other languages.
Anyway, there are others on the cedet-devel mailing list who will likely
help out if you start writing some code.
For me to accept code into CEDET, however, you will need to assign
copyright to the FSF. You can write to copyright-clerk@...
explaining you want to contribute changes to CEDET and emacs and they'll
let you know what to do.
Thanks!
Eric
On 05/26/2010 01:33 PM, David Ventimiglia wrote:
> Hi Eric, and thanks for the reply. Don't worry about "lateness";
> everyone's entitled to a vacation from time to time.
>
> I'm also using JDEE, but I'm interested in also seeing how far CEDET,
> possibly with help from GNU Global, can be taken insofar as providing
> some "killer apps":
>
> * smart completion in uncompiled sources
> * navigation to source definitions
> * navigating a type hierarchy
> * finding usages
> * (less important to me) source refactoring
>
> JDEE provides many (though not all) of these things, and is very nice,
> but it's only for Java. We're a mostly-Java shop (some C/C++ here and
> there), but we've also a lot of stuff written in our own home-grown
> language. CEDET seems to offer a lot of potential for supporting the
> above features for our own language. If/when I get there, it'd be nice
> to have the same features (say, smart completion) work the same way for
> Java; it'd be jarring to use Semantic completion for our own language,
> but then use JDEE completion for Java sources. That's kinda why I've
> been ignoring JDEE in this picture.
>
> I notice that the language support matrix on the web site says that
> completion for Java is partial, that it's for "local structs only". Is
> that up-to-date? How close is Java completion to the maturity of C/C++?
> What would it take to get there?
>
> Thanks!
> Best,
> David
>
>> -----Original Message-----
>> From: Eric M. Ludlam [mailto:eric@...]
>> Sent: Wednesday, May 26, 2010 4:27 AM
>> To: cedet-semantic@...
>> Subject: Re: [cedet-semantic] How to set semanticdb-project-rootsand
>> semantic-java-dependency-system-include-path
>>
>> Hi,
>>
>> Sorry for the late reply.
>>
>> Mostly, I don't know that answer, as I hadn't tried this before. The
>> JDEE folks have had good success combining Emacs, CEDET, and java
>> development, and have a wide range of extra features.
>>
>> If you want to use just Emacs and CEDET, then what you have specified
>> below, of setting the project-roots variable to include 'rootdir' is
>> the
>> right one.
>>
>> For GNU Global, if you run it from 'rootdir', such that you get
>> rootdir/GTAGS, then it will be used in addition to the usual methods
>> for
>> finding tags.
>>
>> Once you start mixing in include paths, things get a little tricky.
>> Project level includes can be set via EDE projects, and there is no
> EDE
>> only project for Java. The JDEE usually deals with that stuff, so I
>> haven't had too, and I don't know what they do to get their features
>> working.
>>
>> You can certainly add some project's include path to the system
> include
>> path. That can work but just isn't as flexible. In that case, there
>> is
>> a configuration that java needs for semantic-tag-include-filename.
>> this
>> function in cedet/semantic/bovine/semantic-java.el basically turns
>> com.foo.Class into "com/foo/Class.java", so if your include path is
>> rootdir/app1, then it will look in rootdir/app1/com/foo.Class.java.
> It
>> should highlight your imports red if this isn't working.
>>
>> On the flip side, this email, plus a couple others provided a bit of
>> inspiration to try and develop a new EDE project that was easier to
>> adapt than the ede-cpp-root project. It doesn't do Java since I don't
>> use Java, but it will be much easier to adapt. It is in
> ede-generic.el
>> in CVS only, and doesn't build by default.
>>
>> Perhaps someone on the list who uses Java can help out adapting this
>> feature to this case? My expectation is that it will be similar to
> the
>> C/C++ case.
>>
>> Eric
>>
>> On 05/18/2010 04:28 PM, David Ventimiglia wrote:
>>> Hi,
>>>
>>> I'm afraid I'm still trying to sort out how best to set up Semantic.
>>> I've had some (but not complete) success using EDE and GNU Global,
>> but I
>>> thought I'd go back to basics and build from there. So, now in my
>> .emacs
>>> file, I'm only doing:
>>>
>>> (require 'cedet)
>>>
>>> (semantic-load-enable-excessive-code-helpers)
>>>
>>> How then in my (mostly) Java project do I set semanticdb-project-
>> roots
>>> and semantic-java-dependency-system-include-path? My project
>> directory
>>> hierarchy looks something like this:
>>>
>>> ../rootdir
>>>
>>> ../app1/src
>>>
>>> ../app2/src
>>>
>>> ../app3/src
>>>
>>> ...etc...
>>>
>>> Where the apps in "app1", "app2", etc., comprise a set of
>> interrelated
>>> source hierarchies, and where the package hierarchies (eg.,
>> com/foo/bar,
>>> etc.) begin below the src directories. Do I set semanticdb-project-
>> roots
>>> to ../rootdir? Or do I set it to a list of ../app1/src, ../app2/src,
>>> etc.? And, what is semantic-java-dependency-system-include-path for?
>>> Right now, I just set it to the source directory where I downloaded
>> the
>>> JDK source files. Is that the correct usage?
>>>
>>> I figure that if I can get this working, then later I can replace
>>> semanticdb-project-roots with an EDE project, and can add in support
>> for
>>> GNU Global.
>>>
>>> Thanks!
>>>
>>> Best,
>>>
>>> David
>>>
>>>
>>>
>>>
> ---------------------------------------------------------------------
>> ---------
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...
>>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>
>>
> -----------------------------------------------------------------------
>> -------
>>
>> _______________________________________________
>> cedet-semantic mailing list
>> cedet-semantic@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
|