Re: Next Gen JDEE

Paul Landes <[email protected]> writes:

> No, I'm talking about what would replace prj.el. 

Currently, prj.el is a user-provided file that duplicates some
information in their build files (classpath, source dir list, etc).

> Create a gradle project and build away but let's write (for starters)
> only one module which gets environment from a pom (i.e. where is the
> source, where are the classes to be compiled if it needs it, resources
> etc).

Right; it would be nice if Emacs could read those build files (or run a
tool that reads them) and extract the needed information; that's what I
did for GNAT build files in ada-mode.

But there's no reason for jdee2 to impose the choice of build system; it
should handle all. So I don't understand why you said gradle is
"overkill for what we need".

The best way to do this is for Emacs core to define a project API, and
for there to be one implementation of it for each build tool. Then jdee2
can simply assume that exists, and use the project API to query for the
needed info.

The jdee2 project could provide the back ends if others don't, but they
should be separate from the jdee2 distribution; separate ELPA packages,
at least.

There is an Emacs git branch for such a core project API: scratch/project.

It may turn out that Java projects need info that other projects don't,
in which case jdee2 would define an extended project API that the
backends would implement. That would be a way to start now without
depending on the Emacs git branch.

At the very least, jdee should be designed to support more than one
build tool, probably via dispatching to backends.


-- 
-- Stephe

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/