emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDE


From: Filipp Gunbin
Subject: Re: IDE
Date: Wed, 28 Oct 2015 15:34:06 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin)

On 27/10/2015 18:28 +0100, Steinar Bang wrote:

>>>>>> Dmitry Gutov <address@hidden>:
>
>> Could we consider it to be constant value across the whole project, or
>> would we have, for certain operations (like "find the class named
>> foo.bar.Bar"), different values of classpath in module1 and module2?
>
> The classpath will be per project/module, and for each project it can
> differ for compilation, runtime, test execution.
>
> A *brief* explanation of how the class path is built (for the initiated:
> by "identity" below, I mean the "maven coordinates" consisting of
> groupId/artifactId/version):
>  - Each pom.xml file, have:
>   - an identity
>   - the identity of a parent pom.xml file
>   - a list of dependencies (including the scope of the dependency,
>     eg. "test")
>  - The combined dependency list of a pom.xml is:
>   - The dependencies in the dependency list
>   - The transitive dependencies of the dependencies in the dependency
>     list
>   - The combined dependencies of the parent pom.xml (which includes that
>     pom.xml file's dependencies and transitive dependencies and those of
>     its parent in turn)
>  - Maven will download all dependencies and install them in the maven
>    local cache (by default the maven local cache resides in
>    $HOME/.m2/repository/ )
>  - Maven will create the appropriate classpath for compile, test, run,
>    etc. consisting of jar files in the maven local cache
>

I've been following this long thread with interest and there's one
thing that keeps bothering me - should we duplicate the logic of build
tool in Emacs IDE-like features?

In my `javaimp' package (available in GNU Elpa) Emacs calls Maven to get
classpath, then scans all jars in it (it takes them from local Maven
cache and reads what classes are inside).  This is done only once given
that pom.xml doesn't change (and if it changes this is repeated).

This requires some time to wait for Maven to finish and output the
classpath.  But jar scanning is inevitable, I guess, and takes more time
(both are cached then).

I'm hoping to implement something like this for Gradle, but I didn't get
to it yet and I don't know whether it can output classpath like Maven
can.

Btw, there are subtleties between different Maven versions in dealing
with dependency merging when what is called an `effective pom' is built
(that is, when pom hierarchy is merged to produce effective settings for
the current module).  I remember that initially Maven 3 was outputting a
slightly wrong tree with `mvn dependency:tree' rather than it was
actually using during build.

This looks a lot like the GCC AST problem.

Filipp



reply via email to

[Prev in Thread] Current Thread [Next in Thread]