Przemysław Wojnowski | 24 Aug 21:24 2015

Purpose of which.el

Hello everybody,

Anyone knows what is the purpose of which.el?

AFAIK it is not used and can be removed.

Thanks,
Przemysław

------------------------------------------------------------------------------
_______________________________________________
jdee-devel mailing list
jdee-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel
Przemysław Wojnowski | 24 Aug 11:49 2015

Recent changes

Hello everybody,

Recently I did a couple of updates to move JDEE to MELPA:
1. Renamed every "jde" to "jdee" match project name and packaging naming 
conventions (rules?).
This means that if you've got an old config with "jde" vars you'll have 
to rename them to "jdee".
Nobody has implemented auto conversion. Sorry. :-)

2. jdee-server-dir is required to have support from JVM side.
The jar from jdee/jdee-server have to be copied to some directory and 
jdee-server-dir should point to it (the dir).
If it is unset then user will see a message on the first call to JVM 
part.

3. Since we're on melpa, we can use other packages.

4. We can work on other things in parallel.

Cheers,
Przemysław

------------------------------------------------------------------------------
_______________________________________________
jdee-devel mailing list
jdee-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel
Lee Hinman | 18 Aug 23:32 2015

Re: Proposed New Structure (starter for 10)


Re-added the jdee-devel list

Phillip Lord writes:

> Lee Hinman <leehinman <at> fastmail.com> writes:
>> This looks neat to me, and I'm interested in contributing. What's the
>> best place to start with this? (Assuming this is adopted)
>
>
> The roadblock for me at the moment is understanding mvn. If you have
> any time to research this, it would be appreciated. In particular, how
> to add dependencies or plugins without changing the pom.
>
> Phil

So I looked into this briefly, it looks like this can be added to
${user.home}/.m2/settings.xml, specifically, one can specify plugin
groups with:

<pluginGroups>
  <pluginGroup>org.jdee.plugin</pluginGroup>
<pluginGroups>

The docs say: "This element contains a list of pluginGroup elements,
each contains a groupId. The list is searched when a plugin is used and
the groupId is not provided in the command line."

So if we provided a jdee-mvn plugin and added the groupId here, someone
could use
(Continue reading)

Lee Hinman | 16 Aug 20:03 2015

Where to contribute?


Hi All,

So, I'd like to contribute to jdee, but with the latest discussion, I'm
slightly confused on where to focus my efforts. I see there are a few
different options:

- jdee master branch (on Github)
- jdee "cask" branch (based on the recent jdee-devel discussion)
- jde-with-clojure-backend (https://github.com/phillord/jde-with-clojure-backend)

Where's the best place to contribute to?

--

-- 
;; Lee

------------------------------------------------------------------------------
Phillip Lord | 14 Aug 18:51 2015
Picon
Picon

Proposed New Structure (starter for 10)


So, I wanted to put some meat onto the bone of my proposed new
structure for JDEE.

It doesn't work yet, of course, but I think that it can in a relatively
short space of time.

https://github.com/phillord/jde-with-clojure-backend

The four components are:

jde -- this will be the Java centric major mode. It will involve NO JVM
interaction and not depend on any of the other parts. The "minimal
viable product" here is a ELPA packaged major mode that is a child of
Java mode and adds no functionality.

jde-interactive (crappy name, sorry) -- a minor mode which will be
active once the JVM (bsh interpreter equivalent) has been started and is
running. In the short term, this will have a dependency on cider, but
eventually this may just become a dependency on nrepl-client.el. I say
may, because, I think quite a bit of the cider functionality (like the
inspector) is JVM centric and entirely relevant.

The MVP here is to use maven inside a project to launch an nrepl, and
then to invoke a call to get the version number of the jde-nrepl
middleware and check that it is consistent with the version of jde-interactive.

jde-nrepl -- this is the nrepl middleware that provides all the backend
functionality, like class look up and the like. The MVP here is to
install some middleware into a nrepl, which returns a version map for
(Continue reading)

Stephen Leake | 14 Aug 01:12 2015

Re: [jdee] Automated Build (#3)

Phil Lord <notifications <at> github.com> writes:

> I think we just need to decide. I would argue that broad architectural
> decisions should be on the mailing list. Specific bug reports and
> discussion about them might as well be github.

Bug report discussions should be on the bug report, not on a general git
hub list.

--

-- 
-- Stephe

------------------------------------------------------------------------------
Stephen Leake | 14 Aug 01:08 2015

Re: [jdee] Automated Build (#3)

Phil Lord <notifications <at> github.com> writes:

> Paul Landes <notifications <at> github.com> writes:
>
>> I believe you submit .tar files.  The jar would go in the .tar file.
>>
>> On Aug 12, 2015, at 3:13 PM, Przemysław Wojnowski <notifications <at> github.com>
>> wrote:
>>
>>> But what to do with Java code? Is it possible to upload a JAR to (m)ELPA?
>
>
> We probably also need to make a rough decision about github vs mailing
> list conversations!

A moot point to me; they all show up in the same Gnus group :).

There is a difference in searching for things later; you have to search
two databases.

--

-- 
-- Stephe

------------------------------------------------------------------------------
_______________________________________________
jdee-devel mailing list
jdee-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel
Stephen Leake | 14 Aug 01:07 2015

Re: [jdee] Automated Build (#3)

Phil Lord <notifications <at> github.com> writes:

> With Marmalade, this would be possible, I think, unless Nic has
> specially blocked it. With ELPA this might be possible, but ELPA
> requires copyright assignment, which is just not going to happen short
> term. 

The term "ELPA" means "Emacs Lisp Package Archive"; it does not refer to
any particular repository of packages. It means a repository that can be
accessed by the Emacs package API.

I believe you are actually refering to "Gnu ELPA" here; the ELPA
repository containing FSF packages, at http://elpa.gnu.org/.

> JDEE currently has the nightmare of Emacs Lisp build with ant. Let's
> build emacs-lisp with cask, Java with maven. Any otherway lies, well,
> lies this:
>
>     <exec dir="${build.lisp.escaped.dir}"
> 	  executable="${build.bin.emacs}" failonerror="true">
>       <arg value="--no-site-file"/>
>       <arg value="--batch"/>
>       <arg value="--load"/>
>       <arg value="${build.lisp.dst.escaped.file}"/>
>     </exec>

I was tempted to complain about that as well :). My reaction was
"exactly how is this better than a Makefile line?".

--

-- 
(Continue reading)

Przemysław Wojnowski | 12 Aug 22:09 2015

Purpose of jde-autoloads

Hello everybody,

I was thinking about purpose of autoloads and IIUC its sole purpose is to lazy 
load parts of JDEE. But what for? Maybe 10-15 years ago it was speeding up 
loading of JDEE, but now the difference is marginal. The only function I would 
see in autoloads would be something like this:
(defun jde-start ()
   "Start JDEE."
  (require 'jde))

Rationale: If someone would install JDEE (e.g. from elpa) it wouldn't slow down 
Emacs startup. But user could load it anytime using M-x jde-start when s/he 
would like to open a Java project.

What do you think about it?
I nobody mind or answer by the end of the week I'll reduce jde-autoload to the 
one method.

Cheers,
Przemysław

------------------------------------------------------------------------------
_______________________________________________
jdee-devel mailing list
jdee-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel
Phillip Lord | 20 Jul 15:12 2015
Picon
Picon

Re: Next Gen JDEE


(Resent after bounce -- apologies for lateness)

My suggestion: why not create a branch and a file called next-gen.org into it. Then we can write up plans as to
what needs to be done
to move toward the next-gen what ever form that takes. If this is to happen, there needs to be some
co-ordination and a list of tasks is 
about the best I can suggest.

As before, I would work on the basis that things are likely to get worse before they get better,  or move fast
(well faster) and break things approach. So maintaining a current gen version probably does not make sense.

Ironically, I think, the critical features that we need are nothing to do with Java. You asked a while back
what I found in JDEE "unusable". 
That's the critical feature -- automatic installation, from package.el.

Phil
________________________________________
From: Paul Landes <landes <at> mailc.net>
Sent: 20 July 2015 05:08
To: Phillip Lord
Cc: Przemysław Wojnowski; JDEE Development
Subject: Re: [jdee-devel] Next Gen JDEE

Phillip,

I don't think many write Java any more :)  It would definitely be great to get some of your development help.

Yes, no lambda support.

(Continue reading)

Phillip Lord | 4 Aug 13:50 2015
Picon
Picon

Some stories from a user


(Again, apologies for lateness -- been offline)

 > Enter Maven. I use a web search engine (or built-in Eclipse feature,
 > but it's not very good) to find this:
 > http://search.maven.org/#artifactdetails|org.apache.commons|commons-lang3|3.4|jar
 > 
 > Then, I add this to my project's (existing) pom.xml:
 > 
 >     <dependency>
 >         <groupId>org.apache.commons</groupId>
 >         <artifactId>commons-lang3</artifactId>
 >         <version>3.4</version>
 >     </dependency>
 > 
 > As soon as I hit save, I can go back to CoolClass.java and hit c-SPC
 > again. It will work.

I have to agree with what you are saying about maven. Assuming JDEE goes
the route that I have suggested with a Clojure based nrepl client/server
(as opposed to beanshell) approach, there would be several ways of
achieving this.

We could supply explicit support for adding dependencies; trivially, the
nrepl server would need restarting afterwards. Even neater would be to
use a tool like pomegranate which *dynamically* extends the classpath.
This includes adding a new maven dependency (with all the downloads that
this entails, iff any).

The move away from beanshell to something better supported should mean
(Continue reading)


Gmane