✅ add support for Windows#48
Conversation
|
@ryandens this PR seems a bit stuck. Would you like some assistance? I'd gladly help to move it forward. |
31ef87d to
b6917f3
Compare
|
@neboskreb feel free! i just rebased it with main. I don't have a windows machine accessible, so getting the integration tests to pass on windows is a bit painful. |
|
I fixed a couple of very small bugs and it seems to work for me. @ryandens I'd push my changes if you add me to the collaborators |
|
My investigation finds that the test failures in #298 come from Unfortunately, the exact cause of the exception is not know because This error occurs only in Bumping up the version from Also, no errors occur in @ryandens This looks to me like an Open Telemetry setup issue on Windows (or my machine?). Unfortunately, I'm not familiar with the framework. If you are, could you give me some hints to what could be wrong? |
|
Unfortunately, I also don't know what the issue was here - I also saw test failures in the |
264bf47 to
38951ec
Compare
38951ec to
2586352
Compare
|
@macroscope-app review |
|
Manual reviews triggered for commit All prior checks · these links stay valid even if you push more commits. |
|
Review started! I'm analyzing the pull request and will post feedback through check runs when complete. |
… test On Windows a `.bat` file is not a directly executable image, so Gradle's Exec task (which uses ProcessBuilder/CreateProcess) fails to launch it with "A problem occurred starting process 'command '.\hello-world.bat''". Route the generated distribution start script through the command interpreter (`cmd /c hello-world.bat`) on Windows while keeping `./hello-world` on Unix. Fixes the 3 execStartScript-based functional tests on windows-latest. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Unix start script relies on shell word-splitting of the unquoted $DEFAULT_JVM_OPTS, so FakeTransformer collapses the individually-quoted JVM opts into one space-separated string. On Windows the batch script does not word-split inside quotes, so collapsing them glued `-Xmx256m` onto the `-javaagent:` path, producing an invalid argument and making `java` (and thus execStartScript) exit non-zero for distributions with an agent. Skip the collapse on Windows so each opt stays its own quoted token, e.g. set DEFAULT_JVM_OPTS="-javaagent:%APP_HOME%\agent-libs\x.jar" "-Xmx256m" Fixes the two agent-bearing execStartScript functional tests on windows-latest. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The no-agent removal relied on the Unix opt-collapsing to turn the placeholder into an unquoted `-javaagent:...PLACEHOLDER.jar ` substring. On Windows each opt stays its own quoted token, so removing only the unquoted placeholder left `DEFAULT_JVM_OPTS="" "-Xmx256m"`, and the empty first argument made `java` (execStartScript) fail. Also strip the surrounding quotes and trailing space of the Windows-style `"-javaagent:...PLACEHOLDER.jar"` token so an agent-free distribution produces `set DEFAULT_JVM_OPTS="-Xmx256m"`. Unix output is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Windows-only quoting in JavaForkOptionsConfigurer wrapped the agent path in literal double quotes. The JVM launches fine (the Windows C runtime strips the outer quotes when parsing the command line), but agents that re-derive their own jar location get the still-quoted path: the OpenTelemetry agent's premain throws IllegalArgumentException from appendToBootstrapClassLoaderSearch, so its VersionLogger line never prints and the two run/test functional tests fail on windows-latest. The quoting is also unnecessary: these arguments are passed straight to a forked JVM via ProcessBuilder (no shell), which already quotes arguments containing spaces. Drop the manual quoting for all platforms. Also reverts the temporary showStandardStreams diagnostic logging. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
OpenTelemetry javaagent 1.11.1 fails to load on Windows: its premain throws IllegalArgumentException from appendToBootstrapClassLoaderSearch (an old bug in how it locates its own bootstrap jar), so it never logs its version banner. The `can attach to test task` and `can attach two agents` tests assert on that banner, so they failed on windows-latest. Bump those tests to 1.30.0, which logs its version banner on Windows -- the same version the `can handle upgrade` distribution test already exercises successfully there. Also removes the temporary showStandardStreams diagnostic logging. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JavaagentApplicationRunPlugin configured the run task's -javaagent args via a CommandLineArgumentProvider but never registered the javaagent configuration as a task input, so Gradle established no dependency on the tasks that build the agent jars. Under parallel execution the run task could launch with -javaagent:simple-agent.jar before :simple-agent:jar had run, failing with "Error opening zip file or JAR manifest missing" (reproducible 100% with --rerun-tasks, and intermittently on CI). Register the configuration as an input (a Configuration is Buildable), the same way JavaagentApplicationDistributionPlugin already does, so the agent jars are built before the run task launches. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…te PR) The inputs.files/dependsOn wiring added to JavaagentApplicationRunPlugin to fix the run-task build-ordering race also surfaced a pre-existing missing dependency in the otel example (:app:run consuming :app:extendedAgent output without a declared dependency), failing :otel:functionalTest validation. Revert to keep this PR focused on Windows support; the run-task ordering race will be addressed separately. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The OpenTelemetry agent locates its own jar from the -javaagent path the JVM was given, then appends it to the bootstrap classloader search. On the Windows CI runner the Gradle caches sit behind a symlink/junction, so getCanonicalPath() resolved to a path whose round-trip through the agent's jar-location logic produced a name that appendToBootstrapClassLoaderSearch rejected with IllegalArgumentException -- the agent then bailed out before logging its version banner, failing the run/test functional tests on windows-latest. Switch to getAbsolutePath(), the same unresolved form the distribution start scripts already use successfully on Windows. Also drops the now-unnecessary IOException handling. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `can attach to test task` and `can attach two agents` tests attach the
OpenTelemetry javaagent from the TestKit's Gradle cache. That cache lives under
the deeply nested build/tmp/functionalTest/work/.gradle-test-kit, so on the
Windows CI runner the agent jar path
D:\a\...\.gradle-test-kit\caches\modules-2\files-2.1\io.opentelemetry.javaagent\
opentelemetry-javaagent\<ver>\<sha1>\opentelemetry-javaagent-<ver>.jar
was 267 characters -- past Windows' 260-char MAX_PATH. The JVM's native
appendToBootstrapClassLoaderSearch rejects such paths with
IllegalArgumentException, so the agent bailed out before logging its version
banner. simple-agent (121 chars) and the distribution start scripts (which copy
the agent into a short agent-libs/ path) were unaffected, and Linux has no such
limit -- which is why the failure was Windows-only and independent of the agent
version or path canonicalization.
Root the TestKit Gradle home at the drive root on Windows so the cached agent
jar path stays well within MAX_PATH.
Also reverts the temporary diagnostics and the speculative JavaForkOptionsConfigurer
changes (restored to the main baseline), which were not the cause.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Platform now carries a defaultJvmOptsMapper (noop on Windows, collapse on Unix) and an agentArgSeparator, so JavaagentAwareStartScriptGenerator composes platform behavior instead of branching on `platform == Platform.WINDOWS`. - Document what Fake.write does (rewrites/removes the javaagent placeholder in the rendered start script). - Drop the org.apache.commons:commons-text test dependency; its only remaining use was escaping JAVA_HOME for the generated Groovy build script, now done with a small inline backslash/quote escape. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
5422d5e to
54dca34
Compare
Add Windows support to javaagent application distribution plugin
Platformenum with per-platform constants (line separator, path separator, app home variable, JVM opts format) for Unix and Windows.JavaagentAwareStartScriptGeneratorto accept aPlatformparameter, generating correct-javaagentpaths andDEFAULT_JVM_OPTSformat for each OS.JavaagentApplicationDistributionPluginto useJavaagentAwareStartScriptGeneratorfor both Unix and Windows, replacing the previous no-opWindowsStartScriptGenerator.gradle.ymlnow runs builds on bothubuntu-latestandwindows-latest.MAX_PATHissues.-javaagentoptions using%APP_HOME%paths and quoted JVM opt tokens; previously Windows scripts had no javaagent support.Macroscope summarized 54dca34.