jdee-devel Mailing List for JDEE (deprecated/mailing list active)
Brought to you by:
paullandes
Menu
▾
▴
jdee-devel — Forum for JDEE developers to discuss JDEE development issues.
You can subscribe to this list here.
| 2008 |
Jan
(29) |
Feb
(1) |
Mar
(24) |
Apr
(3) |
May
(22) |
Jun
(20) |
Jul
(2) |
Aug
(6) |
Sep
(27) |
Oct
(16) |
Nov
(66) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
(18) |
May
(24) |
Jun
|
Jul
(4) |
Aug
(87) |
Sep
(19) |
Oct
(16) |
Nov
(10) |
Dec
(22) |
| 2010 |
Jan
(48) |
Feb
|
Mar
(7) |
Apr
(17) |
May
(11) |
Jun
(13) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(4) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(9) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(18) |
May
(29) |
Jun
(4) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(106) |
Aug
(79) |
Sep
(9) |
Oct
(14) |
Nov
|
Dec
(13) |
| 2016 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(13) |
Nov
(2) |
Dec
(2) |
|
From: Paul L. <la...@ma...> - 2016-12-02 20:06:45
|
Yes, and there will be additional work I will do! ;) On Dec 2, 2016, at 1:04 PM, Mehul Sanghvi <meh...@gm...> wrote: > > Congratulations Wojnowski. It is good to see some continuation on this project. > > Paul, Thank you for the work you've done as well. > > > cheers, > > mehul > > > On Fri, Dec 2, 2016 at 1:00 PM, Paul Landes <la...@ma...> wrote: > The project’s owner and primary maintainer is now Mr. Wojnowski. He’s been the most active lately and shown to have a very good handle on the project. He’ll make a great project owner. > > I’ll still be a maintainer and help in ways I can. However, I no longer do much in Java and I think the project needs a maintainer who uses it on a daily basis. > > Perhaps one of the first things to do is establish a new mailing list. I don’t have the admin user/password for the sourceforge lists and neither did Paul Kinnucan (original author). > > Thanks all. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > jdee-users mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-users > > > > -- > Mehul N. Sanghvi > email: meh...@gm... |
|
From: Paul L. <la...@ma...> - 2016-12-02 18:18:43
|
The project’s owner and primary maintainer is now Mr. Wojnowski. He’s been the most active lately and shown to have a very good handle on the project. He’ll make a great project owner. I’ll still be a maintainer and help in ways I can. However, I no longer do much in Java and I think the project needs a maintainer who uses it on a daily basis. Perhaps one of the first things to do is establish a new mailing list. I don’t have the admin user/password for the sourceforge lists and neither did Paul Kinnucan (original author). Thanks all. |
|
From: Przemysław W. <esp...@cu...> - 2016-11-14 12:01:16
|
Hi Matthew, I think that we could try to do so. We could start with a separate repository and see if it works. If it won't work as expected we can always delete it. The repo is here: https://github.com/jdee-emacs/jdee-test Cheers, Przemyslaw W dniu 2016-11-13 19:24, Matthew Smith napisał(a): > In looking at gh-84 [1] and the long classpath problem, I thought it > might be good to setup a test repo called "test-prj" in the jdee-emacs > project that would be a project to add test cases for validating JDEE. > This would give a good place to keep the different use cases that > people find. It would also allow people to have a place to > demonstrate issues by branching the test project and giving a solid > example of the problem being seen. > > We also might want to have one called "test-maven" that would use the > maven infrastructure as well. > > Does this sound good? Another option would be to include them in jdee > itself but that might get overwhelming. > > I am, very sincerely and truly, > your Friend and Well-Wisher, > > Matthew O. Smith > Sr. Software Engineer/Consultant > http://www.ferociousflirting.com > > Links: > ------ > [1] https://github.com/jdee-emacs/jdee/issues/84 > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
|
From: Matthew S. <m0...@ya...> - 2016-11-13 18:24:28
|
In looking at gh-84 and the long classpath problem, I thought it might be good to setup a test repo called "test-prj" in the jdee-emacs project that would be a project to add test cases for validating JDEE. This would give a good place to keep the different use cases that people find. It would also allow people to have a place to demonstrate issues by branching the test project and giving a solid example of the problem being seen. We also might want to have one called "test-maven" that would use the maven infrastructure as well. Does this sound good? Another option would be to include them in jdee itself but that might get overwhelming. I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Sr. Software Engineer/Consultanthttp://www.ferociousflirting.com |
|
From: Przemysław W. <esp...@cu...> - 2016-10-31 07:31:40
|
Hi Matthew, Yes. One of the reason of moving to Cask was to be able to use existing elisp libraries, instead of reinventing the wheal. BTW I'll review your PR#76 tomorrow. Thanks, Przemysław W dniu 31.10.2016 o 03:02, Matthew Smith pisze: > Hi, > > Are you ok if I start using dash.el? It is a great elisp package for people > used to Clojure. It provides a lot of the sequence based functions that elisp > is missing. > > See magnars/dash.el <https://github.com/magnars/dash.el> > > > > > > > magnars/dash.el > > dash.el - A modern list library for Emacs > > > <https://github.com/magnars/dash.el> > > > I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith > Programmer / Analyst - Senior http://www.ferociousflirting.com > > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > > > > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel > |
|
From: Matthew S. <m0...@ya...> - 2016-10-31 02:02:54
|
Hi, Are you ok if I start using dash.el? It is a great elisp package for people used to Clojure. It provides a lot of the sequence based functions that elisp is missing. See magnars/dash.el | | | | | | | | | | | magnars/dash.el dash.el - A modern list library for Emacs | | | | I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com |
|
From: Matthew S. <m0...@ya...> - 2016-10-21 15:41:50
|
Hi, I have decided to hold off on moving to groovysh for the time being for a couple of reasons. First, the functionality I want added from malabar can be done without moving to groovysh. Also, as I have been reading people's comments, it seems clear that it would be better to make JDEE agnostic of the shell being used and allow the user to select the shell. When I get back to groovysh, my efforts will be to provide a way to easily add different shells, including things like CIDER, and allow the user to switch between them. At my first look jdee-bsh is already a good way there. With that in mind, the changes I want to make to jdee-server will be agnostic of the shell running it. The things I am thinking of adding are: * Support functions like jdee-jeval passing the classpath to jdee-server and have it create a classloader to execute the call. This will allow projects with different classpaths to share the same instance of bsh * Add unit test running * Add better support for maven * Add gradle support All four of these things are running in malabar so hopefully they will transition over to jdee-server without too much problem. I am not going to change how it works, but just add additional functionality. I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com On Friday, October 21, 2016 8:01 AM, Paul Landes <pau...@ai...> wrote: Questions: Are all the changes you're making new functionality? Are you replacing beanshell with groovysh? Are the changes you're making adding groovysh to JDEE and are those changes decoupled from the rest of the project? How many of the changes are modifying what's already there? Thanks. On Oct 20, 2016, at 2:31 PM, Matthew Smith <m0...@ya...> wrote: Hi, There is some code that I would like to move over from malabar-jar to jdee-server. The code will include support for multiple classpaths, unit tests, maven and gradle integration. Is there any plan to get rid of the jdee-server? It seems worth keeping. I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________ jdee-devel mailing list jde...@li... https://lists.sourceforge.net/lists/listinfo/jdee-devel |
|
From: Matthew S. <m0...@ya...> - 2016-10-20 19:31:24
|
Hi, There is some code that I would like to move over from malabar-jar to jdee-server. The code will include support for multiple classpaths, unit tests, maven and gradle integration. Is there any plan to get rid of the jdee-server? It seems worth keeping. I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com |
|
From: Matthew S. <m0...@ya...> - 2016-10-18 20:30:42
|
Hi, I have a maven integration pull request up on github. Let me know what your think. I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com |
|
From: <jo...@ve...> - 2016-10-18 18:55:38
|
FYI there is a new java emacs mode around: https://github.com/mopemope/meghanada-emacs I tried it briefly, and it seemed to work as advertised. -- Joakim Verona jo...@ve... |
|
From: Paul L. <la...@ma...> - 2016-10-13 13:08:28
|
The reason we talked about Clojure is it works nicely with Emacs Lisp. With beanshell there's lots of moving around bits of code that have little meaning in Emacs Lisp, which would be the case with Groovy. That said, there's not a lot of development going on and if you wanted to try a few things in a branch I'd be open to that. Is it possible to migrate it over not using grovvysh? Otherwise we're adding another scripting language with (once again) not getting rid of beanshell, which would add bloat. On Oct 10, 2016, at 8:51 AM, Przemysław Wojnowski <esp...@cu...> wrote: > W dniu 2016-10-08 00:05, Matthew Smith napisał(a): >> First, grape. This allows the JVM code to be installed and run >> without the user needing to install and maintain it seperately. It has >> really helped in making sure all the dependencies are available >> without making an uber jar. > IMHO this is a very nice thing. This would allow us to extend Java part > without making users to do any work. I like that. > >> Second, it allows the user to have a beanshell type environment but >> which is well supported. It is a nice balance of Java and scripting. > Sounds good too. > > Cheers, > Przemyslaw > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
|
From: Przemysław W. <esp...@cu...> - 2016-10-10 13:51:18
|
W dniu 2016-10-08 00:05, Matthew Smith napisał(a): > First, grape. This allows the JVM code to be installed and run > without the user needing to install and maintain it seperately. It has > really helped in making sure all the dependencies are available > without making an uber jar. IMHO this is a very nice thing. This would allow us to extend Java part without making users to do any work. I like that. > Second, it allows the user to have a beanshell type environment but > which is well supported. It is a nice balance of Java and scripting. Sounds good too. Cheers, Przemyslaw |
|
From: Matthew S. <m0...@ya...> - 2016-10-07 22:05:09
|
Hi, In malabar we use groovysh instead of cider. I am a great fan of Clojure but groovysh has a couple of advantages. First, grape. This allows the JVM code to be installed and run without the user needing to install and maintain it seperately. It has really helped in making sure all the dependencies are available without making an uber jar. Second, it allows the user to have a beanshell type environment but which is well supported. It is a nice balance of Java and scripting. Finally, it is well supported. It is easy to install using sdkman and is kept up to date with the JVM. Thoughts? I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com |
|
From: Matthew S. <m0...@ya...> - 2016-10-07 21:58:09
|
Great. My plan is to start creating issues, maybe tagging them "malabar". That will allow for comment on that feature. I will then be creating pull requests. I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com On Friday, October 7, 2016 3:34 PM, Paul Landes <la...@ma...> wrote: Hi Matthew. This sounds great. In fact I actually borrowed much of your code several years ago to build out pom.xml/maven code to configure JDEE. This would be a great addition. Please proceed. Thanks very much. Regards, Paul On Oct 7, 2016, at 3:13 PM, Przemysław Wojnowski <esp...@cu...> wrote: > Hi, > > For me this sounds very good! :-) > > I cannot decide this by myself, by my vote is for it. > > Thank you, > Przemysław > > W dniu 07.10.2016 o 20:04, Matthew Smith pisze: >> Hi, >> >> I an the maintainer of malabar mode and I would be interested in moving the >> functionality out of malabar mode into JDEE and unifying the two projects. >> >> Does this sound good? >> >> >> >> I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith >> Programmer / Analyst - Senior http://www.ferociousflirting.com >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> >> >> >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel >> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
|
From: Paul L. <la...@ma...> - 2016-10-07 21:51:20
|
Hi Matthew. This sounds great. In fact I actually borrowed much of your code several years ago to build out pom.xml/maven code to configure JDEE. This would be a great addition. Please proceed. Thanks very much. Regards, Paul On Oct 7, 2016, at 3:13 PM, Przemysław Wojnowski <esp...@cu...> wrote: > Hi, > > For me this sounds very good! :-) > > I cannot decide this by myself, by my vote is for it. > > Thank you, > Przemysław > > W dniu 07.10.2016 o 20:04, Matthew Smith pisze: >> Hi, >> >> I an the maintainer of malabar mode and I would be interested in moving the >> functionality out of malabar mode into JDEE and unifying the two projects. >> >> Does this sound good? >> >> >> >> I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith >> Programmer / Analyst - Senior http://www.ferociousflirting.com >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> >> >> >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel >> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
|
From: Przemysław W. <esp...@cu...> - 2016-10-07 20:38:39
|
Hi, For me this sounds very good! :-) I cannot decide this by myself, by my vote is for it. Thank you, Przemysław W dniu 07.10.2016 o 20:04, Matthew Smith pisze: > Hi, > > I an the maintainer of malabar mode and I would be interested in moving the > functionality out of malabar mode into JDEE and unifying the two projects. > > Does this sound good? > > > > I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith > Programmer / Analyst - Senior http://www.ferociousflirting.com > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel > |
|
From: Matthew S. <m0...@ya...> - 2016-10-07 18:05:07
|
Hi, I an the maintainer of malabar mode and I would be interested in moving the functionality out of malabar mode into JDEE and unifying the two projects. Does this sound good? I am, very sincerely and truly, your Friend and Well-Wisher, Matthew O. Smith Programmer / Analyst - Senior http://www.ferociousflirting.com |
|
From: <phi...@ru...> - 2016-02-15 17:37:11
|
Yep, that makes sense. Phil Paul Landes <la...@ma...> writes: > I'm thinking of some kind of straight forward REPL type functionality as a > separate module if someone really wants it. Not anything that would tie too > much into the guts of JDEE. > > > On Feb 12, 2016, at 10:23 AM, Phillip Lord <phi...@ru...> wrote: > >> Paul Landes <la...@ma...> writes: >> >>> I'm in favor of moving forward with the Clojure back end. Clojure tooling >>> makes the Emacs side of things much easier as Phil mentioned earlier. >>> >>> I _do_ think it would be possible really to support both the Java REPL and >>> Clojure, however, it wouldn't make sense to duplicate core JDEE IDE type >>> functionality like method/class completion, wizards, etc. >> >> >> With the amount of developer time that we have, I think this is >> impractical. It's going to mean having data in two different places, >> getting two classpaths correct and it also missed one the main >> advantages -- that maintaining all of this information is shunted >> largely to the JVM. >> >> >> Phil |
|
From: <jo...@ve...> - 2016-02-12 17:50:56
|
phi...@ru... (Phillip Lord) writes: > At this point, we haven't concrete decided on which way to go either > way. > > If there is the willingness to drop the beanshell backend, then we > probably need to plan for this and decide for sure. > > If we go for the Clojure backend, for example, I wonder whether it is > possible to support both clojure and beanshell at once, which would > allow an easy migration path. I suspect not, unfortunately. In which > case, we either have to maintain a fork for a good time, or effectively > freeze the current JDEE, then move to the new backend, which probably > means breaking current features. While I suggested to have a look at the Java REPL, I vastly prefer Clojure over Java. I do maintain Java code however, so for me the Clojure path to a better JDE would be more interesting. I would like to help out, but at this time I'm not sure how. (also, my Emacs hacking time is limited to the emacs xwidget project at the moment) > > Phil > > > Przemysław Wojnowski <esp...@cu...> writes: > >> According to http://openjdk.java.net/projects/jdk9/ the release date (as >> for now) is March 2017, so at least for a year not many people will use it. >> >> Anyway, this may be a good direction in the future. >> >> Cheers, >> Przemysław >> >> W dniu 12.02.2016 o 03:43, Troy Daniels pisze: >>> There is also the fact that not everyone is using Java 9 yet. >>> >>> Troy >>> >>> On Thu, Feb 11, 2016 at 1:16 PM, Phillip Lord >>> <phi...@ru... <mailto:phi...@ru...>> wrote: >>> >>> <jo...@ve... <mailto:jo...@ve...>> writes: >>> >>> > I tried the jdk 9 repl briefly, and it appeared to work as advertized. >>> > >>> > Maybe it could be used in place of bsh, or maybe the Clojure idea is >>> > better, I'm not sure. >>> >>> >>> I haven't tried it yet -- the installation looks to be a bit of a pain. >>> >>> AFAICT, though, it would be a good replacement for bsh and a step up >>> from the current situation, as bsh is not maintained. Having something >>> build into the JDK is a big plus. >>> >>> At the same time, the clojure route has the advantage of a sane >>> communication layer with the running process. I know that Emacs has >>> communicated through a pipe with processes for a long time, but parsing >>> command line output never seems like a fantastic idea to me. >>> >>> Of course, the two ideas are not necessarily a dichotomy. If we had good >>> connectivity with a clojure process via nrepl, then clojure could also >>> launch a Java REPL process. Depending on the Java REPL API, this should >>> avoid the nastiness of parsing. >>> >>> Phil >>> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140>> _______________________________________________ >>> jdee-devel mailing list >>> jde...@li... >>> <mailto:jde...@li...> >>> https://lists.sourceforge.net/lists/listinfo/jdee-devel>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140>> >>> >>> >>> _______________________________________________ >>> jdee-devel mailing list >>> jde...@li... >>> https://lists.sourceforge.net/lists/listinfo/jdee-devel>> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140_______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel -- Joakim Verona |
|
From: Paul L. <la...@ma...> - 2016-02-12 16:28:51
|
I'm thinking of some kind of straight forward REPL type functionality as a separate module if someone really wants it. Not anything that would tie too much into the guts of JDEE. On Feb 12, 2016, at 10:23 AM, Phillip Lord <phi...@ru...> wrote: > Paul Landes <la...@ma...> writes: > >> I'm in favor of moving forward with the Clojure back end. Clojure tooling >> makes the Emacs side of things much easier as Phil mentioned earlier. >> >> I _do_ think it would be possible really to support both the Java REPL and >> Clojure, however, it wouldn't make sense to duplicate core JDEE IDE type >> functionality like method/class completion, wizards, etc. > > > With the amount of developer time that we have, I think this is > impractical. It's going to mean having data in two different places, > getting two classpaths correct and it also missed one the main > advantages -- that maintaining all of this information is shunted > largely to the JVM. > > > Phil |
|
From: <phi...@ru...> - 2016-02-12 16:23:44
|
Paul Landes <la...@ma...> writes: > I'm in favor of moving forward with the Clojure back end. Clojure tooling > makes the Emacs side of things much easier as Phil mentioned earlier. > > I _do_ think it would be possible really to support both the Java REPL and > Clojure, however, it wouldn't make sense to duplicate core JDEE IDE type > functionality like method/class completion, wizards, etc. With the amount of developer time that we have, I think this is impractical. It's going to mean having data in two different places, getting two classpaths correct and it also missed one the main advantages -- that maintaining all of this information is shunted largely to the JVM. Phil |
|
From: Paul L. <la...@ma...> - 2016-02-12 14:52:34
|
I'm in favor of moving forward with the Clojure back end. Clojure tooling makes the Emacs side of things much easier as Phil mentioned earlier. I _do_ think it would be possible really to support both the Java REPL and Clojure, however, it wouldn't make sense to duplicate core JDEE IDE type functionality like method/class completion, wizards, etc. On Feb 12, 2016, at 8:28 AM, Phillip Lord <phi...@ru...> wrote: > > At this point, we haven't concrete decided on which way to go either > way. > > If there is the willingness to drop the beanshell backend, then we > probably need to plan for this and decide for sure. > > If we go for the Clojure backend, for example, I wonder whether it is > possible to support both clojure and beanshell at once, which would > allow an easy migration path. I suspect not, unfortunately. In which > case, we either have to maintain a fork for a good time, or effectively > freeze the current JDEE, then move to the new backend, which probably > means breaking current features. > > Phil > > > Przemysław Wojnowski <esp...@cu...> writes: > >> According to http://openjdk.java.net/projects/jdk9/ the release date (as >> for now) is March 2017, so at least for a year not many people will use it. >> >> Anyway, this may be a good direction in the future. >> >> Cheers, >> Przemysław >> >> W dniu 12.02.2016 o 03:43, Troy Daniels pisze: >>> There is also the fact that not everyone is using Java 9 yet. >>> >>> Troy >>> >>> On Thu, Feb 11, 2016 at 1:16 PM, Phillip Lord >>> <phi...@ru... <mailto:phi...@ru...>> wrote: >>> >>> <jo...@ve... <mailto:jo...@ve...>> writes: >>> >>>> I tried the jdk 9 repl briefly, and it appeared to work as advertized. >>>> >>>> Maybe it could be used in place of bsh, or maybe the Clojure idea is >>>> better, I'm not sure. >>> >>> >>> I haven't tried it yet -- the installation looks to be a bit of a pain. >>> >>> AFAICT, though, it would be a good replacement for bsh and a step up >>> from the current situation, as bsh is not maintained. Having something >>> build into the JDK is a big plus. >>> >>> At the same time, the clojure route has the advantage of a sane >>> communication layer with the running process. I know that Emacs has >>> communicated through a pipe with processes for a long time, but parsing >>> command line output never seems like a fantastic idea to me. >>> >>> Of course, the two ideas are not necessarily a dichotomy. If we had good >>> connectivity with a clojure process via nrepl, then clojure could also >>> launch a Java REPL process. Depending on the Java REPL API, this should >>> avoid the nastiness of parsing. >>> >>> Phil >>> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >>> _______________________________________________ >>> jdee-devel mailing list >>> jde...@li... >>> <mailto:jde...@li...> >>> https://lists.sourceforge.net/lists/listinfo/jdee-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Site24x7 APM Insight: Get Deep Visibility into Application Performance >>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >>> Monitor end-to-end web transactions and take corrective actions now >>> Troubleshoot faster and improve end-user experience. Signup Now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >>> >>> >>> >>> _______________________________________________ >>> jdee-devel mailing list >>> jde...@li... >>> https://lists.sourceforge.net/lists/listinfo/jdee-devel >>> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
|
From: <phi...@ru...> - 2016-02-12 14:29:03
|
At this point, we haven't concrete decided on which way to go either way. If there is the willingness to drop the beanshell backend, then we probably need to plan for this and decide for sure. If we go for the Clojure backend, for example, I wonder whether it is possible to support both clojure and beanshell at once, which would allow an easy migration path. I suspect not, unfortunately. In which case, we either have to maintain a fork for a good time, or effectively freeze the current JDEE, then move to the new backend, which probably means breaking current features. Phil Przemysław Wojnowski <esp...@cu...> writes: > According to http://openjdk.java.net/projects/jdk9/ the release date (as > for now) is March 2017, so at least for a year not many people will use it. > > Anyway, this may be a good direction in the future. > > Cheers, > Przemysław > > W dniu 12.02.2016 o 03:43, Troy Daniels pisze: >> There is also the fact that not everyone is using Java 9 yet. >> >> Troy >> >> On Thu, Feb 11, 2016 at 1:16 PM, Phillip Lord >> <phi...@ru... <mailto:phi...@ru...>> wrote: >> >> <jo...@ve... <mailto:jo...@ve...>> writes: >> >> > I tried the jdk 9 repl briefly, and it appeared to work as advertized. >> > >> > Maybe it could be used in place of bsh, or maybe the Clojure idea is >> > better, I'm not sure. >> >> >> I haven't tried it yet -- the installation looks to be a bit of a pain. >> >> AFAICT, though, it would be a good replacement for bsh and a step up >> from the current situation, as bsh is not maintained. Having something >> build into the JDK is a big plus. >> >> At the same time, the clojure route has the advantage of a sane >> communication layer with the running process. I know that Emacs has >> communicated through a pipe with processes for a long time, but parsing >> command line output never seems like a fantastic idea to me. >> >> Of course, the two ideas are not necessarily a dichotomy. If we had good >> connectivity with a clojure process via nrepl, then clojure could also >> launch a Java REPL process. Depending on the Java REPL API, this should >> avoid the nastiness of parsing. >> >> Phil >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> <mailto:jde...@li...> >> https://lists.sourceforge.net/lists/listinfo/jdee-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> >> >> >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel >> > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
|
From: Przemysław W. <esp...@cu...> - 2016-02-12 08:50:53
|
According to http://openjdk.java.net/projects/jdk9/ the release date (as for now) is March 2017, so at least for a year not many people will use it. Anyway, this may be a good direction in the future. Cheers, Przemysław W dniu 12.02.2016 o 03:43, Troy Daniels pisze: > There is also the fact that not everyone is using Java 9 yet. > > Troy > > On Thu, Feb 11, 2016 at 1:16 PM, Phillip Lord > <phi...@ru... <mailto:phi...@ru...>> wrote: > > <jo...@ve... <mailto:jo...@ve...>> writes: > > > I tried the jdk 9 repl briefly, and it appeared to work as advertized. > > > > Maybe it could be used in place of bsh, or maybe the Clojure idea is > > better, I'm not sure. > > > I haven't tried it yet -- the installation looks to be a bit of a pain. > > AFAICT, though, it would be a good replacement for bsh and a step up > from the current situation, as bsh is not maintained. Having something > build into the JDK is a big plus. > > At the same time, the clojure route has the advantage of a sane > communication layer with the running process. I know that Emacs has > communicated through a pipe with processes for a long time, but parsing > command line output never seems like a fantastic idea to me. > > Of course, the two ideas are not necessarily a dichotomy. If we had good > connectivity with a clojure process via nrepl, then clojure could also > launch a Java REPL process. Depending on the Java REPL API, this should > avoid the nastiness of parsing. > > Phil > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > jdee-devel mailing list > jde...@li... > <mailto:jde...@li...> > https://lists.sourceforge.net/lists/listinfo/jdee-devel > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > > > > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel > |
|
From: Troy D. <uda...@gm...> - 2016-02-12 02:43:57
|
There is also the fact that not everyone is using Java 9 yet. Troy On Thu, Feb 11, 2016 at 1:16 PM, Phillip Lord <phi...@ru...> wrote: > <jo...@ve...> writes: > > > I tried the jdk 9 repl briefly, and it appeared to work as advertized. > > > > Maybe it could be used in place of bsh, or maybe the Clojure idea is > > better, I'm not sure. > > > I haven't tried it yet -- the installation looks to be a bit of a pain. > > AFAICT, though, it would be a good replacement for bsh and a step up > from the current situation, as bsh is not maintained. Having something > build into the JDK is a big plus. > > At the same time, the clojure route has the advantage of a sane > communication layer with the running process. I know that Emacs has > communicated through a pipe with processes for a long time, but parsing > command line output never seems like a fantastic idea to me. > > Of course, the two ideas are not necessarily a dichotomy. If we had good > connectivity with a clojure process via nrepl, then clojure could also > launch a Java REPL process. Depending on the Java REPL API, this should > avoid the nastiness of parsing. > > Phil > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel > |
16 messages has been excluded from this view by a project administrator.