Re: IDE

[Lluís]

Dmitry Gutov writes:

> Hi Steinar,
> On 10/20/2015 06:23 PM, Steinar Bang wrote:
>> With maven, I might do something like this:
>>  project/
>>    pom.xml
>>    .git/
>>    module1/
>>      pom.xml
>>      .git/
>>    module2/
>>      pom.xml
>>      .git/
>>
>> The same projects in an eclipse workspace, might look something like
>> this:
>>  workspace/
>>    module1/
>>      pom.xml
>>      .git/
>>    module2/
>>      pom.xml
>>      .git/
>>
>> Or perhaps something like this (if the parent also has common settings I
>> would like easily editable).
>>  workspace/
>>    project/
>>      pom.xml
>>      .git/
>>    module1/
>>      pom.xml
>>      .git/
>>    module2/
>>      pom.xml
>>      .git/
>>
>> If the project was to be only edited with emacs, I would go for the top
>> layout, however if I was to edit the same projects in both emacs and
>> eclipse, it should handle the latter two layouts as well (though the
>> bottom one doesn't work too well with command line maven).

> That doesn't help, by itself. Surely we want to support all of these directory
> structures. The question is what each of them would translate to in the 
> project
> API.

> Consider A. It could be considered one project, but then it would have certain
> attributes dependent on the current directory. Take classpath, for
> example. 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 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?

> Another option for A is to promote module1 and module2 to whole projects. But
> then, do we track project dependencies now? 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?
> 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.

> 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?

Ok, so what if we let project-types define project nesting?

Let's suppose example A has a "flat" configuration, while example B has a
nested one:

* service-search-paths-X-Y
  A "search path" service where X tells us whether paths are searched
  recursively, and where searches start at path Y.

* project-type-A:
  * children: nil
  * service-types
    * service-type-search-paths: service-search-paths-t-project/

* project-type-B:
  * children: project-type-B-m1 project-type-B-m2
  * service-types
    * service-type-search-paths: service-search-paths-nil-project/

* project-type-B-m1:
  * children: nil
  * service-types
    * service-type-search-paths: service-search-paths-nil-project/module1/

* project-type-B-m2:
  * children: nil
  * service-types
    * service-type-search-paths: service-search-paths-nil-project/module2/

Note that the same can be applied to things like whether cross-module searches
must work. For example, this would activate them for path searches:

    * service-type-search-paths: service-search-paths-nil-project/module1/ 
service-search-paths-nil-project/module2/

In most cases, it probably makes more sense to construct this nesting
programmatically by adding some logic during project auto-detection (e.g., read
some configuration file that is part of the project).


Thanks,
  Lluis

-- 
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth