Shyamal Prasad <shya...@member.fsf.org> writes: > 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. Sounds great! When/how is it activated? Do I have to call some function?
> 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 :-) I've been working in different corporations for couple of years now and the only time I had a contact with Ant projects was when they were migrated to Maven. It's just my experience and I'm aware that there are still Ant based projects. The usual way to start with a Java project is this: User calls/clicks IDE->Open Project, points to directory with project and selects build file. If it's pom.xml, then it's Maven project and IDE-Maven-Configurer sets IDE configuration for this project. If there is IDE's configuration for this project (prj.el in our case) it is loaded, else/and IDE's configuration is (re-)created from pom.xml. There should be also "Reimport Maven project" function, so that user can rebuild IDE's project configuration every time pom.xml changes. Of course, it should be done automatically, when pom.xml change comes from VCS. As starting point build tool can be executed through M-x compile (or some wrapper, which would start always from base dir) or even from shell. Later it would be good to have some configurable runner for the tool. In case of Maven it would need to allow to: select lifecycle phases, select profiles, toggle tests, toggle offline mode, maybe pass some args to JVM. BTW for me possibility to nest prj.el files in subdirs is useless. IMHO it's enough to have only one prj.el file in project base dir. > > 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.... At this moment I don't remember what works and what doesn't. I'll return to it later. When there's no project setup (especially classpaths), then code completion doesn't really matter. ;-) > 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? There is JDibug (http://code.google.com/p/jdibug/), but I'm not sure it's current state. Maybe it could be integrated into JDEE. > > 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. It would be great to apply this customization automatically, when Maven project has been detected. > 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. Nowadays I don't use JDEE. Without real Maven support I can't use it on any project. Of course I'm willing to help and test (on Linux and sometimes on Win7) or implement something. I've written about unit tests on purpose. Without them any project becomes real pain to maintain in long term. Testing something manually tells only that something works at this moment. It doesn't mean that it will still work in a year or five from now. Some tests have to be done manually, but in case of JDEE most could be done automatically. > I think the biggest issue is generics - and that leads to beanshell. I > suspect that is where the fork comes in.... Thankfully Java is also evolving in a slow pace. ;-) > > Cheers! > Shyamal Przemek ------------------------------------------------------------------------------ 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 jdee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdee-devel
