Re: [jdt-dev] Why doesn't JDT set .project "projects"?

[Aaron Digulla <digulla@xxxxxxxx>]

Am 21.11.2017 um 11:38 schrieb Mickael Istria:
> Hi all,
>
> While I'm investigating about how to maybe improve the WorkspaceJob in
> general, I've noticed that despite the Eclipse Resource model allows
> to use .project to define dependency between projects, JDT seems to
> not set the "projects" nodes in the .project.
> I understand it does it in its own .classpath, but I think it's a pity
> to not try to place such typical project dependency model on the
> lowest layer that supports it. Note that the same project could be
> listed as a project reference in .project as well as .classpath, those
> don't have to be exclusive. Having in on the .project as well would
> allow further optimizations of the Build Workspace job, independently
> of JDT, but that would still be profitable to JDT.
> I imagine their are reasons why this is not done. Does anyone know
> what these could be?

I don't know for sure but I imagine that having the dependency once is
enough. If you have two places, they can get out of sync. Which source
should then be trusted "more"? If we trust one source "more", why even
look in the other place when you can't trust it as much? If we can't
come up with a definitive rule that which source is "better", then that
would just create confusion. Every plugin would start to do it
differently. A lot of pain lies down that path.

That said, a project is not always what you expect. Take the Maven
plugin, for example. When you have a dependency in your Maven build that
happens to be in the workspace, the plugin will add the workspace
project to the build path *without* changing .project or .classpath:
Maven adds a dynamic classpath and this entry handles this case.

Why? Because the project in the workspace could be the correct name but
the wrong version. In that case, Maven would ignore the workspace
project. That's what Maven users expect to happen. Eclipse users would
be confused. Adding this special functionality in a general place would
be wrong for many reasons: A large set of the users would be always
upset, it would break stuff unnecessarily, the JDT plugins would need to
know that the Maven plugin exists and how it works and that would soon
mean that other plugins would have to add Maven special handling, too.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits." 
http://blog.pdark.de/