zDev - Tycho - OSS
  1. zDev - Tycho - OSS
  2. TYCHO-547

[MANIFEST-first] Need mapping: execution environment <-> JRE

    Details

    • Type: User Story User Story
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 0.11.0
    • Fix Version/s: None
    • Component/s: Product Development
    • Labels:
      None
    • Global Rank:
      531

      Description

      TYCHO-9 does a great job in configuring the JDT compiler. Unfortunately, we have some plugins for which it is realy necessary to link them against the jars that relates to their execution configuration.

      For that in PDE build you can create a mapping from execution environment to jars:

      J2SE-1.4=/var/j2sdk1.4.2_19/jre/lib/rt.jar:/var/j2sdk1.4.2_19/jre/lib/jsse.jar
      J2SE-1.5=/var/jdk1.5.0_22/jre/lib/rt.jar:/var/jdk1.5.0_22/jre/lib/jsse.jar
      JavaSE-1.6=/var/jdk1.6.0_18/jre/lib/rt.jar:/var/jdk1.6.0_18/jre/lib/jsse.jar
      

        Activity

        Hide
        Bernd Vogt added a comment -

        A workaround is to configure the JDT compiler with a custom bootclasspat (see snippet below). But we have >100 Plugins with different execution environments and want to take advantage of maven-tycho-plugin:generate-poms.

            <pluginManagement>
              <plugins>
                <plugin>
                  <groupId>org.sonatype.tycho</groupId>
                  <artifactId>maven-osgi-compiler-plugin</artifactId>
                  <version>${tychoVersion}</version>
                  <configuration>
                    <compilerId>jdt</compilerId>
                    <compilerArguments>
                      <bootclasspath>${jdk14}\jre\lib\rt.jar</bootclasspath>
                    </compilerArguments>
                  </configuration>
                </plugin>
              </plugins>
            </pluginManagement>
        
        Show
        Bernd Vogt added a comment - A workaround is to configure the JDT compiler with a custom bootclasspat (see snippet below). But we have >100 Plugins with different execution environments and want to take advantage of maven-tycho-plugin:generate-poms . <pluginManagement> <plugins> <plugin> <groupId>org.sonatype.tycho</groupId> <artifactId>maven-osgi-compiler-plugin</artifactId> <version>${tychoVersion}</version> <configuration> <compilerId>jdt</compilerId> <compilerArguments> <bootclasspath>${jdk14}\jre\lib\rt.jar</bootclasspath> </compilerArguments> </configuration> </plugin> </plugins> </pluginManagement>
        Hide
        Igor Fedorenko added a comment -

        This is a legitimate feature request. We have no immediate plans to work on this, but will be happy to review and apply a quality patch.

        As a side note, maven-tycho-plugin:generate-poms is meant for initial tycho build setup. After that, generated pom.xml files are generally expected to be maintained manually as the part of the project source tree.

        Show
        Igor Fedorenko added a comment - This is a legitimate feature request. We have no immediate plans to work on this, but will be happy to review and apply a quality patch. As a side note, maven-tycho-plugin:generate-poms is meant for initial tycho build setup. After that, generated pom.xml files are generally expected to be maintained manually as the part of the project source tree.
        Hide
        Bernd Vogt added a comment -

        As a side note, maven-tycho-plugin:generate-poms is meant for initial tycho build setup. After that, generated pom.xml files are generally expected to be maintained manually as the part of the project source tree.

        Maybe, but the template mechanism of the generate-poms feature is so powerfull that - until now - we have no need to checkin or maintain any pom manually. It's realy awesome

        Show
        Bernd Vogt added a comment - As a side note, maven-tycho-plugin:generate-poms is meant for initial tycho build setup. After that, generated pom.xml files are generally expected to be maintained manually as the part of the project source tree. Maybe, but the template mechanism of the generate-poms feature is so powerfull that - until now - we have no need to checkin or maintain any pom manually. It's realy awesome
        Hide
        Bernd Vogt added a comment -

        ... will be happy to review and apply a quality patch.

        I investigated a bit and came to the conclusion that the best way to establish this is to override the method org.eclipse.jdt.internal.compiler.batch.Main.getJavaHome() in JDTCompiler. It seems a bit hacky but I think it's the safest was to geht the methods Main.handleEndorseddirs(...) and Main.handleExtdirs(...) to work properly.

        A dirtier but simpler solution could be to set and reset the system property java.home in AbstractOsgiCompilerMojo...

        What do ou think?

        Show
        Bernd Vogt added a comment - ... will be happy to review and apply a quality patch. I investigated a bit and came to the conclusion that the best way to establish this is to override the method org.eclipse.jdt.internal.compiler.batch.Main.getJavaHome() in JDTCompiler . It seems a bit hacky but I think it's the safest was to geht the methods Main.handleEndorseddirs(...) and Main.handleExtdirs(...) to work properly. A dirtier but simpler solution could be to set and reset the system property java.home in AbstractOsgiCompilerMojo ... What do ou think?
        Hide
        Jan Sievers added a comment -

        I was thinking that automating your workaround using the bootclasspath above would be cleaner.
        E.g. introduce a new boolean config parameter "useExecutionEnvironmentAsJRE" (not a perfect name...) for maven-osgi-compiler-plugin.

        If this is set to true (default: false), tycho will programmatically configure the compiler bootclasspath

        <compilerArguments>
        <bootclasspath>$

        {EXEC_ENV_NAME}

        </bootclasspath>
        </compilerArguments>

        with EXEC_ENV_NAME taken from MANIFEST.

        In result the user would have to set variables $

        {J2SE-1.4}

        /$

        {J2SE-1.5}

        /$

        {JavaSE-1.6}

        etc. to the respective bootclasspath, which is very similar to what PDE build does. It's also similar to the way maven-compiler-plugin solves this problem, see http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html

        Show
        Jan Sievers added a comment - I was thinking that automating your workaround using the bootclasspath above would be cleaner. E.g. introduce a new boolean config parameter "useExecutionEnvironmentAsJRE" (not a perfect name...) for maven-osgi-compiler-plugin. If this is set to true (default: false), tycho will programmatically configure the compiler bootclasspath <compilerArguments> <bootclasspath>$ {EXEC_ENV_NAME} </bootclasspath> </compilerArguments> with EXEC_ENV_NAME taken from MANIFEST. In result the user would have to set variables $ {J2SE-1.4} /$ {J2SE-1.5} /$ {JavaSE-1.6} etc. to the respective bootclasspath, which is very similar to what PDE build does. It's also similar to the way maven-compiler-plugin solves this problem, see http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html
        Hide
        Bernd Vogt added a comment -

        ... using the bootclasspath above would be cleaner.

        I thought about that too. But then I recognized that if we just do that we will mix Jars from different JDKs. Using the bootclasspath workaround mentioned above will lead to this classpath:

        /opt/java/j2sdk1.4.2_19/jre/lib/rt.jar
        /opt/java/jdk1.6.0_17/jre/lib/ext/sunpkcs11.jar
        /opt/java/jdk1.6.0_17/jre/lib/ext/sunjce_provider.jar
        /opt/java/jdk1.6.0_17/jre/lib/ext/localedata.jar
        /opt/java/jdk1.6.0_17/jre/lib/ext/dnsns.jar
        /home/vr/.m2/repository/.cache/tycho/de.visualrules.java.mail-5.1.0.201101171116.jar/lib/mail.jar
        ...
        

        Hm, it seems that just overriding the Main#getJavaHome() is not enough. I think we have to do both, the bootclasspath and the Java Home thing. For a proper solution we have to:

        1. Add the Java Jars that are related to the projects (minimal?) ExecutionEnv to the classpath
        2. Assure that the Methods Main.handleEndorseddirs(...) and Main.handleExtdirs(...) will return the Jars that are related with the ExecutionEnv (or return nothing when we decide to configure them directly with the step above)

        Actually, unless the JDTCompiler doesn't support forking, there will be a gray area when the compiler doesn't find a class on its "classpath" and is falling back to the current JDKs classes...

        Show
        Bernd Vogt added a comment - ... using the bootclasspath above would be cleaner. I thought about that too. But then I recognized that if we just do that we will mix Jars from different JDKs. Using the bootclasspath workaround mentioned above will lead to this classpath: /opt/java/j2sdk1.4.2_19/jre/lib/rt.jar /opt/java/jdk1.6.0_17/jre/lib/ext/sunpkcs11.jar /opt/java/jdk1.6.0_17/jre/lib/ext/sunjce_provider.jar /opt/java/jdk1.6.0_17/jre/lib/ext/localedata.jar /opt/java/jdk1.6.0_17/jre/lib/ext/dnsns.jar /home/vr/.m2/repository/.cache/tycho/de.visualrules.java.mail-5.1.0.201101171116.jar/lib/mail.jar ... Hm, it seems that just overriding the Main#getJavaHome() is not enough. I think we have to do both, the bootclasspath and the Java Home thing. For a proper solution we have to: Add the Java Jars that are related to the projects (minimal?) ExecutionEnv to the classpath Assure that the Methods Main.handleEndorseddirs(...) and Main.handleExtdirs(...) will return the Jars that are related with the ExecutionEnv (or return nothing when we decide to configure them directly with the step above) Actually, unless the JDTCompiler doesn't support forking, there will be a gray area when the compiler doesn't find a class on its "classpath" and is falling back to the current JDKs classes...
        Hide
        Jan Sievers added a comment -

        OK so it looks like compiling against a different JDK can only be cleanly done if the compile process is forked.
        Then all the Main#getJavaHome(), Main#handleEndorseddirs() etc should just work given you start the process with a different java executable.
        So we first need to enable forking to make this work.

        Show
        Jan Sievers added a comment - OK so it looks like compiling against a different JDK can only be cleanly done if the compile process is forked. Then all the Main#getJavaHome(), Main#handleEndorseddirs() etc should just work given you start the process with a different java executable. So we first need to enable forking to make this work.
        Hide
        Bernd Vogt added a comment -

        Attached a patch that suggests how forking could be realized. The patch is based on the sources of Tycho 0.10.0.

        Configuration:

        <pluginManagement>
        	<plugins>
        		<plugin>
        			<groupId>org.sonatype.tycho</groupId>
        			<artifactId>maven-osgi-compiler-plugin</artifactId>
        			<configuration>
        				<compilerId>jdt</compilerId>
        				<executable>/opt/java/j2sdk1.4.2_19/bin/java</executable>
        				<fork>true</fork>
        			</configuration>
        		</plugin>
        	</plugins>
        </pluginManagement>
        

        Note: java must be used as executable, not javac.

        There is still the question how to configure this. I'm really into Jans proposal to use properties like $

        {J2SE-1.4}

        /$

        {J2SE-1.5}

        /$

        {JavaSE-1.6}

        for that.

        Show
        Bernd Vogt added a comment - Attached a patch that suggests how forking could be realized. The patch is based on the sources of Tycho 0.10.0. Configuration: <pluginManagement> <plugins> <plugin> <groupId>org.sonatype.tycho</groupId> <artifactId>maven-osgi-compiler-plugin</artifactId> <configuration> <compilerId>jdt</compilerId> <executable>/opt/java/j2sdk1.4.2_19/bin/java</executable> <fork> true </fork> </configuration> </plugin> </plugins> </pluginManagement> Note: java must be used as executable, not javac . There is still the question how to configure this. I'm really into Jans proposal to use properties like $ {J2SE-1.4} /$ {J2SE-1.5} /$ {JavaSE-1.6} for that.
        Hide
        Jan Sievers added a comment -
        Show
        Jan Sievers added a comment - now tracked in https://bugs.eclipse.org/bugs/show_bug.cgi?id=362966

          People

          • Assignee:
            Jan Sievers
            Reporter:
            Bernd Vogt
            Last Updated By:
            Jan Sievers
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Date of First Response: