[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 1 Nov 2015 19:49:39 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0
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
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
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
(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
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
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
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.