diff --git a/eclipse/xdocs/changes.xml b/eclipse/xdocs/changes.xml index be5b6d12..b1abe5be 100644 --- a/eclipse/xdocs/changes.xml +++ b/eclipse/xdocs/changes.xml @@ -24,6 +24,7 @@ + Updated FAQ with multiproject entries. Fixed broken test cases. Download and attach javadoc archives to .classpath when no source archive is available. Update jelly dependency to match the ones in maven 1.1 core. diff --git a/eclipse/xdocs/faq.fml b/eclipse/xdocs/faq.fml index a7bde48e..b8e877fc 100644 --- a/eclipse/xdocs/faq.fml +++ b/eclipse/xdocs/faq.fml @@ -35,4 +35,64 @@ + + + + + Eclipse doesn't support hierarchical project structure. How am i supposed to organize my multiproject ? + + +

+ If you use Eclipse, you may already have encountered the Infamous Layout Issue: + Eclipse doesn't handle (yet ?) overlapping projects. Thus if you work in a + multiproject context with a classical non flat layout, Eclipse integration becomes + quite problematic. You surely don't want to use one big Eclipse project because + you'll then lose visibility on dependencies (inter-project dependencies as well + as library dependencies) and this will quickly become quite hard to manage - and + promotes cycles. +

+

+ Best solution found so far is to refactor your project structure to rather + use a flat layout, as described below: + + 

+/project-root               |      /project-root
+  +- subproject1            |         +- project.xml
+       +- project.xml      ===>    /subproject1
+  +- subproject2            |         +- project.xml
+       +- project.xml       |      /subproject2
+  +- project.xml            |         +- project.xml
+
+
+ +

+

+ And alter your properties in a similar way than the example below: + +maven.multiproject.basedir=${basedir}/.. +maven.multiproject.includes=*/project.xml +maven.multiproject.excludes=project-root/project.xml + +

+

+ If you really can't (or don't want to) flatten your layout, the only solutions that are offered to you are a few tricks, each with its own drawback. +

    +
  • + Edit root files outside Eclipse - almost safe but implies switching between tools. + Note that initial checkout must be done through command line in this case, because + parent project shouldn't be in the workspace folder. +
    • +
  • + Create a virtual project which contains links to root files - doesn't + support refactoring well, and implies identical paths on every developer machines. +
    • +
+ Use those tricks at your own risk +

+

+ if this issue really annoys you, then please vote for https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973 +

+ + + \ No newline at end of file