Shyamal Prasad <shya...@member.fsf.org> wrote:
>
>>>>>> "Paul" == Paul Landes <lan...@mailc.net> 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
>jdee-devel@lists.sourceforge.net
>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.
------------------------------------------------------------------------------
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
