Re: IDE

[Steinar Bang]

>>>>> Dmitry Gutov <address@hidden>:

> Consider A. It could be considered one project, but then it would have
> certain attributes dependent on the current directory. Take classpath,
> for example.

(Classpath in maven is actually independent of the directory layout of
the checked out projects, but I won't get into that now)

> 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

The contents of the maven local cache can be both downloaded
dependencies and artifacts (e.g. jar files) built by other local maven
projects.

(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)

> The build-tool behavior would certainly depend on the current
> directory, but could we say that all other important project
> attributes are kind of the same for project, module1 and module2?

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

Dependencies are resolved individually for module1 and module2, but
there can be a common set of dependencies in project (provided "project"
is the parent pom.xml of "module1" and "module2").

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.

> Another option for A is to promote module1 and module2 to whole
> projects. But then, do we track project dependencies now?

The same way eclipse maven support ("m2e") does, perhaps...?
Even projects that should have been in a hierarchy are checked out
separately, and if "module1" is a dependency of "module2",

Ie. if we have only
 workspace/
   module1/
     pom.xml
     .git/
   module2/
     pom.xml
     .git/

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).

This is because each pom.xml file has a (hopefully) unique identity
consisting of groupId/artifactId/version.

> If I call a command "search for occurrences of 'xyz' in project", does
> it also search in module1 and module2? Or similarly for "list all
> files in project", does that include files in module1?

"project" is defined by the existence of a pom.xml file, for both
eclipse and maven, so "project" in eclipse would mean either "module1"
and "module2".

What it would mean if "project" was included into the workspace is a
little more unclear (there is an "enclosing projects" option in eclipse
search, but I don't know what this means").

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

> That would be useful with Helm, for "jump to a project file". Does
> "list all files in project", when called in module1, include files
> from the parent project, and from module2?

> B doesn't look too different, except we apparently don't have a
> top-level pom-file.

In this case, if the top level pom file isn't a parent of either module
it doesn't have to be there (it could be a build-only file).  If the top
level pom _is_ a dependency of the modules, it could be resolved against
the maven local cache (if not found there, the build would break).

> I don't understand C. Is module1 still inside project? Is it still a
> dependency? Do we treat it differently WRT to questions I've asked for
> the option A?

In eclipse, C would be treated identical to A (and look the same in a
workspace), but A would build from the command line, and C would not
(actually: would be cumbersome to build).

So C is just a theoretical possibility, and could be disregarded (though
I have done similar things during early m2e experimentations).