I have this project made of multiple jars and war to make an ear. I build everything in snapshot and it works great. Then I made a release for every single project and saw that the jars and the war were slightly different in size than the snapshot ones.
Comparing file to file I realized that the .class files were all there, but slightly larger or bigger, nothing more than 40 bytes generally.
I force compilation to use java 1.5 using this tag in Maven:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
I use this tag for the release plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<releaseProfiles>release</releaseProfiles>
<goals>deploy</goals>
</configuration>
</plugin>
Could it be that the release plugin is compiling in 1.6 or other, explaining the classes size difference ? If so can I make the release plugin compile in 1.5 ?
Thanks for your input.
Just a note, if a wrong version is picked up, you will get an error something like
During maven release, maven release plugin (sets/defaults to) the compiler version 1.5. To ensure it picks up the correct version specify the properties.
You can verify the version a class is compiled for by using the javap utility included with the JDK. From the command line:
In the output of javap look for "minor version" and "major version" about ten lines down.
Then use this table:
The .class size difference may be due to compile version but also may be due to other compile options like compiling with debug information (line numbers in stacktraces).
--- SPOILER ALERT ---
The short answer is that in order to compile source to an older version, you need to supply both the
-source
option as well as the-bootclasspath
. See this article. And if you want to compile source to a newer version, you need to set<source>
,<target>
,<compilerVersion>
,<fork>
, and<executable>
on the compiler plugin, and set<jvm>
on the surefire plugin...And now for the story...
I ran into the same problem. It turns out that compiling a previous version may not be as easy as setting
<source>
and<target>
. My specific case is that I have a Java 1.7 JDK and I my class has an incompatibility with 1.7 (they added a new method to an interface that I am implementing). When I tried to compile it, the compiler gave me an error message stating that I had not implemented the interface method. Anyway, I tried setting the compiler plugin:but when I ran the build, I got the same error. So I ran maven in debug and saw this:
Note that the ... is put in place of actual arguments for the sake of brevity
in the output. The message starting with
-d
is the actual full compile argument list. So, if you remove the-nowarn
flag and paste the rest afterjavac
on the command line you can see the actual output from the compiler:This prints out the handy-dandy warning bootstrap class path not set in conjunction with -source 1.6. A little googling on that turns up this article which states:
Now referencing the maven documentation for the compiler plugin gives:
Which you can then combine with your earlier configuration to get:
And now you just need to make the
${java.home}
variable available to your mvn (through -D system properties, or through plain old environment variables, or you could get really fancy and stuff it in a java 6 profile in your user settings).Now just run your build and go grab a cold beer while it chugs away...
---- EDIT ----
One last thing... Including rt.jar in your bootclasspath is always required, however, I discovered that more may be needed on a case by case basis. I had to include jce.jar (in the same directory as rt.jar) because my app was doing crypto work.
---- EDIT 2 ----
For grins, I tried it the other direction. Instead of running maven with java 7 compiling for java 6, I ran maven with java 6 compiling for java 7. The first attempt is pretty straight forward:
Basically, I set my
<source>
and<target>
to 1.7, but that clearly would not be enough because 6 cant compile 7 code. So back to the compiler plugin, there is actually an example page describing what needs to be done. Namely, you need to<fork>
off a new process using the java 7<executable>
. So now I think I'm all set. Time to fire up the build...What the heck is UnsupportedClassVersionError? A closer look tells us its the maven-surefire-plugin that is failing. So I try just
mvn compile
and sure enough I get a success as the surefire plugin never fired up. So I runmvn -X package
and notice this gem:Ok, so its running java 6. Why? The documentation for surefire gives this:
Since we ran mvn with a java 6 VM its forking a java 6 VM for its unit tests. So setting this option appropriately:
And firing up the build...
Can't be IMO. The Maven Release Plugin doesn't compile anything, it just triggers a phase that will itself trigger the
compile
phase and the Maven Compiler Plugin. In other words, the Maven Compiler Plugin and its settings will be used.You can use the following commands to control what is happening exactly:
to check profiles. And
to check the effective pom.