maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Changing JDK version without specifying maven-compiler-plugin version
Date Wed, 27 Nov 2013 10:32:36 GMT
On 27 November 2013 10:18, Malte Skoruppa <skoruppa@cs.uni-saarland.de>wrote:

> Hi all,
>
> thank you for your helpful answers. I grasped a lot about how Maven
> internally works and learned some tricks (e.g., dependency:analyze). This
> is a great mailing list indeed.
>
> @Laird: that is quite interesting. From all the other posts I really
> gained the impression that my original question was actually unsolvable
> (e.g., Stephen explicitly stated the goals are "incompatible").
>
> But this also led me to a new question.
>
> Always eager to learn, I tried - just to see what would happen -
> specifying in my POM at the same time <maven.compiler.{source,target}> in
> the <properties> section, *as well as* specifying <{source,target}> in the
> <configuration> section of the maven-compiler-plugin. It turns out that the
> latter takes precedence over the former (i.e., when different Java versions
> are specified in these two places, the <configuration> of the
> maven-compiler-plugin is used).
>
> Therefore, from my understanding up to this point, I suspected that there
> must be something in the "uber"-pom akin to this:
>
>
> <plugin>
>     <groupId>org.apache.maven.plugins</groupId>
>     <artifactId>maven-compiler-plugin</artifactId>
>     <version>SOME_DEFAULT_VERSION</version>
>     <configuration>
>       <source>${maven.compiler.source}</source>
>       <target>${maven.compiler.target}</target>
>     </configuration>
> </plugin>
>

actually what is the case is that these parameters have an annotation like

@Parameter(property="maven.compiler.source",defaultValue="1.5")
private String source;

So what happens is that if you don't specify a value in the <configuration>
section then Maven checks to see if the property is defined, if not then it
uses the default value

Once you specify a value in the <configuration> section that is taken as
gold.

Hence why I said it was incompatible, as the property trick is just that, a
trick, and it will fall over under stress... none the less it is a handy
trick to have... as long as you are aware that it is a trick.


>
> where the maven.compiler.{source,target} would be specified in the
> <properties> section of the "uber"-pom. That would have explained both why
> Maven complains when I reconfigure the maven-compiler-plugin without
> specifying the plugin version, as well as why redefining
> maven.compiler.{source,target} in the <properties> section of my own pom is
> a working solution for my original question.
>
> So I finally decided to take a look at this "uber"-pom :)
>
> I was suprised to find there is *no mention* of the maven-compiler-plugin
> *at all* in this super-pom, that is,
>
> $ export M2_HOME=/usr/share/maven
> $ unzip -p $M2_HOME/lib/maven-model-builder-3.0.4.jar
> org/apache/maven/model/pom-4.0.0.xml | grep compiler
> $
>
> ...the latter command produces no output (I'm using Maven 3.0.4, as can be
> seen from the path).
> (Alternatively, one might search for "compiler" at
> http://maven.apache.org/ref/3.0.4/maven-model-builder/super-pom.html, but
> I wanted to make sure that indeed the same uber-pom is used on my machine).
>
> This is quite confusing. I firmly expected to see some kind of
> configuration of the maven-compiler-plugin in the uber-pom. That is what
> many of you led me to believe:
>
> Stephen:
>
>  the "core" plugins all have a version specified in the über-pom that is
>> embedded within Maven.
>>
>
Hmmm.. it seems I missed http://jira.codehaus.org/browse/MNG-4453 with the
transition to Maven 3.x... and as I lock plugin versions down anyways...


>
> Randal:
>
>  As was pointed out, core components such as the compiler plugin have a
>> stable default version via the 'uber-pom' as of a particular version of
>> Maven
>>
>
> Mark:
>
>  generated POMs *do* specify the version of
>> m-compiler-p, by *not* specifying it.  There's a built-in set of
>> defaults(1) buried inside Maven, which specify much of the
>> not-otherwise-specified.
>>
>
> So... where is this stable maven-compiler-plugin version specified,
> precisely?
> I did find some mentions of a stable maven-compiler-plugin version in
> $M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/components.xml as well
> as $M2_HOME/lib/maven-core-3.0.4.jar:META-INF/plexus/artifact-handlers.xml,
> but I'm not sure whether that's the actual place where the "default
> version" of the maven-compiler-plugin is configured, and certainly none of
> them is the uber-pom.
>
> I'd just like to see it; I like to understand how stuff works ;-)
>
> Thanks,
>
> Malte
>
>
>
> On 11/26/2013 04:26 PM, Stephen Connolly wrote:
>
>> On 26 November 2013 14:59, Malte Skoruppa <skoruppa@cs.uni-saarland.de>
>> wrote:
>>
>>
>>  Hi,
>>>
>>> I'm new to Maven and I'm currently going through the "Getting Started"
>>> guide.
>>>
>>> While reading, the following question came to me.
>>> As far as I understand, Maven defaults to compiling all Java source files
>>> with compatibility for JDK 1.3 (i.e., -source 1.3).
>>>
>>>  Well actually with newer versions of the compiler plugin the default has
>> been upped to 1.5
>>
>>
>>  The guide explains how to change that behaviour, by configuring the
>>> maven-compiler-plugin in the pom.xml:
>>> http://maven.apache.org/guides/getting-started/index.
>>> html#How_do_I_use_plug-ins
>>>
>>> So far so good. However, if I do this, it appears that I also have to
>>> specify the version of maven-compiler-plugin to be used (e.g., 2.5.1 in
>>> the
>>> code snippet shown under the above link).
>>>
>>> Generally, I don't want to do that. On the one hand, I would like for
>>> Maven to simply use the latest version of the maven-compiler-plugin that
>>> is
>>> available (the default behaviour).
>>>
>>
>> Not the default behaviour any more.... at least since 2.0.9 IIRC... the
>> "core" plugins all have a version specified in the über-pom that is
>> embedded within Maven. Thus if you do not specify a version, you get the
>> version specified in the über-pom... for non-core plugins you will get the
>> latest, but your build is now irreproducible. Best practice is to specify
>> the version for all plugins.
>>
>>
>>  On the other hand, I would like to use Java features above 1.3 (for
>>> instance, generics).
>>>
>>> So my first attempt was to simply remove the "<version>2.5.1</version>"
>>> part from the pom.xml under the maven-compiler-plugin configuration.
>>> While
>>> this did in principle work, Maven was not happy at all and complained
>>> with
>>> this message:
>>>
>>> [WARNING] Some problems were encountered while building the effective
>>> model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
>>> [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:
>>> maven-compiler-plugin
>>> is missing. @ line 19, column 15
>>> [WARNING]
>>> [WARNING] It is highly recommended to fix these problems because they
>>> threaten the stability of your build.
>>> [WARNING]
>>> [WARNING] For this reason, future Maven versions might no longer support
>>> building such malformed projects.
>>>
>>> So my question boils down to this: is there some way for me to achieve
>>> the
>>>
>>> following three things at the same time:
>>> (1) have Maven compile my source files with -source 1.4 (or anything
>>> higher than 1.3)
>>> (2) *not* specify the maven-compiler-plugin version to use; instead, have
>>> Maven dynamically use the latest one available;
>>> (3) *not* have Maven bitch about my project being "malformed" ;-)
>>>
>>> I would imagine that this is not such a rare scenario:
>>> (1) I do want to use Java features higher than those available in Java
>>> 1.3;
>>>
>>>  Then set source and target to 1.3... and hope you never upgrade to Java
>> 8
>>
>>
>>  (2) I do *not* want having to monitor the maven-compiler-plugin by myself
>>> all the time in order to check for updates and keep my pom.xml referring
>>> to
>>> the currently latest version;
>>>
>>>  Incompatible goal. If you have a version of the compiler plugin that is
>> working. Leave it as is. If it isn't broken, don't fix it. If you decide
>> that it is broken (e.g. you think the version you have is not compiling
>> fast enough) then try upgrading... this way you have control over your
>> build
>>
>>
>>  (3) yet I do *not* want Maven complaining about my project.xml being
>>> malformed either.
>>>
>>>  Specify the version, or live with Maven complaining.
>>
>> The Maven way is to make doing "the right thing" easy... doing the "not so
>> right thing" should encounter some friction... but unless we have good
>> reason we should not prevent you from shooting your foot off... we can
>> make
>> it difficult to aim the gun at your foot though!
>>
>>  So what's the "clean" way to do this? :-)
>>>
>>> For clarity, I have written down the steps to reproduce my problem in the
>>> Appendix, below.
>>>
>>> Thanks,
>>>
>>> Malte
>>>
>>>
>>>
>>>
>>>
>>> APPENDIX: Steps to reproduce:
>>>
>>> 1. Generate a simple Maven project using the very command stated on
>>> http://maven.apache.org/guides/getting-started/index.
>>> html#How_do_I_make_my_first_Maven_project :
>>>
>>> mvn archetype:generate \
>>>    -DarchetypeGroupId=org.apache.maven.archetypes \
>>>    -DgroupId=com.mycompany.app \
>>>    -DartifactId=my-app
>>>
>>> 2. Replace the generated  src/main/java/com/mycompany/app/App.java with
>>> something that uses generics (not available in Java 1.3), e.g.:
>>>
>>> package com.mycompany.app;
>>> import java.util.*;
>>>
>>> /**
>>>   * Hello world!
>>>   *
>>>   */
>>> public class App {
>>>
>>>      public static void main( String[] args) {
>>>
>>>          List<String> myList = new ArrayList<String>();
>>>          myList.add( "Hello");
>>>          myList.add( "world");
>>>
>>>          for( Iterator<String> i = myList.iterator(); i.hasNext();)
>>>              System.out.println( i.next());
>>>      }
>>> }
>>>
>>> 3. Try to compile using the command 'mvn compile'. Maven fails:
>>>
>>> $ mvn compile
>>> [INFO] Scanning for projects...
>>> ...
>>> [INFO] ------------------------------------------------------------
>>> ------------
>>> [INFO] BUILD FAILURE
>>> [INFO] ------------------------------------------------------------
>>> ------------
>>> [INFO] Total time: 0.995s
>>> [INFO] Finished at: Tue Nov 26 15:26:00 CET 2013
>>> [INFO] Final Memory: 6M/117M
>>> [INFO] ------------------------------------------------------------
>>> ------------
>>> [ERROR] Failed to execute goal org.apache.maven.plugins:
>>> maven-compiler-plugin:2.0.2:compile (default-compile) on project my-app:
>>> Compilation failure
>>> [ERROR] /home/malte/dev/java/testMaven/my-app/src/main/
>>> java/com/mycompany/app/App.java:[13,5] error: generics are not supported
>>> in -source 1.3
>>> ...
>>>
>>> 4. Ok, so let's add the following to our pom.xml. This is copied&pasted
>>> from http://maven.apache.org/guides/getting-started/index.
>>> html#How_do_I_use_plug-ins :
>>>
>>> <build>
>>>    <plugins>
>>>      <plugin>
>>>        <groupId>org.apache.maven.plugins</groupId>
>>>        <artifactId>maven-compiler-plugin</artifactId>
>>>        <version>2.5.1</version>
>>>        <configuration>
>>>          <source>1.5</source>
>>>          <target>1.5</target>
>>>        </configuration>
>>>      </plugin>
>>>    </plugins>
>>> </build>
>>>
>>> Running 'mvn compile' again, everything works fine now.
>>>
>>> 5. Yet, I would like to avoid having to specify the version of
>>> maven-compiler-plugin to be used. I simply want Maven to use the latest
>>> one
>>> available. So, let's remove the line
>>>
>>>        <version>2.5.1</version>
>>>
>>> from the pom.xml again.
>>>
>>> Running 'mvn compile' again, this works too, but Maven complains:
>>>
>>> $ mvn compile
>>> [INFO] Scanning for projects...
>>> [WARNING]
>>> [WARNING] Some problems were encountered while building the effective
>>> model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
>>> [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:
>>> maven-compiler-plugin
>>> is missing. @ line 19, column 15
>>> [WARNING]
>>> [WARNING] It is highly recommended to fix these problems because they
>>> threaten the stability of your build.
>>> [WARNING]
>>> [WARNING] For this reason, future Maven versions might no longer support
>>> building such malformed projects.
>>> [WARNING]
>>> ...
>>> [INFO] ------------------------------------------------------------
>>> ------------
>>> [INFO] BUILD SUCCESS
>>> [INFO] ------------------------------------------------------------
>>> ------------
>>> [INFO] Total time: 0.877s
>>> [INFO] Finished at: Tue Nov 26 15:37:17 CET 2013
>>> [INFO] Final Memory: 5M/117M
>>> [INFO] ------------------------------------------------------------
>>> ------------
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>
>
> On 11/27/2013 01:47 AM, Laird Nelson wrote:
>
>> On Tuesday, November 26, 2013, Malte Skoruppa wrote:
>>
>>> is there some way for me to achieve the following three things at the
>>> same
>>> time:
>>> (1) have Maven compile my source files with -source 1.4 (or anything
>>> higher than 1.3)
>>> (2) *not* specify the maven-compiler-plugin version to use; instead, have
>>> Maven dynamically use the latest one available;
>>> (3) *not* have Maven bitch about my project being "malformed" ;-)
>>>
>>
>> Yes.  In your pom.xml's <properties> section add this:
>>
>> <maven.compiler.source>1.6</maven.compiler.source>
>> <maven.compiler.target>1.6</maven.compiler.target>
>>
>> No other configuration or verbiage needed.
>>
>> All of the other posters' words are good. But no one answered your
>> question.
>>
>> Best,
>> Laird
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message