Re: Proposed New Structure (starter for 10)

W dniu 17.08.2015 o 18:12, Phillip Lord pisze:
> We need to think about release management a bit. How far away are we
> from being able to release something that would work on Marmalade or MELPA?
AFAIK merging the branch to master, and creating PR to MELPA.
After merge to master we can also enable Travis status (everything is
configured, just need to be enabled in Travis).

The jars (jde and bsh) from jdee-server are needed to preserve current
functionality.

>>> 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.
> Yes, but perhaps a bit more so. I would probably also say that limiting
> efforts to those things that Emacs does do is sensible.
Lets start with replacing old code with functionality provided by other packages 
(code completion, libs for files/strings, etc.)

>>> 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.
I still don't understand how to enable nrepl without adding it to a project
configuration (e.g. project's pom.xml) - in many projects such things cannot be
added.

> In the case of Java "project" has no meaning *within* java. So, it is
> the tooling which defines the project to a greater or lesser extent. It
> is maven (or eclipse) which defines most projects. Or OSGI.
Also metadata defines what is a project - for example Spring application
context.

> This may change with Project Jigsaw, but at the moment, the tooling is
> the project. JDEE needs to not recreate that, I think. At the moment, it
> does have a notion of a project (i.e. a think with a prj.el file) but I
> would argue that this is largely a hangover from the days when JDE was a
> JDK wrapper.
Anyways, this will become clear after during development.

>>> 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.
For projects that use build tools it may not be needed at the beginning.
But for automatic compilation or to provide configuration for some other tools
then it may be needed.

Anyway it has to know where sources (main and test) are to know where to put
new code.

> EWW is quite limited. Launching web browsers is slow, but moving URLs is
> okay, I think?
Javadocs are mostly almost text and most important is to show it fast.

>>> 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.
>
> One thing that, I think, would be good to avoid is the situation where
> we end up with 150 packages on ELPA all of which are plugins
> "jdee-spring", "jde-hibernate", "jde-osgi" and so on. Helm has this
> problem to some extent. If JDEE consistently uses autoloads and is
> packaged cleanly (see other thread!) why not just incorporate these?
We don't have to worry about it now.

> There is a compromise here, of course. It's not good if JDE gets into a
> tangled mess with too much old baggage in it (which is sort of like it
> is now!).
Yes. So let's start with replacing it with libraries.

------------------------------------------------------------------------------