Re: IDE

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Steinar,

On 10/20/2015 06:23 PM, Steinar Bang wrote:
> With maven, I might do something like this: (A)
>   project/
>     pom.xml
>     .git/
>     module1/
>       pom.xml
>       .git/
>     module2/
>       pom.xml
>       .git/
>
> The same projects in an eclipse workspace, might look something like
> this: (B)
>   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): (C)
>   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?