Re: Proposed New Structure (starter for 10)

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

W dniu 14.08.2015 o 18:51, Phillip Lord pisze:
 > https://github.com/phillord/jde-with-clojure-backend
 >
 > The four components are:
In the repo they are separate projects. Was that on purpose?

 > jde -- this will be the Java centric major mode. It will involve NO JVM
 > interaction and not depend on any of the other parts. The "minimal
 > viable product" here is a ELPA packaged major mode that is a child of
 > Java mode and adds no functionality.
I don't get it. If it adds no functionality then what is its responsibility?

 > jde-interactive (crappy name, sorry) -- a minor mode which will be
 > active once the JVM (bsh interpreter equivalent) has been started and is
 > running.
What should be responsibility of this component?

Does it have to be in separate project? IMHO having them in the same repository
and directory would make it easier for us to manage - develop and release.

 > In the short term, this will have a dependency on cider, but
 > eventually this may just become a dependency on nrepl-client.el. I say
 > may, because, I think quite a bit of the cider functionality (like the
 > inspector) is JVM centric and entirely relevant.
IIUC cider has some functionality that would be useful for us. I don't know 
cider well enough to justify/deny that, but my concerns are:
1. Is cider code written in a way that it can be reused from outside cider by
    someone who is _not_ cider author?
2. What dependencies exactly we would bring with cider?
3. IIUC if we depend on some cider version then automatically Emacs user has to
    use that version. So if we, for some reason, depend on some older version,
    then it prevent user from upgrading cider.

 > The MVP here is to use maven inside a project to launch an nrepl, and
 > then to invoke a call to get the version number of the jde-nrepl
 > middleware and check that it is consistent with the version of jde-interactive.
Do you mean to start nrepl from Maven in a maven-based project?
In such case users would need to add nrepl libs to each project they want to
work on. What about other types of projects and projects without any build tool?
Am I missing something?

Or maybe Maven starts nrepl and the loads a maven-based project?

 > jde-nrepl -- this is the nrepl middleware that provides all the backend
 > functionality, like class look up and the like. The MVP here is to
 > install some middleware into a nrepl, which returns a version map for
 > checking my jde-interactive, and which is packaged as a maven dependency
 > on clojars.
 >
 > jdee-sample -- this is a sample project. Requirements in the short term
 > are that the project depend on jde-nrepl and
 > https://github.com/talios/clojure-maven-plugin to provide the nrepl
 > functionality we need. Typing "maven jde:nrepl" or equivalent should
 > result in a nrepl session.
Dependency cannot be from project to IDE. In many, many projects nobody will 
allow to add such dependency. IDE (our server side part) has to start a project
with deps we need.
To do that a user would need to have a jde-server var set to path of our
backend code, which we would start from jde-interactive.

 > MVP having a packaged jde-interactive that can install, that starts when
 > we open "App.java" in jdee-sample, and which can then invoke a method of
 > the class object coming from App.java.
IIUC when user opens App.java then we should find project file, configure
everything, start server and then do code completion, right?
What when user will open a Java file in another project?

In such case I would prefer project-centric approach. User creates/opens 
project, have JDEE configured for that project. If s/he wants to work on another 
project (have code completion etc.) s/he would need to open other
project (config, start server, etc.).

 > In the long term, I would expect that all four of these would be
 > separate repos.
I was thinking to have only two separate projects at the beginning:
1. jdee-emacs/jdee with all elisp part (project config, jde-interactive - maybe
    jvm-connector?, etc.)
2. jdee-emacs/jde-server with Java code and all JVM related stuff (nrepl, etc.).
    It could be just a Maven project.

Thanks,
Przemysław

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