Thread: [jdee-devel] Time for a (minor) 2.4.1 release?
Brought to you by:
paullandes
From: Shyamal P. <sh...@me...> - 2013-04-28 01:17:41
|
Hi, Perhaps it's time for a 2.4.1 (minor) release?! A release will get the trunk code out and go some way in dealing with the bit-rot reputation that JDEE is developing (e.g. see http://emacswiki.org/emacs/JavaDevelopmentEnvironment). Yes, there are no significant new features, but the release should allow everyone to reliably use JDEE with GNU Emacs 23/24 and CEDET 1.1. I already took a pass at updating the Source Forge web site a while ago with proposed updates (see svn). Based on recent feedback on the list I will clean up the Windows instructions and push it out with this proposed release. If there are no objections or show stopping bugs reported, I will proceed with a release on some weekend in mid/late May. OK? Cheers! Shyamal PS: If you are using the trunk code with the GNU Emacs' version of CEDET (not externally supplied CEDET 1.1) please get r282 or later from trunk (I committed r282 today). |
From: <phi...@ne...> - 2013-04-29 09:40:19
|
This would be a superb thing. The last time I wrote Java I did it without JDE, because I use Java rarely now that it wasn't worth doing a SVN update. So getting the trunk out would be fantastic. Phil Shyamal Prasad <sh...@me...> writes: > Hi, > > Perhaps it's time for a 2.4.1 (minor) release?! > > A release will get the trunk code out and go some way in dealing with > the bit-rot reputation that JDEE is developing (e.g. see > http://emacswiki.org/emacs/JavaDevelopmentEnvironment). Yes, there are > no significant new features, but the release should allow everyone to > reliably use JDEE with GNU Emacs 23/24 and CEDET 1.1. > > I already took a pass at updating the Source Forge web site a while ago > with proposed updates (see svn). Based on recent feedback on the list I > will clean up the Windows instructions and push it out with this > proposed release. > > If there are no objections or show stopping bugs reported, I will > proceed with a release on some weekend in mid/late May. > > OK? > > Cheers! > Shyamal > > PS: If you are using the trunk code with the GNU Emacs' version of CEDET > (not externally supplied CEDET 1.1) please get r282 or later from trunk > (I committed r282 today). > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel > > -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phi...@ne... School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU |
From: Paul L. <la...@ma...> - 2013-04-29 14:09:17
|
I agree, we're overdue for a release. Shyamal: please proceed when you can and let me know if I can help. We can get on chat and go through it together as well if that's helpful. Re bit rot: I have about as much time to admin the project but not as much time for development. The work that Shymal has been doing by cleaning things up has been great. A while back I put together a todo list of things I thought needed to be done in order to maintain this project easier. For example, there are many aspects of the project that are deprecated and other functionality that isn't used as much that adds clutter. I didn't hear that much back on this so I think to a large degree the project is just not used as much and we've lost interest. If we had more folks using it we'd have more new development and activity. I don't really see a good way to garner a lot of interest in this project and get things moving as things moved before the bigger IDEs matured and became prevalent (i.e. Eclipse) other than fork it and/or seriously modify the project, which I no longer have the time to do--at least for the near future. That said, I do still think there are many that use it (including myself). On Apr 29, 2013, at 4:40 AM, Phillip Lord <phi...@ne...> wrote: > > This would be a superb thing. The last time I wrote Java I did it > without JDE, because I use Java rarely now that it wasn't worth doing a > SVN update. So getting the trunk out would be fantastic. > > Phil > > Shyamal Prasad <sh...@me...> writes: > >> Hi, >> >> Perhaps it's time for a 2.4.1 (minor) release?! >> >> A release will get the trunk code out and go some way in dealing with >> the bit-rot reputation that JDEE is developing (e.g. see >> http://emacswiki.org/emacs/JavaDevelopmentEnvironment). Yes, there are >> no significant new features, but the release should allow everyone to >> reliably use JDEE with GNU Emacs 23/24 and CEDET 1.1. >> >> I already took a pass at updating the Source Forge web site a while ago >> with proposed updates (see svn). Based on recent feedback on the list I >> will clean up the Windows instructions and push it out with this >> proposed release. >> >> If there are no objections or show stopping bugs reported, I will >> proceed with a release on some weekend in mid/late May. >> >> OK? >> >> Cheers! >> Shyamal >> >> PS: If you are using the trunk code with the GNU Emacs' version of CEDET >> (not externally supplied CEDET 1.1) please get r282 or later from trunk >> (I committed r282 today). >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel >> >> > > -- > Phillip Lord, Phone: +44 (0) 191 222 7827 > Lecturer in Bioinformatics, Email: phi...@ne... > School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord > Room 914 Claremont Tower, skype: russet_apples > Newcastle University, twitter: phillord > NE1 7RU > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Shyamal P. <sh...@me...> - 2013-04-29 18:08:13
|
Sorry for the resend - used the wrong source email address which resulted in a bounce from the list server! >>>>> "Paul" == Paul Landes <la...@ma...> writes: Paul> I agree, we're overdue for a release. Shyamal: please proceed Paul> when you can and let me know if I can help. We can get on Paul> chat and go through it together as well if that's helpful. Will do. Thanks. Paul> I think to a large degree the project is just not used as much Paul> and we've lost interest. If we had more folks using it we'd Paul> have more new development and activity. I don't really see a Paul> good way to garner a lot of interest in this project and get Paul> things moving as things moved before the bigger IDEs matured Paul> and became prevalent (i.e. Eclipse) other than fork it and/or Paul> seriously modify the project, which I no longer have the time Paul> to do--at least for the near future. Personally I believe Emacs users will pick up JDEE as long as it is easy to install and largely trouble free to use. Will Java developers use Emacs? I doubt it. I personally don't evangelize Emacs to people who program in Java exclusively, and I would not target JDEE at such folks. I suspect a lot of (Emacs) people get turned off JDEE because it is so hard and confusing to install based on publicly available documentation. Once it is working, it is actually surprisingly good given how little development has happened in the last few years! I remember that when Debian removed the JDEE package (because the cedet package went away) I had a really hard time getting upstream JDEE to work for me. Prior to that I had quietly depended on JDEE for many years, and "it just worked." IMHO, it's not the feature set that is the problem, it's that it is too hard to set up and start up that is causing a loss of interest. The typical JDEE user wants to write Java code, not futz with elisp. Cheers! Shyamal |
From: Shyamal P. <sh...@me...> - 2013-05-06 18:59:39
|
>>>>> "Paul" == Paul Landes <la...@ma...> writes: Paul> I agree, we're overdue for a release. Shyamal: please proceed Paul> when you can and let me know if I can help. We can get on Paul> chat and go through it together as well if that's helpful. So here is one thing I need help with: does anyone remember details on how the release/changelog notes are produced (Paul, I believe you did the last according to svn)? If you do, please read my problem description below and send me some feedback. When I run "ant package" it needs a changelog task to produce the changelog.xml from the svn log. As far as I can tell the apache-ant-svn library died a quiet death of some sort long ago. I cannot find a recent version on the Apache website, and a jar was impossible to find with Google and friends. Is this true? OK, next. I got apache-ant-svn-0.1-2010-01-08-bin.tar.bz2 from the JDEE download area (hooray for archiving dependencies!) and extracted the jar. So, now I can run 'ant release-info'. Doing so with ant 1.8.2 *seems* to work (with ant 1.9.0 it just hangs on my Mac). But here is the problem: even though 'ant release-info' prints the correct revision set for the changelog (200 - HEAD), and runs all the XSLT scripts and produces the output files in build/etc, it never writes any actual changelog entries! It just seems to ignore the commits. If I manually change the revision set in the build.xml file (say to 100 - HEAD) it lists all revisions up to and including 196 (the last rev released in 2.4.0.1), and then stops including everything since then. I tried mucking with the doc/history/release.xml file, but nothing gives. Clearly, I'm missing some critical configuration step. I can't find documentation on the svn changelog library, or the upstream source code, so I'm not sure what debug approach to take. Is it something stupid and simple like my user name is wrong, or that I need to have release branch? I'd also rather not rewrite the release-info task with another svn/ant library just yet. Heck, I'd rather just switch the project to git so I can stop using git-svn :-) Thanks for any ideas, Shyamal |
From: Paul L. <la...@ma...> - 2013-04-29 14:11:38
|
Resending due to a bounce (jdee-bounces): I agree, we're overdue for a release. Shyamal: please proceed when you can and let me know if I can help. We can get on chat and go through it together as well if that's helpful. Re bit rot: I have about as much time to admin the project but not as much time for development. The work that Shymal has been doing by cleaning things up has been great. A while back I put together a todo list of things I thought needed to be done in order to maintain this project easier. For example, there are many aspects of the project that are deprecated and other functionality that isn't used as much that adds clutter. I didn't hear that much back on this so I think to a large degree the project is just not used as much and we've lost interest. If we had more folks using it we'd have more new development and activity. I don't really see a good way to garner a lot of interest in this project and get things moving as things moved before the bigger IDEs matured and became prevalent (i.e. Eclipse) other than fork it and/or seriously modify the project, which I no longer have the time to do--at least for the near future. That said, I do still think there are many that use it (including myself). On Apr 27, 2013, at 7:50 PM, Shyamal Prasad <sh...@me...> wrote: > Hi, > > Perhaps it's time for a 2.4.1 (minor) release?! > > A release will get the trunk code out and go some way in dealing with > the bit-rot reputation that JDEE is developing (e.g. see > http://emacswiki.org/emacs/JavaDevelopmentEnvironment). Yes, there are > no significant new features, but the release should allow everyone to > reliably use JDEE with GNU Emacs 23/24 and CEDET 1.1. > > I already took a pass at updating the Source Forge web site a while ago > with proposed updates (see svn). Based on recent feedback on the list I > will clean up the Windows instructions and push it out with this > proposed release. > > If there are no objections or show stopping bugs reported, I will > proceed with a release on some weekend in mid/late May. > > OK? > > Cheers! > Shyamal > > PS: If you are using the trunk code with the GNU Emacs' version of CEDET > (not externally supplied CEDET 1.1) please get r282 or later from trunk > (I committed r282 today). > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Loyall, D. <dav...@ne...> - 2013-04-29 14:54:56
|
> From: Paul Landes [...] > A while back I put together a todo list of things I thought needed to be done > in order to maintain this project easier. I'm new here and I don't understand the structure of JDEE. Could you show me where to find that list? Cheers, --Dave |
From: Paul L. <la...@ma...> - 2013-04-29 15:11:58
|
It was a post from a long time ago to the jdee-devel list. There should be another list that is more detailed somewhere in the code base. I'll try to find them and get back to you. On Apr 29, 2013, at 9:33 AM, "Loyall, David" <dav...@ne...> wrote: >> From: Paul Landes > [...] >> A while back I put together a todo list of things I thought needed to be done >> in order to maintain this project easier. > > I'm new here and I don't understand the structure of JDEE. Could you show me where to find that list? > > Cheers, > --Dave > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Paul L. <la...@ma...> - 2013-04-29 15:56:06
|
OK, I did some looking and can't find the list I remember creating. It was literally years ago so it's either burred in the previous list serv (before bringing it over to SF) or been deleted in the code base (or both). Here's something I came across, which is interesting given the context of this thread (and funny). http://lists.gnu.org/archive/html/help-gnu-emacs/2010-08/msg00289.html If there is sufficient interest, I'll recreate that list given how see the project in it's current state. Again, I have thought about forking/canabalizing etc. The primary motivation is that the project is large and very dependent on CEDET. I have nothing bad to say about CEDET but it's current integration with Emacs post 23 has been non-compat and created a lot of issues for installation. I am a little leery about its complexity as well (maybe Eric can chime in here). Anyway I have been thinking once again about this and if there is interest I can put some diagrams together in how I'd go about doing that. The basic idea would be to pretty much move all the things that beanshell and semantic currently do to Java packages. That means using things like compilation tools that come with the JDK and other OS packages (i.e. ASM) for parsing, code completion, wizards, templates etc. The basic idea is using straight Java packages for anything involving Java operations. This would really slim down the code base and make it manageable. ABCL (common lisp implementation) would replace the now dead Beanshell language, and frankly, seems like a better fit since its lisp and not Java. Another benefit to this is it already works nicely with Slime so we could get rid of the very (IMO) complex emacs -> beanshell IPC (emacs OO!) library. Just that would be a huge victory in my mind as I've spent hours and hours debugging these two parts that stubbornly do not play well together (i.e. beanshell start times and process hangups). Another idea I had is to move everything to maven so there would be maven integration (bridged through ABCL) for compilations. If others still want to use Ant or something else we can talk about some abstraction layer. Many nice useful parts of JDEE would be folded in (i.e. syntax highlight, maven integration or Malabar mode might be folded in for this). I'm glad to put this on paper and if there is sufficient interest by those WILLING TO HELP and write the CL, Java bindings, and Emacs code then I'll continue this process. IMPORTANT: I am only one person with a day job. The only way we get a solid Java IDE environment is for everyone to pool their time and resources to create this all together! We don't need an army of devs, only a few that can work with me and help me implement specific parts of the architecture. I'm strong on Emacs Lisp, Java and decent with CL (I am weak on APIs out there). Devs and users: please let me know! -Paul L. On Apr 29, 2013, at 10:11 AM, Paul Landes <la...@ma...> wrote: > It was a post from a long time ago to the jdee-devel list. There should be another list that is more detailed somewhere in the code base. I'll try to find them and get back to you. > > > On Apr 29, 2013, at 9:33 AM, "Loyall, David" <dav...@ne...> wrote: > >>> From: Paul Landes >> [...] >>> A while back I put together a todo list of things I thought needed to be done >>> in order to maintain this project easier. >> >> I'm new here and I don't understand the structure of JDEE. Could you show me where to find that list? >> >> Cheers, >> --Dave >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> _______________________________________________ >> jdee-devel mailing list >> jde...@li... >> https://lists.sourceforge.net/lists/listinfo/jdee-devel > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Shyamal P. <sh...@me...> - 2013-04-29 17:46:24
|
>>>>> "Paul" == Paul Landes <la...@ma...> writes: Paul> Again, I have thought about forking/canabalizing etc. The Paul> primary motivation is that the project is large and very Paul> dependent on CEDET. I have nothing bad to say about CEDET but Paul> it's current integration with Emacs post 23 has been Paul> non-compat and created a lot of issues for installation. One thing that working on JDEE has forced me to do is learn more about CEDET, specifically its inclusion into Emacs 23+. The conclusion I've drawn is this: JDEE should work with GNU Emacs CEDET version alone. It's the right thing to do for *users* and it resolves the compatibility issues by making the choice of platform. I would welcome feedback on this (in particular I'm still unclear about the relationship between the CEDET and Emacs code bases, though it seems friendly enough). Paul> ABCL (common lisp implementation) would replace the now dead Paul> Beanshell language, and frankly, seems like a better fit since Paul> its lisp and not Java. Has anyone looked at implementing the beanshell functionality in elisp? While I *love* coding in CL, I'm not sure I've talked myself to where I'm sold on switching beanshell out with still another languge. The truth is, I actually like elisp, and it will always be a well supported language in Emacs :-) Getting rid of, or improving on, beanshell is probably #2 on the list of things I need though (mostly to get Java 5+ language support). Paul> Another idea I had is to move everything to maven so there Paul> would be maven integration (bridged through ABCL) for Paul> compilations. If others still want to use Ant or something Paul> else we can talk about some abstraction layer. Maven is #1 on my list. I'd really like to fold Maven support into JDEE. There have been so many efforts out there to do it in the past that I feel it just a matter of picking and choosing appropriately licensed code and adding it to JDEE. I personally need this big time, so from a motivation perspective I will work on it personally. Paul> IMPORTANT: I am only one person with a day job. The only way Paul> we get a solid Java IDE environment is for everyone to pool Paul> their time and resources to create this all together! This is key. I use JDEE when my day job asks me to write Java. So I'm very focused on always having a working, maintainable, and useful JDEE. This leads to the following "roadmap" in my head: 1. Get JDEE to work with Emacs CEDET (I believe this is now done on trunk, at least I am using it daily) 2. Get the code base out (which I'm proposing we do now with a minor release, and I will also work on getting this version back into Debian). 3. Now clean out all the cruft to support old versions of Emacs, CEDET, and other libraries. Build for GNU Emacs with it's included CEDET. Period. No third party dependencies other than beanshell (and Ant to build). This cleans up build and start up code, the CEDET integration, sub-process management, and many other minor things that are annoyances when making changes/improvements to JDEE (to me anyway, because I find myself testing to many configurations since it is so hard to tell which ones to worry about). 4. Documentation updates, and another minor release I can get (3) and (4) done relatively quickly after the release. It will mean trunk will target only GNU Emacs going forward. With that out of the way my list continues to: 5. Add Maven support (at a minimum like jde-ant today, but I'd like better EDE/prj.el integration) 6. Do a release with working Maven support for Emacs 24+? 7. Replace Beanshell (probably along the lines that Paul is suggesting) 8. Major release Step (7) is where a fork is a realistic thing to do. But I think we should get this done in this code base. I'm not sure there is a community large enough to support a fork, and without some basic housekeeping the existing community, as it were, will fade away. Cheers! Shyamal |
From: <phi...@ne...> - 2013-04-30 10:48:32
|
Shyamal Prasad <sh...@me...> writes: >>>>>> "Paul" == Paul Landes <la...@ma...> writes: > > Paul> Again, I have thought about forking/canabalizing etc. The > Paul> primary motivation is that the project is large and very > Paul> dependent on CEDET. I have nothing bad to say about CEDET but > Paul> it's current integration with Emacs post 23 has been > Paul> non-compat and created a lot of issues for installation. > > One thing that working on JDEE has forced me to do is learn more about > CEDET, specifically its inclusion into Emacs 23+. The conclusion I've > drawn is this: JDEE should work with GNU Emacs CEDET version alone. It's > the right thing to do for *users* and it resolves the compatibility > issues by making the choice of platform. I would welcome feedback on > this (in particular I'm still unclear about the relationship between the > CEDET and Emacs code bases, though it seems friendly enough). For me, this is also the motivation behind getting rid of beanshell. There is actually quite a lot of Java in JDEE -- beanshell is not rich enough to do complicated things, so it was only ever used to interact with the JDEE java code. So, JDEE needs building and packaging. This makes it harder to hack, because it doesn't work from a checkout, as well as making inclusion in ELPA/Marmalade/MELPA difficult. Having a JDEE written all in lisp (Emacs + a JVM hosted one) would make life easier. Phil |
From: Shyamal P. <sh...@me...> - 2013-04-29 21:45:28
|
>>>>> "Henry" == Henry S Thompson <ht...@in...> writes: Henry> Paul Landes writes: >> dependent on CEDET. I have nothing bad to say about CEDET but >> it's current integration with Emacs post 23 has been non-compat >> and created a lot of issues for installation. Henry> I spent a full day over the weekend attempting to get a Henry> version of the current CEDET (from the bzr repo) to load into Henry> XEmacs (21.5 beta 33) and failed miserably. XEmacs Henry> compatability is clearly not on the CEDET agenda at all. I'm Henry> not coding in Java right now myself, but when I get back to Henry> doing so I'd be sorry if JDEE had become an Emacs-only Henry> toolset. . . As far as I can tell you are correct about CEDET and XEmacs. I'd tried doing the same late last year and gave up pretty quickly. This thread seems to confirm that XEmacs is not on the CEDET agenda unless some one asks: http://sourceforge.net/mailarchive/forum.php?thread_name=514E0C0E.6000909%40siege-engine.com&forum_name=cedet-devel I was an XEmacs user until 2004. I have since switched to using the GNU version exclusively, and lost track of where XEmacs is. It does seem that the momentum in Emacs development has switched to the GNU version in the last decade (?). I'm personally biased towards making JDEE a GNU Emacs only toolset because I'm not sure there is a community of users who will make it work for XEmacs (or even just one user). The final straw is that CEDET seems impossible to use on XEmacs, at least to a casual user like me, which knocks JDEE off that platform. Cheers! Shyamal |
From: Paul L. <la...@ma...> - 2013-04-30 19:25:40
|
Sounds like a lot of share the experience of going to XEmacs at a time it was better than GNU Emacs. I like many others went back to GNU Emacs after they implemented all the missing features XEmacs had the GNU didn't. XEmacs (thanks to Jamie for a much needed emacs "revolution") did what it needed IMO, but maintaining both is a lot of extra effort. I tried to look for an XEmacs user that was willing to maintain it but no one stepped forward. For this reason JDEE officially no longer is supported under XEmacs. On Apr 29, 2013, at 4:45 PM, Shyamal Prasad <sh...@me...> wrote: >>>>>> "Henry" == Henry S Thompson <ht...@in...> writes: > > Henry> Paul Landes writes: > >>> dependent on CEDET. I have nothing bad to say about CEDET but >>> it's current integration with Emacs post 23 has been non-compat >>> and created a lot of issues for installation. > > Henry> I spent a full day over the weekend attempting to get a > Henry> version of the current CEDET (from the bzr repo) to load into > Henry> XEmacs (21.5 beta 33) and failed miserably. XEmacs > Henry> compatability is clearly not on the CEDET agenda at all. I'm > Henry> not coding in Java right now myself, but when I get back to > Henry> doing so I'd be sorry if JDEE had become an Emacs-only > Henry> toolset. . . > > As far as I can tell you are correct about CEDET and XEmacs. I'd tried > doing the same late last year and gave up pretty quickly. This thread > seems to confirm that XEmacs is not on the CEDET agenda unless some one > asks: http://sourceforge.net/mailarchive/forum.php?thread_name=514E0C0E.6000909%40siege-engine.com&forum_name=cedet-devel > > I was an XEmacs user until 2004. I have since switched to using the GNU > version exclusively, and lost track of where XEmacs is. It does seem > that the momentum in Emacs development has switched to the GNU version > in the last decade (?). > > I'm personally biased towards making JDEE a GNU Emacs only toolset > because I'm not sure there is a community of users who will make it work > for XEmacs (or even just one user). The final straw is that CEDET seems > impossible to use on XEmacs, at least to a casual user like me, which > knocks JDEE off that platform. > > Cheers! > Shyamal > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Mark A. F. <mf...@ve...> - 2013-04-30 04:58:50
|
Shyamal Prasad <sh...@me...> wrote: > >>>>>> "Paul" == Paul Landes <la...@ma...> writes: > > Paul> Again, I have thought about forking/canabalizing etc. The > Paul> primary motivation is that the project is large and very > Paul> dependent on CEDET. I have nothing bad to say about CEDET but > Paul> it's current integration with Emacs post 23 has been > Paul> non-compat and created a lot of issues for installation. > >One thing that working on JDEE has forced me to do is learn more about >CEDET, specifically its inclusion into Emacs 23+. The conclusion I've >drawn is this: JDEE should work with GNU Emacs CEDET version alone. >It's >the right thing to do for *users* and it resolves the compatibility >issues by making the choice of platform. I would welcome feedback on >this (in particular I'm still unclear about the relationship between >the >CEDET and Emacs code bases, though it seems friendly enough). > > Paul> ABCL (common lisp implementation) would replace the now dead > Paul> Beanshell language, and frankly, seems like a better fit since > Paul> its lisp and not Java. > >Has anyone looked at implementing the beanshell functionality in elisp? >While I *love* coding in CL, I'm not sure I've talked myself to where >I'm sold on switching beanshell out with still another languge. The >truth is, I actually like elisp, and it will always be a well supported >language in Emacs :-) > >Getting rid of, or improving on, beanshell is probably #2 on the list >of >things I need though (mostly to get Java 5+ language support). > > Paul> Another idea I had is to move everything to maven so there > Paul> would be maven integration (bridged through ABCL) for > Paul> compilations. If others still want to use Ant or something > Paul> else we can talk about some abstraction layer. > >Maven is #1 on my list. I'd really like to fold Maven support into >JDEE. There have been so many efforts out there to do it in the past >that I feel it just a matter of picking and choosing appropriately >licensed code and adding it to JDEE. I personally need this big time, >so >from a motivation perspective I will work on it personally. > > Paul> IMPORTANT: I am only one person with a day job. The only way > Paul> we get a solid Java IDE environment is for everyone to pool > Paul> their time and resources to create this all together! > >This is key. I use JDEE when my day job asks me to write Java. So I'm >very focused on always having a working, maintainable, and useful >JDEE. This leads to the following "roadmap" in my head: > > 1. Get JDEE to work with Emacs CEDET (I believe this is now done on > trunk, at least I am using it daily) > > 2. Get the code base out (which I'm proposing we do now with a minor > release, and I will also work on getting this version back into > Debian). > > 3. Now clean out all the cruft to support old versions of Emacs, > CEDET, and other libraries. Build for GNU Emacs with it's included > CEDET. Period. No third party dependencies other than beanshell (and > Ant to build). This cleans up build and start up code, the CEDET > integration, sub-process management, and many other minor things that > are annoyances when making changes/improvements to JDEE (to me > anyway, because I find myself testing to many configurations since it > is so hard to tell which ones to worry about). > > 4. Documentation updates, and another minor release > >I can get (3) and (4) done relatively quickly after the release. It >will >mean trunk will target only GNU Emacs going forward. > >With that out of the way my list continues to: > > 5. Add Maven support (at a minimum like jde-ant today, but I'd like > better EDE/prj.el integration) > > 6. Do a release with working Maven support for Emacs 24+? > > 7. Replace Beanshell (probably along the lines that Paul is > suggesting) > > 8. Major release > >Step (7) is where a fork is a realistic thing to do. But I think we >should get this done in this code base. I'm not sure there is a >community large enough to support a fork, and without some basic >housekeeping the existing community, as it were, will fade away. > >Cheers! >Shyamal > >------------------------------------------------------------------------------ >Try New Relic Now & We'll Send You this Cool Shirt >New Relic is the only SaaS-based application performance monitoring >service >that delivers powerful full stack analytics. Optimize and monitor your >browser, app, & servers with just a few lines of code. Try New Relic >and get this awesome Nerd Life shirt! >http://p.sf.net/sfu/newrelic_d2d_apr >_______________________________________________ >jdee-devel mailing list >jde...@li... >https://lists.sourceforge.net/lists/listinfo/jdee-devel Use elpa to distribute jdee. It's built into the current emacs version. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
From: <phi...@ne...> - 2013-04-30 10:44:34
|
Paul Landes <la...@ma...> writes: > The basic idea would be to pretty much move all the things that beanshell and > semantic currently do to Java packages. That means using things like > compilation tools that come with the JDK and other OS packages (i.e. ASM) for > parsing, code completion, wizards, templates etc. The basic idea is using > straight Java packages for anything involving Java operations. This would > really slim down the code base and make it manageable. > > ABCL (common lisp implementation) would replace the now dead Beanshell > language, and frankly, seems like a better fit since its lisp and not Java. > Another benefit to this is it already works nicely with Slime so we could get > rid of the very (IMO) complex emacs -> beanshell IPC (emacs OO!) library. Just > that would be a huge victory in my mind as I've spent hours and hours > debugging these two parts that stubbornly do not play well together (i.e. > beanshell start times and process hangups). Beanshell was good for it's time, but is now a big problem with JDEE. Another option over ABCL would be Clojure. There is quite a big emacs community behind it now, with tools like nrepl.el nicely separate from the clojure-mode. The Java integration is also very nice and, from a quick look at ABCL, better than ABCL. It's already got some stuff we use (a Javadoc lookup for instance). The negative side is that Clojure is Eclipse Public License. My interpretation of these two licenses is that we *could* use Clojure (the GPL talks of "standard interface" which would cover this), but we would be restricted for other packages which are EPL which could not be validly linked to JDEE. > > Another idea I had is to move everything to maven so there would be maven > integration (bridged through ABCL) for compilations. If others still want to > use Ant or something else we can talk about some abstraction layer. > > Many nice useful parts of JDEE would be folded in (i.e. syntax highlight, > maven integration or Malabar mode might be folded in for this). > > I'm glad to put this on paper and if there is sufficient interest by those > WILLING TO HELP and write the CL, Java bindings, and Emacs code then I'll > continue this process. The other thing that would be worth thinking about is what we *do not* need. My own feeling is that all the template stuff can be ditched; writing these templates was always a total pain in the ass, and why bother -- yasnippet does the job. As far as I can tell, it should be possible to get maven to launch the nrepl-server. So, all the dependency stuff, classpath and all that nastiness would go. The project would be maintained in pom.xml. An ant task wouldn't be too hard. This would mean a lot of the project switching stuff could be binned. JDEE cannot compete with Eclipse or netbeans. The Emacs ecosystem, however, can, especially for people who, like myself, use Java as one of many tools. Caveat to all of this, of course, is doing the work. I'm a very occasional Java user these days, so like everyone else, can only contribute a small amount of time. Phil |
From: Paul L. <la...@ma...> - 2013-04-30 19:36:10
|
Shyamal, It isn't possible to duplicate the beanshell functionality in elisp. It has to be in Java or a Java scripting language since Java reflection is used for templating/wizards etc. On Apr 29, 2013, at 12:46 PM, Shyamal Prasad <sh...@me...> wrote: > >>>>>> "Paul" == Paul Landes <la...@ma...> writes: > > Paul> Again, I have thought about forking/canabalizing etc. The > Paul> primary motivation is that the project is large and very > Paul> dependent on CEDET. I have nothing bad to say about CEDET but > Paul> it's current integration with Emacs post 23 has been > Paul> non-compat and created a lot of issues for installation. > > Has anyone looked at implementing the beanshell functionality in elisp? > While I *love* coding in CL, I'm not sure I've talked myself to where > I'm sold on switching beanshell out with still another languge. The > truth is, I actually like elisp, and it will always be a well supported > language in Emacs :-) |
From: Paul L. <la...@ma...> - 2013-04-30 20:12:48
|
HI Phillip, I actually did consider Clojure, nrepl, Leiningen etc. and I agree on all points. The issue for me is it isn't Lisp. It's lisp like and has many of the features, but still isn't lisp. I see this turning into religion very soon, and I really don't want that :) Now that I've said that: http://en.wikipedia.org/wiki/Greenspun's_tenth_rule However, the big thing to me is that at the very minimum the data communication is between Emacs and ABCL is still s-expressions. The biggest pain point is creating lisp and in beanshell/java and hoping Emacs makes sense of it. If both languages speak the same basic same language development should prove to be faster and the project easier to maintain. There will be those that use an Emacs IDE that will want to use Clojure, others JRuby, Jython etc. I can't see adding these other languages in the 0th iteration of the new software but I could see abstracting some general API that could plug into a JVM and provide interfaces to standard services provided (i.e. reflection, template services, wizards, debugging, compiling (maven integration), etc). That would have to be a later iteration though. The idea is to have Emacs fork a JVM that acts a server and binds ports for each language. This wouldn't be a command event loop (currently beanshell impl), it would be a well defined protocol where a client specifies the language and communication parameters. The first and only would be CL and ABCL would interpret and respond. Later we could other languages as plugins so if you love groovy create your own groovy lang plugin and implement a group of services for the JVM to hook into. Given this design bringing other languages should be trivial but also give us a way of reusing (at least the core) of the services. This sounds good on paper, but my gut tells me we'd waste much less time and effort if we could just all agree on one language--but I doubt that will happen and someone (the one with the most time) will just have to make this call. On Apr 30, 2013, at 5:44 AM, Phillip Lord <phi...@ne...> wrote: > Paul Landes <la...@ma...> writes: >> The basic idea would be to pretty much move all the things that beanshell and >> semantic currently do to Java packages. That means using things like >> compilation tools that come with the JDK and other OS packages (i.e. ASM) for >> parsing, code completion, wizards, templates etc. The basic idea is using >> straight Java packages for anything involving Java operations. This would >> really slim down the code base and make it manageable. >> >> ABCL (common lisp implementation) would replace the now dead Beanshell >> language, and frankly, seems like a better fit since its lisp and not Java. >> Another benefit to this is it already works nicely with Slime so we could get >> rid of the very (IMO) complex emacs -> beanshell IPC (emacs OO!) library. Just >> that would be a huge victory in my mind as I've spent hours and hours >> debugging these two parts that stubbornly do not play well together (i.e. >> beanshell start times and process hangups). > > > Beanshell was good for it's time, but is now a big problem with JDEE. > Another option over ABCL would be Clojure. There is quite a big emacs > community behind it now, with tools like nrepl.el nicely separate from > the clojure-mode. The Java integration is also very nice and, from a > quick look at ABCL, better than ABCL. It's already got some stuff we use > (a Javadoc lookup for instance). > > The negative side is that Clojure is Eclipse Public License. My > interpretation of these two licenses is that we *could* use Clojure (the > GPL talks of "standard interface" which would cover this), but we would > be restricted for other packages which are EPL which could not be > validly linked to JDEE. > >> >> Another idea I had is to move everything to maven so there would be maven >> integration (bridged through ABCL) for compilations. If others still want to >> use Ant or something else we can talk about some abstraction layer. >> >> Many nice useful parts of JDEE would be folded in (i.e. syntax highlight, >> maven integration or Malabar mode might be folded in for this). >> >> I'm glad to put this on paper and if there is sufficient interest by those >> WILLING TO HELP and write the CL, Java bindings, and Emacs code then I'll >> continue this process. > > The other thing that would be worth thinking about is what we *do not* > need. My own feeling is that all the template stuff can be ditched; > writing these templates was always a total pain in the ass, and why > bother -- yasnippet does the job. > > As far as I can tell, it should be possible to get maven to launch the > nrepl-server. So, all the dependency stuff, classpath and all that > nastiness would go. The project would be maintained in pom.xml. An ant > task wouldn't be too hard. This would mean a lot of the project > switching stuff could be binned. > > JDEE cannot compete with Eclipse or netbeans. The Emacs ecosystem, > however, can, especially for people who, like myself, use Java as one of > many tools. > > Caveat to all of this, of course, is doing the work. I'm a very > occasional Java user these days, so like everyone else, can only > contribute a small amount of time. > > Phil |
From: Phillip L. <phi...@ne...> - 2013-04-30 20:22:54
|
I think that the situation is more subtle than this. Consider, for instance, this piece of code: (defun nrepl-ido-form (ns) "Construct a clojure form for ido read using NS." `(concat (if (find-ns (symbol ,ns)) (map name (concat (keys (ns-interns (symbol ,ns))) (keys (ns-refers (symbol ,ns)))))) (if (not= "" ,ns) [".."]) (->> (all-ns) (map (fn [n] (re-find (re-pattern (str "^" (if (not= ,ns "") (str ,ns "\\.")) "[^\\.]+")) (str n)))) (filter identity) (map (fn [n] (str n "/"))) (into (hash-set))))) This is an Emacs lisp function which returns a clojure form. The clojure in this case is covered by GPL because the file itself says that it is. Now, this GPL code is clearly linked to "map", "filter" and so on. This is allowable under GPL because "map" and "filter" are "Standard Interfaces". So, GPL code here is mere aggregation with clojure and not a derived work. However, this is not true for a third party EPL library; these are not standard interfaces, so you would have an derived work, which would mean an EPL/GPL code basis which is not legal. Personally, I do not think this would be too much of a problem. The core of clojure is most of what we would need. Of course, this is my interpretation. For instance, I think nrepl.el is on dodgy ground with its use of complete.core which, as far as I can tell, is EPL. Obviously the nrepl.el people think not. Sorry to be a licence bore; I've had a lot of reason to think about this recently, as I would like to use GPL code in a clojure project that I am working on. I can do so, but if I do, I cannot use third party libraries which are EPL. None of this is to knock the EPL or the GPL. But they are incompatible. I agree with the rest of what you say; the clojure ecosystem is fairly rich, and includes quite a few Emacs hackers. Many of them also use Java directly (as well as via clojure). And, by definition, anyone who uses clojure is lisp literate. So, it might bring in more developers. Phil ________________________________________ From: Steven Huwig [ste...@gm...] Sent: 30 April 2013 17:18 To: Phillip Lord Cc: Paul Landes; JDEE Users; JDEE Development Subject: Re: [jdee-devel] Call to Fork or simply for JDEE TODO items I don't see the problem with using Clojure unless you're planning on making JDEE a GNU project or distributing it with GNU Emacs. Just distribute the Clojure portions under Clojure's license and JDEE under JDEE's license. There's no way to link ELisp to Clojure anyway -- all the GNU-licensed code in Emacs needs a socket to talk to the EPL-licensed code in Clojure (whether Clojure itself or EPL-licensed libraries in Clojure). EPL is still a free software license after all. I think there's a much greater chance of a "halo effect" of Clojure developers who use emacs improving a Clojure-based JDEE, than there is of ABCL being significantly more effective at implementing JDEE. On Apr 30, 2013, at 6:44 AM, phi...@ne... (Phillip Lord) wrote: > Paul Landes <la...@ma...> writes: >> The basic idea would be to pretty much move all the things that beanshell and >> semantic currently do to Java packages. That means using things like >> compilation tools that come with the JDK and other OS packages (i.e. ASM) for >> parsing, code completion, wizards, templates etc. The basic idea is using >> straight Java packages for anything involving Java operations. This would >> really slim down the code base and make it manageable. >> >> ABCL (common lisp implementation) would replace the now dead Beanshell >> language, and frankly, seems like a better fit since its lisp and not Java. >> Another benefit to this is it already works nicely with Slime so we could get >> rid of the very (IMO) complex emacs -> beanshell IPC (emacs OO!) library. Just >> that would be a huge victory in my mind as I've spent hours and hours >> debugging these two parts that stubbornly do not play well together (i.e. >> beanshell start times and process hangups). > > > Beanshell was good for it's time, but is now a big problem with JDEE. > Another option over ABCL would be Clojure. There is quite a big emacs > community behind it now, with tools like nrepl.el nicely separate from > the clojure-mode. The Java integration is also very nice and, from a > quick look at ABCL, better than ABCL. It's already got some stuff we use > (a Javadoc lookup for instance). > > The negative side is that Clojure is Eclipse Public License. My > interpretation of these two licenses is that we *could* use Clojure (the > GPL talks of "standard interface" which would cover this), but we would > be restricted for other packages which are EPL which could not be > validly linked to JDEE. > >> >> Another idea I had is to move everything to maven so there would be maven >> integration (bridged through ABCL) for compilations. If others still want to >> use Ant or something else we can talk about some abstraction layer. >> >> Many nice useful parts of JDEE would be folded in (i.e. syntax highlight, >> maven integration or Malabar mode might be folded in for this). >> >> I'm glad to put this on paper and if there is sufficient interest by those >> WILLING TO HELP and write the CL, Java bindings, and Emacs code then I'll >> continue this process. > > The other thing that would be worth thinking about is what we *do not* > need. My own feeling is that all the template stuff can be ditched; > writing these templates was always a total pain in the ass, and why > bother -- yasnippet does the job. > > As far as I can tell, it should be possible to get maven to launch the > nrepl-server. So, all the dependency stuff, classpath and all that > nastiness would go. The project would be maintained in pom.xml. An ant > task wouldn't be too hard. This would mean a lot of the project > switching stuff could be binned. > > JDEE cannot compete with Eclipse or netbeans. The Emacs ecosystem, > however, can, especially for people who, like myself, use Java as one of > many tools. > > Caveat to all of this, of course, is doing the work. I'm a very > occasional Java user these days, so like everyone else, can only > contribute a small amount of time. > > Phil > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel |
From: Loyall, D. <dav...@ne...> - 2013-04-30 21:17:39
|
> From: Paul Landes [...] > It isn't possible to duplicate the beanshell functionality in elisp. It has to be in > Java or a Java scripting language since Java reflection is used for > templating/wizards etc. After reading this the first time and balking at the phrase "it isn't possible", I wrote a couple of Java classes for my amusement, and I hope yours, too. (See below.) After reading this the second time, I realized that I missed your point. (If I hadn't missed the point, I would have tried to write elisp, not java.) Incidentally, conversation regarding ABCL in the other messages in this thread is in line with the idea that I intended to express in the proof of concept: that emacs can carry on a conversation with a (thin) process in a running JVM in order to get information that isn't readily available outside of a JVM. So, +1 for ABCL. (I've used it elsewhere and I like it. It seems to be maturing at a pretty good rate. Apparently MOP stuff works, and there's some maven-asdf bridge that I haven't tried yet.) Regarding whether or not to fork, I can't comment on that, other than that it certainly wasn't my intent when I asked for a list of TODO items. :) Cheers, --Dave >>>>>>>>> hobbes@metalbaby:~/workspace/poc-el-reflection$ find . . ./.classpath ./.project ./bin ./bin/gnu ./bin/gnu/emacs ./bin/gnu/emacs/ElispBridge.class ./bin/gnu/emacs/MyObject.class ./src ./src/gnu ./src/gnu/emacs ./src/gnu/emacs/ElispBridge.java ./src/gnu/emacs/MyObject.java hobbes@metalbaby:~/workspace/poc-el-reflection$ head -1000 src/*/*/* ==> src/gnu/emacs/ElispBridge.java <== package gnu.emacs; import java.lang.reflect.Method; public class ElispBridge { public static void main(String[] args) throws Exception { //TODO get these strings from stdin, or a socket, or SOAP, or whatever. //I don't know lisp, so pardon me if these strings are silly. String query1 = "('object-methods 'gnu.emacs.MyObject)"; String query2 = "('invoke-method 'gnu.emacs.MyObject 'getStuff)"; //TODO determine query type at runtime, instead of hardcoding it. // query1 is looking for a list myObject's methods. // query2 is looking for information about a method. //query1 ... //TODO extract object name from query more reliably. String className = chewSexp(query1)[2]; Class<?> cls = Class.forName(className); for (Method m : cls.getMethods()) { //TODO return data to elisp in more elegant way. System.out.println(m); } System.out.println("***\n\n"); // query2 ... String otherClassName = chewSexp(query2)[2]; String methodName = chewSexp(query2)[3]; Class<?> otherCls = Class.forName(otherClassName); Object instance = otherCls.newInstance(); System.out.println(otherCls.getMethod(methodName, null).invoke(instance, null)); //TODO POC the other dozens of things reflection can do. } private static String[] chewSexp(String sexp) { // TODO Use off the shelf sexp parser, something with stacks... return sexp.replaceAll("[()]","").split(" *'"); } } ==> src/gnu/emacs/MyObject.java <== package gnu.emacs; public class MyObject { public String getStuff(){ return "Hello, World!"; } public void doNothing(String s, Object o, char[] ca){}; } hobbes@metalbaby:~/workspace/poc-el-reflection$ cd bin; java gnu.emacs.ElispBridge public java.lang.String gnu.emacs.MyObject.getStuff() public void gnu.emacs.MyObject.doNothing(java.lang.String,java.lang.Object,char[]) public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException public final void java.lang.Object.wait() throws java.lang.InterruptedException public boolean java.lang.Object.equals(java.lang.Object) public java.lang.String java.lang.Object.toString() public native int java.lang.Object.hashCode() public final native java.lang.Class java.lang.Object.getClass() public final native void java.lang.Object.notify() public final native void java.lang.Object.notifyAll() *** Hello, World! hobbes@metalbaby:~/workspace/poc-el-reflection/bin$ >>>>>>>>> |
From: Steven H. <ste...@ac...> - 2013-05-01 15:43:43
|
Nothing against ABCL at all, but the size of the intersection of (JDEE users, Clojure users) has to be an order of magnitude greater than the intersection of (JDEE users, ABCL users). On Tue, Apr 30, 2013 at 5:17 PM, Loyall, David <dav...@ne...>wrote: > > From: Paul Landes > [...] > > It isn't possible to duplicate the beanshell functionality in elisp. It > has to be in > > Java or a Java scripting language since Java reflection is used for > > templating/wizards etc. > > After reading this the first time and balking at the phrase "it isn't > possible", I wrote a couple of Java classes for my amusement, and I hope > yours, too. (See below.) > > After reading this the second time, I realized that I missed your point. > (If I hadn't missed the point, I would have tried to write elisp, not > java.) > > Incidentally, conversation regarding ABCL in the other messages in this > thread is in line with the idea that I intended to express in the proof of > concept: that emacs can carry on a conversation with a (thin) process in a > running JVM in order to get information that isn't readily available > outside of a JVM. > > So, +1 for ABCL. (I've used it elsewhere and I like it. It seems to be > maturing at a pretty good rate. Apparently MOP stuff works, and there's > some maven-asdf bridge that I haven't tried yet.) > > Regarding whether or not to fork, I can't comment on that, other than that > it certainly wasn't my intent when I asked for a list of TODO items. :) > > Cheers, > --Dave > > > >>>>>>>>> > hobbes@metalbaby:~/workspace/poc-el-reflection$ find . > . > ./.classpath > ./.project > ./bin > ./bin/gnu > ./bin/gnu/emacs > ./bin/gnu/emacs/ElispBridge.class > ./bin/gnu/emacs/MyObject.class > ./src > ./src/gnu > ./src/gnu/emacs > ./src/gnu/emacs/ElispBridge.java > ./src/gnu/emacs/MyObject.java > hobbes@metalbaby:~/workspace/poc-el-reflection$ head -1000 src/*/*/* > ==> src/gnu/emacs/ElispBridge.java <== > package gnu.emacs; > > import java.lang.reflect.Method; > > public class ElispBridge { > > public static void main(String[] args) throws Exception { > //TODO get these strings from stdin, or a socket, or SOAP, > or whatever. > //I don't know lisp, so pardon me if these strings are > silly. > String query1 = "('object-methods 'gnu.emacs.MyObject)"; > String query2 = "('invoke-method 'gnu.emacs.MyObject > 'getStuff)"; > > //TODO determine query type at runtime, instead of > hardcoding it. > // query1 is looking for a list myObject's methods. > // query2 is looking for information about a method. > > > //query1 ... > > //TODO extract object name from query more reliably. > String className = chewSexp(query1)[2]; > > Class<?> cls = Class.forName(className); > > for (Method m : cls.getMethods()) { > //TODO return data to elisp in more elegant way. > System.out.println(m); > } > > System.out.println("***\n\n"); > > // query2 ... > String otherClassName = chewSexp(query2)[2]; > String methodName = chewSexp(query2)[3]; > Class<?> otherCls = Class.forName(otherClassName); > Object instance = otherCls.newInstance(); > > System.out.println(otherCls.getMethod(methodName, > null).invoke(instance, null)); > > //TODO POC the other dozens of things reflection can do. > } > > private static String[] chewSexp(String sexp) { > // TODO Use off the shelf sexp parser, something with > stacks... > return sexp.replaceAll("[()]","").split(" *'"); > } > > > > } > > ==> src/gnu/emacs/MyObject.java <== > package gnu.emacs; > > public class MyObject { > > public String getStuff(){ > return "Hello, World!"; > } > > public void doNothing(String s, Object o, char[] ca){}; > } > hobbes@metalbaby:~/workspace/poc-el-reflection$ cd bin; java > gnu.emacs.ElispBridge > public java.lang.String gnu.emacs.MyObject.getStuff() > public void > gnu.emacs.MyObject.doNothing(java.lang.String,java.lang.Object,char[]) > public final native void java.lang.Object.wait(long) throws > java.lang.InterruptedException > public final void java.lang.Object.wait(long,int) throws > java.lang.InterruptedException > public final void java.lang.Object.wait() throws > java.lang.InterruptedException > public boolean java.lang.Object.equals(java.lang.Object) > public java.lang.String java.lang.Object.toString() > public native int java.lang.Object.hashCode() > public final native java.lang.Class java.lang.Object.getClass() > public final native void java.lang.Object.notify() > public final native void java.lang.Object.notifyAll() > *** > > > Hello, World! > hobbes@metalbaby:~/workspace/poc-el-reflection/bin$ > >>>>>>>>> > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > jdee-devel mailing list > jde...@li... > https://lists.sourceforge.net/lists/listinfo/jdee-devel > |
From: Przemysław W. <esp...@cu...> - 2013-05-01 12:48:56
|
Hello everybody! A roadmap can be based on what is most commonly used in different Java IDEs: 1. Easy installation and configuration No one will use JDEE if it takes a weekend to make it up and running. For example available JDKs (jde-jdk-registry) usually can be setup automatically from: JAVA_HOME, default paths in OS (/usr/lib/jvm, "C:\Program Files\java", etc.). 2. Integration with build tools (especially Maven) By that I mean loading project configuration (source/test classpaths) form build tool definition - pom.xml in case of Maven. This is a must for any non-HelloWorld project. 3. Code completion IMHO from this point JDEE can be used at all. 4. Jumping around the code - back and forth. To types/methods/fields at point, even if they are in external libraries (sources usually can be downloaded from Maven repo). 5. Finding usages of fields, methods, types. I use it everyday for finding dead code. It's also for refactoring tools. 6. Debugger with GUI. There was such project. Maybe it could be integrated with JDEE sometime. 7. Jump to compilation errors During editing and form build tool window. 8. Execution of selected tests (especially currently edited one) It's just TDD routine. 9. The most common refactorings Rename field/method/class. Extract method. Move class (for example static nested class to it's own file). 10. Easy way to write extensions for JDEE. 11. Configurable indentation. 12. Facets/extensions for common technologies (Spring, JPA/Hibernate): - indicate which classes are Spring beans - jump to a bean definition - find beans implementing given interface It's just a roadmap, my idea for what's important for any Java development. You even don't have to agree with it and can pipe to /dev/null. :-) Of course Java IDEs have many more features, but from what I've seen for past 9 years of work as Java developer most of work is concentrated around writing tests, code, simple refactorings, and jumping around the code. :-) IMHO from the development perspective, it would be cool to write some unit tests for features (especially in elisp). In Java world it's a standard. If someone is not used to it I just can tell that it prevents regression and enables refactoring. If it's not a standard practice in a project, then it quickly becomes unmaintainable and sooner or later dies. BTW As a developer I can contribute Java, elisp, and some Clojure if needed. Cheers, Przemek |
From: Paul L. <la...@ma...> - 2013-05-06 18:00:42
|
These are great details--Thanks Przemysław. However, I think first we need to either come to a consensus as to whether it is worth forking or refactored. BTW--There already is some code completion (`jde-complete') and method jumping in its current form can be accomplished with CEDET's speedbar). On May 1, 2013, at 7:22 AM, Przemysław Wojnowski <esp...@cu...> wrote: > Hello everybody! > > A roadmap can be based on what is most commonly used in different Java > IDEs: > 1. Easy installation and configuration > No one will use JDEE if it takes a weekend to make it up and > running. > For example available JDKs (jde-jdk-registry) usually can be setup > automatically from: JAVA_HOME, default paths in OS (/usr/lib/jvm, > "C:\Program Files\java", etc.). > 2. Integration with build tools (especially Maven) > By that I mean loading project configuration (source/test > classpaths) form build tool definition - pom.xml in case of Maven. > This is a must for any non-HelloWorld project. > 3. Code completion > IMHO from this point JDEE can be used at all. > 4. Jumping around the code - back and forth. > To types/methods/fields at point, even if they are in external > libraries (sources usually can be downloaded from Maven repo). > 5. Finding usages of fields, methods, types. > I use it everyday for finding dead code. It's also for refactoring tools. > 6. Debugger with GUI. > There was such project. Maybe it could be integrated with JDEE sometime. > 7. Jump to compilation errors > During editing and form build tool window. > 8. Execution of selected tests (especially currently edited one) > It's just TDD routine. > 9. The most common refactorings > Rename field/method/class. Extract method. Move class (for example > static nested class to it's own file). > 10. Easy way to write extensions for JDEE. > 11. Configurable indentation. > 12. Facets/extensions for common technologies (Spring, JPA/Hibernate): > - indicate which classes are Spring beans > - jump to a bean definition > - find beans implementing given interface > > It's just a roadmap, my idea for what's important for any Java > development. You even don't have to agree with it and can pipe > to /dev/null. :-) > > Of course Java IDEs have many more features, but from what I've seen for > past 9 years of work as Java developer most of work is concentrated > around writing tests, code, simple refactorings, and jumping around the > code. :-) > > IMHO from the development perspective, it would be cool to write some > unit tests for features (especially in elisp). In Java world it's a > standard. If someone is not used to it I just can tell that it prevents > regression and enables refactoring. If it's not a standard practice in a > project, then it quickly becomes unmaintainable and sooner or later > dies. > > BTW As a developer I can contribute Java, elisp, and some Clojure if needed. > > Cheers, > Przemek |
From: <phi...@ne...> - 2013-05-01 13:50:39
|
Paul Landes <la...@ma...> writes: > I actually did consider Clojure, nrepl, Leiningen etc. and I agree on all > points. The issue for me is it isn't Lisp. It's lisp like and has many of the > features, but still isn't lisp. Wikipedia disagrees with you! There isn't a complete definition of lisp, but functional, untyped, prefixed and with lots of parenthesis seems to cover it. Clojure isn't common lisp for sure, but then neither is Elisp. The biggest single difference is the way functions are called. So ;; elisp (defvar x 10) (defun x () x) (x) ;; returns 10 ;; clojure (def x) (defn x[] x) (x) ;; returns #<user$x user$x@3f7ebc6c> where elisp makes more sense. But, the gain for this is: ;; elisp (defun f (g x) (g x)) (f (lambda(x) x) 10) ;; crashes ;; clojure (defn f[g x] (g x)) (f (fn [x] x) 10) ;; returns 10 As far as I can see, the Java integration is much nicer for Clojure. So compare this ABCL example, with my attempt at two clojure equivalents after it. ;; ABCL (defun void-function (param) (let* ((class (jclass "Main")) (intclass (jclass "int")) (method (jmethod class "addTwoNumbers" intclass intclass)) (result (jcall method param 2 4))) (format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" result))) ;; clojure (two equivalents) (defn f [param] (printf "in f, adding two numbers: %s" (.addTwoNumbers (Main.) 2 4))) (defn f [param] (let [main (Main.) result (.addTwoNumbers main 2 4)] (printf "in f, adding two numbers: %s" result))) Having written quite a lot of Clojure using an Java API underneath, I think the integration is very nice. The difference is that Clojure was designed to be tightly integrated with the JVM; ABCL was designed to be common lisp on a JVM. There is already a reasonable amount of stuff in Clojure which we could use. So... ;; fetching javadoc (use 'clojure.core.javadoc) (javadoc String) Nrepl.el provides most of the code that we need to interact already. So, for instance this is from my own tawny-mode.el which calls clojure (to call Java). The first function is the key one; all the rest are subsidiary. ;; elisp calling clojure (defun tawny-mode-is-coherent () (interactive) (when (tawny-mode-check-for-nrepl-buffer) (tawny-mode-nrepl-reasoner-eval-string (format "(do (require 'tawny.emacs)(tawny.emacs/is-coherent \"%s\"))" (clojure-find-ns) )))) (defun tawny-mode-check-for-nrepl-buffer () (if (find-if (lambda (buffer) (lexical-let ((buffer (get-buffer buffer))) (equal (nrepl-project-directory-for (nrepl-current-dir)) (buffer-local-value 'nrepl-project-dir buffer)))) nrepl-connection-list) t (message "No nREPL buffer exists. Please use `nrepl-jack-in'") nil )) (defun tawny-mode-make-reasoner-response-handler (buffer) (nrepl-make-response-handler buffer (lambda (buffer value) (tawny-message "For %s: %s" buffer value)) (lambda (buffer value) (tawny-message "Output: %s %s" buffer value)) (lambda (buffer value) (tawny-message "Error: %s %s" buffer value)) (lambda (buffer value) (tawny-message "Complete: %s %s" buffer value)))) > I see this turning into religion very soon, and I really don't want > that :) I think we can avoid this. Now that I have written this email, I won't say more! At the end of the day, the choice is likely to be yours, as I am not likely to find the time to do more than contribute a little. It is, of course, absolutely the case that I have an asymmetric knowledge; I've used clojure a lot since last October, while my closest exposure to CL is emacs, and I've never used ABCL. > However, the big thing to me is that at the very minimum the data > communication is between Emacs and ABCL is still s-expressions. The biggest > pain point is creating lisp and in beanshell/java and hoping Emacs makes sense > of it. If both languages speak the same basic same language development should > prove to be faster and the project easier to maintain. Sure, it's just a question of how similar. You can manipulate common lisp or clojure in elisp both as strings or as lisp data structures, and vice versa. > There will be those that use an Emacs IDE that will want to use Clojure, > others JRuby, Jython etc. I can't see adding these other languages in the 0th > iteration of the new software but I could see abstracting some general API > that could plug into a JVM and provide interfaces to standard services > provided (i.e. reflection, template services, wizards, debugging, compiling > (maven integration), etc). That would have to be a later iteration though. > > The idea is to have Emacs fork a JVM that acts a server and binds ports for > each language. This wouldn't be a command event loop (currently beanshell > impl), it would be a well defined protocol where a client specifies the > language and communication parameters. The first and only would be CL and ABCL > would interpret and respond. Later we could other languages as plugins so if > you love groovy create your own groovy lang plugin and implement a group of > services for the JVM to hook into. Given this design bringing other languages > should be trivial but also give us a way of reusing (at least the core) of the > services. This is basically the same as swank -- single Emacs backend, multiple language backends (even if they are all lisp). Interesting, nrepl is going in the opposite backend direction -- single language backend, multiple IDE/editor backends. > This sounds good on paper, but my gut tells me we'd waste much less time and > effort if we could just all agree on one language--but I doubt that will > happen and someone (the one with the most time) will just have to make this > call. Yes, I agree. I've no desire to see multiple languages in JDEE; a pragmatic replacement for beanshell is required, and a JVM hosted lisp makes a lot of sense. Either clojure or ABCL could fulfil that requirement. The secondary points that I raise are important also, though. Having a goal of replacing all the java so that JDEE would not require a compilation step, would really simplify the build. And, being able to launch the JVM hosted from Maven, (as well as without) so that it shared all the classpath settings, would be a big save. At this point, the my contribution to the religious war ends! I'll look forward to what ever is decided. Phil |
From: Paul L. <la...@ma...> - 2013-05-06 18:24:39
|
On May 1, 2013, at 8:50 AM, Phillip Lord <phi...@ne...> wrote: > Paul Landes <la...@ma...> writes: >> I actually did consider Clojure, nrepl, Leiningen etc. and I agree on all >> points. The issue for me is it isn't Lisp. It's lisp like and has many of the >> features, but still isn't lisp. > > Wikipedia disagrees with you! Don't believe everything a community definition site tells you :) Hehe, seriously, at some point it becomes semantic, but if I were to edit this wikipedia page I'd emphasize syntax and speaking from experience, the devil is in the details when parsing it. > There isn't a complete definition of lisp, but functional, untyped, > prefixed and with lots of parenthesis seems to cover it. Clojure isn't > common lisp for sure, but then neither is Elisp. Again, I think we're talking about semantics, but most would agree that Elisp is a lisp dialect and again the operative disagreement is over syntax of the language. > Having written quite a lot of Clojure using an Java API underneath, I > think the integration is very nice. The difference is that Clojure was > designed to be tightly integrated with the JVM; ABCL was designed to be > common lisp on a JVM. I don't disagree, but why couldn't you macro out the Java native calls in CL and carry object instances in CLOS objects? In fact, I've already started this work. --<interesting twany library code examples snipped>-- > >> I see this turning into religion very soon, and I really don't want >> that :) > > > I think we can avoid this. Now that I have written this email, I won't > say more! At the end of the day, the choice is likely to be yours, as I > am not likely to find the time to do more than contribute a little. > > It is, of course, absolutely the case that I have an asymmetric > knowledge; I've used clojure a lot since last October, while my closest > exposure to CL is emacs, and I've never used ABCL. I actually have the same amount of experience with Clojure (one project) than CL. I'm trying to make this decision to fix head aches we currently have in JDEE and get the project moving again, which has been very difficult I think we can all agree. >> However, the big thing to me is that at the very minimum the data >> communication is between Emacs and ABCL is still s-expressions. The biggest >> pain point is creating lisp and in beanshell/java and hoping Emacs makes sense >> of it. If both languages speak the same basic same language development should >> prove to be faster and the project easier to maintain. > > Sure, it's just a question of how similar. You can manipulate common > lisp or clojure in elisp both as strings or as lisp data structures, and > vice versa. Frankly I disagree: given more keyword and syntax differences parsing and munging code going back and forth between the two will be heavier if Clojure is chosen. --<multi-lang/nrepl snipped>-- >> This sounds good on paper, but my gut tells me we'd waste much less time and >> effort if we could just all agree on one language--but I doubt that will >> happen and someone (the one with the most time) will just have to make this >> call. > > Yes, I agree. I've no desire to see multiple languages in JDEE; a > pragmatic replacement for beanshell is required, and a JVM hosted lisp > makes a lot of sense. Either clojure or ABCL could fulfil that > requirement. We agree on this point and I'm still not ruling out Clojure as they both have advantages and disadvantages. > The secondary points that I raise are important also, though. Having a > goal of replacing all the java so that JDEE would not require a > compilation step, would really simplify the build. And, being able to > launch the JVM hosted from Maven, (as well as without) so that it shared > all the classpath settings, would be a big save. Agreed. > At this point, the my contribution to the religious war ends! I'll look > forward to what ever is decided. Your discussion is helpful and your arguments are persuasive. Thanks Phil. |
From: Shyamal P. <sh...@me...> - 2013-05-01 18:41:04
|
>>>>> "Przemysław" == Przemysław Wojnowski <esp...@cu...> writes: Nice list Przemysław. I can see common themes between Paul's original list and the user features people seem to want. Leaving aside the question "to fork, or not to fork?" here are some observations. Przemysław> 1. Easy installation and configuration No one will use Przemysław> JDEE if it takes a weekend to make it up and running. Przemysław> For example available JDKs (jde-jdk-registry) usually Przemysław> can be setup automatically from: JAVA_HOME, default Przemysław> paths in OS (/usr/lib/jvm, "C:\Program Files\java", Przemysław> etc.). The detection of available JDK works *except* for gnu/linux systems that use /etc/alternatives. I have a fix that I will commit this weekend for gnu/linux that should solve it (at least on the systems I have). But on recent Mac OS X systems, or if you set JAVA_HOME, it should Just Work. Bug reports/patches always welcome. Przemysław> 2. Integration with build tools (especially Maven) By Przemysław> that I mean loading project configuration (source/test Przemysław> classpaths) form build tool definition - pom.xml in case Przemysław> of Maven. This is a must for any non-HelloWorld Przemysław> project. Right now it only works with ant (and, IMHO, extremely well - on ant based projects JDEE is the best way to use Emacs). Yes, I need pom.xml parsing too. I will attempt to add it as soon as I have the time, or if some one sends me patches that work :-) Przemysław> 3. Code completion IMHO from this point JDEE Przemysław> can be used at all. Which parts of "C-c C-v ." (jde-complete-in-line) or (jde-complete-menu) are you unhappy with? I really want to know so it can be improved, and it works for me. Yes, I wish we had generics support too.... Przemysław> 4. Jumping around the code - back and forth. To Przemysław> types/methods/fields at point, even if they are in Przemysław> external libraries (sources usually can be downloaded Przemysław> from Maven repo). Jumping between classes works pretty well for me. The rest of it, yes, it needs some improvement. Przemysław> 5. Finding usages of fields, methods, types. I use it Przemysław> everyday for finding dead code. It's also for Przemysław> refactoring tools. Yep, that would be awesome. As far as I know semantic is totally capable of doing this, though a fork might choose to do it totally differently. Przemysław> 6. Debugger with GUI. There was such project. Maybe it Przemysław> could be integrated with JDEE sometime. The jdb integration actually does work (I've made edits to the code to fix warnings, and tested it recently) but it is very hard to set up for a "real" project. What debugger do people actually use? Przemysław> 7. Jump to compilation errors During editing and form Przemysław> build tool window. This works extremely well for Ant. I personally add this to get Maven 2 "support" (require 'compile) (add-to-list 'compilation-error-regexp-alist 'maven) (add-to-list 'compilation-error-regexp-alist-alist '(maven "\\(^/.+?\\):\\[\\([0-9]+\\),\\([0-9]+\\)\\].*" 1 2 3)) and use M-x compile and it gets the job done for me. I wish I had more, and I'm personally going to put something together in the weeks to come. Przemysław> 8. Execution of selected tests (especially currently Przemysław> edited one) It's just TDD routine. Przemysław> 9. The most common refactorings Rename Przemysław> field/method/class. Extract method. Move class (for Przemysław> example static nested class to it's own file). 10. Easy Przemysław> way to write extensions for JDEE. Przemysław> 11. Configurable indentation. This one already exists in JDEE but is poorly documented/designed (if you think the underlying cc-mode indentation is good enough). Przemysław> 12. Facets/extensions for common technologies (Spring, Przemysław> JPA/Hibernate): - indicate which classes are Spring Przemysław> beans - jump to a bean definition - find beans Przemysław> implementing given interface All good ideas for people who need them, I agree. Przemysław> BTW As a developer I can contribute Java, elisp, and Przemysław> some Clojure if needed. If you are using JDEE regularly (or even otherwise) I'd be happy to accept any fixes, or even bug reports with an offer to help test fixes on platforms I don't have. I think the biggest issue is generics - and that leads to beanshell. I suspect that is where the fork comes in.... Cheers! Shyamal |