Geek Answers Handbook

How to organize a Java project using the IDE?

I am going to develop a java system consisting of three applications. These applications use the same packages. How to organize this project, for example, in IntelliJ IDEA? Should there be all sources in the project organized in one hierarchy of packages or different projects that are used in the library. Could you tell me a professional solution?

+4
source share
3 answers

The professional solution is not to rely on an IDE to build your software. You want to use the build tool to create software. There are many construction tools to choose from, for example

  • Make sure
  • ANT
  • Maven
  • Rake
  • Gradle
  • Buildr

and etc.

The tool you choose depends on how you see the firmware.

For example, tools such as Make, ANT, etc., take the “do what I say” approach to create software. This can be useful if you like to indicate exactly what you want to do and how you want.

Tools such as Maven take a “convention on configuration” approach. They say that if you follow the conventions, you won’t have to repeatedly tell the build tool how to do standard things, for example, with Maven, if you put the Java source code in the src/main/java directory, then Maven will automatically compile it for you if you put your test source code in src/test/java then Maven will do this for you and run all the tests.

Maven is not for everyone ... some people seem to want to spend more time telling the build tool what to do and less time writing their software ... that's great ... it's not me (I'm on Maven PMC ... there are no surprises to guess what my favorite build tool is)) but these people really love some of the configuration things that Maven gives ... they just need a more flexible way to override when they need to move away from the convention .. Tools like Gradle and Buildr are used by people with this mind.

Good IDEs will take the build file and derive the project structure from this build tool. IntelliJ, Eclipse, and NetBeans all understand the Maven pom.xml assembly file. This forces your IDE to create a no-op. I have not investigated how other building tools are fair in the IDE, as I personally use Maven and IntelliJ.

Choose a build tool and see how it works for you. I assume that you are using a version control system ... if you change the build tool, this should not be a big problem.

If you decide to use Maven, you will start with a module project 4 or 5 (a parent module and three child modules with a possibly shared common module)

The code will be structured like this

 +- pom.xml (the root parent pom) +- common (the common module directory) | +- pom.xml (the common module pom) | \- src | +- main | | +- java | | | \- com... (your package dirs for common classes) | | \- resources | | \- com... (your package dirs for common classpath resources) | \- test | +- java | | \- com... (your package dirs for tests of common classes) | \- resources | \- com... (your package dirs for common test classpath resources) +- app1 (the app1 module directory) | +- pom.xml (the app1 module pom) | \- src | +- main | | +- java | | | \- com... | | \- resources | | \- com... | \- test | +- java | | \- com... | \- resources | \- com... +- app2 (the app2 module directory) | +- pom.xml (the app2 module pom) | \- src | +- main | | +- java | | | \- com... | | \- resources | | \- com... | \- test | +- java | | \- com... | \- resources | \- com... \- app3 (the app3 module directory) +- pom.xml (the app3 module pom) \- src +- main | +- java | | \- com... | \- resources | \- com... \- test +- java | \- com... \- resources \- com...

The root of pom.xml will look something like this:

 <project> <modelVersion>4.0.0</modelVersion> <groupId>com.mydomain.something</groupId> <artifactId>something-parent</artifactId> <version>1.0-SNAPSHOT</version> <packaging>pom</packaging> <modules> <module>common</module> <module>app1</module> <module>app2</module> <module>app3</module> </modules> </project>

And common/pom.xml will look something like this:

 <project> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.mydomain.something</groupId> <artifactId>something-parent</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>something-common</artifactId> <dependencies> <!-- insert the 3rd party dependencies you want --> </dependencies> </project>

And then each of the poms applications will look something like this.

 <project> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.mydomain.something</groupId> <artifactId>something-parent</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>something-app1</artifactId> <dependencies> <dependency> <groupId>com.mydomain.something</groupId> <artifactId>something-common</artifactId> <version>1.0-SNAPSHOT</version> </dependency> <!-- insert any 3rd party dependencies you want for app1 only --> </dependencies> </project>

Hope this helps

+10
source

I use the following approach: root-project consists of some subprojects. Some of them depend on others (this is configured in the project properties) in order to use the project code base.

 root-project +---- project1 +---- project2 +---- project3 +---- shared-code-project
+3
source

If really professional, suppose you also need to create your own project using Maven and Maven concept layouts. Even if you never build from the command line, most of the latest good IDEs should support Maven projects. It is very likely that you may need to use Maven in the future, and this will be less of an effort for migration.

UPDATE: This was at the time of writing. Now I suggest using gradle , which is somewhat becoming more popular compared to Maven.

+2
source

More articles:


All Articles