CEDET

Hi David,

   You have a tendency to ask hard questions I can't readily answer.  Of 
the many you asked recently, I'll focus on this one.  Due to many 
questions on the topic, I started a ede/java-root project to mimic what 
cpp-root does for C, and includes the classpath as a setting.  Hopefully 
I can get it tested and post it sometime soon.

   To describe the relationship between the java support files, I 
started with the android project type, because that's what I was 
learning at the time.  There are many kinds of Java projects, so I 
wanted to make sure that if a new project type was created, (such as 
ede/java-root) it could lean on the work that came before.

   Thus the cedet-java file is as you have noticed, just some utilities 
for calling java functions.  Db-javap is, of course, a generic way to 
create Semantic symbol tables from java Jar files, or from directories.

   You are right about the semanticdb-javap-classpath being left-overs 
from development.  It could probably be deleted, or added to 
semanticdb-javap-classpath-objects.

   Finally back to android.  The android project needs to point at the 
android java jar file (thus the method you discuss below.)  That will 
use both the default java utilities, and the android utilities, both 
defined as cedet-java or cedet-android, which are just utils for calling 
external programs.

The best place to have a classpath is via EDE, but that only works if 
you have a good project.  You can use cedet-java-classpath-extension 
too.  I haven't tried setting up a project like this, but I think others 
have done so successfully.

You can mostly ignore cedet-java.el, except apparently for the classpath 
extension.  You can also use it to check version numbers of your JDK.  I 
think long term it would be nice if this file allowed users to 
investigate their java environment, and check for compatibility problems.

I don't know the answer to the other completion questions you asked. 
When I was working on Android I know I had completion situations similar 
to what you describe that worked ok for me.  What needs to happen is for 
some robust generic java project type to be created so that some serious 
tests can be written against java that includes the system jar files. 
Perhaps java-root will enable that.  The current java tests are forced 
to complete only on locally defined symbols, which means we can't lock 
down behaviors against jar files similar to the problem you described.

Eric

On 05/31/2012 12:02 AM, David Ventimiglia wrote:
> Hi,
>
> What is the relationship between cedet-java.el, android.el, and
> db-javap.el?  My observations so far:
>
>     * cedet-java.el defines variables for the classpath, the javap
>       command, etc., and defines methods for calling javap.
>     * db-javap.el in turn calls cedet-java.el's cedet-javap-get-class.
>     * db-javap.el gets used by Semantic, via an override of
>       semanticdb-find-table-for-include in db-javap.el
>     * db-javap.el also defines its own semanticdb-javap-classpath.
>     * But then db-javap.el seems not to use that
>       semanticdb-javap-classpath in semanticdb-javap-classpath-objects
>     * Instead, semanticdb-javap-classpath-objects uses just the EDE
>       project's ede-java-classpath method.
>     * android.el defines an ede-javap-classpath method to its EDE project.
>
> I think I see some patterns here.
>
>     * android.el defines an EDE project type for Android projects (A
>       Java EDE project type probably would look similar).
>     * cedet-android.el defines helper functions for Android projects,
>       but isn't directly related to EDE or Semantic.
>     * Semantic/SemanticDB gets tags for JAR files from db-javap.el,
>       which uses helper functions in cedet-java.el.
>
> Some specific questions I have are:
>
>    1. Where should I set my classpath?  cedet-java-classpath-extension?
>       semanticdb-javap-classpath?  ede-java-classpath in an EDE
>       project?  Some combination thereof?
>    2. What is semanticdb-javap-classpath for, since it's not referenced
>       anywhere?  Is it vestigial?
>    3. Few of the functions in cedet-java.el are interactive.  As a user
>       of CEDET, Semantic, and EDE, should I largely ignore this file?
>
> Thanks!
>
> Best,
>
> David
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Hi Eric,

I apologize for asking hard questions.  I'm not trying to be difficult.
It's just that I love Emacs and am impressed by CEDET and really want it to
work for the Java development that I do.  As for the Semantic Analyzer
completion problems I described in my other emails, they relate not
specifically to completing symbols from types in Jar files, but to
completing any locally defined type in Java with the Analyzer.

Is there much in the cpp-root project that actually is C/C++ specific?  If
not, perhaps much of its functionality could be abstracted into a base
ede-root project type and then cpp-root and java-root could extend from
that.  Just a thought.

Cheers,
David

On 06/04/2012 12:22 AM, David Ventimiglia wrote:
> Hi Eric,
>
> I apologize for asking hard questions.  I'm not trying to be difficult.
> It's just that I love Emacs and am impressed by CEDET and really want it
> to work for the Java development that I do.  As for the Semantic
> Analyzer completion problems I described in my other emails, they relate
> not specifically to completing symbols from types in Jar files, but to
> completing any locally defined type in Java with the Analyzer.
>
> Is there much in the cpp-root project that actually is C/C++ specific?
> If not, perhaps much of its functionality could be abstracted into a
> base ede-root project type and then cpp-root and java-root could extend
> from that.  Just a thought.

No worries about hard questions.  It just means I can't always answer 
them quickly. ;)

There is some code in ede-cpp-root that could be considered 'common'. 
Mostly around project loading / detection.  Most of ede-cpp-root is 
about include paths and preprocessor symbols, and optimizations around 
finding files if you don't use something like GNU Global.

The java version I've started only has to manipulate the classpath.  It 
may be there is more to it than that, but that will take some 
experimentation.

I looked through some of the existing java tests, it is true that there 
are no tests for completing a variable, such as:

MyClass x;
x.

or testing out local imports that exist in the same directory.  It would 
be good for us to come up with some tests so we can find the boundary of 
what works and what doesn't.  This is generically true for all supported 
languages, but the growing need for Java support raises the priority there.

Eric