Community
Participate
Working Groups
I was always confused why I have to modify build paths in two views: 1. Source dirs on "build path" tab 2. Referenced projects and libraries on "include path" I think we could try merge it into one view (include pathes for *.ini, build path for indexes, referenced projects, libraries, ordering).
There is also Library Folders, which should be marked as those (currently listed as source folders under build path)
I plan to take care of it during 3.6 release cycle. Any objections? Plan: 1. Merge build path and include path page 2. Drop build path page during project creation Any suggestions? (In reply to gossi from comment #1) > There is also Library Folders, which should be marked as those (currently > listed as source folders under build path) If will be possible using current DLTK API I'll do this, if not I'll prepare feature request on DLTK (probably extension for DLTK build path attribute which will be also important to introduce compliant with PSR-0/PSR-4 class loaders)
I am +1 for every change that will reduce configuration complexity :)
Created attachment 255128 [details] Concept Art for configuration Pages
I created a concept a while ago I just found again, see the attached screenshot. The idea is to combine current "Build Path" and "Include Path" project-configuration pages into one (I named it "Path" for now - in lack of a better name). I never used Libraries, that's why I left it out - I don't even understand its existence but I guess there are people out there who need it. The "Order" tab ... is there anything relevant happening there? If not it can go away. My understanding for "Library" would be to have everything in there, that shows up in the project explorer with the library Icon (at the moment that is "PHP Include Path" (empty for me) and "PHP Language Library"). Also there is [1] to contribute to the project explorer (which I still would really like for the composer plugin - yet Robert and me didn't find a good idea yet to implement it). [1] https://wiki.eclipse.org/Extending_PDT#Contributing_a_PHPTreeContentProvider
DLTK is in general fork%mod JDK. So, libraries and references projects extends build path (indexing, type inference). PDT use also libraries and referenced project for include path generation [1], it's important for cli scripts with PEAR-like class loaders. For DLTK we need: * Build path (JDT classpath) * Libraries (for example old PHPUnit) * Projects (DLTK will use build pathes from referenced projects) For php.ini#include-path * Include path * Libraries * Projects (PDT will use include pathes from referenced projects) * Ordering [1] - http://php.net/manual/en/ini.core.php#ini.include-path
Thanks Dawid, good to know. On the other hand, I don't know much about the internals, so that's why I can have a different view on this. For me this looks like there is one thing like "references" that includes: - Build Path - Include Path - Libraries - Projects - Order Am I correct? One more question (you get me curious): How is Libraries and Order used by PDT? for what php.ini things?
in same way like include path order. Library will be transform to single path, project into set of patches (with own order): include_path=second_project_path/dir;my_project/path;my_library_path; If you change order, result might be: include_path=my_project/path;my_library_path;second_project_path/dir; Nothing special :P Usually useless on modern php applications with composer.
I'm still not convinced with the word "Build path". I refer to build as when I build my code, like compiling it, which doesn't happen in php. I rather see it as "class path" or "autoload path". Also both sound creepy and weird, still better than "build path" to me. On the other hand the autoload path for pdt and for your actual code can be different (e.g. think about phpunit plugged in as library for PDT) but not for your actual code (forgot it in composer.json or if you don't use composer, just forgot to include the dependency). Also there are going to be two concepts in one preference page. This is very tricky to reflect from a UI point of view. I will come up with some sketches and thanks to your explanations I know which paths belong to which concept.
How about naming it "Validation Path" since 4.1? And off course describe in help as validation and index path.
'Validation Path' will be for sure a little bit more descriptive than "Build Path". At the moment I just started to think if we really need to have this preference page visible to the user. If users wants to avoid validation is easier to use Library folders. But I'm not 100% sure about hiding it :) I think we should also remove "Build Path" menu from PHP Explorer popup menu, but I will create separate bug for that.
