POLL: project structure layout: how do you configure your projects



Hello everyone,

We are thinking on a new feature "auto configure project". We would greatly appreciate if you shared with us the information about
the way your project is structured:
- how the sources and test sources are laid out
- where do you usually store libraries
- what kind of libraries do you prefer - module-level, project level or global
- where do you prefer to store project (ipr and iml) files
- any other peculiarities of project structure that you find convenient/inconvenient or some rules of thumb you follow when
structuring a new project.

Thanks in advance for any thoughts,

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

6 comments

- how the sources and test sources are laid out


See 1.png (generated by maven). Folders marked in blue are module roots.

- where do you usually store libraries


Maven repository

- what kind of libraries do you prefer -
module-level, project level or global


We generate *.ipr and *.iml files with "mvn idea:idea". The way these files are created by the plugin - there are no "Libraries" defined but rather module's "Dependencies".
In my previous project - we were defining mostly module-level libraries and never global.

- where do you prefer to store project (ipr and iml)
files


See 2.png

- any other peculiarities of project structure that
you find convenient/inconvenient or some rules of
thumb you follow when
structuring a new project.


Personally, I'd prefer following Maven's path as close as possible as it seems to be the correct one. May be IDEA may support Maven's archetypes when auto-configuring the project.



Attachment(s):
2.PNG
1.PNG
0

Our structure is pretty screwed up honestly. Our J2EE app is structured around "modules", where each module equates to an ear, which may contain ejbs, a war, a har, and sars. So it's like each module is a standalone J2EE application. EXCEPT that in fact the module have compile-time dependencies on each other, and are all deployed into Jboss in a flat classpath. Additionally, we built our own Jboss deployer that takes all the wars from all the ears, and merges them into a single war.

The motivation for this was to allow adding and removing features simply by adding/removing ear files from the deploy directory, while still having having a single webapp (we have code that dynamically builds the menus and application navigation based on which modules are present at runtime).

So our project tree is seperated into a core module, on which all the other modules depend, and a bunch of feature modules. Each module has it's own project subtree, and the structure of all the module trees are roughly the same, exception for the core module, which is organized slightly differently, just to be difficult.

We have a few other directories off the project root which hold sundry other things, like some plain java modules, our installer project, jboss, mysql, etc.

We use both project libraries (like jboss) and module libraries. The library jars are stored in the lib directories sprinkled throughout the project, and the sources and javadocs are stored in a separate directory, or outside the project altogether.
.ipr is stored in the project root, imls are stored in each module.

If we did it again, we'd probably follow the Sun BluePrints standard, for lack of anything better, and would probably investigate using Maven (we use ant, which build.xml files for each module, using macros and imports to refactor common parts of the build.)

core
core/src
core/src/java
core/src/test
core/conf
core/conf/ear
core/conf/ear/META-INF
core/conf/har
core/conf/har/META-INF
core/conf/sar
core/conf/sar/META-INF
core/lib
core/war
core/war/src
core/war/src/java
core/war/src/test
core/war/src/web
core/war/conf
core/war/conf/META-INF
core/war/conf/WEB-INF
core/war/lib
features
features/[feature]
features/[feature]/conf
features/[feature]/conf/sar
features/[feature]/conf/ejb
features/[feature]/conf/har
features/[feature]/ear
features/[feature]/ear/conf
features/[feature]/ear/conf/META-INF
features/[feature]/ear/src
features/[feature]/ear/src/java
features/[feature]/ear/src/test
features/[feature]/lib
features/[feature]/war
features/[feature]/war/conf
features/[feature]/war/conf/WEB-INF
features/[feature]/war/lib
features/[feature]/war/src
features/[feature]/war/src/java
features/[feature]/war/src/test
features/[feature]/war/src/web

0

See attached text file, but a summary would be:

- Root source directory in each module, containing sub-directories for production java sources and resources and test java sources and resources.
- Project level libraries are stored in categorised directories in a "Libraries" directory at the root level of the project
- Project level libraries preferred
- IPR and IML files stored in a sub-directory off the root



Attachment(s):
project-structure.txt
0

project
---module
-


src
-


test
-


lib
---module
-


src
-


test
-


web
-


WEB-INF
-


lib <- module libraries here


libraries could be in a lib directory under the modue or from a library dependency plugin (maven or ivy) or via global library declarations (pointed at a local CVS repository)

0

I would suggest for Maven projects to create groups automatically for nested projects (m2 integration plugin can do it now).

I know Eclipse users have to use a flat structure, but for large projects that is very helpful.

0

- how the sources and test sources are laid out


Our sources & test sources are required to reside on a slow remote drive. The layout is Maven style

- where do you usually store libraries


On a local drive.

- what kind of libraries do you prefer - module-level, project level or global


Tend to use Module primarily followed by Project.

- where do you prefer to store project (ipr and iml) files


local drive for performance. IDEA is almost unusable when they are on the Samba mount.

0

Please sign in to leave a comment.