Bug 532016 - Set default Java execution environment when creating a new project
Summary: Set default Java execution environment when creating a new project
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: m2e (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2018-03-05 08:32 EST by Jens Reimann CLA
Modified: 2021-04-19 13:22 EDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Reimann CLA 2018-03-05 08:32:52 EST
When creating a new simple maven module, the default is that a maven project with an empty POM and the default language level of Java 1.5 will be set.

I guess this is wrong in 99.99% of the cases now.

In addition the JDT preferences allow selecting a "default" JRE: "By default, the checked JRE is added to the build path of newly created Java projects".

I think it would be nice to have an option in the M2E new project dialog to "Use default Java version", which will add and configure the default Java compiler plugin with the selected JRE version. Unsetting the checkbox will revert to the current behavior.

Even nicer would be a dropdown, featuring all JRE versions, with an option "Maven Default" (current behavior) and "Workspace Default" (from JDT default).
Comment 1 Mickael Istria CLA 2018-03-05 08:39:05 EST
(In reply to Jens Reimann from comment #0)
> I think it would be nice to have an option in the M2E new project dialog to
> "Use default Java version", which will add and configure the default Java
> compiler plugin with the selected JRE version. Unsetting the checkbox will
> revert to the current behavior.

Or better, not giving the particular option, let m2e use JDT setting for default, generate with JDT default and then let user easily change that later if they need to (by simply changing the pom.xml I guess).
Smart defaults are more important for usability than giving plethora of options.
Comment 2 Torkild Resheim CLA 2018-03-05 15:20:39 EST
(In reply to Mickael Istria from comment #1)
> Or better, not giving the particular option, let m2e use JDT setting for
> default, generate with JDT default and then let user easily change that
> later if they need to (by simply changing the pom.xml I guess).
> Smart defaults are more important for usability than giving plethora of
> options.

+1
Comment 3 Pierre-Yves Bigourdan CLA 2019-06-25 05:11:44 EDT
Agreed, it would be nice to have m2e use the default JRE set in JDT when creating new Maven projects/modules.
Comment 4 Mickael Istria CLA 2019-06-25 05:14:50 EDT
@Pierre-Yves: Would you be interested in contributing that?
Comment 5 Pierre-Yves Bigourdan CLA 2019-06-25 05:20:54 EDT
@Mickael: never contributed to this part of Eclipse, but I can at least look into it. :)
Comment 6 Mickael Istria CLA 2019-06-25 05:24:52 EDT
(In reply to Pierre-Yves B. from comment #5)
> @Mickael: never contributed to this part of Eclipse, but I can at least look
> into it. :)

It's a typical Gerrit workflow, so you wouldn't have anything new to learn about the process.
Comment 7 Pierre-Yves Bigourdan CLA 2019-06-29 17:13:49 EDT
Unfortunately, I'm having trouble setting up the m2e project in Eclipse. I've followed the instructions in "Development Environment Setup" (https://www.eclipse.org/m2e/documentation/m2e-development-environment.html) and tried importing the different projects as existing Maven ones, but I'm facing at least two issues:
* the takari-lifecycle plugin connector required by org.eclipse.m2e.workspace cannot be installed (https://download.takari.io/eclipse/takari-lifecycle/content.xml times out).
* the imported projects aren't recognized as Java ones.
Comment 8 Mickael Istria CLA 2019-07-25 11:23:44 EDT
(In reply to Pierre-Yves B. from comment #7)
> Unfortunately, I'm having trouble setting up the m2e project in Eclipse.
> I've followed the instructions in "Development Environment Setup"
> (https://www.eclipse.org/m2e/documentation/m2e-development-environment.html)
> and tried importing the different projects as existing Maven ones, but I'm
> facing at least two issues:
> * the takari-lifecycle plugin connector required by
> org.eclipse.m2e.workspace cannot be installed
> (https://download.takari.io/eclipse/takari-lifecycle/content.xml times out).
> * the imported projects aren't recognized as Java ones.

@Fred: any suggestion? I also find hard and annoying to require 3rd party plugins to work with m2e (especially since takari ones force data collection). Is there some possible alternative that wouldn't involve those error-prone steps?
Comment 9 Pierre-Yves Bigourdan CLA 2019-12-08 14:53:17 EST
I've circled back to this issue. Having done a bit more digging and put in some more thought, I now think it would be wrong to change the current behaviour.

By default, the latest version of Maven invokes Compiler version 3.1 (https://github.com/apache/maven/blob/13c80d506f7219f05f229a752b9e541b6ce85345/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml#L73).

For that old version of the Compiler plugin, source and target versions default to 1.5 (https://github.com/apache/maven-compiler-plugin/blob/b48dfe37a002150985d410fccdbfd74988c5bb8c/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L120).

In org.eclipse.m2e.jdt.internal.AbstractJavaProjectConfigurator, Eclipse correctly picks this up by going through the MOJO for the compiler:compile goal, and sets Java 1.5 as described by other users.

If you override the default Maven Compiler version and use the latest 3.8.1, Eclipse sets target and source to 1.6, which is what is expected (https://github.com/apache/maven-compiler-plugin/blob/1455594a943791fa14f7a733dbcf48b648100a8d/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L101). If you explicitly configure source and target in your pom.xml, Eclipse will correctly match the Java language level you've defined.

Trying to make Eclipse override the Java execution environment rather than letting Maven handle it may become even more confusing for users and may cause the IDE to behave inconsistently compared to running Maven from the command line for example. I would suggest a "Won't fix" in this case.
Comment 10 Pierre-Yves Bigourdan CLA 2019-12-08 15:19:48 EST
Alternatively, we could consider this issue from a different angle: on a new Maven project creation, rather than having an (almost) empty pom.xml, we could pre-populate with Maven Compiler configuration inferred from the user's default JRE, e.g.:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>some-group</groupId>
    <artifactId>some-artifact</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                  <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

All depends on how fancy we want to get when users select "Create a simple project" and skip the archetype selection phase. Some users may not want such overrides imposed upon them.
Comment 11 Mickael Istria CLA 2019-12-09 03:44:15 EST
What about we lobby with Maven (ie contribute a patch) to use latest version of compiler by default? So we'd just have to upgrade Maven and that's all.
By the way, Maven 3.7.0 changes to newer Java version by default: https://mail-archives.apache.org/mod_mbox/maven-dev/201910.mbox/browser , so upgrading the compiler should be more welcome now.
I suggest anyone interested to open a bug to Maven Jira ( https://issues.apache.org/jira/projects/MNG/issues ) and considers submitting a PR to Maven.
Once it's fixed in Maven release, we just need to upgrade m2e and this would be fixed automatically.
Comment 12 Pierre-Yves Bigourdan CLA 2019-12-09 04:08:52 EST
(In reply to Mickael Istria from comment #11)
> What about we lobby with Maven (ie contribute a patch) to use latest version
> of compiler by default? So we'd just have to upgrade Maven and that's all.
> By the way, Maven 3.7.0 changes to newer Java version by default:
> https://mail-archives.apache.org/mod_mbox/maven-dev/201910.mbox/browser , so
> upgrading the compiler should be more welcome now.
> I suggest anyone interested to open a bug to Maven Jira (
> https://issues.apache.org/jira/projects/MNG/issues ) and considers
> submitting a PR to Maven.
> Once it's fixed in Maven release, we just need to upgrade m2e and this would
> be fixed automatically.

Unsure what using latest *Compiler plugin* would achieve. If not overridden, it still targets Java 1.6 as default source and target - I've even linked the source code in my previous message.
Comment 13 Mickael Istria CLA 2021-03-30 05:32:23 EDT
Eclipse m2e is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse-m2e/m2e-core/issues/ instead. If this issue is relevant to you, your action is required.
0. Verify this issue is still happening with latest Eclipse Platform and m2e release
  if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done
  if issue is still present when latest release:
* Create a new issue at https://github.com/eclipse-m2e/m2e-core/issues/
  ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  ** In the GitHub description, start with a link to this bugzilla ticket
  ** Optionally add new content to the description if it can helps towards resolution
  ** Submit GitHub issue
* Update bugzilla ticket
  ** Add to "See also" property (up right column) the link to the newly created GitHub issue
  ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  ** Set status as CLOSED MOVED
  ** Submit

All issues that remain open will be automatically closed next week or so. Then the m2e component for m2e will be made read-only.
Comment 14 Mickael Istria CLA 2021-03-30 05:39:45 EDT
Eclipse m2e is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse-m2e/m2e-core/issues/ instead. If this issue is relevant to you, your action is required.
0. Verify this issue is still happening with latest Eclipse Platform and m2e release
  if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done
  if issue is still present when latest release:
* Create a new issue at https://github.com/eclipse-m2e/m2e-core/issues/
  ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  ** In the GitHub description, start with a link to this bugzilla ticket
  ** Optionally add new content to the description if it can helps towards resolution
  ** Submit GitHub issue
* Update bugzilla ticket
  ** Add to "See also" property (up right column) the link to the newly created GitHub issue
  ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  ** Set status as CLOSED MOVED
  ** Submit

All issues that remain open will be automatically closed next week or so. Then the m2e component for m2e will be made read-only.
Comment 15 Denis Roy CLA 2021-04-19 13:22:01 EDT
Moved to https://github.com/eclipse-m2e/m2e-core/issues/