CEDET

On 07/12/2011 02:28 PM, David Ventimiglia wrote:
> Hi!
>
> How would I go about creating a new semanticdb backend?  I wanted to see
> if I could create one for Java that uses javap as a tag source.  Is
> there a recipe to follow?  I tried reading semanticdb-global.el, and can
> continue to do that, but some guidance would be extremely useful.  Thanks!

You are in luck, this is implemented in semanticdb-javap.el, and has 
worked ok for me.  Unfortunately, this is still in my android branch in 
bzr, so it is not quite so easy to get at.

The browsable tree is here:

http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files

It depends on changes in the java parser on that branch also.

If you'd like to try out the android branch that includes this, you can 
use bzr to download it.

bzr checkout bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android 
cedet

I've hooked it up with default support for android, but other types of 
classpaths are not in by default.  If anyone would like to add such 
support, let me know.

Good Luck
Eric

This is great!  How would I plug this into a system-include-path for an EDE
project, to pull tags from, say, JAR files rather than Java source files.
Currently, I'm using an ede-cpp-root-project, with :system-include-path
having a list of directories that contain Java source files for various
libaries and such.  But it's not always convenient or possible to have the
source code, so it would be nice to get the tags from compiled JAR files
instead.

On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam <ericludlam@...:

> On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>
>> Hi!
>>
>> How would I go about creating a new semanticdb backend?  I wanted to see
>> if I could create one for Java that uses javap as a tag source.  Is
>> there a recipe to follow?  I tried reading semanticdb-global.el, and can
>> continue to do that, but some guidance would be extremely useful.  Thanks!
>>
>
> You are in luck, this is implemented in semanticdb-javap.el, and has worked
> ok for me.  Unfortunately, this is still in my android branch in bzr, so it
> is not quite so easy to get at.
>
> The browsable tree is here:
>
> http://cedet.bzr.sourceforge.**net/bzr/cedet/code/android/**files<http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>
>
> It depends on changes in the java parser on that branch also.
>
> If you'd like to try out the android branch that includes this, you can use
> bzr to download it.
>
> bzr checkout bzr://cedet.bzr.sourceforge.**net/bzrroot/cedet/code/android<http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android>cedet
>
> I've hooked it up with default support for android, but other types of
> classpaths are not in by default.  If anyone would like to add such support,
> let me know.
>
> Good Luck
> Eric
>

Hi,

ede-cpp-root is specific to C files, and doesn't implement the EDE 
method ede-java-classpath.  I suppose it could, as it wouldn't really 
need much else other than a slot to specify that path in the main 
project class.

I expect it should be more generic a name than that, but that's what 
we've got at the moment.

Anyway, I've always left the java project stuff to JDEE which knows 
about classpaths and such, but I haven't linked to two together.

Someone would need to created an ede-java-root project to build 
something specific for java and its features.  Alternately, someone 
could add some stuff to ede-generic if the build systems for Java are 
particularly deterministic.  In either case, a project needs to 
implement the classpath method, and so far, only the android project 
does that because that's the only thing I've tried to do so far.

Chasing either of the two EDE project types should be pretty easy. 
There are good pre-existing examples in both cases.

Eric

On 07/12/2011 11:54 PM, David Ventimiglia wrote:
> This is great!  How would I plug this into a system-include-path for an
> EDE project, to pull tags from, say, JAR files rather than Java source
> files.  Currently, I'm using an ede-cpp-root-project, with
> :system-include-path having a list of directories that contain Java
> source files for various libaries and such.  But it's not always
> convenient or possible to have the source code, so it would be nice to
> get the tags from compiled JAR files instead.
>
> On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam <ericludlam@...
> <mailto:ericludlam@...>> wrote:
>
>     On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>
>         Hi!
>
>         How would I go about creating a new semanticdb backend?  I
>         wanted to see
>         if I could create one for Java that uses javap as a tag source.  Is
>         there a recipe to follow?  I tried reading semanticdb-global.el,
>         and can
>         continue to do that, but some guidance would be extremely
>         useful.  Thanks!
>
>
>     You are in luck, this is implemented in semanticdb-javap.el, and has
>     worked ok for me.  Unfortunately, this is still in my android branch
>     in bzr, so it is not quite so easy to get at.
>
>     The browsable tree is here:
>
>     http://cedet.bzr.sourceforge.__net/bzr/cedet/code/android/__files
>     <http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>
>
>     It depends on changes in the java parser on that branch also.
>
>     If you'd like to try out the android branch that includes this, you
>     can use bzr to download it.
>
>     bzr checkout
>     bzr://cedet.bzr.sourceforge.__net/bzrroot/cedet/code/android
>     <http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android> cedet
>
>     I've hooked it up with default support for android, but other types
>     of classpaths are not in by default.  If anyone would like to add
>     such support, let me know.
>
>     Good Luck
>     Eric
>
>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
>
>
>
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Hi Eric,

I was using ede-cpp-root for Java even though it's specific to C files,
since it had some of the desirable properties.  Namely, the ability easily
to define a project root, and the ability easily to plug in system
directories.  I didn't want to have the kind of EDE project that relies on a
particular file in every directory, like the Makefiles you would have with
recursive make.  Seems to me that fits better with the way Java does
things.  I'm not sure, but I think the parts of ede-cpp-root that are the
most C-specific relate to defining and building targets.  If that's true,
those are things I don't much care about, since I have my own stuff for
managing the build.  Though, as you point out, it doesn't implement
ede-java-classpath.

I could try to make a Java-specific ede-java-root, or to use ede-generic,
whichever is more suitable for the task.  Mainly, I'd like Emacs to have
easy and reliable access to tags when visiting Java files, in service of all
the other stuff in CEDET that can make use of tags.  ede-cpp-root works
surprisingly well.  But as far as I know, the only way it gets tags is to
have semantic parse the source files of all the includes, and it'd be nice
also to be able to get them from JAR files and class files, in a sort of
seamless way.

I've used JDEE for years and years and know it to be very good.  Still, I
think there'd be an appetite for a lightweight, pure-CEDET solution for
getting all the tags for Java file.

Anyway, so what your saying is, one option is to implement ede-java-root and
implement ede-java-classpath, is that correct?  Should I sub-class
ede-cpp-root, or write ede-java-root from scratch?  Could your Android
project type be adapted into a generic Java project type?

Thanks!
Cheers,
David





On Wed, Jul 13, 2011 at 4:26 AM, Eric M. Ludlam <ericludlam@...:

> Hi,
>
> ede-cpp-root is specific to C files, and doesn't implement the EDE method
> ede-java-classpath.  I suppose it could, as it wouldn't really need much
> else other than a slot to specify that path in the main project class.
>
> I expect it should be more generic a name than that, but that's what we've
> got at the moment.
>
> Anyway, I've always left the java project stuff to JDEE which knows about
> classpaths and such, but I haven't linked to two together.
>
> Someone would need to created an ede-java-root project to build something
> specific for java and its features.  Alternately, someone could add some
> stuff to ede-generic if the build systems for Java are particularly
> deterministic.  In either case, a project needs to implement the classpath
> method, and so far, only the android project does that because that's the
> only thing I've tried to do so far.
>
> Chasing either of the two EDE project types should be pretty easy. There
> are good pre-existing examples in both cases.
>
> Eric
>
>
> On 07/12/2011 11:54 PM, David Ventimiglia wrote:
>
>> This is great!  How would I plug this into a system-include-path for an
>> EDE project, to pull tags from, say, JAR files rather than Java source
>> files.  Currently, I'm using an ede-cpp-root-project, with
>> :system-include-path having a list of directories that contain Java
>> source files for various libaries and such.  But it's not always
>> convenient or possible to have the source code, so it would be nice to
>> get the tags from compiled JAR files instead.
>>
>> On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam <ericludlam@...
>> <mailto:ericludlam@...>> wrote:
>>
>>    On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>>
>>        Hi!
>>
>>        How would I go about creating a new semanticdb backend?  I
>>        wanted to see
>>        if I could create one for Java that uses javap as a tag source.  Is
>>        there a recipe to follow?  I tried reading semanticdb-global.el,
>>        and can
>>        continue to do that, but some guidance would be extremely
>>        useful.  Thanks!
>>
>>
>>    You are in luck, this is implemented in semanticdb-javap.el, and has
>>    worked ok for me.  Unfortunately, this is still in my android branch
>>    in bzr, so it is not quite so easy to get at.
>>
>>    The browsable tree is here:
>>
>>    http://cedet.bzr.sourceforge._**_net/bzr/cedet/code/android/__**files
>>    <http://cedet.bzr.sourceforge.**net/bzr/cedet/code/android/**files<http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>
>> >
>>
>>    It depends on changes in the java parser on that branch also.
>>
>>    If you'd like to try out the android branch that includes this, you
>>    can use bzr to download it.
>>
>>    bzr checkout
>>    bzr://cedet.bzr.sourceforge.__**net/bzrroot/cedet/code/android
>>    <http://cedet.bzr.sourceforge.**net/bzrroot/cedet/code/android<http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android>
>> **> cedet
>>
>>
>>    I've hooked it up with default support for android, but other types
>>    of classpaths are not in by default.  If anyone would like to add
>>    such support, let me know.
>>
>>    Good Luck
>>    Eric
>>
>>
>>
>>
>> ------------------------------**------------------------------**
>> ------------------
>> AppSumo Presents a FREE Video for the SourceForge Community by Eric
>> Ries, the creator of the Lean Startup Methodology on "Lean Startup
>> Secrets Revealed." This video shows you how to validate your ideas,
>> optimize your ideas and identify your business strategy.
>> http://p.sf.net/sfu/**appsumosfdev2dev<http://p.sf.net/sfu/appsumosfdev2dev>
>>
>>
>>
>> ______________________________**_________________
>> cedet-semantic mailing list
>> cedet-semantic@...>
>> https://lists.sourceforge.net/**lists/listinfo/cedet-semantic<https://lists.sourceforge.net/lists/listinfo/cedet-semantic>
>>
>

This might be out of context, but it might be more efficient than creating a
new thread.

When I create new header files, classes, etc, do I have to update the
semanticdb some how, or is this done automatically?

Jai

On Wed, Jul 13, 2011 at 10:40 AM, David Ventimiglia <dventimi@...:

> Hi Eric,
>
> I was using ede-cpp-root for Java even though it's specific to C files,
> since it had some of the desirable properties.  Namely, the ability easily
> to define a project root, and the ability easily to plug in system
> directories.  I didn't want to have the kind of EDE project that relies on a
> particular file in every directory, like the Makefiles you would have with
> recursive make.  Seems to me that fits better with the way Java does
> things.  I'm not sure, but I think the parts of ede-cpp-root that are the
> most C-specific relate to defining and building targets.  If that's true,
> those are things I don't much care about, since I have my own stuff for
> managing the build.  Though, as you point out, it doesn't implement
> ede-java-classpath.
>
> I could try to make a Java-specific ede-java-root, or to use ede-generic,
> whichever is more suitable for the task.  Mainly, I'd like Emacs to have
> easy and reliable access to tags when visiting Java files, in service of all
> the other stuff in CEDET that can make use of tags.  ede-cpp-root works
> surprisingly well.  But as far as I know, the only way it gets tags is to
> have semantic parse the source files of all the includes, and it'd be nice
> also to be able to get them from JAR files and class files, in a sort of
> seamless way.
>
> I've used JDEE for years and years and know it to be very good.  Still, I
> think there'd be an appetite for a lightweight, pure-CEDET solution for
> getting all the tags for Java file.
>
> Anyway, so what your saying is, one option is to implement ede-java-root
> and implement ede-java-classpath, is that correct?  Should I sub-class
> ede-cpp-root, or write ede-java-root from scratch?  Could your Android
> project type be adapted into a generic Java project type?
>
> Thanks!
> Cheers,
> David
>
>
>
>
>
>
> On Wed, Jul 13, 2011 at 4:26 AM, Eric M. Ludlam <ericludlam@...:
>
>> Hi,
>>
>> ede-cpp-root is specific to C files, and doesn't implement the EDE method
>> ede-java-classpath.  I suppose it could, as it wouldn't really need much
>> else other than a slot to specify that path in the main project class.
>>
>> I expect it should be more generic a name than that, but that's what we've
>> got at the moment.
>>
>> Anyway, I've always left the java project stuff to JDEE which knows about
>> classpaths and such, but I haven't linked to two together.
>>
>> Someone would need to created an ede-java-root project to build something
>> specific for java and its features.  Alternately, someone could add some
>> stuff to ede-generic if the build systems for Java are particularly
>> deterministic.  In either case, a project needs to implement the classpath
>> method, and so far, only the android project does that because that's the
>> only thing I've tried to do so far.
>>
>> Chasing either of the two EDE project types should be pretty easy. There
>> are good pre-existing examples in both cases.
>>
>> Eric
>>
>>
>> On 07/12/2011 11:54 PM, David Ventimiglia wrote:
>>
>>> This is great!  How would I plug this into a system-include-path for an
>>> EDE project, to pull tags from, say, JAR files rather than Java source
>>> files.  Currently, I'm using an ede-cpp-root-project, with
>>> :system-include-path having a list of directories that contain Java
>>> source files for various libaries and such.  But it's not always
>>> convenient or possible to have the source code, so it would be nice to
>>> get the tags from compiled JAR files instead.
>>>
>>> On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam <ericludlam@...
>>> <mailto:ericludlam@...>> wrote:
>>>
>>>    On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>>>
>>>        Hi!
>>>
>>>        How would I go about creating a new semanticdb backend?  I
>>>        wanted to see
>>>        if I could create one for Java that uses javap as a tag source.
>>>  Is
>>>        there a recipe to follow?  I tried reading semanticdb-global.el,
>>>        and can
>>>        continue to do that, but some guidance would be extremely
>>>        useful.  Thanks!
>>>
>>>
>>>    You are in luck, this is implemented in semanticdb-javap.el, and has
>>>    worked ok for me.  Unfortunately, this is still in my android branch
>>>    in bzr, so it is not quite so easy to get at.
>>>
>>>    The browsable tree is here:
>>>
>>>    http://cedet.bzr.sourceforge._**_net/bzr/cedet/code/android/__**files
>>>    <http://cedet.bzr.sourceforge.**net/bzr/cedet/code/android/**files<http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>
>>> >
>>>
>>>    It depends on changes in the java parser on that branch also.
>>>
>>>    If you'd like to try out the android branch that includes this, you
>>>    can use bzr to download it.
>>>
>>>    bzr checkout
>>>    bzr://cedet.bzr.sourceforge.__**net/bzrroot/cedet/code/android
>>>    <http://cedet.bzr.sourceforge.**net/bzrroot/cedet/code/android<http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android>
>>> **> cedet
>>>
>>>
>>>    I've hooked it up with default support for android, but other types
>>>    of classpaths are not in by default.  If anyone would like to add
>>>    such support, let me know.
>>>
>>>    Good Luck
>>>    Eric
>>>
>>>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> AppSumo Presents a FREE Video for the SourceForge Community by Eric
>>> Ries, the creator of the Lean Startup Methodology on "Lean Startup
>>> Secrets Revealed." This video shows you how to validate your ideas,
>>> optimize your ideas and identify your business strategy.
>>> http://p.sf.net/sfu/**appsumosfdev2dev<http://p.sf.net/sfu/appsumosfdev2dev>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> cedet-semantic mailing list
>>> cedet-semantic@...>
>>> https://lists.sourceforge.net/**lists/listinfo/cedet-semantic<https://lists.sourceforge.net/lists/listinfo/cedet-semantic>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
>

It is probably OK to use ede-cpp-root as you describe, there just 
doesn't happen to be the method support for classpaths.  The reason to 
create a java version is mostly just because of the name.  It would 
probably be easiest to just add the ede-java-classpath implementation to 
ede-cpp-root and see how it goes.  If things go well, then we can try to 
solve the name issue later.

You will discover that the implementation in ede-android.el is quite 
simple.  You can probably do something similar as a first step.

The ede-generic view is if you want it to detect some custom java make 
system, in which case adding classpath support would just be a copy of 
perhaps the C stuff, which a configuration for classpath.  That is 
probably worth while also.

Step one, however, is creating the prototype and seeing how it goes, and 
if there is some additional type of support missing in the android branch.

Eric

On 07/13/2011 12:40 PM, David Ventimiglia wrote:
> Hi Eric,
>
> I was using ede-cpp-root for Java even though it's specific to C files,
> since it had some of the desirable properties.  Namely, the ability
> easily to define a project root, and the ability easily to plug in
> system directories.  I didn't want to have the kind of EDE project that
> relies on a particular file in every directory, like the Makefiles you
> would have with recursive make.  Seems to me that fits better with the
> way Java does things.  I'm not sure, but I think the parts of
> ede-cpp-root that are the most C-specific relate to defining and
> building targets.  If that's true, those are things I don't much care
> about, since I have my own stuff for managing the build.  Though, as you
> point out, it doesn't implement ede-java-classpath.
>
> I could try to make a Java-specific ede-java-root, or to use
> ede-generic, whichever is more suitable for the task.  Mainly, I'd like
> Emacs to have easy and reliable access to tags when visiting Java files,
> in service of all the other stuff in CEDET that can make use of tags.
> ede-cpp-root works surprisingly well.  But as far as I know, the only
> way it gets tags is to have semantic parse the source files of all the
> includes, and it'd be nice also to be able to get them from JAR files
> and class files, in a sort of seamless way.
>
> I've used JDEE for years and years and know it to be very good.  Still,
> I think there'd be an appetite for a lightweight, pure-CEDET solution
> for getting all the tags for Java file.
>
> Anyway, so what your saying is, one option is to implement ede-java-root
> and implement ede-java-classpath, is that correct?  Should I sub-class
> ede-cpp-root, or write ede-java-root from scratch?  Could your Android
> project type be adapted into a generic Java project type?
>
> Thanks!
> Cheers,
> David
>
>
>
>
>
> On Wed, Jul 13, 2011 at 4:26 AM, Eric M. Ludlam <ericludlam@...
> <mailto:ericludlam@...>> wrote:
>
>     Hi,
>
>     ede-cpp-root is specific to C files, and doesn't implement the EDE
>     method ede-java-classpath.  I suppose it could, as it wouldn't
>     really need much else other than a slot to specify that path in the
>     main project class.
>
>     I expect it should be more generic a name than that, but that's what
>     we've got at the moment.
>
>     Anyway, I've always left the java project stuff to JDEE which knows
>     about classpaths and such, but I haven't linked to two together.
>
>     Someone would need to created an ede-java-root project to build
>     something specific for java and its features.  Alternately, someone
>     could add some stuff to ede-generic if the build systems for Java
>     are particularly deterministic.  In either case, a project needs to
>     implement the classpath method, and so far, only the android project
>     does that because that's the only thing I've tried to do so far.
>
>     Chasing either of the two EDE project types should be pretty easy.
>     There are good pre-existing examples in both cases.
>
>     Eric
>
>
>     On 07/12/2011 11:54 PM, David Ventimiglia wrote:
>
>         This is great!  How would I plug this into a system-include-path
>         for an
>         EDE project, to pull tags from, say, JAR files rather than Java
>         source
>         files.  Currently, I'm using an ede-cpp-root-project, with
>         :system-include-path having a list of directories that contain Java
>         source files for various libaries and such.  But it's not always
>         convenient or possible to have the source code, so it would be
>         nice to
>         get the tags from compiled JAR files instead.
>
>         On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam
>         <ericludlam@... <mailto:ericludlam@...>
>         <mailto:ericludlam@... <mailto:ericludlam@...>>> wrote:
>
>             On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>
>                 Hi!
>
>                 How would I go about creating a new semanticdb backend?  I
>                 wanted to see
>                 if I could create one for Java that uses javap as a tag
>         source.  Is
>                 there a recipe to follow?  I tried reading
>         semanticdb-global.el,
>                 and can
>                 continue to do that, but some guidance would be extremely
>                 useful.  Thanks!
>
>
>             You are in luck, this is implemented in semanticdb-javap.el,
>         and has
>             worked ok for me.  Unfortunately, this is still in my
>         android branch
>             in bzr, so it is not quite so easy to get at.
>
>             The browsable tree is here:
>
>         http://cedet.bzr.sourceforge.____net/bzr/cedet/code/android/____files
>         <http://cedet.bzr.sourceforge.__net/bzr/cedet/code/android/__files
>         <http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>>
>
>             It depends on changes in the java parser on that branch also.
>
>             If you'd like to try out the android branch that includes
>         this, you
>             can use bzr to download it.
>
>             bzr checkout
>             bzr://cedet.bzr.sourceforge.____net/bzrroot/cedet/code/android
>         <http://cedet.bzr.sourceforge.__net/bzrroot/cedet/code/android
>         <http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android>__>
>         cedet
>
>
>             I've hooked it up with default support for android, but
>         other types
>             of classpaths are not in by default.  If anyone would like
>         to add
>             such support, let me know.
>
>             Good Luck
>             Eric
>
>
>
>
>         ------------------------------__------------------------------__------------------
>         AppSumo Presents a FREE Video for the SourceForge Community by Eric
>         Ries, the creator of the Lean Startup Methodology on "Lean Startup
>         Secrets Revealed." This video shows you how to validate your ideas,
>         optimize your ideas and identify your business strategy.
>         http://p.sf.net/sfu/__appsumosfdev2dev
>         <http://p.sf.net/sfu/appsumosfdev2dev>
>
>
>
>         _________________________________________________
>         cedet-semantic mailing list
>         cedet-semantic@...
>         <mailto:cedet-semantic@...>
>         https://lists.sourceforge.net/__lists/listinfo/cedet-semantic
>         <https://lists.sourceforge.net/lists/listinfo/cedet-semantic>
>
>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
>
>
>
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Semanticdb will always check the files to see if reparsing is necessary. 
  There are some cases (usually labeled as 'fast' in the code) that will 
skip that step, but all commands will do a full stat to be sure.

The exception is for back-ends that poll from a 3rd party tool like 
global, which will update whenever global feels like updating.

Eric

On 07/13/2011 12:43 PM, Jai Dayal wrote:
> This might be out of context, but it might be more efficient than
> creating a new thread.
>
> When I create new header files, classes, etc, do I have to update the
> semanticdb some how, or is this done automatically?
>
> Jai
>
> On Wed, Jul 13, 2011 at 10:40 AM, David Ventimiglia <dventimi@...
> <mailto:dventimi@...>> wrote:
>
>     Hi Eric,
>
>     I was using ede-cpp-root for Java even though it's specific to C
>     files, since it had some of the desirable properties.  Namely, the
>     ability easily to define a project root, and the ability easily to
>     plug in system directories.  I didn't want to have the kind of EDE
>     project that relies on a particular file in every directory, like
>     the Makefiles you would have with recursive make.  Seems to me that
>     fits better with the way Java does things.  I'm not sure, but I
>     think the parts of ede-cpp-root that are the most C-specific relate
>     to defining and building targets.  If that's true, those are things
>     I don't much care about, since I have my own stuff for managing the
>     build.  Though, as you point out, it doesn't implement
>     ede-java-classpath.
>
>     I could try to make a Java-specific ede-java-root, or to use
>     ede-generic, whichever is more suitable for the task.  Mainly, I'd
>     like Emacs to have easy and reliable access to tags when visiting
>     Java files, in service of all the other stuff in CEDET that can make
>     use of tags.  ede-cpp-root works surprisingly well.  But as far as I
>     know, the only way it gets tags is to have semantic parse the source
>     files of all the includes, and it'd be nice also to be able to get
>     them from JAR files and class files, in a sort of seamless way.
>
>     I've used JDEE for years and years and know it to be very good.
>     Still, I think there'd be an appetite for a lightweight, pure-CEDET
>     solution for getting all the tags for Java file.
>
>     Anyway, so what your saying is, one option is to implement
>     ede-java-root and implement ede-java-classpath, is that correct?
>     Should I sub-class ede-cpp-root, or write ede-java-root from
>     scratch?  Could your Android project type be adapted into a generic
>     Java project type?
>
>     Thanks!
>     Cheers,
>     David
>
>
>
>
>
>
>     On Wed, Jul 13, 2011 at 4:26 AM, Eric M. Ludlam
>     <ericludlam@... <mailto:ericludlam@...>> wrote:
>
>         Hi,
>
>         ede-cpp-root is specific to C files, and doesn't implement the
>         EDE method ede-java-classpath.  I suppose it could, as it
>         wouldn't really need much else other than a slot to specify that
>         path in the main project class.
>
>         I expect it should be more generic a name than that, but that's
>         what we've got at the moment.
>
>         Anyway, I've always left the java project stuff to JDEE which
>         knows about classpaths and such, but I haven't linked to two
>         together.
>
>         Someone would need to created an ede-java-root project to build
>         something specific for java and its features.  Alternately,
>         someone could add some stuff to ede-generic if the build systems
>         for Java are particularly deterministic.  In either case, a
>         project needs to implement the classpath method, and so far,
>         only the android project does that because that's the only thing
>         I've tried to do so far.
>
>         Chasing either of the two EDE project types should be pretty
>         easy. There are good pre-existing examples in both cases.
>
>         Eric
>
>
>         On 07/12/2011 11:54 PM, David Ventimiglia wrote:
>
>             This is great!  How would I plug this into a
>             system-include-path for an
>             EDE project, to pull tags from, say, JAR files rather than
>             Java source
>             files.  Currently, I'm using an ede-cpp-root-project, with
>             :system-include-path having a list of directories that
>             contain Java
>             source files for various libaries and such.  But it's not always
>             convenient or possible to have the source code, so it would
>             be nice to
>             get the tags from compiled JAR files instead.
>
>             On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam
>             <ericludlam@... <mailto:ericludlam@...>
>             <mailto:ericludlam@... <mailto:ericludlam@...>>>
>             wrote:
>
>                 On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>
>                     Hi!
>
>                     How would I go about creating a new semanticdb
>             backend?  I
>                     wanted to see
>                     if I could create one for Java that uses javap as a
>             tag source.  Is
>                     there a recipe to follow?  I tried reading
>             semanticdb-global.el,
>                     and can
>                     continue to do that, but some guidance would be
>             extremely
>                     useful.  Thanks!
>
>
>                 You are in luck, this is implemented in
>             semanticdb-javap.el, and has
>                 worked ok for me.  Unfortunately, this is still in my
>             android branch
>                 in bzr, so it is not quite so easy to get at.
>
>                 The browsable tree is here:
>
>             http://cedet.bzr.sourceforge.____net/bzr/cedet/code/android/____files
>             <http://cedet.bzr.sourceforge.__net/bzr/cedet/code/android/__files
>             <http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>>
>
>                 It depends on changes in the java parser on that branch
>             also.
>
>                 If you'd like to try out the android branch that
>             includes this, you
>                 can use bzr to download it.
>
>                 bzr checkout
>
>               bzr://cedet.bzr.sourceforge.____net/bzrroot/cedet/code/android
>             <http://cedet.bzr.sourceforge.__net/bzrroot/cedet/code/android
>             <http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android>__>
>             cedet
>
>
>                 I've hooked it up with default support for android, but
>             other types
>                 of classpaths are not in by default.  If anyone would
>             like to add
>                 such support, let me know.
>
>                 Good Luck
>                 Eric
>
>
>
>
>             ------------------------------__------------------------------__------------------
>             AppSumo Presents a FREE Video for the SourceForge Community
>             by Eric
>             Ries, the creator of the Lean Startup Methodology on "Lean
>             Startup
>             Secrets Revealed." This video shows you how to validate your
>             ideas,
>             optimize your ideas and identify your business strategy.
>             http://p.sf.net/sfu/__appsumosfdev2dev
>             <http://p.sf.net/sfu/appsumosfdev2dev>
>
>
>
>             _________________________________________________
>             cedet-semantic mailing list
>             cedet-semantic@...
>             <mailto:cedet-semantic@...>
>             https://lists.sourceforge.net/__lists/listinfo/cedet-semantic <https://lists.sourceforge.net/lists/listinfo/cedet-semantic>
>
>
>
>     ------------------------------------------------------------------------------
>     AppSumo Presents a FREE Video for the SourceForge Community by Eric
>     Ries, the creator of the Lean Startup Methodology on "Lean Startup
>     Secrets Revealed." This video shows you how to validate your ideas,
>     optimize your ideas and identify your business strategy.
>     http://p.sf.net/sfu/appsumosfdev2dev
>     _______________________________________________
>     cedet-semantic mailing list
>     cedet-semantic@...
>     <mailto:cedet-semantic@...>
>     https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
>
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
>
>
>
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Hi!

I see from August 10, 2011 that you merged many things from your Android
branch over to the trunk, so that CEDET now has greater support for Java
(among other things).  Thanks!  In your notice, you wrote,

"If you just do Java w/out Android, you can setup your classpath in Emacs,
and also enjoy full smart completion on a wide array of syntaxes."

What exactly does this mean?  For instance the only place I see in Emacs
(really, in CEDET) to set up a classpath is semanticdb-javap-classpath.  Is
that what you're referring to?  Is this all that's needed, or are there
other steps that are needed?  For instance, I have not (yet) set up any
specific EDE projects for my Java projects.  In the past, I'd used
ede-cpp-root in order to specify :system-include-path, and that actually
worked well at finding Java source files.  I also once subclassed
ede-cpp-root to do essentially the same thing.  Is an EDE project still
necessary?  Seems like it would be, though I wonder if I can get away with
just using semanticdb-project-roots instead.  That never worked for me in
the past, though I'm not sure why.

Thanks!
Cheers,
David

On Thu, Jul 14, 2011 at 4:35 AM, Eric M. Ludlam <ericludlam@...:

> Semanticdb will always check the files to see if reparsing is necessary.
>  There are some cases (usually labeled as 'fast' in the code) that will
> skip that step, but all commands will do a full stat to be sure.
>
> The exception is for back-ends that poll from a 3rd party tool like
> global, which will update whenever global feels like updating.
>
> Eric
>
> On 07/13/2011 12:43 PM, Jai Dayal wrote:
> > This might be out of context, but it might be more efficient than
> > creating a new thread.
> >
> > When I create new header files, classes, etc, do I have to update the
> > semanticdb some how, or is this done automatically?
> >
> > Jai
> >
> > On Wed, Jul 13, 2011 at 10:40 AM, David Ventimiglia <dventimi@...
> > <mailto:dventimi@...>> wrote:
> >
> >     Hi Eric,
> >
> >     I was using ede-cpp-root for Java even though it's specific to C
> >     files, since it had some of the desirable properties.  Namely, the
> >     ability easily to define a project root, and the ability easily to
> >     plug in system directories.  I didn't want to have the kind of EDE
> >     project that relies on a particular file in every directory, like
> >     the Makefiles you would have with recursive make.  Seems to me that
> >     fits better with the way Java does things.  I'm not sure, but I
> >     think the parts of ede-cpp-root that are the most C-specific relate
> >     to defining and building targets.  If that's true, those are things
> >     I don't much care about, since I have my own stuff for managing the
> >     build.  Though, as you point out, it doesn't implement
> >     ede-java-classpath.
> >
> >     I could try to make a Java-specific ede-java-root, or to use
> >     ede-generic, whichever is more suitable for the task.  Mainly, I'd
> >     like Emacs to have easy and reliable access to tags when visiting
> >     Java files, in service of all the other stuff in CEDET that can make
> >     use of tags.  ede-cpp-root works surprisingly well.  But as far as I
> >     know, the only way it gets tags is to have semantic parse the source
> >     files of all the includes, and it'd be nice also to be able to get
> >     them from JAR files and class files, in a sort of seamless way.
> >
> >     I've used JDEE for years and years and know it to be very good.
> >     Still, I think there'd be an appetite for a lightweight, pure-CEDET
> >     solution for getting all the tags for Java file.
> >
> >     Anyway, so what your saying is, one option is to implement
> >     ede-java-root and implement ede-java-classpath, is that correct?
> >     Should I sub-class ede-cpp-root, or write ede-java-root from
> >     scratch?  Could your Android project type be adapted into a generic
> >     Java project type?
> >
> >     Thanks!
> >     Cheers,
> >     David
> >
> >
> >
> >
> >
> >
> >     On Wed, Jul 13, 2011 at 4:26 AM, Eric M. Ludlam
> >     <ericludlam@... <mailto:ericludlam@...>> wrote:
> >
> >         Hi,
> >
> >         ede-cpp-root is specific to C files, and doesn't implement the
> >         EDE method ede-java-classpath.  I suppose it could, as it
> >         wouldn't really need much else other than a slot to specify that
> >         path in the main project class.
> >
> >         I expect it should be more generic a name than that, but that's
> >         what we've got at the moment.
> >
> >         Anyway, I've always left the java project stuff to JDEE which
> >         knows about classpaths and such, but I haven't linked to two
> >         together.
> >
> >         Someone would need to created an ede-java-root project to build
> >         something specific for java and its features.  Alternately,
> >         someone could add some stuff to ede-generic if the build systems
> >         for Java are particularly deterministic.  In either case, a
> >         project needs to implement the classpath method, and so far,
> >         only the android project does that because that's the only thing
> >         I've tried to do so far.
> >
> >         Chasing either of the two EDE project types should be pretty
> >         easy. There are good pre-existing examples in both cases.
> >
> >         Eric
> >
> >
> >         On 07/12/2011 11:54 PM, David Ventimiglia wrote:
> >
> >             This is great!  How would I plug this into a
> >             system-include-path for an
> >             EDE project, to pull tags from, say, JAR files rather than
> >             Java source
> >             files.  Currently, I'm using an ede-cpp-root-project, with
> >             :system-include-path having a list of directories that
> >             contain Java
> >             source files for various libaries and such.  But it's not
> always
> >             convenient or possible to have the source code, so it would
> >             be nice to
> >             get the tags from compiled JAR files instead.
> >
> >             On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam
> >             <ericludlam@... <mailto:ericludlam@...>
> >             <mailto:ericludlam@... <mailto:ericludlam@...>>>
> >             wrote:
> >
> >                 On 07/12/2011 02:28 PM, David Ventimiglia wrote:
> >
> >                     Hi!
> >
> >                     How would I go about creating a new semanticdb
> >             backend?  I
> >                     wanted to see
> >                     if I could create one for Java that uses javap as a
> >             tag source.  Is
> >                     there a recipe to follow?  I tried reading
> >             semanticdb-global.el,
> >                     and can
> >                     continue to do that, but some guidance would be
> >             extremely
> >                     useful.  Thanks!
> >
> >
> >                 You are in luck, this is implemented in
> >             semanticdb-javap.el, and has
> >                 worked ok for me.  Unfortunately, this is still in my
> >             android branch
> >                 in bzr, so it is not quite so easy to get at.
> >
> >                 The browsable tree is here:
> >
> >             http://cedet.bzr.sourceforge.
> ____net/bzr/cedet/code/android/____files
> >             <http://cedet.bzr.sourceforge.
> __net/bzr/cedet/code/android/__files
> >             <
> http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>>
> >
> >                 It depends on changes in the java parser on that branch
> >             also.
> >
> >                 If you'd like to try out the android branch that
> >             includes this, you
> >                 can use bzr to download it.
> >
> >                 bzr checkout
> >
> >
> bzr://cedet.bzr.sourceforge.____net/bzrroot/cedet/code/android
> >             <http://cedet.bzr.sourceforge.
> __net/bzrroot/cedet/code/android
> >             <http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android
> >__>
> >             cedet
> >
> >
> >                 I've hooked it up with default support for android, but
> >             other types
> >                 of classpaths are not in by default.  If anyone would
> >             like to add
> >                 such support, let me know.
> >
> >                 Good Luck
> >                 Eric
> >
> >
> >
> >
> >
> ------------------------------__------------------------------__------------------
> >             AppSumo Presents a FREE Video for the SourceForge Community
> >             by Eric
> >             Ries, the creator of the Lean Startup Methodology on "Lean
> >             Startup
> >             Secrets Revealed." This video shows you how to validate your
> >             ideas,
> >             optimize your ideas and identify your business strategy.
> >             http://p.sf.net/sfu/__appsumosfdev2dev
> >             <http://p.sf.net/sfu/appsumosfdev2dev>
> >
> >
> >
> >             _________________________________________________
> >             cedet-semantic mailing list
> >             cedet-semantic@...
> >             <mailto:cedet-semantic@...>
> >
> https://lists.sourceforge.net/__lists/listinfo/cedet-semantic <
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >     AppSumo Presents a FREE Video for the SourceForge Community by Eric
> >     Ries, the creator of the Lean Startup Methodology on "Lean Startup
> >     Secrets Revealed." This video shows you how to validate your ideas,
> >     optimize your ideas and identify your business strategy.
> >     http://p.sf.net/sfu/appsumosfdev2dev
> >     _______________________________________________
> >     cedet-semantic mailing list
> >     cedet-semantic@...
> >     <mailto:cedet-semantic@...>
> >     https://lists.sourceforge.net/lists/listinfo/cedet-semantic
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > AppSumo Presents a FREE Video for the SourceForge Community by Eric
> > Ries, the creator of the Lean Startup Methodology on "Lean Startup
> > Secrets Revealed." This video shows you how to validate your ideas,
> > optimize your ideas and identify your business strategy.
> > http://p.sf.net/sfu/appsumosfdev2dev
> >
> >
> >
> > _______________________________________________
> > cedet-semantic mailing list
> > cedet-semantic@...
> > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
>
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community by Eric
> Ries, the creator of the Lean Startup Methodology on "Lean Startup
> Secrets Revealed." This video shows you how to validate your ideas,
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

Hi,

The different CEDET parts, such as semantic, ede, etc augment each 
other, as opposed to being dependent on each other.

Thus, you can setup semanticdb features without ever using EDE.  If you 
do use EDE, then EDE can provide some of the information automatically 
if it can figure it out.

Thus, if you edit the classpath variable with the locations of your 
system jar files, that should allow the javap database to provide the 
info you need.

The include path is used for finding sources, as opposed to the jar 
files which will not be searchable without using javap to decode them. 
If all your code is in sources, I find it interesting that the 
ede-cpp-root project was helpful in that way, as I hadn't thought of that.

Anyway, EDE is not necessary.  It does, however, provide an easy place 
to put configurations unique to different parts of the file system.  As 
such, I recommend using one when possible.  It would be nice to have a 
java specific project too, though most folks just use JDEE, and do not 
need to use any configurations in CEDET specifically since JDEE usually 
provides those features.

Ideally, the classpath would self-populate, but I don't really know how 
to teach it where the system jar files are in some reliable way.  It is 
possible to use javap with the system classpath, but I ran into trouble 
since you can't query the system jar files for the lists of all the 
classes in them.  (AFAIK anyway).

The semanticdb-project-roots is a way of telling semantic, without using 
EDE, where to stop during semanticdb global searches.  If you don't get 
all your files parsed ahead of time, however, it won't do much.  As it 
turns out, EDE adds itself to the roots lists, and provides those 
directories automatically.

Eric

On 08/27/2011 03:09 PM, David Ventimiglia wrote:
> Hi!
>
> I see from August 10, 2011 that you merged many things from your Android
> branch over to the trunk, so that CEDET now has greater support for Java
> (among other things).  Thanks!  In your notice, you wrote,
>
> "If you just do Java w/out Android, you can setup your classpath in
> Emacs, and also enjoy full smart completion on a wide array of syntaxes."
>
> What exactly does this mean?  For instance the only place I see in Emacs
> (really, in CEDET) to set up a classpath is semanticdb-javap-classpath.
> Is that what you're referring to?  Is this all that's needed, or are
> there other steps that are needed?  For instance, I have not (yet) set
> up any specific EDE projects for my Java projects.  In the past, I'd
> used ede-cpp-root in order to specify :system-include-path, and that
> actually worked well at finding Java source files.  I also once
> subclassed ede-cpp-root to do essentially the same thing.  Is an EDE
> project still necessary?  Seems like it would be, though I wonder if I
> can get away with just using semanticdb-project-roots instead.  That
> never worked for me in the past, though I'm not sure why.
>
> Thanks!
> Cheers,
> David
>
> On Thu, Jul 14, 2011 at 4:35 AM, Eric M. Ludlam <ericludlam@...
> <mailto:ericludlam@...>> wrote:
>
>     Semanticdb will always check the files to see if reparsing is necessary.
>       There are some cases (usually labeled as 'fast' in the code) that will
>     skip that step, but all commands will do a full stat to be sure.
>
>     The exception is for back-ends that poll from a 3rd party tool like
>     global, which will update whenever global feels like updating.
>
>     Eric
>
>     On 07/13/2011 12:43 PM, Jai Dayal wrote:
>      > This might be out of context, but it might be more efficient than
>      > creating a new thread.
>      >
>      > When I create new header files, classes, etc, do I have to update the
>      > semanticdb some how, or is this done automatically?
>      >
>      > Jai
>      >
>      > On Wed, Jul 13, 2011 at 10:40 AM, David Ventimiglia
>     <dventimi@... <mailto:dventimi@...>
>      > <mailto:dventimi@... <mailto:dventimi@...>>> wrote:
>      >
>      >     Hi Eric,
>      >
>      >     I was using ede-cpp-root for Java even though it's specific to C
>      >     files, since it had some of the desirable properties.
>       Namely, the
>      >     ability easily to define a project root, and the ability
>     easily to
>      >     plug in system directories.  I didn't want to have the kind
>     of EDE
>      >     project that relies on a particular file in every directory, like
>      >     the Makefiles you would have with recursive make.  Seems to
>     me that
>      >     fits better with the way Java does things.  I'm not sure, but I
>      >     think the parts of ede-cpp-root that are the most C-specific
>     relate
>      >     to defining and building targets.  If that's true, those are
>     things
>      >     I don't much care about, since I have my own stuff for
>     managing the
>      >     build.  Though, as you point out, it doesn't implement
>      >     ede-java-classpath.
>      >
>      >     I could try to make a Java-specific ede-java-root, or to use
>      >     ede-generic, whichever is more suitable for the task.
>       Mainly, I'd
>      >     like Emacs to have easy and reliable access to tags when visiting
>      >     Java files, in service of all the other stuff in CEDET that
>     can make
>      >     use of tags.  ede-cpp-root works surprisingly well.  But as
>     far as I
>      >     know, the only way it gets tags is to have semantic parse the
>     source
>      >     files of all the includes, and it'd be nice also to be able
>     to get
>      >     them from JAR files and class files, in a sort of seamless way.
>      >
>      >     I've used JDEE for years and years and know it to be very good.
>      >     Still, I think there'd be an appetite for a lightweight,
>     pure-CEDET
>      >     solution for getting all the tags for Java file.
>      >
>      >     Anyway, so what your saying is, one option is to implement
>      >     ede-java-root and implement ede-java-classpath, is that correct?
>      >     Should I sub-class ede-cpp-root, or write ede-java-root from
>      >     scratch?  Could your Android project type be adapted into a
>     generic
>      >     Java project type?
>      >
>      >     Thanks!
>      >     Cheers,
>      >     David
>      >
>      >
>      >
>      >
>      >
>      >
>      >     On Wed, Jul 13, 2011 at 4:26 AM, Eric M. Ludlam
>      > <ericludlam@... <mailto:ericludlam@...>
>     <mailto:ericludlam@... <mailto:ericludlam@...>>> wrote:
>      >
>      >         Hi,
>      >
>      >         ede-cpp-root is specific to C files, and doesn't
>     implement the
>      >         EDE method ede-java-classpath.  I suppose it could, as it
>      >         wouldn't really need much else other than a slot to
>     specify that
>      >         path in the main project class.
>      >
>      >         I expect it should be more generic a name than that, but
>     that's
>      >         what we've got at the moment.
>      >
>      >         Anyway, I've always left the java project stuff to JDEE which
>      >         knows about classpaths and such, but I haven't linked to two
>      >         together.
>      >
>      >         Someone would need to created an ede-java-root project to
>     build
>      >         something specific for java and its features.  Alternately,
>      >         someone could add some stuff to ede-generic if the build
>     systems
>      >         for Java are particularly deterministic.  In either case, a
>      >         project needs to implement the classpath method, and so far,
>      >         only the android project does that because that's the
>     only thing
>      >         I've tried to do so far.
>      >
>      >         Chasing either of the two EDE project types should be pretty
>      >         easy. There are good pre-existing examples in both cases.
>      >
>      >         Eric
>      >
>      >
>      >         On 07/12/2011 11:54 PM, David Ventimiglia wrote:
>      >
>      >             This is great!  How would I plug this into a
>      >             system-include-path for an
>      >             EDE project, to pull tags from, say, JAR files rather
>     than
>      >             Java source
>      >             files.  Currently, I'm using an ede-cpp-root-project,
>     with
>      >             :system-include-path having a list of directories that
>      >             contain Java
>      >             source files for various libaries and such.  But it's
>     not always
>      >             convenient or possible to have the source code, so it
>     would
>      >             be nice to
>      >             get the tags from compiled JAR files instead.
>      >
>      >             On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam
>      > <ericludlam@... <mailto:ericludlam@...>
>     <mailto:ericludlam@... <mailto:ericludlam@...>>
>      > <mailto:ericludlam@... <mailto:ericludlam@...>
>     <mailto:ericludlam@... <mailto:ericludlam@...>>>>
>      >             wrote:
>      >
>      >                 On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>      >
>      >                     Hi!
>      >
>      >                     How would I go about creating a new semanticdb
>      >             backend?  I
>      >                     wanted to see
>      >                     if I could create one for Java that uses
>     javap as a
>      >             tag source.  Is
>      >                     there a recipe to follow?  I tried reading
>      >             semanticdb-global.el,
>      >                     and can
>      >                     continue to do that, but some guidance would be
>      >             extremely
>      >                     useful.  Thanks!
>      >
>      >
>      >                 You are in luck, this is implemented in
>      >             semanticdb-javap.el, and has
>      >                 worked ok for me.  Unfortunately, this is still in my
>      >             android branch
>      >                 in bzr, so it is not quite so easy to get at.
>      >
>      >                 The browsable tree is here:
>      >
>      > http://cedet.bzr.sourceforge.____net/bzr/cedet/code/android/____files
>      > <http://cedet.bzr.sourceforge.__net/bzr/cedet/code/android/__files
>      > <http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>>
>      >
>      >                 It depends on changes in the java parser on that
>     branch
>      >             also.
>      >
>      >                 If you'd like to try out the android branch that
>      >             includes this, you
>      >                 can use bzr to download it.
>      >
>      >                 bzr checkout
>      >
>      >
>     bzr://cedet.bzr.sourceforge.____net/bzrroot/cedet/code/android
>      > <http://cedet.bzr.sourceforge.__net/bzrroot/cedet/code/android
>      > <http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android>__>
>      >             cedet
>      >
>      >
>      >                 I've hooked it up with default support for
>     android, but
>      >             other types
>      >                 of classpaths are not in by default.  If anyone would
>      >             like to add
>      >                 such support, let me know.
>      >
>      >                 Good Luck
>      >                 Eric
>      >
>      >
>      >
>      >
>      >
>     ------------------------------__------------------------------__------------------
>      >             AppSumo Presents a FREE Video for the SourceForge
>     Community
>      >             by Eric
>      >             Ries, the creator of the Lean Startup Methodology on
>     "Lean
>      >             Startup
>      >             Secrets Revealed." This video shows you how to
>     validate your
>      >             ideas,
>      >             optimize your ideas and identify your business strategy.
>      > http://p.sf.net/sfu/__appsumosfdev2dev
>      > <http://p.sf.net/sfu/appsumosfdev2dev>
>      >
>      >
>      >
>      >             _________________________________________________
>      >             cedet-semantic mailing list
>      >             cedet-semantic@...
>     <http://sourceforge.net>
>      > <mailto:cedet-semantic@...
>     <mailto:cedet-semantic@...>>
>      > https://lists.sourceforge.net/__lists/listinfo/cedet-semantic
>     <https://lists.sourceforge.net/lists/listinfo/cedet-semantic>
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------------
>      >     AppSumo Presents a FREE Video for the SourceForge Community
>     by Eric
>      >     Ries, the creator of the Lean Startup Methodology on "Lean
>     Startup
>      >     Secrets Revealed." This video shows you how to validate your
>     ideas,
>      >     optimize your ideas and identify your business strategy.
>      > http://p.sf.net/sfu/appsumosfdev2dev
>      >     _______________________________________________
>      >     cedet-semantic mailing list
>      > cedet-semantic@...
>     <mailto:cedet-semantic@...>
>      > <mailto:cedet-semantic@...
>     <mailto:cedet-semantic@...>>
>      > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>      >
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------------
>      > AppSumo Presents a FREE Video for the SourceForge Community by Eric
>      > Ries, the creator of the Lean Startup Methodology on "Lean Startup
>      > Secrets Revealed." This video shows you how to validate your ideas,
>      > optimize your ideas and identify your business strategy.
>      > http://p.sf.net/sfu/appsumosfdev2dev
>      >
>      >
>      >
>      > _______________________________________________
>      > cedet-semantic mailing list
>      > cedet-semantic@...
>     <mailto:cedet-semantic@...>
>      > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
>     ------------------------------------------------------------------------------
>     AppSumo Presents a FREE Video for the SourceForge Community by Eric
>     Ries, the creator of the Lean Startup Methodology on "Lean Startup
>     Secrets Revealed." This video shows you how to validate your ideas,
>     optimize your ideas and identify your business strategy.
>     http://p.sf.net/sfu/appsumosfdev2dev
>     _______________________________________________
>     cedet-semantic mailing list
>     cedet-semantic@...
>     <mailto:cedet-semantic@...>
>     https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
>
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>
>
>
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic

Hello

I put some comemts inline

On Thu, Sep 1, 2011 at 3:49 AM, Eric M. Ludlam <ericludlam@...> wrote:
> Thus, you can setup semanticdb features without ever using EDE.  If you
> do use EDE, then EDE can provide some of the information automatically
> if it can figure it out.
>
> Thus, if you edit the classpath variable with the locations of your
> system jar files, that should allow the javap database to provide the
> info you need.
>
> The include path is used for finding sources, as opposed to the jar
> files which will not be searchable without using javap to decode them.
> If all your code is in sources, I find it interesting that the
> ede-cpp-root project was helpful in that way, as I hadn't thought of that.
>
> Anyway, EDE is not necessary.  It does, however, provide an easy place
> to put configurations unique to different parts of the file system.  As
> such, I recommend using one when possible.  It would be nice to have a
> java specific project too, though most folks just use JDEE, and do not
> need to use any configurations in CEDET specifically since JDEE usually
> provides those features.
>
> Ideally, the classpath would self-populate, but I don't really know how
> to teach it where the system jar files are in some reliable way.  It is
> possible to use javap with the system classpath, but I ran into trouble
> since you can't query the system jar files for the lists of all the
> classes in them.  (AFAIK anyway).

I think, that teaching where "system" jars are is a task of specific
project. For example, you can ask maven to generate classpath from all
dependencies that are specified in pom.xml.

For Java's jars we could generate this database once for each Java
version and distribute this database separately. In this case, project
should specify which java version is used (or detect it automatically)

> The semanticdb-project-roots is a way of telling semantic, without using
> EDE, where to stop during semanticdb global searches.  If you don't get
> all your files parsed ahead of time, however, it won't do much.  As it
> turns out, EDE adds itself to the roots lists, and provides those
> directories automatically.
>
> Eric
>
> On 08/27/2011 03:09 PM, David Ventimiglia wrote:
>> Hi!
>>
>> I see from August 10, 2011 that you merged many things from your Android
>> branch over to the trunk, so that CEDET now has greater support for Java
>> (among other things).  Thanks!  In your notice, you wrote,
>>
>> "If you just do Java w/out Android, you can setup your classpath in
>> Emacs, and also enjoy full smart completion on a wide array of syntaxes."
>>
>> What exactly does this mean?  For instance the only place I see in Emacs
>> (really, in CEDET) to set up a classpath is semanticdb-javap-classpath.
>> Is that what you're referring to?  Is this all that's needed, or are
>> there other steps that are needed?  For instance, I have not (yet) set
>> up any specific EDE projects for my Java projects.  In the past, I'd
>> used ede-cpp-root in order to specify :system-include-path, and that
>> actually worked well at finding Java source files.  I also once
>> subclassed ede-cpp-root to do essentially the same thing.  Is an EDE
>> project still necessary?  Seems like it would be, though I wonder if I
>> can get away with just using semanticdb-project-roots instead.  That
>> never worked for me in the past, though I'm not sure why.
>>
>> Thanks!
>> Cheers,
>> David
>>
>> On Thu, Jul 14, 2011 at 4:35 AM, Eric M. Ludlam <ericludlam@...
>> <mailto:ericludlam@...>> wrote:
>>
>>     Semanticdb will always check the files to see if reparsing is necessary.
>>       There are some cases (usually labeled as 'fast' in the code) that will
>>     skip that step, but all commands will do a full stat to be sure.
>>
>>     The exception is for back-ends that poll from a 3rd party tool like
>>     global, which will update whenever global feels like updating.
>>
>>     Eric
>>
>>     On 07/13/2011 12:43 PM, Jai Dayal wrote:
>>      > This might be out of context, but it might be more efficient than
>>      > creating a new thread.
>>      >
>>      > When I create new header files, classes, etc, do I have to update the
>>      > semanticdb some how, or is this done automatically?
>>      >
>>      > Jai
>>      >
>>      > On Wed, Jul 13, 2011 at 10:40 AM, David Ventimiglia
>>     <dventimi@... <mailto:dventimi@...>
>>      > <mailto:dventimi@... <mailto:dventimi@...>>> wrote:
>>      >
>>      >     Hi Eric,
>>      >
>>      >     I was using ede-cpp-root for Java even though it's specific to C
>>      >     files, since it had some of the desirable properties.
>>       Namely, the
>>      >     ability easily to define a project root, and the ability
>>     easily to
>>      >     plug in system directories.  I didn't want to have the kind
>>     of EDE
>>      >     project that relies on a particular file in every directory, like
>>      >     the Makefiles you would have with recursive make.  Seems to
>>     me that
>>      >     fits better with the way Java does things.  I'm not sure, but I
>>      >     think the parts of ede-cpp-root that are the most C-specific
>>     relate
>>      >     to defining and building targets.  If that's true, those are
>>     things
>>      >     I don't much care about, since I have my own stuff for
>>     managing the
>>      >     build.  Though, as you point out, it doesn't implement
>>      >     ede-java-classpath.
>>      >
>>      >     I could try to make a Java-specific ede-java-root, or to use
>>      >     ede-generic, whichever is more suitable for the task.
>>       Mainly, I'd
>>      >     like Emacs to have easy and reliable access to tags when visiting
>>      >     Java files, in service of all the other stuff in CEDET that
>>     can make
>>      >     use of tags.  ede-cpp-root works surprisingly well.  But as
>>     far as I
>>      >     know, the only way it gets tags is to have semantic parse the
>>     source
>>      >     files of all the includes, and it'd be nice also to be able
>>     to get
>>      >     them from JAR files and class files, in a sort of seamless way.
>>      >
>>      >     I've used JDEE for years and years and know it to be very good.
>>      >     Still, I think there'd be an appetite for a lightweight,
>>     pure-CEDET
>>      >     solution for getting all the tags for Java file.
>>      >
>>      >     Anyway, so what your saying is, one option is to implement
>>      >     ede-java-root and implement ede-java-classpath, is that correct?
>>      >     Should I sub-class ede-cpp-root, or write ede-java-root from
>>      >     scratch?  Could your Android project type be adapted into a
>>     generic
>>      >     Java project type?
>>      >
>>      >     Thanks!
>>      >     Cheers,
>>      >     David
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >     On Wed, Jul 13, 2011 at 4:26 AM, Eric M. Ludlam
>>      > <ericludlam@... <mailto:ericludlam@...>
>>     <mailto:ericludlam@... <mailto:ericludlam@...>>> wrote:
>>      >
>>      >         Hi,
>>      >
>>      >         ede-cpp-root is specific to C files, and doesn't
>>     implement the
>>      >         EDE method ede-java-classpath.  I suppose it could, as it
>>      >         wouldn't really need much else other than a slot to
>>     specify that
>>      >         path in the main project class.
>>      >
>>      >         I expect it should be more generic a name than that, but
>>     that's
>>      >         what we've got at the moment.
>>      >
>>      >         Anyway, I've always left the java project stuff to JDEE which
>>      >         knows about classpaths and such, but I haven't linked to two
>>      >         together.
>>      >
>>      >         Someone would need to created an ede-java-root project to
>>     build
>>      >         something specific for java and its features.  Alternately,
>>      >         someone could add some stuff to ede-generic if the build
>>     systems
>>      >         for Java are particularly deterministic.  In either case, a
>>      >         project needs to implement the classpath method, and so far,
>>      >         only the android project does that because that's the
>>     only thing
>>      >         I've tried to do so far.
>>      >
>>      >         Chasing either of the two EDE project types should be pretty
>>      >         easy. There are good pre-existing examples in both cases.
>>      >
>>      >         Eric
>>      >
>>      >
>>      >         On 07/12/2011 11:54 PM, David Ventimiglia wrote:
>>      >
>>      >             This is great!  How would I plug this into a
>>      >             system-include-path for an
>>      >             EDE project, to pull tags from, say, JAR files rather
>>     than
>>      >             Java source
>>      >             files.  Currently, I'm using an ede-cpp-root-project,
>>     with
>>      >             :system-include-path having a list of directories that
>>      >             contain Java
>>      >             source files for various libaries and such.  But it's
>>     not always
>>      >             convenient or possible to have the source code, so it
>>     would
>>      >             be nice to
>>      >             get the tags from compiled JAR files instead.
>>      >
>>      >             On Tue, Jul 12, 2011 at 7:49 PM, Eric M. Ludlam
>>      > <ericludlam@... <mailto:ericludlam@...>
>>     <mailto:ericludlam@... <mailto:ericludlam@...>>
>>      > <mailto:ericludlam@... <mailto:ericludlam@...>
>>     <mailto:ericludlam@... <mailto:ericludlam@...>>>>
>>      >             wrote:
>>      >
>>      >                 On 07/12/2011 02:28 PM, David Ventimiglia wrote:
>>      >
>>      >                     Hi!
>>      >
>>      >                     How would I go about creating a new semanticdb
>>      >             backend?  I
>>      >                     wanted to see
>>      >                     if I could create one for Java that uses
>>     javap as a
>>      >             tag source.  Is
>>      >                     there a recipe to follow?  I tried reading
>>      >             semanticdb-global.el,
>>      >                     and can
>>      >                     continue to do that, but some guidance would be
>>      >             extremely
>>      >                     useful.  Thanks!
>>      >
>>      >
>>      >                 You are in luck, this is implemented in
>>      >             semanticdb-javap.el, and has
>>      >                 worked ok for me.  Unfortunately, this is still in my
>>      >             android branch
>>      >                 in bzr, so it is not quite so easy to get at.
>>      >
>>      >                 The browsable tree is here:
>>      >
>>      > http://cedet.bzr.sourceforge.____net/bzr/cedet/code/android/____files
>>      > <http://cedet.bzr.sourceforge.__net/bzr/cedet/code/android/__files
>>      > <http://cedet.bzr.sourceforge.net/bzr/cedet/code/android/files>>
>>      >
>>      >                 It depends on changes in the java parser on that
>>     branch
>>      >             also.
>>      >
>>      >                 If you'd like to try out the android branch that
>>      >             includes this, you
>>      >                 can use bzr to download it.
>>      >
>>      >                 bzr checkout
>>      >
>>      >
>>     bzr://cedet.bzr.sourceforge.____net/bzrroot/cedet/code/android
>>      > <http://cedet.bzr.sourceforge.__net/bzrroot/cedet/code/android
>>      > <http://cedet.bzr.sourceforge.net/bzrroot/cedet/code/android>__>
>>      >             cedet
>>      >
>>      >
>>      >                 I've hooked it up with default support for
>>     android, but
>>      >             other types
>>      >                 of classpaths are not in by default.  If anyone would
>>      >             like to add
>>      >                 such support, let me know.
>>      >
>>      >                 Good Luck
>>      >                 Eric
>>      >
>>      >
>>      >
>>      >
>>      >
>>     ------------------------------__------------------------------__------------------
>>      >             AppSumo Presents a FREE Video for the SourceForge
>>     Community
>>      >             by Eric
>>      >             Ries, the creator of the Lean Startup Methodology on
>>     "Lean
>>      >             Startup
>>      >             Secrets Revealed." This video shows you how to
>>     validate your
>>      >             ideas,
>>      >             optimize your ideas and identify your business strategy.
>>      > http://p.sf.net/sfu/__appsumosfdev2dev
>>      > <http://p.sf.net/sfu/appsumosfdev2dev>
>>      >
>>      >
>>      >
>>      >             _________________________________________________
>>      >             cedet-semantic mailing list
>>      >             cedet-semantic@...
>>     <http://sourceforge.net>
>>      > <mailto:cedet-semantic@...
>>     <mailto:cedet-semantic@...>>
>>      > https://lists.sourceforge.net/__lists/listinfo/cedet-semantic
>>     <https://lists.sourceforge.net/lists/listinfo/cedet-semantic>
>>      >
>>      >
>>      >
>>      >
>>     ------------------------------------------------------------------------------
>>      >     AppSumo Presents a FREE Video for the SourceForge Community
>>     by Eric
>>      >     Ries, the creator of the Lean Startup Methodology on "Lean
>>     Startup
>>      >     Secrets Revealed." This video shows you how to validate your
>>     ideas,
>>      >     optimize your ideas and identify your business strategy.
>>      > http://p.sf.net/sfu/appsumosfdev2dev
>>      >     _______________________________________________
>>      >     cedet-semantic mailing list
>>      > cedet-semantic@...
>>     <mailto:cedet-semantic@...>
>>      > <mailto:cedet-semantic@...
>>     <mailto:cedet-semantic@...>>
>>      > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>      >
>>      >
>>      >
>>      >
>>      >
>>     ------------------------------------------------------------------------------
>>      > AppSumo Presents a FREE Video for the SourceForge Community by Eric
>>      > Ries, the creator of the Lean Startup Methodology on "Lean Startup
>>      > Secrets Revealed." This video shows you how to validate your ideas,
>>      > optimize your ideas and identify your business strategy.
>>      > http://p.sf.net/sfu/appsumosfdev2dev
>>      >
>>      >
>>      >
>>      > _______________________________________________
>>      > cedet-semantic mailing list
>>      > cedet-semantic@...
>>     <mailto:cedet-semantic@...>
>>      > https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>
>>     ------------------------------------------------------------------------------
>>     AppSumo Presents a FREE Video for the SourceForge Community by Eric
>>     Ries, the creator of the Lean Startup Methodology on "Lean Startup
>>     Secrets Revealed." This video shows you how to validate your ideas,
>>     optimize your ideas and identify your business strategy.
>>     http://p.sf.net/sfu/appsumosfdev2dev
>>     _______________________________________________
>>     cedet-semantic mailing list
>>     cedet-semantic@...
>>     <mailto:cedet-semantic@...>
>>     https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> EMC VNX: the world's simplest storage, starting under $10K
>> The only unified storage solution that offers unified management
>> Up to 160% more powerful than alternatives and 25% more efficient.
>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>>
>>
>>
>> _______________________________________________
>> cedet-semantic mailing list
>> cedet-semantic@...
>> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> cedet-semantic mailing list
> cedet-semantic@...
> https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>



-- 
With best wishes,                    Alex Ott
http://alexott.net/
Tiwtter: alexott_en (English), alexott (Russian)
Skype: alex.ott

On 09/01/2011 04:05 AM, Alex Ott wrote:
> Hello
>
> I put some comemts inline
>
> On Thu, Sep 1, 2011 at 3:49 AM, Eric M. Ludlam<ericludlam@...>  wrote:
>> Thus, you can setup semanticdb features without ever using EDE.  If you
>> do use EDE, then EDE can provide some of the information automatically
>> if it can figure it out.
>>
>> Thus, if you edit the classpath variable with the locations of your
>> system jar files, that should allow the javap database to provide the
>> info you need.
>>
>> The include path is used for finding sources, as opposed to the jar
>> files which will not be searchable without using javap to decode them.
>> If all your code is in sources, I find it interesting that the
>> ede-cpp-root project was helpful in that way, as I hadn't thought of that.
>>
>> Anyway, EDE is not necessary.  It does, however, provide an easy place
>> to put configurations unique to different parts of the file system.  As
>> such, I recommend using one when possible.  It would be nice to have a
>> java specific project too, though most folks just use JDEE, and do not
>> need to use any configurations in CEDET specifically since JDEE usually
>> provides those features.
>>
>> Ideally, the classpath would self-populate, but I don't really know how
>> to teach it where the system jar files are in some reliable way.  It is
>> possible to use javap with the system classpath, but I ran into trouble
>> since you can't query the system jar files for the lists of all the
>> classes in them.  (AFAIK anyway).
>
> I think, that teaching where "system" jars are is a task of specific
> project. For example, you can ask maven to generate classpath from all
> dependencies that are specified in pom.xml.
>
> For Java's jars we could generate this database once for each Java
> version and distribute this database separately. In this case, project
> should specify which java version is used (or detect it automatically)

Yes, that is possible, but that requires special EDE projects (or other 
code) for each.  If a user knows how to run maven to spit out that info, 
and then the user puts it into the classpath, that is fine too.

What I thought was going on is that it will tell you about the 'extra' 
stuff on the classpath, but not have the system classpath.  If there is 
some recipe for different build systems that can solve that, then that 
would be helpful first as a piece of documentation, and later as code 
that could be added in.  I don't use Java much (just my toy on Android) 
so I don't know what those tricks might be.

Eric

Eric

Meant to send this to the list.  Essentially, with a minor hack to
semanticdb-javap.el, I'm able to fetch tags from compiled JAR files.
Very nice!
Cheers,
David


---------- Forwarded message ----------
From: David Ventimiglia <dventimi@...>
Date: Thu, Sep 1, 2011 at 12:41 PM
Subject: Re: [cedet-semantic] creating a semanticdb backend?
To: "Eric M. Ludlam" <ericludlam@...>


Thanks, Eric.  It's good to know that semantic and ede augment, rather
than depend on each other.  Very nice.  I'm not opposed to using ede
and probably will switch back to it very soon, but I thought I'd try
using just the features of semanticdb first, to see how far I could
get.  I did notice that, at least in the version of
semanticdb-javap.el I have (I believe I have the latest code from the
bzr repo), in semanticdb-javap-classpath-objects, there's no reference
to the custom variable semanticdb-java-classpath.  I added that
variable to the list of things appended together to form the classpath
list, in semanticdb-javap-classpath-objects, right after edepaths and
edeclasspath.  After that, the java-mode override of
semanticdb-find-translate-path was able to find my java imports.  Very
cool!

Cheers,
David