Build failed in Jenkins: JClouds » jclouds #112

2024-04-24 Thread Apache Jenkins Server 
See 


Changes:

[Andrew Gaul] JCLOUDS-1637: Use glassfish jaxb implementation


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on builds37 (ubuntu) in workspace 

The recommended git tool is: NONE
No credentials specified
 > git rev-parse --resolve-git-dir 
 >  # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://gitbox.apache.org/repos/asf/jclouds.git 
 > # timeout=10
Fetching upstream changes from https://gitbox.apache.org/repos/asf/jclouds.git
 > git --version # timeout=10
 > git --version # 'git version 2.34.1'
 > git fetch --tags --force --progress -- 
 > https://gitbox.apache.org/repos/asf/jclouds.git 
 > +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision c73660dac8303266d875a4fabe63cc731ebdd437 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f c73660dac8303266d875a4fabe63cc731ebdd437 # timeout=10
Commit message: "JCLOUDS-1637: Use glassfish jaxb implementation"
 > git rev-list --no-walk d733401ce7d8817228f7b5a8ed3cdfe38745b207 # timeout=10
[EnvInject] - Executing scripts and injecting environment variables after the 
SCM step.
[EnvInject] - Injecting as environment variables the properties content 
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8

[EnvInject] - Variables injected successfully.
Parsing POMs
Modules changed, recalculating dependency graph
Established TCP socket on 43353
maven35-agent.jar already up to date
maven35-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[jclouds] $ /home/jenkins/tools/java/latest1.8/bin/java -cp 
/home/jenkins/jenkins-agent/maven35-agent.jar:/home/jenkins/tools/maven/apache-maven-3.5.4/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.5.4/conf/logging
 jenkins.maven3.agent.Maven35Main /home/jenkins/tools/maven/apache-maven-3.5.4 
/home/jenkins/jenkins-agent/agent.jar 
/home/jenkins/jenkins-agent/maven35-interceptor.jar 
/home/jenkins/jenkins-agent/maven3-interceptor-commons.jar 43353
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher has been compiled by a more recent version of the Java 
Runtime (class file version 55.0), this version of the Java Runtime only 
recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:136)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:66)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:459)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:404)
at hudson.slaves.Channels.forProcess(Channels.java:121)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:298)
at hudson.maven.ProcessCache.get(ProcessCache.java:237)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:802)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:526)
at hudson.model.Run.execute(Run.java:1841)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at hudson.model.Executor.run(Executor.java:442)

[jira] [Commented] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath

2024-04-24 Thread ASF subversion and git services (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840407#comment-17840407
 ] 

ASF subversion and git services commented on JCLOUDS-1637:
--

Commit c73660dac8303266d875a4fabe63cc731ebdd437 in jclouds's branch 
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=c73660dac8 ]

JCLOUDS-1637: Use glassfish jaxb implementation

Required by jakarta.xml.bind-api.


> JClouds does not work with Jakarta XML bind on classpath
> 
>
> Key: JCLOUDS-1637
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.6.0
>Reporter: Philipp Nanz
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.6.1
>
>
> This is kind-of a follow up to JCLOUDS-1627:
> When you have Spring Boot 3.2 powered environment/classpath, JClouds will 
> fail to start with {{{}java.lang.NoClassDefFoundError: 
> javax/xml/bind/JAXBException{}}}.
> The issue basically stems from 
> https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
>  which is still pointing to {{javax.xml.bind}} classes.
> The most simplistic solution probably would be to just replace the package 
> names with {{{}jakarta.xml.bind{}}}.
> However, if you want to continue supporting {{{}javax.xml.bind{}}}, a 
> possible solution would be to have two different XMLParser implementations 
> and then load either of them, depending on which JAXB variant is available on 
> the classpath.
> For reference, I have created a simple demo application that showcases the 
> problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]
> Thanks in advance for looking into it!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Build failed in Jenkins: JClouds » jclouds #111

2024-04-24 Thread Apache Jenkins Server 
See 


Changes:

[Andrew Gaul] JCLOUDS-1637: Replace java.xml.bind uses

[Andrew Gaul] Set version to 2.6.1-SNAPSHOT


--
Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on builds37 (ubuntu) in workspace 

The recommended git tool is: NONE
No credentials specified
Cloning the remote Git repository
Cloning repository https://gitbox.apache.org/repos/asf/jclouds.git
 > git init  # 
 > timeout=10
Fetching upstream changes from https://gitbox.apache.org/repos/asf/jclouds.git
 > git --version # timeout=10
 > git --version # 'git version 2.34.1'
 > git fetch --tags --force --progress -- 
 > https://gitbox.apache.org/repos/asf/jclouds.git 
 > +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git config remote.origin.url https://gitbox.apache.org/repos/asf/jclouds.git 
 > # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
Avoid second fetch
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision d733401ce7d8817228f7b5a8ed3cdfe38745b207 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f d733401ce7d8817228f7b5a8ed3cdfe38745b207 # timeout=10
Commit message: "Set version to 2.6.1-SNAPSHOT"
 > git rev-list --no-walk da1bc06f9efb626c03eb3119e9c77adf5b12f179 # timeout=10
[EnvInject] - Executing scripts and injecting environment variables after the 
SCM step.
[EnvInject] - Injecting as environment variables the properties content 
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8

[EnvInject] - Variables injected successfully.
Parsing POMs
Modules changed, recalculating dependency graph
Established TCP socket on 41881
maven35-agent.jar already up to date
maven35-interceptor.jar already up to date
maven3-interceptor-commons.jar already up to date
[jclouds] $ /home/jenkins/tools/java/latest1.8/bin/java -cp 
/home/jenkins/jenkins-agent/maven35-agent.jar:/home/jenkins/tools/maven/apache-maven-3.5.4/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.5.4/conf/logging
 jenkins.maven3.agent.Maven35Main /home/jenkins/tools/maven/apache-maven-3.5.4 
/home/jenkins/jenkins-agent/agent.jar 
/home/jenkins/jenkins-agent/maven35-interceptor.jar 
/home/jenkins/jenkins-agent/maven3-interceptor-commons.jar 41881
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
hudson/remoting/Launcher has been compiled by a more recent version of the Java 
Runtime (class file version 55.0), this version of the Java Runtime only 
recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:401)
at 
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
at 
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:136)
at jenkins.maven3.agent.Maven35Main.main(Maven35Main.java:66)
ERROR: Failed to parse POMs
java.io.EOFException: unexpected stream termination
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:459)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:404)
at hudson.slaves.Channels.forProcess(Channels.java:121)
at 
hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:298)
at hudson.maven.ProcessCache.get(ProcessCache.java:237)
at 
hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:802)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:526)
at hudson.model.Run.execute(Run.java:1841)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:543)
at hudson.model.ResourceController.execute(ResourceController.java:101)
at

[jira] [Resolved] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath

2024-04-24 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1637.
--
Fix Version/s: 2.6.1
   Resolution: Fixed

Please wait a few hours for CI then test 2.6.1-SNAPSHOT.  I wonder if there are 
any other stale javax references?  For example s3 has 
javax.xml.parsers.DocumentBuilderFactory.

> JClouds does not work with Jakarta XML bind on classpath
> 
>
> Key: JCLOUDS-1637
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.6.0
>Reporter: Philipp Nanz
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.6.1
>
>
> This is kind-of a follow up to JCLOUDS-1627:
> When you have Spring Boot 3.2 powered environment/classpath, JClouds will 
> fail to start with {{{}java.lang.NoClassDefFoundError: 
> javax/xml/bind/JAXBException{}}}.
> The issue basically stems from 
> https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
>  which is still pointing to {{javax.xml.bind}} classes.
> The most simplistic solution probably would be to just replace the package 
> names with {{{}jakarta.xml.bind{}}}.
> However, if you want to continue supporting {{{}javax.xml.bind{}}}, a 
> possible solution would be to have two different XMLParser implementations 
> and then load either of them, depending on which JAXB variant is available on 
> the classpath.
> For reference, I have created a simple demo application that showcases the 
> problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]
> Thanks in advance for looking into it!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath

2024-04-24 Thread Andrew Gaul (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul updated JCLOUDS-1637:
-
Issue Type: Improvement  (was: Bug)

> JClouds does not work with Jakarta XML bind on classpath
> 
>
> Key: JCLOUDS-1637
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
> Project: jclouds
>  Issue Type: Improvement
>  Components: jclouds-core
>Affects Versions: 2.6.0
>Reporter: Philipp Nanz
>Assignee: Andrew Gaul
>Priority: Major
>
> This is kind-of a follow up to JCLOUDS-1627:
> When you have Spring Boot 3.2 powered environment/classpath, JClouds will 
> fail to start with {{{}java.lang.NoClassDefFoundError: 
> javax/xml/bind/JAXBException{}}}.
> The issue basically stems from 
> https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
>  which is still pointing to {{javax.xml.bind}} classes.
> The most simplistic solution probably would be to just replace the package 
> names with {{{}jakarta.xml.bind{}}}.
> However, if you want to continue supporting {{{}javax.xml.bind{}}}, a 
> possible solution would be to have two different XMLParser implementations 
> and then load either of them, depending on which JAXB variant is available on 
> the classpath.
> For reference, I have created a simple demo application that showcases the 
> problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]
> Thanks in advance for looking into it!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath

2024-04-24 Thread ASF subversion and git services (Jira) 


[ 
https://issues.apache.org/jira/browse/JCLOUDS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840401#comment-17840401
 ] 

ASF subversion and git services commented on JCLOUDS-1637:
--

Commit 7a438ceebdc298a707d4ce8e1ec22bea2834bf3d in jclouds's branch 
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=7a438ceebd ]

JCLOUDS-1637: Replace java.xml.bind uses


> JClouds does not work with Jakarta XML bind on classpath
> 
>
> Key: JCLOUDS-1637
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 2.6.0
>Reporter: Philipp Nanz
>Assignee: Andrew Gaul
>Priority: Major
>
> This is kind-of a follow up to JCLOUDS-1627:
> When you have Spring Boot 3.2 powered environment/classpath, JClouds will 
> fail to start with {{{}java.lang.NoClassDefFoundError: 
> javax/xml/bind/JAXBException{}}}.
> The issue basically stems from 
> https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
>  which is still pointing to {{javax.xml.bind}} classes.
> The most simplistic solution probably would be to just replace the package 
> names with {{{}jakarta.xml.bind{}}}.
> However, if you want to continue supporting {{{}javax.xml.bind{}}}, a 
> possible solution would be to have two different XMLParser implementations 
> and then load either of them, depending on which JAXB variant is available on 
> the classpath.
> For reference, I have created a simple demo application that showcases the 
> problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]
> Thanks in advance for looking into it!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath

2024-04-24 Thread Philipp Nanz (Jira) 


 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Philipp Nanz updated JCLOUDS-1637:
--
Description: 
This is kind-of a follow up to JCLOUDS-1627:

When you have Spring Boot 3.2 powered environment/classpath, JClouds will fail 
to start with {{{}java.lang.NoClassDefFoundError: 
javax/xml/bind/JAXBException{}}}.

The issue basically stems from 
https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
 which is still pointing to {{javax.xml.bind}} classes.

The most simplistic solution probably would be to just replace the package 
names with {{{}jakarta.xml.bind{}}}.

However, if you want to continue supporting {{{}javax.xml.bind{}}}, a possible 
solution would be to have two different XMLParser implementations and then load 
either of them, depending on which JAXB variant is available on the classpath.

For reference, I have created a simple demo application that showcases the 
problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]

Thanks in advance for looking into it!

  was:
This is kind-of a follow up to JCLOUDS-1627: 

When you have Spring Boot 3.2 powered environment/classpath, JClouds will fail 
to start with {{java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException}}.

The issue basically stems from 
[https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java|JAXBParser.java],
 which is still pointing to {{javax.xml.bind}} classes.

The most simplistic solution probably would be to just replace the package 
names with {{jakarta.xml.bind}}.

However, if you want to continue supporting {{javax.xml.bind}}, a possible 
solution would be to have two different XMLParser implementations and then load 
either of them, depending on which JAXB variant is available on the classpath.

For reference, I have created a simple demo application that showcases the 
problem: https://github.com/philippn/jclouds-vs-jakarta-xml-bind

Thanks in advance for looking into it!


> JClouds does not work with Jakarta XML bind on classpath
> 
>
> Key: JCLOUDS-1637
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-core
>Affects Versions: 2.6.0
>Reporter: Philipp Nanz
>Assignee: Andrew Gaul
>Priority: Major
>
> This is kind-of a follow up to JCLOUDS-1627:
> When you have Spring Boot 3.2 powered environment/classpath, JClouds will 
> fail to start with {{{}java.lang.NoClassDefFoundError: 
> javax/xml/bind/JAXBException{}}}.
> The issue basically stems from 
> https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
>  which is still pointing to {{javax.xml.bind}} classes.
> The most simplistic solution probably would be to just replace the package 
> names with {{{}jakarta.xml.bind{}}}.
> However, if you want to continue supporting {{{}javax.xml.bind{}}}, a 
> possible solution would be to have two different XMLParser implementations 
> and then load either of them, depending on which JAXB variant is available on 
> the classpath.
> For reference, I have created a simple demo application that showcases the 
> problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]
> Thanks in advance for looking into it!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath

2024-04-24 Thread Philipp Nanz (Jira) 
Philipp Nanz created JCLOUDS-1637:
-

 Summary: JClouds does not work with Jakarta XML bind on classpath
 Key: JCLOUDS-1637
 URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
 Project: jclouds
  Issue Type: Bug
  Components: jclouds-core
Affects Versions: 2.6.0
Reporter: Philipp Nanz
Assignee: Andrew Gaul


This is kind-of a follow up to JCLOUDS-1627: 

When you have Spring Boot 3.2 powered environment/classpath, JClouds will fail 
to start with {{java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException}}.

The issue basically stems from 
[https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java|JAXBParser.java],
 which is still pointing to {{javax.xml.bind}} classes.

The most simplistic solution probably would be to just replace the package 
names with {{jakarta.xml.bind}}.

However, if you want to continue supporting {{javax.xml.bind}}, a possible 
solution would be to have two different XMLParser implementations and then load 
either of them, depending on which JAXB variant is available on the classpath.

For reference, I have created a simple demo application that showcases the 
problem: https://github.com/philippn/jclouds-vs-jakarta-xml-bind

Thanks in advance for looking into it!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)