views:

243

answers:

5

I've noticed that a lot of projects have the following structure:

  • Project-A
    • bin
    • lib
    • src
      • main
        • java
          • RootLevelPackageClass.java

I currently use the following convention (as my projects are 100% java):

  • Project-A
    • bin
    • lib
    • src
      • RootLevelPackageClass.java

I'm not currently using Maven but am wondering if this is a Maven convention or not or if there is another reason. Can someone explain why the first version is so popular these days and if I should adopt this new convention or not?

Chris

+8  A: 

Yes, this is the Maven convention.

Even if your project is 100% Java (as is typical with Maven btw), you often have resource files (which go to src/main/resources according to the Maven convention), or web app stuff, or ... all these fit into the Maven system easily.

If you are happy with your current build system (whatever it is), there is no reason to switch to Maven. Otherwise, or if starting a new project, you could evaluate your options, including Maven.

Péter Török
+7  A: 

Main benefit is in having the test directory as subdirectory of src with the same directory structure as the one in main:

  • Project-A
    • bin
    • lib
    • src
      • main
        • java
          • RootLevelPackageClass.java
        • resources
      • test
        • java
          • TestRootLevelPackageClass.java
        • resource

All package private methods of RootLevelPackageClass will be visible, i.e. testable from TestRootLevelPackageClass. Since the testing code is also source its place should be under src directory.

Boris Pavlović
Usually the resources directory is also split into `src/main/resources` and `src/test/resources`.
Joachim Sauer
@Joachim Sauer thanks. fixed.
Boris Pavlović
+2  A: 

Its a Maven convention.

Maven is based on Convention over configuration paradigm. Thats means: if you dont follow this convention you must configure where the sources are located. Thats the main benefit IMHO.

SourceRebels
They *say* Maven is based on convention over configuration, but why are the `pom.xml`:s a billion lines long and what is all this complex XML in general...? :)
Esko
You are right. But for sure if you dont use /src/main/java as your source folder, your pom.xml will have a billion and one lines :-)
SourceRebels
+2  A: 

Others have already told you it's a Maven convention, I'm going to answer your question instead:

Absolutely none. Certainly it's beneficial to separate pieces of code to separate root folders, but usually you could achieve the same with

  • [root]
    • src
      • com.org.net
        • Your.class
    • test
      • com.org.net
        • YourTest.class
    • lib
    • bin
    • resources

instead. In fact here's a big thing Maven does that's actually hugely wrong: It wants to add binary content to source code repository which is meant for textual content only! All binary content should be managed outside the source code repository, that includes images in web applications and whatnot.

But OK, lets assume that you've decided to live in the somewhat smelly Maven ecosystem; then you should of course follow the Maven conventions as strictly as possible.

Esko
Hi,Thanks for your comments. The structure you show in your answer is similar to the structure I use in my existing projects and the normal convention up until Maven it seems.I'd be interested in your further views of Maven and what you would recommend for multi-project builds as an alternative and why (gradle/ant/ivy ...)?
Chris
@Chris: Sure, I'll edit in more stuff later today.
Esko
Source code repos, despite the name, are meant for binary as well as textual content. Maybe your projects have no dependencies on binary assets, but all my recent (web) projects have a visual (or aural), and they won't function without them. They are integral to the project. It's very beneficial to have them versioned along with the "code". Not including them would just make everyone's job harder.
ndp
@ndp: Most versioning systems are made for textual content and very few support *proper* versioning of binary content. I do acknowledge they're integral to the project but that doesn't mean they necessarily belong to the same place as the actual source code.
Esko
@Esko... What do you mean "proper" versioning of binary content? Every system I've used in the last 20 years has allowed me to check in binary files. Sure, CVS was a little finicky, but these days git is perfect-- in fact, git treats all content as binary blobs (at least at the storage layer). What am I/we missing?
ndp
A: 

Yes, this is a maven convention, but even if you're not using maven, there are benefits to using it:

  1. people new to the project will have an easier time coming up to speed, since it's a "standard"
  2. this convention is flexible and has a place for non-Java code and other things you don't have at this point. This is one reason it's popular and you may find it evolves better than a scheme you come up with on your own
  3. if you want to move to maven at some point it will be easy

Although I wouldn't argue you should switch just to switch, when starting a new project there's really no reason to not use it-- unless you disagree philosophically with how it breaks the code up.

ndp