Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

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.