• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Maven
    • None
    • 0
    • 2
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Summary

      Maven comes with a library called Jansi. Jansi attempts to extract libraries to a temporary directory by checking jansi.tmpdir. If that property isn't set it attempts to use java.io.tmpdir instead (https://github.com/fusesource/jansi/blob/2cf446182c823a4c110411b765a1f0367eb8a913/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L79). Jansi is not picking up the java.io.tmpdir that's added to the Maven command by Bamboo because java.io.tmpdir is set as a user property. That property eventually gets promoted to a system property (https://github.com/apache/maven/blob/35b93b0a589752cc88105623a2ddf9e52b56c1ce/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1783-L1793) but Jansi uses static methods that are run before Maven has a chance to set that promoted property so the files end up going to /tmp.

      This won't necessarily break your builds but it may start generating a lot of warnings in your build logs if Jansi is not able to write to the /tmp folder. One reason for that could be if the /tmp directory has been mounted with a noexec flag. For example:

      Failed to load native library:jansi-2.4.0-8248ee3780e1fb9a-libjansi.so. The native library file at /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64
      java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: failed to map segment from shared object
      

      Suggestion

      Update the Bamboo Maven task to account for Jansi and a potential change to the Maven code https://github.com/fusesource/jansi/issues/241#issuecomment-1242330210. It looks like Maven will stop promoting user properties to system properties in the near future. This can potentially break the Bamboo Maven task so we need to be prepared for it.

      Workaround

      One way to workaround the problem within Bamboo is to make use of the MAVEN_OPTS properties in the Maven task's Environment variables field and set it to MAVEN_OPTS=-Djansi.tmpdir=/path/to/tmp. This way you can customize the tmp directory used by Jansi to prevent it from trying to write to /tmp.

      • You can also use MAVEN_OPTS=-Djava.io.tmpdir=/path/to/tmp in the Environment variables field but this shouldn't really be necessary (at least for now while Maven is still promoting user properties to system properties) since Maven is picking up the tmp directory correctly. Setting -Djansi.tmpdir should be enough to workaround the problem and get rid of the warning messages in your build logs.

            [BAM-21888] Update the way Bamboo sets java.io.tmpdir in Maven tasks

            SET Analytics Bot made changes -
            Support reference count New: 2
            SET Analytics Bot made changes -
            UIS Original: 1 New: 0
            SET Analytics Bot made changes -
            UIS Original: 0 New: 1
            SET Analytics Bot made changes -
            UIS Original: 1 New: 0
            SET Analytics Bot made changes -
            UIS New: 1
            Daniel W made changes -
            Remote Link New: This issue links to "Page (Confluence)" [ 693035 ]
            Bruno Rosa made changes -
            Description Original: h4. Summary

            Maven comes with a library called [Jansi|https://github.com/fusesource/jansi]. Jansi attempts to extract libraries to a temporary directory by checking jansi.tmpdir. If that property isn't set it attempts to use java.io.tmpdir instead ([https://github.com/fusesource/jansi/blob/2cf446182c823a4c110411b765a1f0367eb8a913/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L79]). Jansi is not picking up the java.io.tmpdir that's added to the Maven command by Bamboo because java.io.tmpdir is set a user property. That property eventually gets promoted to a system property ([https://github.com/apache/maven/blob/35b93b0a589752cc88105623a2ddf9e52b56c1ce/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1783-L1793]) but Jansi uses static methods that are run before Maven has a chance to set that promoted property so the files end up going to /tmp.

            This won't necessarily break your builds but it may start generating a lot of warnings in your build logs if Jansi is not able to write to the /tmp folder. One reason for that could be if the /tmp directory has been mounted with a *noexec* flag. For example:
            {noformat}
            Failed to load native library:jansi-2.4.0-8248ee3780e1fb9a-libjansi.so. The native library file at /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64
            java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: failed to map segment from shared object
            {noformat}
            h4. Suggestion

            Update the Bamboo Maven task to account for Jansi and a potential change to the Maven code [https://github.com/fusesource/jansi/issues/241#issuecomment-1242330210]. It looks like Maven will stop promoting user properties to system properties in the near future. This can potentially break the Bamboo Maven task so we need to be prepared for it.
            h4. Workaround

            One way to workaround the problem within Bamboo is to make use of the MAVEN_OPTS properties in the Maven task's *Environment variables* field and set it to {{MAVEN_OPTS=-Djansi.tmpdir=/path/to/tmp}}. This way you can customize the tmp directory used by Jansi to prevent it from trying to write to /tmp.
             * You can also use {{MAVEN_OPTS=-Djava.io.tmpdir=/path/to/tmp}} in the *Environment variables* field but this shouldn't really be necessary (at least for now while Maven is still promoting user properties to system properties) since Maven is picking up the tmp directory correctly. Setting *-Djansi.tmpdir* should be enough to workaround the problem and get rid of the warning messages in your build logs.
            New: h4. Summary

            Maven comes with a library called [Jansi|https://github.com/fusesource/jansi]. Jansi attempts to extract libraries to a temporary directory by checking jansi.tmpdir. If that property isn't set it attempts to use java.io.tmpdir instead ([https://github.com/fusesource/jansi/blob/2cf446182c823a4c110411b765a1f0367eb8a913/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L79]). Jansi is not picking up the java.io.tmpdir that's added to the Maven command by Bamboo because java.io.tmpdir is set as a user property. That property eventually gets promoted to a system property ([https://github.com/apache/maven/blob/35b93b0a589752cc88105623a2ddf9e52b56c1ce/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1783-L1793]) but Jansi uses static methods that are run before Maven has a chance to set that promoted property so the files end up going to /tmp.

            This won't necessarily break your builds but it may start generating a lot of warnings in your build logs if Jansi is not able to write to the /tmp folder. One reason for that could be if the /tmp directory has been mounted with a *noexec* flag. For example:
            {noformat}
            Failed to load native library:jansi-2.4.0-8248ee3780e1fb9a-libjansi.so. The native library file at /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64
            java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: failed to map segment from shared object
            {noformat}
            h4. Suggestion

            Update the Bamboo Maven task to account for Jansi and a potential change to the Maven code [https://github.com/fusesource/jansi/issues/241#issuecomment-1242330210]. It looks like Maven will stop promoting user properties to system properties in the near future. This can potentially break the Bamboo Maven task so we need to be prepared for it.
            h4. Workaround

            One way to workaround the problem within Bamboo is to make use of the MAVEN_OPTS properties in the Maven task's *Environment variables* field and set it to {{MAVEN_OPTS=-Djansi.tmpdir=/path/to/tmp}}. This way you can customize the tmp directory used by Jansi to prevent it from trying to write to /tmp.
             * You can also use {{MAVEN_OPTS=-Djava.io.tmpdir=/path/to/tmp}} in the *Environment variables* field but this shouldn't really be necessary (at least for now while Maven is still promoting user properties to system properties) since Maven is picking up the tmp directory correctly. Setting *-Djansi.tmpdir* should be enough to workaround the problem and get rid of the warning messages in your build logs.
            Bruno Rosa made changes -
            Summary Original: Improve the use of variables in maven task New: Update the way Bamboo sets java.io.tmpdir in Maven tasks
            Bruno Rosa made changes -
            Description Original: h4. Summary

            Maven comes with a library called [Jansi|https://github.com/fusesource/jansi]. Jansi attempts to extract libraries to a temporary directory by checking jansi.tmpdir. If that property isn't set it attempts to use java.io.tmpdir instead ([https://github.com/fusesource/jansi/blob/2cf446182c823a4c110411b765a1f0367eb8a913/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L79]). Jansi is not picking up the java.io.tmpdir that's added to the Maven command by Bamboo because java.io.tmpdir is set a user property. That property eventually gets promoted to a system property ([https://github.com/apache/maven/blob/35b93b0a589752cc88105623a2ddf9e52b56c1ce/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1783-L1793]) but Jansi uses static methods that are run before Maven has a chance to set that promoted property so the files end up going to /tmp.

            This won't necessarily break your builds but it may start generating a lot of warnings in your build logs if Jansi is not able to write to the /tmp folder. One reason for that could be if the /tmp directory has been mounted with a *noexec* flag. For example:
            {noformat}
            Failed to load native library:jansi-2.4.0-8248ee3780e1fb9a-libjansi.so. The native library file at /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64
            java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: failed to map segment from shared object
            {noformat}
            h4. Suggestion

            Update the Bamboo Maven task to account for Jansi and a potential change to the Maven code [https://github.com/fusesource/jansi/issues/241#issuecomment-1242330210]. It looks like Maven will stop promoting user properties to system properties in the near future. This can potentially break the Bamboo Maven task so we need to be prepared for it.
            h4. Workaround

            One way to workaround the problem within Bamboo is to make use of the MAVEN_OPTS properties in the Maven task's *Environment variables* field and set it to {{{}MAVEN_OPTS=-Djansi.tmpdir=/path/to/tmp{}}}. This way you can customize the tmp directory used by Jansi to prevent it from trying to write to /tmp.
             * You can also use 
            New: h4. Summary

            Maven comes with a library called [Jansi|https://github.com/fusesource/jansi]. Jansi attempts to extract libraries to a temporary directory by checking jansi.tmpdir. If that property isn't set it attempts to use java.io.tmpdir instead ([https://github.com/fusesource/jansi/blob/2cf446182c823a4c110411b765a1f0367eb8a913/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L79]). Jansi is not picking up the java.io.tmpdir that's added to the Maven command by Bamboo because java.io.tmpdir is set a user property. That property eventually gets promoted to a system property ([https://github.com/apache/maven/blob/35b93b0a589752cc88105623a2ddf9e52b56c1ce/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1783-L1793]) but Jansi uses static methods that are run before Maven has a chance to set that promoted property so the files end up going to /tmp.

            This won't necessarily break your builds but it may start generating a lot of warnings in your build logs if Jansi is not able to write to the /tmp folder. One reason for that could be if the /tmp directory has been mounted with a *noexec* flag. For example:
            {noformat}
            Failed to load native library:jansi-2.4.0-8248ee3780e1fb9a-libjansi.so. The native library file at /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64
            java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: failed to map segment from shared object
            {noformat}
            h4. Suggestion

            Update the Bamboo Maven task to account for Jansi and a potential change to the Maven code [https://github.com/fusesource/jansi/issues/241#issuecomment-1242330210]. It looks like Maven will stop promoting user properties to system properties in the near future. This can potentially break the Bamboo Maven task so we need to be prepared for it.
            h4. Workaround

            One way to workaround the problem within Bamboo is to make use of the MAVEN_OPTS properties in the Maven task's *Environment variables* field and set it to {{MAVEN_OPTS=-Djansi.tmpdir=/path/to/tmp}}. This way you can customize the tmp directory used by Jansi to prevent it from trying to write to /tmp.
             * You can also use {{MAVEN_OPTS=-Djava.io.tmpdir=/path/to/tmp}} in the *Environment variables* field but this shouldn't really be necessary (at least for now while Maven is still promoting user properties to system properties) since Maven is picking up the tmp directory correctly. Setting *-Djansi.tmpdir* should be enough to workaround the problem and get rid of the warning messages in your build logs.
            Bruno Rosa made changes -
            Description Original: h4. Summary

            Maven comes with a library called [Jansi|https://github.com/fusesource/jansi]. Jansi attempts to extract libraries to a temporary directory by checking jansi.tmpdir. If that property isn't set it attempts to use java.io.tmpdir instead ([https://github.com/fusesource/jansi/blob/2cf446182c823a4c110411b765a1f0367eb8a913/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L79]). Jansi is not picking up the java.io.tmpdir that's added to the Maven command by Bamboo because java.io.tmpdir is set a user property. That property eventually gets promoted to a system property ([https://github.com/apache/maven/blob/35b93b0a589752cc88105623a2ddf9e52b56c1ce/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1783-L1793]) but Jansi uses static methods that are run before Maven has a chance to set that promoted property so the files end up going to /tmp.

            This won't necessarily break your builds but it may start generating a lot of warnings in your build logs if Jansi is not able to write to the /tmp folder. One reason for that could be if the /tmp directory has been mounted with a *noexec* flag. For example:
            {noformat}
            Failed to load native library:jansi-2.4.0-8248ee3780e1fb9a-libjansi.so. The native library file at /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64
            java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: failed to map segment from shared object
            {noformat}
            h4. Suggestion

            Update the Bamboo Maven task to account for Jansi and a potential change to the Maven code [https://github.com/fusesource/jansi/issues/241#issuecomment-1242330210]. It looks like Maven will stop promoting user properties to system properties in the near future. This can potentially break the Bamboo Maven task so we need to be prepared for it.
            h4. Workaround

            One way to workaround the problem within Bamboo is to make use of the MAVEN_OPTS properties in the Maven task's *Environment variables* field and set it to {{{}MAVEN_OPTS=-Djansi.tmpdir=/path/to/tmp{}}}. This way you can customize the tmp directory used by Jansi to prevent it from trying to write to /tmp.
            New: h4. Summary

            Maven comes with a library called [Jansi|https://github.com/fusesource/jansi]. Jansi attempts to extract libraries to a temporary directory by checking jansi.tmpdir. If that property isn't set it attempts to use java.io.tmpdir instead ([https://github.com/fusesource/jansi/blob/2cf446182c823a4c110411b765a1f0367eb8a913/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L79]). Jansi is not picking up the java.io.tmpdir that's added to the Maven command by Bamboo because java.io.tmpdir is set a user property. That property eventually gets promoted to a system property ([https://github.com/apache/maven/blob/35b93b0a589752cc88105623a2ddf9e52b56c1ce/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1783-L1793]) but Jansi uses static methods that are run before Maven has a chance to set that promoted property so the files end up going to /tmp.

            This won't necessarily break your builds but it may start generating a lot of warnings in your build logs if Jansi is not able to write to the /tmp folder. One reason for that could be if the /tmp directory has been mounted with a *noexec* flag. For example:
            {noformat}
            Failed to load native library:jansi-2.4.0-8248ee3780e1fb9a-libjansi.so. The native library file at /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64
            java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: /tmp/jansi-2.4.0-8248ee3780e1fb9a-libjansi.so: failed to map segment from shared object
            {noformat}
            h4. Suggestion

            Update the Bamboo Maven task to account for Jansi and a potential change to the Maven code [https://github.com/fusesource/jansi/issues/241#issuecomment-1242330210]. It looks like Maven will stop promoting user properties to system properties in the near future. This can potentially break the Bamboo Maven task so we need to be prepared for it.
            h4. Workaround

            One way to workaround the problem within Bamboo is to make use of the MAVEN_OPTS properties in the Maven task's *Environment variables* field and set it to {{{}MAVEN_OPTS=-Djansi.tmpdir=/path/to/tmp{}}}. This way you can customize the tmp directory used by Jansi to prevent it from trying to write to /tmp.
             * You can also use 

              Unassigned Unassigned
              voseghale VICTOR-OSEGHALE (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: