Я бачив, читав і продумав різні способи використання робочих просторів (за проектом, за програмою (багатокомпонентна чи ні), за мовою програми, за ціллю (веб-розробка, плагіни, ..) тощо) і я я все ще сумніваюся, який найкращий підхід.

Чи можна в будь-якому випадку дати детальну, але не довгу сторінку про це?

Це пов'язано з великою кількістю під-питань, так би мовити, і я не знаю всіх конкретних під-питань, які мені слід задати, тому що я не впевнений, що не знаю всіх аспектів затемнення (і робочих просторів), але Я спробую навести приклад того, що я шукаю:

• Для чого?
  
  • Що означало розвиток затемнення?
  • Що думають інші / більшість людей?
  • Що ти думаєш?
  • ...?
• Чому?
  
  • Чи існують конфлікти конфігурації та обмінів
  • Будь-які причини файлового простору?
  • Продуктивність?
  • ...?

О, і я кажу про мінімальний варіант використання для розробника, який використовує різні мови та протоколи, і НЕ обов'язково всі вони в одному проекті (наприклад, php, javascript та xml для деяких проектів, C # для інших, Java та SQL для нерухомих інші тощо)

Редагувати 2012-11-27: Не зрозумійте мене неправильно. Я не сумніваюся у використанні робочих просторів, я просто хочу використовувати його таким, яким він мав бути, інакше, якщо хтось вважатиме це краще. Так "для чого?" означає: Що найкраще використовувати? І чому?" насправді націлено на те, на що «чому?», іншими словами: скажіть мені причини вашої відповіді.

Я надаю вам своє бачення того, хто відчуває себе дуже незручно у світі Java, і я вважаю, що це також ваш випадок.

Що це

Робоча область - це концепція групування:

1. набір (якось) пов'язаних проектів
2. деяка конфігурація, що стосується всіх цих проектів
3. деякі параметри для самого Eclipse

Це відбувається, створивши каталог і помістивши всередину нього (не потрібно цього робити, це робиться для вас) файли, які вдається повідомити Eclipse ці дані. Все, що вам потрібно зробити явно, - це вибрати папку, в якій будуть розміщені ці файли. І ця папка не повинна бути тією самою, куди ви ставите свій вихідний код - переважно, вона не буде.

Вивчення кожного елемента вище:

1. набір (якось) пов'язаних проектів

Здається, Eclipse завжди відкривається в поєднанні з певним робочим простором, тобто якщо ви перебуваєте в робочій області A і вирішите перейти на робочу область B (Файл> Переключити робочі простори ), Eclipse закриється і знову відкриється. Усі проекти, пов’язані з робочою областю A (і з'являлися в Провіднику проектів), більше не з’являться, і проекти, пов’язані з робочою областю B , тепер з’являться. Отже, здається, що проект, щоб бути відкритим у Eclipse, ОБОВ'ЯЗКОВО бути пов'язаний з робочим простором.

Зауважте, що це не означає, що вихідний код проекту повинен знаходитися всередині робочої області. Робоча область якось матиме відношення до фізичного шляху ваших проектів на вашому диску (хто-небудь знає, як? Я заглянув всередину робочої області, шукаючи якийсь файл, що вказує на шляхи проектів, без успіху).

Таким чином, проект може перебувати всередині більше ніж 1 робочої області одночасно. Тож здається добре тримати робочу область та вихідний код відокремленими.

2. деяка конфігурація, що стосується всіх цих проектів

Я чув, що щось на зразок версії компілятора Java (наприклад, 1.7, наприклад, - я не знаю, чи є "версія" тут словом) - це конфігурація на рівні робочої області. Якщо у вашій робочій області є кілька проектів, і компілюйте їх всередині Eclipse, всі вони будуть зібрані з одним і тим же компілятором Java.

3. деякі параметри для самого Eclipse

Деякі речі, такі як ваші ключові прив’язки, також зберігаються на рівні робочої області. Отже, якщо ви визначите, що вкладка ctrl + буде перемикати вкладки розумним способом (не укладаючи їх), це буде прив'язане лише до вашої поточної робочої області. Якщо ви хочете використовувати ту саму прив'язку ключів в іншій робочій області (і я думаю, що ви хочете!), Здається, що вам доведеться експортувати / імпортувати їх між робочими просторами (якщо це правда, цей IDE був побудований на деяких дійсно дивних приміщеннях). Ось посилання на це .

Також видається, що робочі простори не обов'язково сумісні між різними версіями Eclipse. У цій статті пропонується назвати робочі простори, що містять назву версії Eclipse.

І, що ще важливіше, вибираючи папку для своєї робочої області, не торкайтеся жодного файлу всередині себе, або у вас виникають проблеми.

Як я вважаю, це хороший спосіб використовувати його

(насправді, коли я це пишу, я не знаю, як це добре використовувати, тому я шукав відповідь - що я намагаюся зібрати тут)

1. Створіть папку для своїх проектів:
   /projects

2. Створіть папку для кожного проекту та згрупуйте підпроекти проектів всередині нього:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Створіть окрему папку для своїх робочих просторів:
   /eclipse-workspaces

4. Створіть робочі місця для своїх проектів:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

Вся суть робочої області полягає в групуванні набору пов'язаних проектів разом, які зазвичай складають додаток. Рамка робочої області зводиться до eclipse.core.resourcesплагіна, і це, природно, дизайн має сенс.

Проекти мають характер, будівельники приєднуються до конкретних проектів, і коли ви змінюєте ресурси в одному проекті, ви можете бачити в реальному часі компіляцію або інші проблеми в проектах, що знаходяться в одному робочому просторі. Тому стратегія, яку я пропоную, - це мати різні робочі простори для різних проектів, над якими ви працюєте, але без робочої області в затемненні не було б концепції колекції проектів та конфігурацій, і врешті-решт це інструмент IDE.

Якщо це не має сенсу запитати, як Net Beans або Visual Studio це вирішують? Це та сама тема. Maven - хороший приклад, перевірка групи пов'язаних проектів Maven у робочій області дозволяє розробляти та бачити помилки в режимі реального часу. Якщо б не робоча область, що б ви ще запропонували? Додаток RCP може бути різним звіром залежно від того, для чого він використовується, але в справжньому сенсі IDE я не знаю, що було б кращим рішенням, ніж робоча область чи контекст проектів. Просто мої думки. - Дункан

В основному сфера робочої області (-ів) ділиться на два моменти.

Перша точка (і первинна) - це затемнення, яке само собою пов'язане з налаштуваннями та конфігураціями метаданих (плагін ctr). Кожен раз, коли ви створюєте проект, eclipse збирає всі конфігурації та зберігає їх у цій робочій області, і якщо якимось чином у тому ж робочому просторі присутній конфліктний проект, ви можете втратити певну функціональність або навіть стабільність затемнення.

І другий (вторинний) пункт стратегії розвитку, який можна прийняти. Після того, як основний обсяг буде досягнуто (і засвоєно) та виникне потреба в подальших корекціях стосовно проектних відносин (як бібліотеки, перспективи ctr), тоді ініціювати окремі робочі області може бути доцільним на основі звичок розвитку або можливих мовних / рамкових "поведінок". DLTK для прикладів - звір, який повинен міститися в окремій клітці. Багато скарг на форумах на те, що він перестав працювати (належним чином або взагалі немає), і запропонованим рішенням було очищення налаштувань еквівалентного плагіна з поточної робочої області.

Особисто я виявив, що більше схильний до розрізнення мови, коли мова йде про окремі робочі простори, що стосується відомих проблем, що стосуються поточного стану використовуваних плагінів. Переважно я тримаю їх у мінімальній кількості, оскільки це призводить до менших розладів, коли проекти стають ... великою мірою, а контроль версій - не єдина версія, де ви зберігаєте свої проекти. Нарешті, швидкість завантаження та продуктивність - це проблема, яка може виникнути, якщо буде завантажено багато (непотрібних) плагінів через подання нерелевантних проектів. Нижня лінія; не існує жодного рішення для кожного, немає головного синього друку, який би вирішив проблему. Це щось, що росте з досвідом, менше менше, хоча!

Хоча я користувався Eclipse роками, ця "відповідь" - це лише здогадка (яку я спробую сьогодні спробувати). Якщо вона втрачає голос поза існуванням, то явно я помиляюся.

Oracle покладається на CMake для створення Visual Studio "Рішення" для їх вихідного коду MySQL Connector C. У межах Рішення знаходяться «Проекти», які можна складати окремо або колективно (за рішенням). Кожен проект має свій власний makefile, компілюючи свою частину рішення з налаштуваннями, які відрізняються від інших проектів.

Аналогічно, я сподіваюся, що робоча область Eclipse може вмістити мої пов'язані проекти Makefile (Eclipse) з головним проектом, залежності якого складають різні унікальні проекти make-make як передумови для створення його "Рішення". (Структура моєї папки буде такою, як описано @Rafael).

Тож я сподіваюся, що хорошим способом використання Workspaces є наслідування здатності Visual Studio поєднувати різні проекти в рішення.