J2EE deploy ear with source code

Question

What are the (dis)advantages of deploying ear with source file? Is that the right way to deliver/deploy code ? Apart from making the ear bulky does this have any advantage?

Answer 1

Any reason to do so?

If you are using maven, you can use do it by running

mvn source:jar deploy

or automatically generate the sources jar bay adding the following configuration to your POM

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
        <executions>
          <execution>
            <id>attach-sources</id>
            <phase>verify</phase>
            <goals>
              <goal>jar-no-fork</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

Answer 2

What are the (dis)advantages of deploying ear with source file?

EAR files are primarily for deploying to a server. There is no advantage to deploying source code onto a webserver or J2EE server. You need to deploy compiled code, plus configurations, static web content, JSPs etc. But the source code is of no use to anyone deployed to the server. It just takes up disk space, and slows down deployment.

Is that the right way to deliver/deploy code ?

You are asking two questions here; deploy and deliver. For deploying webapps, etc, then WAR, EAR, etc files are the best solution. For deploying a standalone app to a user's desktop, an installer of some kind is what you need. And there are other options.

On the other hand, if you are talking about delivering a project (including source code) to a customer, then I think that the best medium is a ZIP or TAR archive. It may include the WAR/EAR file, installer or whatever, but the source code should be in a separate JAR file. You probably need to deliver manuals, javadocs, release notes and so on in the archive. Alternatively, make your source code repository accessible to your customers, or publish the source modules using Maven.

Apart from making the ear bulky does this have any advantage?

None that I can think of. WAR / EAR files are for deploying to an execution platform, not for making project releases.

Answer 3

Depends on the strategy:

If the recipient is a customer receiving a finished product, there is no need to include source code as such. If you are in a situation where your infrastructure does not easily allow you to reconstruct the source code corresponding to a given customer, you as the maintainer will appreciate having the source code available to debug sessions.

If the recipient needs to be able to do changes, they will need source code.

So, what is the scenario?

Answer 4

Hello,

It seems quite interesting to provide the source code with the ear for the specific case when you need to monitor precisely the logs of the application : If you don't provide the source code, it's impossible to locate in the stack trace the line which is concerned by an Exception.

Since production environments are often different from development ones ( even if it shouldn't, it's often the case... ) there is a potential risk of encountering an Exception which you can't reproduce in other environments, therefore, I recommend including sources into the ear for this reason.

Of course, it all depends of your needs, there is no global rule to follow, even though in a perfect world, the best option would be to have test environments which match the production one, but it's often not the case.