You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by virg g <06...@gmail.com> on 2013/06/25 07:59:33 UTC
Multiple JDK versions
Hi, I need build my project with multiple jdk versions 1.5 and 1.6. I am
using maven compiler plugin to set the compiler based on JAVA_HOME set. Is
it mandatory to set target either 1.5 or 1.6 based on the jdk version i
want to build. Why because if i set compiler to jdk 1.6, in the debug log
it shows that target is 1.5 but it should be 1.6 right? target should set
automatically based on JAVA_HOME right unless i specically mention the
target if i want to change? Any pointers for my problem?
[DEBUG] (f) executable = D:/jdk1.6.0_14/bin/javac
[DEBUG] (f) source = 1.5
[DEBUG] (f) staleMillis = 0
[DEBUG] (f) target = 1.5
Thanks
virg
Re: Multiple JDK versions
Posted by virg g <06...@gmail.com>.
Thank your all for all your suggestions. I am really grateful to you all.
Thanks
Virg
On Thu, Jun 27, 2013 at 6:51 AM, Mark Derricutt <ma...@talios.com> wrote:
> Ron Wheeler wrote:
>
>> So always compile with 1.5 and make a package for 1.5 and copy it to
>> files with 1.6 and 1.7 names.
>> If the managers don't know how Java JVM works they will be impressed by
>> how fast you can deliver new packages in so many operating systems and
>> really impressed at the speed with which you can bring out 1.8 support.
>>
> Well yes generally - however this week I had code that when compiled ON
> JDK7 but targetting JDK6 worked fine, but targetting JDK7 failed to even
> compile.
>
> This was the in part my discovery of this new javac error message:
>
> [ERROR] .../TransactionFilter.java:[**112,11] exception javax.validation.*
> *ConstraintViolationException has already been caught
>
> turns out, javac now enforces/tracks the loss of visibility in catch
> blocks, in this case, above the ConstraintViolationException catch block
> was one for ValidationException , this is ConstraintViolationExceptions
> super class.
>
> However, I was pointing out the just "compiling to JDK5" doesn't really
> help much, but you are correct and I got my terms backwards - I refer to
> this quote that I posted on my own darn blog ;p
>
> http://www.theoryinpractice.**net/post/18036749530/java-has-**
> never-been-future-compatible-**and-will<http://www.theoryinpractice.net/post/18036749530/java-has-never-been-future-compatible-and-will>
>
> Java has never been future compatible, and will never be. I just want to
> make sure that is clear, because if you've been under the impression that
> it was 100% future compatible or that there was an implied contract I can
> assure you that is not the case. There are numerous times in each release
> where fixing a bug will break somebody. It is just the nature, or physics,
> of the situation.
> -- Richard Bair on bundling a JRE per-application for desktop applications.
>
> If you want to be JDK5 compatible, compile for, and WITH JDK5.
>
>
Re: Multiple JDK versions
Posted by Mark Derricutt <ma...@talios.com>.
Ron Wheeler wrote:
> So always compile with 1.5 and make a package for 1.5 and copy it to
> files with 1.6 and 1.7 names.
> If the managers don't know how Java JVM works they will be impressed
> by how fast you can deliver new packages in so many operating systems
> and really impressed at the speed with which you can bring out 1.8
> support.
Well yes generally - however this week I had code that when compiled ON
JDK7 but targetting JDK6 worked fine, but targetting JDK7 failed to even
compile.
This was the in part my discovery of this new javac error message:
[ERROR] .../TransactionFilter.java:[112,11] exception
javax.validation.ConstraintViolationException has already been caught
turns out, javac now enforces/tracks the loss of visibility in catch
blocks, in this case, above the ConstraintViolationException catch block
was one for ValidationException , this is ConstraintViolationExceptions
super class.
However, I was pointing out the just "compiling to JDK5" doesn't really
help much, but you are correct and I got my terms backwards - I refer to
this quote that I posted on my own darn blog ;p
http://www.theoryinpractice.net/post/18036749530/java-has-never-been-future-compatible-and-will
Java has never been future compatible, and will never be. I just want to
make sure that is clear, because if you've been under the impression
that it was 100% future compatible or that there was an implied contract
I can assure you that is not the case. There are numerous times in each
release where fixing a bug will break somebody. It is just the nature,
or physics, of the situation.
-- Richard Bair on bundling a JRE per-application for desktop applications.
If you want to be JDK5 compatible, compile for, and WITH JDK5.
Re: Multiple JDK versions
Posted by Ron Wheeler <rw...@artifact-software.com>.
https://en.wikipedia.org/wiki/Backward_compatibility
In telecommunications <https://en.wikipedia.org/wiki/Telecommunications>
and computing <https://en.wikipedia.org/wiki/Computing>, a product or
technology is *backward* or *downward compatible* if it can work with
input <https://en.wikipedia.org/wiki/Input/output> generated by an
/older/ product or technology.^[1]
<https://en.wikipedia.org/wiki/Backward_compatibility#cite_note-1> If
products designed for the new standard can receive, read, view or play
older standards or formats, then the product is said to be
backward-compatible; examples of such a standard include data formats
and communication protocols
<https://en.wikipedia.org/wiki/Communications_protocol>. Modifications
to a system that do not allow backward compatibility are sometimes
called "breaking changes <https://en.wiktionary.org/wiki/breaking_change>."
Java has a good history of backwards compatibility.
Forward compatible is almost impossible for any designer (Tiff standard
is the only exception that I know and they only did it by defining that
there will be no other version that 42) and Java is not.
You can safely compile with Java 1.5 and run it on 1.6 and 1.7 run-times.
If the code is written for 1.6 and uses a 1.6 feature then you cannot
compile it in 1.5.
If the code is written for 1.5, you can compile it with 1.5 compiler (or
1.6 or 1.7 and 1.8, etc) and run it on 1.6 or 1.7 with no difference
except better performance.
So always compile with 1.5 and make a package for 1.5 and copy it to
files with 1.6 and 1.7 names.
If the managers don't know how Java JVM works they will be impressed by
how fast you can deliver new packages in so many operating systems and
really impressed at the speed with which you can bring out 1.8 support.
Ron
On 26/06/2013 4:52 PM, Mark Derricutt wrote:
> -1 on this. The JDK is *not* 100% backwards compatible. It's FORWARDS
> compatible yes, but not backwards.
>
> One case I know of is that certain String methods in JDK6 went from
> taking (String s) as an arg, to taking (CharSequence c) as arguments,
> if compiled against JDK6 -even if targetting 1.5 bytecode- the
> compiled method signature looks for CharSequence, which when run on
> JDK5 fails with method-not-found and blows up.
>
> There -are- legitimate cases for compiling with JDK5/JDK6 as your
> boot-class-path - for this - the toolchains plugin is your answer.
>
> Mark
>
>
> Baptiste MATHUS wrote:
>> +1 on the question, do you really need to build for both versions?
>> As JDK
>> is backward compatible, you could for example build only with1.5.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Multiple JDK versions
Posted by Mark Derricutt <ma...@talios.com>.
-1 on this. The JDK is *not* 100% backwards compatible. It's FORWARDS
compatible yes, but not backwards.
One case I know of is that certain String methods in JDK6 went from
taking (String s) as an arg, to taking (CharSequence c) as arguments, if
compiled against JDK6 -even if targetting 1.5 bytecode- the compiled
method signature looks for CharSequence, which when run on JDK5 fails
with method-not-found and blows up.
There -are- legitimate cases for compiling with JDK5/JDK6 as your
boot-class-path - for this - the toolchains plugin is your answer.
Mark
Baptiste MATHUS wrote:
> +1 on the question, do you really need to build for both versions? As JDK
> is backward compatible, you could for example build only with1.5.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: JavaDoc plugin and firewall
Posted by Anders Hammar <an...@hammar.net>.
You're just mirroring "central" so I'm guessing there is another repo
declared pointing at repo1 but with a different id than "central". Could
you check the effective pom of the project?
/Anders
On Tue, Jun 25, 2013 at 2:52 PM, Jan Engler <Ja...@sick.de> wrote:
> Hi,
>
> currently, I am facing a problem with the javadoc plugin: It seems that
> the plugin tries to download connected dependencies (that are used in our
> type hierarchy) from repo1 (central) although we have a defined mirror for
> that in the settings. Can I specify mirrors for plugins somewhere in the
> settings.xml or in the configuration of the plugin?
>
> Here is my "stacktrace" (the output from the plugin):
>
> The javasoft:synthetica:jar lies in our own repository....but apperantly,
> the plugin only searches in repo1.
>
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building My-Custom-App
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] >>> maven-javadoc-plugin:2.9:javadoc (default-cli)
> @My-Custom-App>>>
> [INFO]
> [INFO] <<< maven-javadoc-plugin:2.9:javadoc (default-cli) @ My-Custom-App
> <<<
> Downloading: http://repo1.maven.org/maven2/junit/junit/4.11/junit-4.11.pom
>
> Downloading:
> http://repo1.maven.org/maven2/org/easymock/easymock/3.1/easymock-3.1.pom
> Downloading:
>
> http://repo1.maven.org/maven2/org/easymock/easymockclassextension/3.1/easymockclassextension-3.1.pom
>
> Downloading:
>
> http://repo1.maven.org/maven2/org/springframework/spring-test/3.2.2.RELEASE/spring-test-3.2.2.RELEASE.pom
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1:45.795s
> [INFO] Finished at: Tue Jun 25 08:26:59 CEST 2013
> [INFO] Final Memory: 5M/15M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project sick-lnf: Could not resolve
> dependencies for project de.sick.sopas:my-custom-app:jar:3.0.0-SNAPSHOT:
> Failed to collect dependencies for [de.javasoft:synthetica:jar:1.0
> (compile), junit:junit:jar:4.11 (test), org.easymock:easymock:jar:3.1
> (test), org.easymock:easymockclassextension:jar:3.1 (test),
> org.springframework:spring-test:jar:3.2.2.RELEASE (test)]: Failed to read
> artifact descriptor for de.javasoft:synthetica:jar:1.0: Could not transfer
> artifact de.javasoft:synthetica:pom:1.0 from/to central (
> http://repo1.maven.org/maven2): Error transferring file: Connection timed
> out: connect -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
>
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
>
>
>
> I have a mirrorOf entry in our settings.xml:
> <mirrors>
> <mirror>
> <id>central-proxy</id>
> <name>Local proxy of central repo</name>
> <url>
> http://nexusserver.devserver.net:8080/nexus/content/repositories/central/
> </url>
> <mirrorOf>central</mirrorOf>
> </mirror>
> </mirrors>
>
> Any hints?
>
> Mit freundlichen Grüßen / Best regards
>
> Jan Engler
>
>
> SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB
> 280355
> Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Mats
> Gökstorp - Dr. Martin Krämer - Markus Vatter
> Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger
> (Vorsitzender)
>
JavaDoc plugin and firewall
Posted by Jan Engler <Ja...@sick.de>.
Hi,
currently, I am facing a problem with the javadoc plugin: It seems that
the plugin tries to download connected dependencies (that are used in our
type hierarchy) from repo1 (central) although we have a defined mirror for
that in the settings. Can I specify mirrors for plugins somewhere in the
settings.xml or in the configuration of the plugin?
Here is my "stacktrace" (the output from the plugin):
The javasoft:synthetica:jar lies in our own repository....but apperantly,
the plugin only searches in repo1.
[INFO] Scanning for projects...
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building My-Custom-App
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-javadoc-plugin:2.9:javadoc (default-cli)
@My-Custom-App>>>
[INFO]
[INFO] <<< maven-javadoc-plugin:2.9:javadoc (default-cli) @ My-Custom-App
<<<
Downloading: http://repo1.maven.org/maven2/junit/junit/4.11/junit-4.11.pom
Downloading:
http://repo1.maven.org/maven2/org/easymock/easymock/3.1/easymock-3.1.pom
Downloading:
http://repo1.maven.org/maven2/org/easymock/easymockclassextension/3.1/easymockclassextension-3.1.pom
Downloading:
http://repo1.maven.org/maven2/org/springframework/spring-test/3.2.2.RELEASE/spring-test-3.2.2.RELEASE.pom
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1:45.795s
[INFO] Finished at: Tue Jun 25 08:26:59 CEST 2013
[INFO] Final Memory: 5M/15M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal on project sick-lnf: Could not resolve
dependencies for project de.sick.sopas:my-custom-app:jar:3.0.0-SNAPSHOT:
Failed to collect dependencies for [de.javasoft:synthetica:jar:1.0
(compile), junit:junit:jar:4.11 (test), org.easymock:easymock:jar:3.1
(test), org.easymock:easymockclassextension:jar:3.1 (test),
org.springframework:spring-test:jar:3.2.2.RELEASE (test)]: Failed to read
artifact descriptor for de.javasoft:synthetica:jar:1.0: Could not transfer
artifact de.javasoft:synthetica:pom:1.0 from/to central (
http://repo1.maven.org/maven2): Error transferring file: Connection timed
out: connect -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
I have a mirrorOf entry in our settings.xml:
<mirrors>
<mirror>
<id>central-proxy</id>
<name>Local proxy of central repo</name>
<url>
http://nexusserver.devserver.net:8080/nexus/content/repositories/central/
</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
Any hints?
Mit freundlichen Grüßen / Best regards
Jan Engler
SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB
280355
Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Mats
Gökstorp - Dr. Martin Krämer - Markus Vatter
Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger
(Vorsitzender)
Re: Multiple JDK versions
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Virg,
virg g wrote:
> Yes you are absolutely right, I totally agree with you. I am asked to
> implement these kind of builds.
Ahh, OK. Nothing helps against ignorance in the business layer ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple JDK versions
Posted by virg g <06...@gmail.com>.
Yes you are absolutely right, I totally agree with you. I am asked to
implement these kind of builds.
On Tue, Jun 25, 2013 at 3:35 PM, Jörg Schaible
<Jo...@scalaris.com>wrote:
> Hi Virg,
>
> virg g wrote:
>
> > Yes. We have multiple customers, some of them support 1.5 and others 1.6.
> > We need to release both the builds with 1.5 and 1.6.
>
> [snip]
>
> sorry, in this case it simply does not make sense to use different JDKs. If
> you are able to compile the same sources for JDK 1.5 and JDK 1.6, the
> source
> *must* be compatible to JDK 1.5.
>
> Let's take it to the extreme. Have a look at current commons-logging-1.1.3.
> That one is JDK 1.1 compatible. With your logic, Apache commons sould have
> to release commons-logging for JDK 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7 and
> soon for 1.8. Do you find such releases somewhere? No, because it is
> absolutely not necessary.
>
> So, compile your source with target JDK 1.5 and you're done.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Multiple JDK versions
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Virg,
virg g wrote:
> Yes. We have multiple customers, some of them support 1.5 and others 1.6.
> We need to release both the builds with 1.5 and 1.6.
[snip]
sorry, in this case it simply does not make sense to use different JDKs. If
you are able to compile the same sources for JDK 1.5 and JDK 1.6, the source
*must* be compatible to JDK 1.5.
Let's take it to the extreme. Have a look at current commons-logging-1.1.3.
That one is JDK 1.1 compatible. With your logic, Apache commons sould have
to release commons-logging for JDK 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7 and
soon for 1.8. Do you find such releases somewhere? No, because it is
absolutely not necessary.
So, compile your source with target JDK 1.5 and you're done.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multiple JDK versions
Posted by Baptiste MATHUS <ml...@batmat.net>.
Well, if you have multiple customers, some on 1.5, some on 1.6, then just
release a 1.5 version.
It will work perfectly with both 1.5 AND 1.6.
Please note this is actually what you certainly are already doing with a
lot of dependencies in your classpath. Not all have the same bytecode
version.
What you might just want to do that is running some integration tests on
your project.
To do that, you'd just need to execute the corresponding tests with some CI
environment (like Jenkins, to illustrate/be clear).
About your question for source and target parameters, please note this is
actually something related to javac, not the maven-compiler-plugin.
See http://docs.oracle.com/javase/1.5.0/docs/tooldocs/solaris/javac.html
To sum up:
* source is asking the compiler you're not using things of upper jdk in
your *source* code
* target is asking the compiler to generated bytecode that will run on the
specified JRE (minimum).
Cheers
2013/6/25 virg g <06...@gmail.com>
> Yes. We have multiple customers, some of them support 1.5 and others 1.6.
> We need to release both the builds with 1.5 and 1.6. Right now i am
> initiating build separately one after the other, setting JAVA_HOME
> correctly and passing jdk-version according build i need, this parameter i
> am setting for both source and target. Sending both the parameters
> JAVA_HOME, jdk-versions(1.5 to 1.6 to set source and target) is kind of
> duplicate and also we need to ensure that both are in parameters Sync and
> should match, should be not any mistakes.
> Looking for right solution. As you suggested matrix build, i will check.
> Any other best solutions?
>
> This is plugin i am using
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>2.5.1</version>
> <configuration>
> <source>${jdk-version}</source>
> <target>${jdk-version}</target>
> <encoding>${project.build.sourceEncoding}</encoding>
> <executable>${JAVA_HOME}/bin/javac</executable>
> <compilerArguments>
> <J-Xms1024m/>
> <J-Xmx1024m/>
> </compilerArguments>
> <fork>true</fork>
> </configuration>
> </plugin>
>
> Thanks
> Virg
>
>
> On Tue, Jun 25, 2013 at 12:39 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
>
> > Hi,
> > +1 on the question, do you really need to build for both versions? As JDK
> > is backward compatible, you could for example build only with 1.5.
> >
> > Maybe you only want to test your build on a 1.5 and 1.6, then I
> personally
> > would prefer keeping a quite simple build and keep those combinations on
> > some CI server like jenkins (see matrix build in this case).
> >
> > Cheers
> > Le 25 juin 2013 08:16, "Ron Wheeler" <rw...@artifact-software.com> a
> > écrit :
> >
> > > Why do you need to compile with 2 versions?
> > > You can run apps compiled with 1.5 under 1.6.
> > >
> > > I am not sure that the value of JAVA_HOME has any effect on compiling.
> > > Check the settings in the compile plug-in.
> > >
> > > Ron
> > >
> > >
> > > On 25/06/2013 1:59 AM, virg g wrote:
> > >
> > >> Hi, I need build my project with multiple jdk versions 1.5 and 1.6. I
> > >>
> > > > am using maven compiler plugin to set the compiler based on JAVA_HOME
> > > > set. Is it mandatory to set target either 1.5 or 1.6 based on the jdk
> > > > version i want to build. Why because if i set compiler to jdk 1.6, in
> > > > the debug log it shows that target is 1.5 but it should be 1.6 right?
> > > > target should set automatically based on JAVA_HOME right unless i
> > > > specically mention the target if i want to change? Any pointers for
> > > > my problem?
> > > >
> > > > [DEBUG] (f) executable = D:/jdk1.6.0_14/bin/javac [DEBUG] (f)
> > > > source = 1.5 [DEBUG] (f) staleMillis = 0 [DEBUG] (f) target =
> > > > 1.5
> > > >
> > > > Thanks virg
> > > >
> > >
> > >
> > > --
> > > Ron Wheeler
> > > President
> > > Artifact Software Inc
> > > email: rwheeler@artifact-software.com
> > > skype: ronaldmwheeler
> > > phone: 866-970-2435, ext 102
> > >
> > >
> >
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>
Re: Multiple JDK versions
Posted by virg g <06...@gmail.com>.
Yes. We have multiple customers, some of them support 1.5 and others 1.6.
We need to release both the builds with 1.5 and 1.6. Right now i am
initiating build separately one after the other, setting JAVA_HOME
correctly and passing jdk-version according build i need, this parameter i
am setting for both source and target. Sending both the parameters
JAVA_HOME, jdk-versions(1.5 to 1.6 to set source and target) is kind of
duplicate and also we need to ensure that both are in parameters Sync and
should match, should be not any mistakes.
Looking for right solution. As you suggested matrix build, i will check.
Any other best solutions?
This is plugin i am using
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>${jdk-version}</source>
<target>${jdk-version}</target>
<encoding>${project.build.sourceEncoding}</encoding>
<executable>${JAVA_HOME}/bin/javac</executable>
<compilerArguments>
<J-Xms1024m/>
<J-Xmx1024m/>
</compilerArguments>
<fork>true</fork>
</configuration>
</plugin>
Thanks
Virg
On Tue, Jun 25, 2013 at 12:39 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
> Hi,
> +1 on the question, do you really need to build for both versions? As JDK
> is backward compatible, you could for example build only with 1.5.
>
> Maybe you only want to test your build on a 1.5 and 1.6, then I personally
> would prefer keeping a quite simple build and keep those combinations on
> some CI server like jenkins (see matrix build in this case).
>
> Cheers
> Le 25 juin 2013 08:16, "Ron Wheeler" <rw...@artifact-software.com> a
> écrit :
>
> > Why do you need to compile with 2 versions?
> > You can run apps compiled with 1.5 under 1.6.
> >
> > I am not sure that the value of JAVA_HOME has any effect on compiling.
> > Check the settings in the compile plug-in.
> >
> > Ron
> >
> >
> > On 25/06/2013 1:59 AM, virg g wrote:
> >
> >> Hi, I need build my project with multiple jdk versions 1.5 and 1.6. I
> >>
> > > am using maven compiler plugin to set the compiler based on JAVA_HOME
> > > set. Is it mandatory to set target either 1.5 or 1.6 based on the jdk
> > > version i want to build. Why because if i set compiler to jdk 1.6, in
> > > the debug log it shows that target is 1.5 but it should be 1.6 right?
> > > target should set automatically based on JAVA_HOME right unless i
> > > specically mention the target if i want to change? Any pointers for
> > > my problem?
> > >
> > > [DEBUG] (f) executable = D:/jdk1.6.0_14/bin/javac [DEBUG] (f)
> > > source = 1.5 [DEBUG] (f) staleMillis = 0 [DEBUG] (f) target =
> > > 1.5
> > >
> > > Thanks virg
> > >
> >
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwheeler@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
>
Re: Multiple JDK versions
Posted by Baptiste MATHUS <ml...@batmat.net>.
Hi,
+1 on the question, do you really need to build for both versions? As JDK
is backward compatible, you could for example build only with 1.5.
Maybe you only want to test your build on a 1.5 and 1.6, then I personally
would prefer keeping a quite simple build and keep those combinations on
some CI server like jenkins (see matrix build in this case).
Cheers
Le 25 juin 2013 08:16, "Ron Wheeler" <rw...@artifact-software.com> a
écrit :
> Why do you need to compile with 2 versions?
> You can run apps compiled with 1.5 under 1.6.
>
> I am not sure that the value of JAVA_HOME has any effect on compiling.
> Check the settings in the compile plug-in.
>
> Ron
>
>
> On 25/06/2013 1:59 AM, virg g wrote:
>
>> Hi, I need build my project with multiple jdk versions 1.5 and 1.6. I
>>
> > am using maven compiler plugin to set the compiler based on JAVA_HOME
> > set. Is it mandatory to set target either 1.5 or 1.6 based on the jdk
> > version i want to build. Why because if i set compiler to jdk 1.6, in
> > the debug log it shows that target is 1.5 but it should be 1.6 right?
> > target should set automatically based on JAVA_HOME right unless i
> > specically mention the target if i want to change? Any pointers for
> > my problem?
> >
> > [DEBUG] (f) executable = D:/jdk1.6.0_14/bin/javac [DEBUG] (f)
> > source = 1.5 [DEBUG] (f) staleMillis = 0 [DEBUG] (f) target =
> > 1.5
> >
> > Thanks virg
> >
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Re: Multiple JDK versions
Posted by Ron Wheeler <rw...@artifact-software.com>.
Why do you need to compile with 2 versions?
You can run apps compiled with 1.5 under 1.6.
I am not sure that the value of JAVA_HOME has any effect on compiling.
Check the settings in the compile plug-in.
Ron
On 25/06/2013 1:59 AM, virg g wrote:
> Hi, I need build my project with multiple jdk versions 1.5 and 1.6. I
> am using maven compiler plugin to set the compiler based on JAVA_HOME
> set. Is it mandatory to set target either 1.5 or 1.6 based on the jdk
> version i want to build. Why because if i set compiler to jdk 1.6, in
> the debug log it shows that target is 1.5 but it should be 1.6 right?
> target should set automatically based on JAVA_HOME right unless i
> specically mention the target if i want to change? Any pointers for
> my problem?
>
> [DEBUG] (f) executable = D:/jdk1.6.0_14/bin/javac [DEBUG] (f)
> source = 1.5 [DEBUG] (f) staleMillis = 0 [DEBUG] (f) target =
> 1.5
>
> Thanks virg
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Multiple JDK versions
Posted by Barrie Treloar <ba...@gmail.com>.
On 25 June 2013 15:29, virg g <06...@gmail.com> wrote:
> Hi, I need build my project with multiple jdk versions 1.5 and 1.6. I am
> using maven compiler plugin to set the compiler based on JAVA_HOME set. Is
> it mandatory to set target either 1.5 or 1.6 based on the jdk version i
> want to build. Why because if i set compiler to jdk 1.6, in the debug log
> it shows that target is 1.5 but it should be 1.6 right? target should set
> automatically based on JAVA_HOME right unless i specically mention the
> target if i want to change? Any pointers for my problem?
>
> [DEBUG] (f) executable = D:/jdk1.6.0_14/bin/javac
> [DEBUG] (f) source = 1.5
> [DEBUG] (f) staleMillis = 0
> [DEBUG] (f) target = 1.5
Did you see the docs?
http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
Tells you how to change the compiler
http://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html
Tells you how to change the -source and -target arguments.
You can run with a different JDK than the java class files being generated.
i.e. JDK is 1.6 and output classes are 1.5 byte code.
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
Tells you the default value for source
(http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#source)
and target (http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#target)
is 1.5
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org