Ik heb verschillende manieren gezien, gelezen en bedacht om Workspaces te gebruiken (per project, per applicatie (multi-asseted of niet), per programmeertaal, per doel (webontwikkeling, plug-ins,..), enzovoort ) en ik twijfel nog steeds wat de beste aanpak is.

Kan iemand hier een gedetailleerd, maar niet een pagina lang inzicht in geven?

Dit omvat een heleboel subvragen, om zo te zeggen, en ik ken niet alle specifieke subvragen die ik zou moeten stellen, omdat ik zeker weet dat ik niet alle aspecten van Eclipse (en werkruimten) ken, maar ik zal proberen een voorbeeld te geven van wat ik zoek:

• Waarvoor?
• Waarvoor verwachtte het Eclipse-ontwikkelteam dat het zou worden gebruikt?
  • Wat denken andere/de meeste mensen?
  • Wat denk je?
  • … ?
• Waarom?
• Zijn er configuratieconflicten versus voordelen voor delen?
• Enkele redenen voor bestandsruimte?
• Prestaties?
• … ?

Ik heb het over de minimale use-case voor een ontwikkelaar die verschillende talen en protocollen gebruikt, nietnoodzakelijkerwijs allemaal in één project (bijv. Php, Javascript en XML voor sommige projecten, C# voor anderen, Java en SQL voor nog anderen, enz.)

Bewerken 27-11-2012: Begrijp me niet verkeerd. Ik twijfel niet aan het gebruik van
Werkruimten, ik wil het gewoon gebruiken zoals het bedoeld is of anders als
iemand zou het beter vinden. Dus “waarvoor?” betekent: Wat is het beste gebruik? En
“waarom?” eigenlijk richt op de “waarvoor?”, met andere woorden: vertel me de redenen
voor je antwoord.

Antwoord 1, autoriteit 100%

Ik zal je mijn visie geven van iemand die zich erg ongemakkelijk voelt in de Java-wereld, waarvan ik aanneem dat dit ook jouw geval is.

Wat het is

Een werkruimte is een concept van groeperen:

1. een reeks (op de een of andere manier) gerelateerde projecten
2. een configuratie met betrekking tot al deze projecten
3. enkele instellingen voor Eclipse zelf

Dit gebeurt door een map aan te maken en daarin bestanden te plaatsen (u hoeft het niet te doen, het wordt voor u gedaan) die erin slagen om Eclipse deze informatie te vertellen. Het enige wat u hoeft te doen is expliciet de map te selecteren waarin deze bestanden worden geplaatst. En deze map hoeft niet dezelfde te zijn waar u uw broncode plaatst – bij voorkeur zal dit niet het geval zijn.

Elk item hierboven verkennen:

1. een reeks (op de een of andere manier) gerelateerde projecten

Eclipse lijkt altijd te worden geopend in combinatie met een bepaalde werkruimte, dat wil zeggen, als u zich in een werkruimte Abevindt en besluit over te schakelen naar werkruimte B(Bestand > Switch Workspace), zal Eclipse zichzelf sluiten en opnieuw openen. Alle projecten die waren gekoppeld aan werkruimte A(en verschenen in de Projectverkenner) zullen niet meer verschijnen en projecten die zijn gekoppeld aan werkruimte Bzullen nu verschijnen. Het lijkt er dus op dat een project, om open te staan ​​in Eclipse, MOETgekoppeld zijn aan een werkruimte.

Merk op dat dit niet betekent dat de broncode van het project zich in de werkruimte moet bevinden. De werkruimte zal op de een of andere manier een relatie hebben met het fysieke pad van je projecten op je schijf (weet iemand hoe? Ik heb in de werkruimte gekeken op zoek naar een bestand dat naar de projectpaden verwijst, maar zonder succes).

Op deze manier kan een project zich in meer dan één werkruimte tegelijk bevinden. Het lijkt dus goed om je werkruimte en je broncode gescheiden te houden.

2. een configuratie met betrekking tot al deze projecten

Ik heb gehoord dat iets, zoals de Java-compilerversie (zoals 1.7, bijv. – ik weet niet of ‘versie’ hier het woord is), een configuratie op werkruimteniveau is. Als u meerdere projecten in uw werkruimte heeft en deze in Eclipse compileert, worden ze allemaal gecompileerd met dezelfde Java-compiler.

3. enkele instellingen voor Eclipse zelf

Sommige dingen, zoals uw toetsbindingen, worden ook op werkruimteniveau opgeslagen. Dus als je definieert dat ctrl+tab op een slimme manier van tabblad wisselt (niet stapelt), is dit alleen gebonden aan je huidige werkruimte. Als je dezelfde toetsbinding in een andere werkruimte wilt gebruiken (en ik denk dat je dat ook wilt!), dan lijkt het erop dat je ze tussen werkruimten moet exporteren/importeren (als dat waar is, is deze IDE gebouwd op een heel vreemd gebouw). Hier is een link hierover.

Het lijkt er ook op dat werkruimten niet noodzakelijk compatibel zijn tussen verschillende Eclipse-versies. Dit artikelsuggereert dat u uw werkruimten een naam geeft met de naam van de Eclipse-versie.

En, nog belangrijker, als je eenmaal een map hebt gekozen als je werkruimte, raak dan geen enkel bestand daarin aan, anders krijg je problemen.

Hoe ik denk dat het een goede manier is om het te gebruiken

(eigenlijk, terwijl ik dit schrijf, weet ik niet hoe ik dit op een goede manier moet gebruiken, daarom was ik op zoek naar een antwoord – dat ik hier probeer te verzamelen)

1. Maak een map voor uw projecten:
   /projects

2. Maak een map voor elk project en groepeer de subprojecten van de projecten erin:
   /projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1

3. Maak een aparte map voor uw werkruimten:
   /eclipse-workspaces

4. Maak werkruimten voor uw projecten:
   /eclipse-workspaces/proj1
/eclipse-workspaces/proj2

Antwoord 2, autoriteit 81%

Het hele punt van een werkruimte is om een ​​reeks gerelateerde projecten te groeperen die gewoonlijk een toepassing vormen. Het werkruimteframework komt neer op de plug-in eclipse.core.resourcesen is natuurlijk logisch.

Projecten hebben een karakter, bouwers zijn gekoppeld aan specifieke projecten en als je resources in een project verandert, kun je in realtime compileren of andere problemen zien in projecten die zich in dezelfde werkruimte bevinden. Dus de strategie die ik voorstel is om verschillende werkruimten te hebben voor verschillende projecten waaraan je werkt, maar zonder een werkruimte in eclipse zou er geen concept zijn van een verzameling projecten en configuraties en het is tenslotte een IDE-tool.

Als dat niet logisch is, vraag dan hoe Net Beans of Visual Studio dit aanpakken? Het is hetzelfde thema. Maven is een goed voorbeeld: door een groep gerelateerde maven-projecten in een werkruimte te bekijken, kun je fouten in realtime ontwikkelen en zien. Als het geen werkruimte is, wat zou je dan nog meer voorstellen? Een RCP-toepassing kan een ander beest zijn, afhankelijk van waarvoor het wordt gebruikt, maar in de echte IDE-zin weet ik niet wat een betere oplossing zou zijn dan een werkruimte of context van projecten. Alleen mijn gedachten. – Duncan

Antwoord 3, autoriteit 6%

In principe is het bereik van de werkruimte(n) verdeeld in twee punten.

Eerste punt (en primair) is de zonsverduistering zelf en is gerelateerd aan de instellingen en metadataconfiguraties (plugin ctr). Elke keer dat u een project maakt, verzamelt eclipse alle configuraties en slaat ze op die werkruimte op en als op de een of andere manier in dezelfde werkruimte een conflicterend project aanwezig is, zou u wat functionaliteit of zelfs stabiliteit van eclipse zelf kunnen verliezen.

En ten tweede (secundair) het punt van de ontwikkelingsstrategie die men kan aannemen.
Zodra de primaire reikwijdte is bereikt (en onder de knie) en er behoefte is aan verdere aanpassingen met betrekking tot projectrelaties (zoals bibliotheken, perspectieven ctr), kan het starten van afzonderlijke werkruimte(n) geschikt zijn op basis van ontwikkelingsgewoonten of mogelijke taal/kaders “gedrag”.
DLTK is bijvoorbeeld een beest dat in een aparte kooi zou moeten zitten.
Veel klachten op forums omdat het niet meer werkte (goed of helemaal niet) en de voorgestelde oplossing was om de instellingen van de equivalente plug-in uit de huidige werkruimte te verwijderen.

Persoonlijk merkte ik dat ik meer leunde op taalonderscheid als het gaat om afzonderlijke werkruimten, wat relevant is voor bekende problemen die gepaard gaan met de huidige staat van de plug-ins die worden gebruikt. Bij voorkeur houd ik ze in het minimum aantal omdat dit leidt tot minder frustratie wanneer de projecten zijn geworden… genoeg en versiebeheer is niet de enige versie die u uw projecten bewaart.
Ten slotte is laadsnelheid en -prestaties een probleem dat kan optreden als er veel (onnodige) plug-ins worden geladen vanwege presentaties van irrelevante projecten.
Bottom-line; er is niet één oplossing voor iedereen, geen hoofdblauwdruk die het probleem oplost. Het is iets dat groeit met ervaring,
Minder is echter meer!

Antwoord 4, autoriteit 2%

Hoewel ik Eclipse al jaren gebruik, is dit “antwoord” slechts een vermoeden (wat ik vanavond ga proberen). Als het niet meer bestaat, heb ik het natuurlijk mis.

Oracle vertrouwt op CMake om een ​​Visual Studio “oplossing” te genereren voor hun MySQL Connector C-broncode. Binnen de Oplossing bevinden zich “Projecten” die afzonderlijk of gezamenlijk (door de Oplossing) kunnen worden samengesteld. Elk project heeft zijn eigen makefile, waarbij het deel van de oplossing wordt gecompileerd met instellingen die anders zijn dan de andere projecten.

Evenzo hoop ik dat een Eclipse-werkruimte mijn gerelateerde makefile-projecten (Eclipse) kan bevatten, met een hoofdproject waarvan de afhankelijkheden de verschillende unique-makefile-projecten compileren als voorafgaande vereisten voor het bouwen van de “oplossing”. (Mijn mappenstructuur zou zijn zoals @Rafael beschrijft).

Dus ik hoop dat een goede manier om Workspaces te gebruiken is om het vermogen van Visual Studio om ongelijkeprojecten te combineren tot een oplossing te emuleren.

Antwoord 5

Het is slechts een functie voor het structureren van projecten.
Het is duidelijk dat Eclipse-ontwerpers probeerden om globale instellingen voor Eclipse te vermijden en besloten ze in de werkruimte te plaatsen.
Elke Eclipse-app is afhankelijk van de instellingen van elke werkruimte.
Is het een goede beslissing? Ik denk dat het niet zo is.
Het ontbreekt aan flexibiliteit. Het was naïef om te verwachten dat globale instellingen vermeden kunnen worden.
Het staat je niet toe om afzonderlijke projecten te hebben (het kan een verrassing zijn voor Eclipse-ontwerpers, maar het gebeurt vrij vaak).
Maar het werkt nog steeds.
Veel mensen gebruiken het. Soms lijden ze, maar vaker is alles in orde.