Re: [jdee-devel] Call to Fork or simply for JDEE TODO items

Hi all, just wanted to chime in and say I'm excited about this thread! I'd
really love to use emacs to as my java IDE. And it'd be a fun challenge and
learning experience for me to help with development of the effort. I'd like
to help where I can, so please feel free to assign me tasks ;-). I'm fluent
in java, elisp and clojure, but I can pick up other langs as needed. I'm
primarily a web developer but looking for an excuse to stretch my skills
and learn more about lower level intricacies of parsing, compilation, etc.

I think Paul's high level design sounds good:

I recommend the following components for the fork:
> - Java program to host development "services": compilation, debugging,
> code generation.  This is a separate process.
> - Maven: either as a separate JVM process or preferably in the same JVM as
> the development services JVM
> - Emacs: Brand new code base with limited JDEE functionality that make
> sense to bring over (i.e. highlighting).


And I think Przemek's list of features is a great start. I'm guessing that
we all have a list of features like that we'd love to have available in
emacs. Once the development services component takes a basic shape, my
understanding is that all features in his list can be accomplished by using
a combination of existing jdee code + new code (and maybe pulling in some
ideas from other libs like malabar, etc).

And +1 for unit tests!

>From the ideas described on the thread so far, I think it would be possible
to implement features using a strategy like this:

1) a new elisp client lib exposes api for each feature

2) the actual implementation of the feature can make use of existing jdee
code, cedet code, and/or new code that runs in development services
component jvm process that elisp client lib knows how to communicate with
(using lisp as data format).

3) emacs users can then easily make use of development services elisp
client api. modes can be built on top, etc.

As a concrete example, here's some elisp that I hacked together a while
back. It's a very simple way to search the maven repo for dependencies and
add the results to the current pom.xml:

http://javajing.com/2012/08/25/emacs-maven-mode.html

If the development services jvm + elisp client lib existed, then I could
change this maven dependency example code to call the api of the
development service in order to search for dependencies. The development
service could then use whatever mechanism makes the most sense to do
actually perform the search for the dependencies under the hood. Maybe it
would use maven api to do a search, or maybe we write custom code to stuff
metadata about dependencies into some sort of search index, or whatever.
There could even be multiple implementations for searching dependencies.

Using lisp as the data format for communicating between a development
services jvm process and a elisp client lib sounds good to me. I'd vote for
clojure flavored lisp, but if the consensus is for ABCL, that's fine too,
it'll be fun to learn ;-)

I hope that makes sense and I'm interested in any feedback. I'm also
interested in diving into figuring out and peoples thoughts about the best
libs to use for parsing and compiling java code.

Excited to help out, please let me know when you setup the repo (and I'd
like to add my vote for git if it's a option).

Thanks!
Dave

On Wed, May 1, 2013 at 8:22 AM, Przemysław Wojnowski
<[email protected]>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
>
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jdee-users
>



-- 
Dave Paroulek
m. 703.989.3562

------------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jdee-users