>>>>> "Joakim" == joakim <joakim@...> writes:
Joakim> Phillip.Lord@... writes:
>> Sorry me not being clear.
>> The build we have working is in ant. I think it makes sense to
>> stick with this, I think. Maven is better than ant in many ways,
>> but not for building lisp code.
>> I meant I haven't got JDEE working with maven in the sense of using
>> maven as a tool to build the java projects that I am developing
>> with maven. I'd like to put better support in for this.
Joakim> I agree. Espens maven library has the right idea. We use maven
Joakim> a lot at work, and many developers use Eclipse with the maven
Joakim> plugin. With the jdee getting its settings from the maven
Joakim> project file, its very easy to use emacs and eclipse side by
Joakim> side. (not that Id use eclipse rather than emacs, but its
Joakim> easier to work with other people this way)
If I may be so bold, and with due respect to Espens library, I think
it's actually got things backward, and based on limited understanding of
the code (time, as ever, being against me).
There are two basic ways we can have JDEE support maven. Either, we have
JDEE understand pom files which is the approach pom-parser.el takes. Or,
we make maven understand JDEE. I would argue that the latter is the
Basically, pom files and particularly project aggregation and
inheritance in maven are nasty and poorly documented. It's unlikely that
any independent implementation will get the same behaviour as maven. In
fact, I am having problems at the moment because of this very issue in
some code I am using. One of the libraries (in java) parses the pom but
doesn't do exactly the right thing.
This is borne out by the existence of eclipse and intelli-j plugins for
maven. Basically, maven generates project files for these editors. We
could do the same for JDEE; in fact, I did the same a number of years
ago by writing an ant task which generated prj.el files.
So, I've took a look at the idea and eclipse plugins for maven. Both
quite large. The eclipse plugin looks the better coded. So, it would be
rewritable, but a significant job.
Then I thought, why rewrite things. The eclipse plugin produces
.classpath files which look something like this....
<classpathentry kind="src" path="src/main/java"/>
<classpathentry kind="src" path="src/test/java" output="target/test-classes"/>
<classpathentry kind="output" path="target/classes"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="var" path="M2_REPO/javax/activation/activation/1.1/activation-1.1.jar"/>
<classpathentry kind="var" path="M2_REPO/aopalliance/aopalliance/1.0/aopalliance-1.0.jar"/>
<classpathentry kind="src" path="/instantsoap-api"/>
<classpathentry kind="var" path="M2_REPO/javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar"/>
<classpathentry kind="var" path="M2_REPO/org/apache/ws/commons/schema/XmlSchema/1.4.2/XmlSchema-1.4.2.jar"/>
<classpathentry kind="var" path="M2_REPO/junit/junit/3.8.1/junit-3.8.1.jar"/>
This is a shortened version .classpath from one of my projects. It's
basically got all the information we need: (nearly) explicit locations
for the jar files, source locations, and source locations from other
sibiling projects (instantsoap-api in this case). The "M2_REPO" business
can be handled either in the environment or using another maven, or
using maven help:effective-settings.
So, my thought is this. We make JDEE read .classpath files. This would
give us maven support at a stroke; as a by-product, incidentally, JDEE
would be able to reuse eclipse projects. Assuming the classpath format
remains stable, it should also mean that someone else takes care of
updating the maven plugin as and when it's needed, with no effort to us.
To achieve this should not be too hard. I think that JDEE accesses it's
classpath (and sourcepath etc) information via a function rather than
direct through the classpath variables. So, we'd need a new variable
called "jde-use-maven" or something better. The various
classpath/sourcepath functions would then redirect their functionality
to methods which would parse the .classpath files (or rather parse once
Integration the other way (jde launching maven), I would agree is a
known entity. Launch via command line and through the internal
I need to check through the JDEE source to make sure that all of this
makes sense. Parsing .classpath should be straightforward. Finding the
relevant .classpath files is not too bad. Caching and regenerating the
variables should be okay.
Anyway, that's the idea. With any hope I will get time to do this at some