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@gmail.com> 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@gmail.com
<mailto:ericludlam@gmail.com>> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-semantic