Re: Proposed New Structure (starter for 10)

Przemysław Wojnowski <[email protected]> writes:

> To begin with. My project vision is that JDEE will be (at least) something
> IDE-like, which means that it would be:
> 1. Project oriented (contrary to file oriented). It should be good enough to
>    work on enterprise Java projects - create and load them.
> 2. Have core features:
>    - automatic configuration of classpaths (source, compile, test, runtime)
>      from build tools (Maven, Gradle, etc.)
>    - code completion
>    - jumping around the code (also into libraries, when code is available)
>    - viewing javadocs
>    - running app (static and in a container - e.g. Tomcat)
>    - running tests
>    - finding usages of fields, methods, classes
>    - constant compilation
>    - debugger
>    - extendibility (through plugins)
>    - basic refactoring support
>
> I'm not interested in working on a major-mode just to open a Java file from
> time to time - java-mode is good enough for that purpose.
>
> It's just to be clear what my goals are. If your's are different then it would
> be good to know sooner than later. :-)

My starting point is that I would rather have a major-mode to open files
and does nothing else, but is installable via package.el. This is the
most critical change that we must achieve. Until this happens JDEE is
effectively junk.

After this my vision is subtly different. I believe that JDEE should be
relatively small and do as little as possible, while allowing Emacs and
the environment to do most or all of the things that you speak off.

So, project support. Eric has already mentioned EDE. Combine this with
rapid navigation tools like projectile, and we should have what we need.
The rest of the project support can be binned.

I believe we need connectivity to the JVM. I suggest nrepl for this, as
it allows us to connect, and gives structured access, an interactive
repl (albeit Clojure based rather than bsh which looks like Java) and an
independent channel for tooling. This already exists. My starter for 10
just adds maven support (will when it works!).

Automatic configuration of classpaths. Once we have JVM connectivity, I
believe, JDEE does not need configuration of the classpath. Rather Maven
or other build tools we support will do this. JDEE then should not need
to know where the classes are.

Auto-completion -- we should support completion-at-point-function, using
a connection to the JVM, and a Java (or JVM) based completion library.
Actual completion can be done by company, auto-complete or what ever.

Source browsing -- we use the JVM connection to a build tool to find the
source, combined with EDE and projectile.

Viewing Javadocs. We launch a web browser. EWW support for Javadoc (or
vice versa) would be fun.

Object/Class introspection -- CIDER already does this.

Find usages of -- backend middleware. Hopefully we can plugin to helm
and the like.

Constant Compilation (and class reloading) -- no idea how to achieve
this, but I think it is not an Emacs issue, I think it is a build tool
and repl issue. We should work with CIDER and ENSIME to achieve this, as
they would probably both like it.

Extensibility -- no support. I mean, Emacs is extensible by definition.
An nrepl backend is extensible by definition. We just follow the
conventions for packaging, and JDEE will fit straight into the Emacs
ecosystem. JDEE needs to add nothing.

My point is, JDEE has been a fore-runner in many of these things, but is
now carrying a lot of baggage. A lot of it's features now shadow more
general implementations. We need to throw out everything but the glue
that we need.

As I said before, though, I only have a limited time to work on this. I
think my structure makes sense, and will take the least effort. But I do
not even have a lot of time to convince people, let alone code it. I'll
get my core idea up there as a starting point. But this is probably
where I will leave it. If no one takes it up, it's not going anywhere.

Phil

------------------------------------------------------------------------------
_______________________________________________
jdee-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jdee-devel