Thread: [jdee-devel] Proposed New Structure (starter for 10)
Brought to you by:
paullandes
From: <phi...@ne...> - 2015-08-14 16:52:01
|
So, I wanted to put some meat onto the bone of my proposed new structure for JDEE. It doesn't work yet, of course, but I think that it can in a relatively short space of time. https://github.com/phillord/jde-with-clojure-backend The four components are: 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. jde-interactive (crappy name, sorry) -- a minor mode which will be active once the JVM (bsh interpreter equivalent) has been started and is running. 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. 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. 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. 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. In the long term, I would expect that all four of these would be separate repos. That's the idea. The lisp packaging already works (as you can see form the dist directories that I should not have checked in). Most of the rest can be stolen from cider. Thoughts? Phil |
From: Przemysław W. <esp...@cu...> - 2015-08-14 22:40:25
|
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 |
From: Paul L. <la...@ma...> - 2015-08-14 23:19:29
|
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 <esp...@cu...> 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 > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: <phi...@ne...> - 2015-08-15 09:05:40
|
Przemysław Wojnowski <esp...@cu...> 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 |
From: Przemysław W. <esp...@cu...> - 2015-08-15 10:09:11
|
W dniu 15.08.2015 o 11:05, Phillip Lord pisze: > Przemysław Wojnowski <esp...@cu...> 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 |
From: Stephen L. <ste...@st...> - 2015-08-15 18:04:51
|
phi...@ne... (Phillip Lord) writes: > 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. +1. However, JDEE needs to provide some things to "the rest of Emacs" to leverage that properly. > So, project support. Eric has already mentioned EDE. JDEE needs to provide an EDE java project. > Combine this with rapid navigation tools like projectile, I suggest we stick to Emacs core functionality when we can. That means xref, here (in Emacs 25). If xref is insufficient, we can help extend it. > 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. There is a trade-off here when editing code; if the code has syntax errors, you may get better results from Semantic than from the java compiler. So we should design for a choice of completion backends, to allow experimenting. > 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. +1. -- -- Stephe |
From: Lee H. <lee...@fa...> - 2015-08-16 19:31:24
|
Phillip Lord writes: > 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. +1, having to manually install is a non-starter for a lot of people. Having an actual package so people can follow along or MELPA would be fantastic. > 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. +1, I think jde-mode should be a minor mode rather than a major-mode, all the non-interactive parts should be part of java-mode and contributions/enhancements should be made there. > 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 think nrepl is a good choice for it, but I enjoy clojure so I might be biased. Perhaps for Java 9 the included JDK REPL would be a good idea though (since it will be supported by the OpenJDK team)? > 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. Yeah, just making the information available and using Emacss' completion is a good idea. > Source browsing -- we use the JVM connection to a build tool to find > the source, combined with EDE and projectile. This is largely already possible offline with gtags (which I use for Java development in Emacs currently). I'm not sure it's worth adding unless this can be as good or better than the gtags integration. > Object/Class introspection -- CIDER already does this. +1, a great feature that requires a connection to a JVM > 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. Constant compilation (to me) isn't such an important feature, but I *definitely* want to be able to compile the project/file manually with something like =C-c C-k= (ala Cider) or =C-c C-v C-c= (jde current). An important feature of the compilation (again, for me) would be integrating with Flycheck so I could see the lines that have compilation errors/warnings. > 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. I'm happy to work on an idea like this, but I don't have any history working with JDEE before, so I don't know the best way to go about this. My idea of a minimum-viable-project is one where I can do =M-x jde-connect= and then hit =C-c C-v C-c= to compile the project (or get the compilation errors). This includes JDEE detecting the project type and configuring the appropriate classpath. Just let me know how I can help ^_^ -- ;; Lee |
From: <phi...@ru...> - 2015-08-17 16:24:09
|
Lee Hinman <lee...@fa...> writes: > Phillip Lord writes: > >> 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. > > +1, having to manually install is a non-starter for a lot of people. > Having an actual package so people can follow along or MELPA would be > fantastic. > >> 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. > > +1, I think jde-mode should be a minor mode rather than a major-mode, > all the non-interactive parts should be part of java-mode and > contributions/enhancements should be made there. I think that there are a few practical issues here, esp with the release cycle and potentially with copyright policy for core. Having a small jde-major-mode, which is essentially java-mode + some improvements is less good than contributing straight through to core but may be a practical necessity. >> 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 think nrepl is a good choice for it, but I enjoy clojure so I might be > biased. Perhaps for Java 9 the included JDK REPL would be a good idea > though (since it will be supported by the OpenJDK team)? I would separate out "nrepl" and the current nrepl backend. Even if the JDK REPL existed in widespread usage, then we'd probably still want to use an NREPL client-server. Just to clarify, nrepl is a protocol for structured communication with a REPL process. It's an attempt to move Emacs away from the situation when it sends a string to a process, then parses the output and tries to put the two together. nrepl is a little Clojure biased, but is generic enough. I know, for instance, Vitalie Spinu has built a nrepl client/server for R, because parsing R output is a pain. I'd suggest the clojure backend, simply because it's JVM and some of the middleware (e.g. classpath, the object inspector, the stack trace presentation) is likely to be directly sharable. >> 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. > > Constant compilation (to me) isn't such an important feature, but I > *definitely* want to be able to compile the project/file manually with > something like =C-c C-k= (ala Cider) or =C-c C-v C-c= (jde current). An > important feature of the compilation (again, for me) would be > integrating with Flycheck so I could see the lines that have compilation > errors/warnings. I wonder whether Malabar mode would already provide this when integrated with JDE as a minor mode? > >> 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. > > I'm happy to work on an idea like this, but I don't have any history > working with JDEE before, so I don't know the best way to go about this. > > My idea of a minimum-viable-project is one where I can do =M-x > jde-connect= and then hit =C-c C-v C-c= to compile the project (or get > the compilation errors). This includes JDEE detecting the project type > and configuring the appropriate classpath. > > Just let me know how I can help ^_^ My starter for 10 works now, and installs the CIDER "classpath" middleware. Help would be appreciated, including just giving it a go and seeing if it makes sense for you. I'd like to get my code doing one useful thing (probably an auto-importer) working. After which, I will stop, as it will be complete as a proof-of-principle. Others are right -- we need to have a vaguely coherent vision about the way forward for the simple reason that none of us has the energy for a fork! Phil |
From: <phi...@ne...> - 2015-08-17 16:00:54
|
Stephen Leake <ste...@st...> writes: > phi...@ne... (Phillip Lord) writes: > >> 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. > > +1. However, JDEE needs to provide some things to "the rest of Emacs" to > leverage that properly. > >> So, project support. Eric has already mentioned EDE. > > JDEE needs to provide an EDE java project. I think this is sounds sensible, but I am not sure what it would bring. In particular, I'd be worried if it involves duplicating information between Emacs and what-ever build tool is being used (probably maven), unless we know how to completely automate this. >> Combine this with rapid navigation tools like projectile, > > I suggest we stick to Emacs core functionality when we can. That means > xref, here (in Emacs 25). If xref is insufficient, we can help extend it. > >> 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. > > There is a trade-off here when editing code; if the code has syntax > errors, you may get better results from Semantic than from the java > compiler. So we should design for a choice of completion backends, to > allow experimenting. Sorry, my fault, it is `completion-at-point-functions' i.e. plural. So this comes off the shelf, I think. And user configurable. So, we can, for example, do completion in comments as well whcih neither semantic nor java will naturally support. Phil |
From: Przemysław W. <esp...@cu...> - 2015-08-17 20:45:11
|
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. |
From: Stephen L. <ste...@st...> - 2015-08-17 22:37:17
|
phi...@ne... (Phillip Lord) writes: > Stephen Leake <ste...@st...> writes: > >> phi...@ne... (Phillip Lord) writes: >> >>> 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. >> >> +1. However, JDEE needs to provide some things to "the rest of Emacs" to >> leverage that properly. >> >>> So, project support. Eric has already mentioned EDE. >> >> JDEE needs to provide an EDE java project. > > I think this is sounds sensible, but I am not sure what it would bring. > In particular, I'd be worried if it involves duplicating information > between Emacs and what-ever build tool is being used (probably maven), > unless we know how to completely automate this. That's the point of the EDE project; it would get whatever info Emacs needs from maven (by reading files or calling an external tool; I don't know what maven provides in that way), and deliver it to Emacs via the EDE API. >>> 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. >> >> There is a trade-off here when editing code; if the code has syntax >> errors, you may get better results from Semantic than from the java >> compiler. So we should design for a choice of completion backends, to >> allow experimenting. > > Sorry, my fault, it is `completion-at-point-functions' i.e. plural. So > this comes off the shelf, I think. Hmm. Let's say the first item in that hook relies on the Java compiler, and the second on Semantic. We edit a few files (and save them), then try to do completion. The compiler completion tool notices the changed files, tries to run the compiler and fails, and returns nil. Then the Semantic tool runs and succeeds. That works, but may give a significant delay. In that case, the user can rearrange completion-at-point-functions until the code does compile. We might want a better way to do that. The java compiler based completion tool could check a flag that the user sets that says "don't bother", for example. It should not be hard to come up with a good way to switch between them. -- -- Stephe |
From: <phi...@ne...> - 2015-08-18 16:22:09
|
Stephen Leake <ste...@st...> writes: > phi...@ne... (Phillip Lord) writes: > >> In particular, I'd be worried if it involves duplicating information >> between Emacs and what-ever build tool is being used (probably maven), >> unless we know how to completely automate this. > > That's the point of the EDE project; it would get whatever info Emacs > needs from maven (by reading files or calling an external tool; I don't > know what maven provides in that way), and deliver it to Emacs via the > EDE API. Maven is a pain, I am afraid and trying to get it to provide anything coherent is difficult. This is why I thinking of launching a JVM and asking it about itself. This latter also works for any method of launching a JVM, so avoids supporting lots of different build tools beyond the launch of the JVM. That's the theory. But maven in a pain when launching the JVM also, so it might not be possible. >>>> 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. >>> >>> There is a trade-off here when editing code; if the code has syntax >>> errors, you may get better results from Semantic than from the java >>> compiler. So we should design for a choice of completion backends, to >>> allow experimenting. >> >> Sorry, my fault, it is `completion-at-point-functions' i.e. plural. So >> this comes off the shelf, I think. > > Hmm. Let's say the first item in that hook relies on the Java compiler, > and the second on Semantic. > > We edit a few files (and save them), then try to do completion. The > compiler completion tool notices the changed files, tries to run the > compiler and fails, and returns nil. Then the Semantic tool runs and > succeeds. > > That works, but may give a significant delay. In that case, the user can > rearrange completion-at-point-functions until the code does compile. We > might want a better way to do that. The java compiler based completion > tool could check a flag that the user sets that says "don't bother", for > example. It should not be hard to come up with a good way to switch > between them. Sounds sensible. I don't know how c-a-p-f works yet. It's something to be investigated. Phil |
From: Przemysław W. <esp...@cu...> - 2015-08-18 08:12:10
|
W dniu 18.08.2015 o 00:28, Phillip Lord pisze: >> The jars (jde and bsh) from jdee-server are needed to preserve current >> functionality. > This is kind of my worry. I realise that MELPA is bleeding edge, but > "install these jars as well" would, I think, by outside my definition of > "working". Now everything has to be downloaded and build every time anything changes - elisp or java. As of now elisp side changes way faster that java, so the elisp side is more important to build and install automatically, which cask branch does. Having to manually build and install a JAR once is not a big problem. Anyways, we have to start somewhere. IMHO you are trying to solve to many problems at the same time. To automate installation of Java part we will create a separate issue. > We could hack JDE to include a download step. Emacs has a url capability now. Download from where? Maybe sometime we'll be able to release JARs to some reasonable place (like maven central or clojars or some such repository). > We need to think a bit about what kind of dependencies we are prepared > to accept and what we are not. Specifically, in core, in ELPA, not in > ELPA, and stable (i.e. MELPA-stable/marmalade) or unstable (MELPA). Yes, but in a separate topic(s). After moving to ELPA. > Yep. There is a very simple answer to this, of course. I just wish I > [...] We'll work on that problems. > Spring always rather scared me, so I know little of it. "metadata" as in > Java annotation? Yes and no. It can be in Java annotations and/or XML (maybe in some other files too for other types of libraries, for example properties files). >>> 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. > > In a lot of cases, we just need removal. I would start off with all the > tempo stuff. It would probably make sense to write a list of things to > deprecate. Good idea. This way or another lets do one thing at a time. Move to cask and elpa allows us to release frequently and use libraries from package manager. Moreover it makes it easier for users to install and update the package. So IMHO we should do that despite manual installation of JARs (I can make it only one JAR). Then we can work on different things - removal of old stuff, reuse of existing Emacs functionality or from existing packages, reuse of common libs, connection with nrepl, automatic installation of Java package, etc. Cheers, Przemysław |
From: David E. <de...@ra...> - 2015-08-18 12:55:17
|
Stephen Leake writes: > phi...@ne... (Phillip Lord) writes: > >> Stephen Leake <ste...@st...> writes: >> >>> phi...@ne... (Phillip Lord) writes: >>> >>>> 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. >>> >>> +1. However, JDEE needs to provide some things to "the rest of Emacs" to >>> leverage that properly. >>> >>>> So, project support. Eric has already mentioned EDE. >>> >>> JDEE needs to provide an EDE java project. >> >> I think this is sounds sensible, but I am not sure what it would bring. >> In particular, I'd be worried if it involves duplicating information >> between Emacs and what-ever build tool is being used (probably maven), >> unless we know how to completely automate this. > > That's the point of the EDE project; it would get whatever info Emacs > needs from maven (by reading files or calling an external tool; I don't > know what maven provides in that way), and deliver it to Emacs via the > EDE API. FWIW, upstream CEDET has some support for Java projects in EDE (ant.el, java-root.el, jvm-base.el, and maven2.el). I did not merge them to Emacs because I was unsure how usable/stable they are. -David |
From: Paul L. <la...@ma...> - 2015-08-18 13:03:18
|
When will the cask branch be ready to merge into master? On Aug 18, 2015, at 3:12 AM, Przemysław Wojnowski <esp...@cu...> wrote: > W dniu 18.08.2015 o 00:28, Phillip Lord pisze: >>> The jars (jde and bsh) from jdee-server are needed to preserve current >>> functionality. >> This is kind of my worry. I realise that MELPA is bleeding edge, but >> "install these jars as well" would, I think, by outside my definition of >> "working". > Now everything has to be downloaded and build every time anything changes - > elisp or java. As of now elisp side changes way faster that java, so the elisp > side is more important to build and install automatically, which cask branch > does. Having to manually build and install a JAR once is not a big problem. |
From: Przemysław W. <esp...@cu...> - 2015-08-18 13:14:01
|
W dniu 2015-08-18 15:03, Paul Landes napisał(a): > When will the cask branch be ready to merge into master? It is ready now.u |
From: Przemysław W. <esp...@cu...> - 2015-08-19 21:07:13
|
W dniu 19.08.2015 o 15:43, Phillip Lord pisze: >> Now everything has to be downloaded and build every time anything changes - >> elisp or java. > No. You put a "version required" into the Elisp, then check the Java at > start up. You update the Java only when the elisp demands it. Hm... I think I did use wrong expression. I meant that currently there's no such functionality, so use has to rebuild everything every time. If/when we add "version required" then we'll let know when Java rebuild is needed. We can add that into our backlog and implement that. >> As of now elisp side changes way faster that java, so the elisp side >> is more important to build and install automatically, which cask >> branch does. Having to manually build and install a JAR once is not a >> big problem. > > I guess, but it would be unfortunate if the MELPA install just crashed. > At least we need something which cleanly catches the error and reports > something sensible. Better would be to cleanly "optionalise" all the JVM > dependent technology, but that would be probably be more effort than > it's worth. In won't crash on install - I've checked that. When someone tries to use Beanshell functionality then it checks jde-server-dir and tells user to set it. Of course, later we can (and even should) improve that to be more user friendly. But this is another story. >> This way or another lets do one thing at a time. >> Move to cask and elpa allows us to release frequently and use libraries from >> package manager. Moreover it makes it easier for users to install and update >> the package. So IMHO we should do that despite manual installation of JARs (I >> can make it only one JAR). > > I think that you are probably right. I'll wait until Friday morning (UTC). If nobody argues against I'll merge the cask branch into master and transfer pwojnowski/jdee-server to jdee-emacs/jdee-server. Further we can extend both parts in different directions, but this will separate elisp part from Java and allows to add JDEE to an elpa repository. Then we can turn all recently discussed issues into GH issues and improve based on that. |
From: <phi...@ne...> - 2015-08-20 10:38:00
|
Przemysław Wojnowski <esp...@cu...> writes: > W dniu 19.08.2015 o 15:43, Phillip Lord pisze: >>> Now everything has to be downloaded and build every time anything changes - >>> elisp or java. >> No. You put a "version required" into the Elisp, then check the Java at >> start up. You update the Java only when the elisp demands it. > Hm... I think I did use wrong expression. I meant that currently there's no > such functionality, so use has to rebuild everything every time. > If/when we add "version required" then we'll let know when Java rebuild is > needed. We can add that into our backlog and implement that. > >>> As of now elisp side changes way faster that java, so the elisp side >>> is more important to build and install automatically, which cask >>> branch does. Having to manually build and install a JAR once is not a >>> big problem. >> >> I guess, but it would be unfortunate if the MELPA install just crashed. >> At least we need something which cleanly catches the error and reports >> something sensible. Better would be to cleanly "optionalise" all the JVM >> dependent technology, but that would be probably be more effort than >> it's worth. > In won't crash on install - I've checked that. When someone tries to use > Beanshell functionality then it checks jde-server-dir and tells user to set it. > Of course, later we can (and even should) improve that to be more user friendly. > But this is another story. > >>> This way or another lets do one thing at a time. >>> Move to cask and elpa allows us to release frequently and use libraries from >>> package manager. Moreover it makes it easier for users to install and update >>> the package. So IMHO we should do that despite manual installation of JARs (I >>> can make it only one JAR). >> >> I think that you are probably right. > I'll wait until Friday morning (UTC). If nobody argues against I'll merge > the cask branch into master and transfer pwojnowski/jdee-server to > jdee-emacs/jdee-server. Further we can extend both parts in different > directions, but this will separate elisp part from Java and allows to add JDEE > to an elpa repository. > > Then we can turn all recently discussed issues into GH issues and improve based > on that. Sounds like the fastest, most rapid plan. Probably, we need to do change the "README" file also. I would like to get this onto MELPA, but if (as I believe is necessary) our plan is to remove cruft, we should not that in the README saying "development has restarted, but we expect that there will be instability for a while". Phil |
From: <phi...@ru...> - 2015-08-17 16:12:34
|
Przemysław Wojnowski <esp...@cu...> writes: > W dniu 15.08.2015 o 11:05, Phillip Lord pisze: >> Przemysław Wojnowski <esp...@cu...> 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). Cask build is cool. That's a really good start. 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? >> 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. >> 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. 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. 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. >> 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. EWW is quite limited. Launching web browsers is slow, but moving URLs is okay, I think? >> 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? 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!). > 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. I'd agree! Phil |
From: <phi...@ru...> - 2015-08-17 22:28:59
|
Przemysław Wojnowski <esp...@cu...> writes: > 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. This is kind of my worry. I realise that MELPA is bleeding edge, but "install these jars as well" would, I think, by outside my definition of "working". We could hack JDE to include a download step. Emacs has a url capability now. >>>> 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.) We need to think a bit about what kind of dependencies we are prepared to accept and what we are not. Specifically, in core, in ELPA, not in ELPA, and stable (i.e. MELPA-stable/marmalade) or unstable (MELPA). >>>> 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. Yep. There is a very simple answer to this, of course. I just wish I knew what it was. Unfortunately, I fear, to find out the answer I would have to read the maven documentation; this is an experience which generally makes me want to hit things with a cricket bat. Where "things" == "maven developers". As you say, though, at the moment my system has a requirement for jde-nrepl as a dependency of the project and the maven-exec plugin. Can you do this with profile and a .m2 settings? This is equivalent to leiningen. Maven is one of the reasons that I have largely stopped using Java for anything real, so I was hoping that some-one else would know the answer to this. I had also been worried about maintaining the current state of the REPL -- not a problem in Clojure (reloading code is a basic part of lisp) but more taxing in Java. I think Vinyasa (https://github.com/zcaudate/vinyasa) though provides most of what is needed there with an "reimport" functionality. It also has nice wrappers for adding (maven) dependencies on-the-fly. >> 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. Spring always rather scared me, so I know little of it. "metadata" as in Java annotation? >> 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. I agree. This is one of the chief areas that Java and Clojure differ. However, maven *does* have this information. Outside of maven, any project defining tool must have this information also. I fear that the only solution here is going to be two nrepl connections per project. One to the build tool (to get source data) and one to the project (to introspect). For maven this would need a new plugin to be written, although it should not be too hard to write. We get back to the problem of injecting things into the pom. >> 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. In a lot of cases, we just need removal. I would start off with all the tempo stuff. It would probably make sense to write a list of things to deprecate. Phil |
From: Lee H. <lee...@fa...> - 2015-08-18 21:32:52
|
Re-added the jdee-devel list Phillip Lord writes: > Lee Hinman <lee...@fa...> writes: >> This looks neat to me, and I'm interested in contributing. What's the >> best place to start with this? (Assuming this is adopted) > > > The roadblock for me at the moment is understanding mvn. If you have > any time to research this, it would be appreciated. In particular, how > to add dependencies or plugins without changing the pom. > > Phil So I looked into this briefly, it looks like this can be added to ${user.home}/.m2/settings.xml, specifically, one can specify plugin groups with: <pluginGroups> <pluginGroup>org.jdee.plugin</pluginGroup> <pluginGroups> The docs say: "This element contains a list of pluginGroup elements, each contains a groupId. The list is searched when a plugin is used and the groupId is not provided in the command line." So if we provided a jdee-mvn plugin and added the groupId here, someone could use mvn jde:jack-in (or whatever it is called) And it would search the `org.jdee.plugin` groupId for the plugin. There is also a "pluginRepositories" element that can be used to add a repository for downloading plugins, which I could see as being useful for providing the plugin for download somewhere. Sources: - https://maven.apache.org/settings.html#Plugin_Groups - https://maven.apache.org/settings.html#Plugin_Repositories -- ;; Lee |
From: Loyall, D. <dav...@ne...> - 2015-08-18 21:56:27
|
> So I looked into this briefly, it looks like this can be added to > ${user.home}/.m2/settings.xml Hm, that's my file. Maybe you're looking for the -s command line option for the mvn executable. (Specify the path to an arbitrary settings.xml.) Hope this helps, cheers, --Dave |
From: <phi...@ru...> - 2015-08-19 13:48:13
|
Lee Hinman <lee...@fa...> writes: > Re-added the jdee-devel list > > Phillip Lord writes: > >> Lee Hinman <lee...@fa...> writes: >>> This looks neat to me, and I'm interested in contributing. What's the >>> best place to start with this? (Assuming this is adopted) >> >> >> The roadblock for me at the moment is understanding mvn. If you have >> any time to research this, it would be appreciated. In particular, how >> to add dependencies or plugins without changing the pom. >> >> Phil > > So I looked into this briefly, it looks like this can be added to > ${user.home}/.m2/settings.xml, specifically, one can specify plugin > groups with: > > <pluginGroups> > <pluginGroup>org.jdee.plugin</pluginGroup> > <pluginGroups> > > The docs say: "This element contains a list of pluginGroup elements, > each contains a groupId. The list is searched when a plugin is used and > the groupId is not provided in the command line." > > So if we provided a jdee-mvn plugin and added the groupId here, someone > could use > > mvn jde:jack-in (or whatever it is called) > > And it would search the `org.jdee.plugin` groupId for the plugin. Ah, now that is interesting. That would still require writing a plugin (was trying to avoid that!). Or we could have a talk with the clojure maven plugin devs and see if they were interested in adding pomegranate as a dependency to their plugin. That would be all I would need. Phil |
From: Lee H. <lee...@fa...> - 2015-08-18 22:02:36
|
Loyall, David writes: >> So I looked into this briefly, it looks like this can be added to >> ${user.home}/.m2/settings.xml > > Hm, that's my file. I thought that was the point? This is similar to using leiningen plugins where you specify a plugin you want to use globally in ~/.lein/profiles.clj > Maybe you're looking for the -s command line option for the mvn > executable. (Specify the path to an arbitrary settings.xml.) I think there's a disconnect here? -- ;; Lee |
From: Loyall, D. <dav...@ne...> - 2015-08-18 22:12:12
|
> I thought that was the point? This is similar to using leiningen plugins where > you specify a plugin you want to use globally in ~/.lein/profiles.clj Wouldn't that open the possibility of this jdee plugin interfering with my non-emacs related mvn usage? The maven integration in Eclipse doesn't touch ~/.m2/settings.xml. (In fact, it doesn't even employ the system-wide maven unless you configure it to do so, which I had to do for some reason.) > I think there's a disconnect here? Probably. I'm no maven expert. I've used leiningen once; don't remember why. :) Will I be asked to edit settings.xml myself (preferred) or will jdee alter it? In any case, if you're confident that it won't interfere with my normal command line invocations of mvn, then I'll take your word for it and consider the question resolved. Cheers, --Dave |