emacs-devel
[Top][All Lists]
Advanced

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

Re: IDE


From: Dmitry Gutov
Subject: Re: IDE
Date: Sun, 1 Nov 2015 19:49:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

Hi Steinar,

Sorry for the late response.

On 10/27/2015 07:28 PM, Steinar Bang wrote:
(Classpath in maven is actually independent of the directory layout of
the checked out projects, but I won't get into that now)

I meant that either we have several values: project-project, project-module1, project-module2, and each of those reports a different value of classpath, or we only have one value, project, and the accessor function project-classpath takes a additional argument, DIR, and can return different values, depending on which module, internally, DIR belongs to.

Note that classpath itself is a pretty JVM-centric attribute. It points to jars, as well as directories (the latter less often), and reading the contents of jars, if we want to, will have to be handled specially. Overall, classpath will be more relevant for features that particularly target the JVM.

More language agnostic attributes, which I'm more worried about, are sets of directories related to the project. We can search those directories, and we can list files in them (and implement, based on that, the feature "jump to file in the project", with completion).

We have currently selected two attributes like that: "project roots", directories which contain the code of the current project, and "search path" (which would probably be more appropriately named as "library roots"). Those directories contain the code that the current project refers to.

For C or C++ the closest analog would be the include path. For Ruby or Python - the directories in the current language installation where the libraries are installed.

For JVM languages, the classpath seems to be the closest thing, but it contains compiled code. The same jars can also contain sources (I think?), but searching through them, as well as listing contained files, or visiting them, is tricker. We should probably consider that for a later stage.

(That means that as long as the projects are built in dependency order,
they can in *theory* be be checked out separately and built separately,
parent, and dependencies to other projects can be resolved against the
local cache.  In practice, however, it is simpler to organize the maven
project in the recommended hierarchy and let maven handle built order
and stuff)

This is all great, but as long as Maven knows how to build the project, is there a reason for the project API to know these details?

Depends on what you mean with important project attributes...?

The full set will probably emerge incrementally, over time, as developers who want to use the project API complain that it covers too little.

If "project" is the parent pom.xml of the two modules, you can set
properties in "project" that are shared by module1 and module2.  You can
also share plugin configurations in this way.

All right. So either the project API will handle of property inheritance, or the implementations will need to do that.

The latter imposes some difficulties on how the project values are constructed, but since the multi-module project model seem to be prevalent in the Maven world only, I think I'd rather have a simpler API.

eclipse m2e will still recognize that "module1" contains the dependency
of "module2" and build them in order (they will show up as project
dependencies in the project classpath in eclipse).

So I take it the dependencies are mostly important for the "build everything" command.

The default search scope in eclipse is "workspace", which is the
projects seen in eclipse's package explorer.

That's very interesting. Maybe we'll have a notion of a workspace (the set of the currently opened projects), as well as manual "open/visit/close project" commands. Like, in the second version.



reply via email to

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