[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IDE
From: |
Lluís |
Subject: |
Re: IDE |
Date: |
Wed, 21 Oct 2015 16:52:41 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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
- Re: IDE, (continued)
- Re: IDE, Lluís, 2015/10/18
- Re: IDE, Dmitry Gutov, 2015/10/18
- Re: IDE, Lluís, 2015/10/19
- Re: IDE, Dmitry Gutov, 2015/10/19
- Re: IDE, Lluís, 2015/10/20
- Re: IDE, Dmitry Gutov, 2015/10/20
- Re: IDE, Lluís, 2015/10/21
- Re: IDE, Dmitry Gutov, 2015/10/21
- Re: IDE, Steinar Bang, 2015/10/20
- Re: IDE, Dmitry Gutov, 2015/10/20
- Re: IDE,
Lluís <=
- Re: IDE, Dmitry Gutov, 2015/10/27
- Re: IDE, Lluís, 2015/10/28
- Re: IDE, Steinar Bang, 2015/10/27
- Re: IDE, Filipp Gunbin, 2015/10/28
- Re: IDE, Steinar Bang, 2015/10/28
- Re: IDE, Filipp Gunbin, 2015/10/28
- Re: IDE, Richard Stallman, 2015/10/28
- Re: IDE, Xue Fuqiao, 2015/10/16
- Re: IDE, Eric Ludlam, 2015/10/16
- Re: IDE, David Engster, 2015/10/18