Re: Proposed New Structure (starter for 10)

W dniu 15.08.2015 o 11:05, Phillip Lord pisze:
> 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:
Just to be clear: by saying that I don't mean that we should implement all that
stuff - many of this functionality is already available in different emacs
packages. We should reuse as much as we can.

My point was only to present what I expect from JDEE, not how it is implemented.

> My starting point is that I would rather have a major-mode to open files
> and does nothing else,
Here our expectations are different. I would like to work on a Java project
using JDEE, effectively. To do that I would need the functionality I've listed.
Intellij has many more features, but, frankly, most of them is not needed.
Everyday effective work is done using those listed features.

> but is installable via package.el. This is the
> most critical change that we must achieve. Until this happens JDEE is
> effectively junk.
See cask branch - I put lisp files in top dir (as you suggested) and now basic
Cask build works (with tests).

> 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.
I agree if you are talking about reuse.

> 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!).
I'm ok with the tooling, but not with how it should be connected with the
project. The tooling should embrace a project, not other way around.

> 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.

> Viewing Javadocs. We launch a web browser. EWW support for Javadoc (or
> vice versa) would be fun.
Launching web browser is painfully slow, but with eww user experience may be
better. Anyways this is not the highest priority.

> Extensibility -- no support. I mean, Emacs is extensible by definition.
I meant an API that would allow someone to write a plugin, which would add 
support for some Java technology - e.g. Spring support (navigation around
application context). To do that JDEE will need to provide some informations
about a project.
This is not the highest priority, but IMHO still important.

> 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
I also have limited time. But I think that with clear project vision, goals,
small tasks (one at a time), and easy way to contribute we'll be able to
produce a good software.

IMHO it's very important to make it easy for people to contribute to the
project and move to GH was very good step in that direction.

Cheers,
Przemysław

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