Re: Proposed New Structure (starter for 10)

We need something a little more formal to sort what everyone wants and who's tackling it.  You've already started a list to this effect on GH--maybe we expand on it.


On Aug 14, 2015, at 5:40 PM, Przemysław Wojnowski <[email protected]> wrote:

> 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


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