ec2-api-tools comes with a lot of bundled dependencies; half were found in the Portage tree, the other half needs additional packages to be added to the Portage tree. The following packages were found and used as a dependency: dev-java/bcprov:0 dev-java/commons-cli:1 dev-java/commons-codec:0 dev-java/commons-discovery:0 dev-java/commons-httpclient:3 dev-java/commons-logging:0 dev-java/jaxb:2 dev-java/jax-ws:2 dev-java/jdom:1.0 dev-java/log4j:0 dev-java/wsdl4j:0 dev-java/xalan:0 dev-java/xalan-serializer:0 dev-java/xerces:2 dev-libs/xmlsec:0 java-virtuals/stax-api:0 The following jars have a bug filed: wss4j-1.5.3.jar: bug #168284 The following jars currently have no bug filed as far as I can see: activation-1.1.jar AWSEC2JavaClient-1.2ux.jar AWSJavaClientRuntime-1.1.jar BlockDeviceLib-1.0.jar ec2-api-tools-1.6.7.2.jar EC2CltJavaClient-1.0.jar EC2ConversionLib-1.0.jar EC2WsdlJavaClient-1.0.jar httpclient-4.2.jar HttpClientSslContrib-1.0.jar httpcore-4.2.jar j2ee_mail.jar java-xmlbuilder-0.4.jar jets3t-0.9.0.jar jets3t-gui-0.9.0.jar woodstox-core-asl-4.0.5.jar xfire-all-1.2.6.jar xfire-jsr181-api-1.0-M1.jar xml-apis.jar XmlSchema-1.4.5.jar Besides that, the ebuild could be brought a little more up to Java standards.
virtual/stax-api:0 temporarily replaced by dev-java/jsr173:0, although we probably should get dev-java/stax2-api::java iff that's a proper ebuild (version numbers in package names often are no good).
dev-libs/xmlsec:0 doesn't install *.jar file, therefore I removed it again in favour of the bundled dependency; we probably need to either request a java USE flag to be added to this package or create a dev-java/xmlsec package.
Given there is a ec2-api-tools-1.6.7.2.jar I think this package should be renamed to -bin or removed as per Java policy. I've added this revision as unkeyworded since it heavily breaks things. This can likely be helped a bit by replacing all the wrappers by Java wrappers and doing furher investigations on mismatches between system and bundled. $ ec2-cmd Error: Could not find or load main class com.amazon.aes.webservices.client.cmd. $ ec2-copy-image Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/httpclient/ConnectTimeoutException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2451) at java.lang.Class.getMethod0(Class.java:2694) at java.lang.Class.getMethod(Class.java:1622) at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486) Caused by: java.lang.ClassNotFoundException: org.apache.commons.httpclient.ConnectTimeoutException at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 6 more + 31 May 2013; Tom Wijsman <TomWij@gentoo.org> +ec2-api-tools-1.6.7.2-r2.ebuild: + Unbundled half of the libraries, the other half is missing, committed as + unkeyworded since this is a work in progress and breaks a lot of things; + reported by robbat2 on IRC, tracked in bug #471942.
Over the night I realized that the symlinks were accidentally installed to /! It appears to work fine again if I correct this mistake. We can proceed with further library unbundling and correcting the ebuild... + 01 Jun 2013; Tom Wijsman <TomWij@gentoo.org> +ec2-api-tools-1.6.7.2-r3.ebuild, + -ec2-api-tools-1.6.7.2-r2.ebuild: + Revision bump, keyworded again and removed broken revision. Library symlinks + were accidentally installed to /, also corrected a remaining EC2_HOME related + error...
(In reply to Tom Wijsman (TomWij) from comment #1) > virtual/stax-api:0 temporarily replaced by dev-java/jsr173:0, although we > probably should get dev-java/stax2-api::java iff that's a proper ebuild > (version numbers in package names often are no good). jsr173 is stax as found in java 6 and later for which we have the virtual stax-api. Stax2 is rather different. The 2 in it's name isn't meant to denote a version but kind a different project. Summa summarum, if jsr173 does the trick so should stax-api. activation.jar -> java-virtuals/jaf xml-apis.jar -> dev-java/xml-commons-external
(In reply to Tom Wijsman (TomWij) from comment #2) > dev-libs/xmlsec:0 doesn't install *.jar file, therefore I removed it again > in favour of the bundled dependency; we probably need to either request a > java USE flag to be added to this package or create a dev-java/xmlsec > package. Aren't this different upstreams to begin with?
(In reply to Ralph Sennhauser from comment #5) > (In reply to Tom Wijsman (TomWij) from comment #1) > > virtual/stax-api:0 temporarily replaced by dev-java/jsr173:0, although we > > probably should get dev-java/stax2-api::java iff that's a proper ebuild > > (version numbers in package names often are no good). > > jsr173 is stax as found in java 6 and later for which we have the virtual > stax-api. Stax2 is rather different. The 2 in it's name isn't meant to > denote a version but kind a different project. Summa summarum, if jsr173 > does the trick so should stax-api. Okay, but Stax2 isn't in tree and likely should be brought into Portage tree. As for virtuals in general, how do I obtain the jar path in that case? The reason I temporarily replaced because I couldn't obtain the jar path, I forgot to mention that in the above comment apparently; I can't seem to get java-pkg_getjar to do. I'll see what dropping stax does to running the applications as to see whether to see if the stax actually satisfies it (I want to provoke missing class errors); in the long run we can switch to properly depend on Stax2. > activation.jar -> java-virtuals/jaf > xml-apis.jar -> dev-java/xml-commons-external Thanks. (In reply to Ralph Sennhauser from comment #6) > (In reply to Tom Wijsman (TomWij) from comment #2) > > dev-libs/xmlsec:0 doesn't install *.jar file, therefore I removed it again > > in favour of the bundled dependency; we probably need to either request a > > java USE flag to be added to this package or create a dev-java/xmlsec > > package. > > Aren't this different upstreams to begin with? Indeed. http://www.aleksey.com/xmlsec/ http://santuario.apache.org/ I found its package name (dev-java/xml-security) in bug #435256, it appears we only have this available in overlays; so this probably needs to be brought into the Portage tree as well.
(In reply to Tom Wijsman (TomWij) from comment #7) > (In reply to Ralph Sennhauser from comment #5) > > (In reply to Tom Wijsman (TomWij) from comment #1) > > > virtual/stax-api:0 temporarily replaced by dev-java/jsr173:0, although we > > > probably should get dev-java/stax2-api::java iff that's a proper ebuild > > > (version numbers in package names often are no good). > > > > jsr173 is stax as found in java 6 and later for which we have the virtual > > stax-api. Stax2 is rather different. The 2 in it's name isn't meant to > > denote a version but kind a different project. Summa summarum, if jsr173 > > does the trick so should stax-api. > > Okay, but Stax2 isn't in tree and likely should be brought into Portage tree. If something needs it, yes. > As for virtuals in general, how do I obtain the jar path in that case? If the java runtime is one possible provider there won't be a separate jar. Rewriting the classpath and adding the virtual to EANT_GENTOO_CLASSPATH will do the right thing tho. > (In reply to Ralph Sennhauser from comment #6) > > (In reply to Tom Wijsman (TomWij) from comment #2) > > > dev-libs/xmlsec:0 doesn't install *.jar file, therefore I removed it again > > > in favour of the bundled dependency; we probably need to either request a > > > java USE flag to be added to this package or create a dev-java/xmlsec > > > package. > > > > Aren't this different upstreams to begin with? > > Indeed. > > http://www.aleksey.com/xmlsec/ > http://santuario.apache.org/ > > I found its package name (dev-java/xml-security) in bug #435256, it appears > we only have this available in overlays; so this probably needs to be > brought into the Portage tree as well. Yes, looks like dmol overlay has a recent version thereof.
fiddling with ~amd64 updates that weren't working tonight (until giving up and going back to 1.6.0.1-r1) but discovered the dev-java/wstx ("woodstox") package already contains org.codehaus.stax2... http://woodstox.codehaus.org/3.2.3/javadoc/org/codehaus/stax2/package-summary.html
I ran into this too, today, with ec2-api-tools-1.7.6.2-r4 on ~amd64. jsr173 doesn't really satisfy the requirement (it's not the same as stax2), so we get a: Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/stax2/XMLInputFactory2 You can see if your run "jar tf" on the two jars that the contents are not the same. Fell back to ec2-api-tools-1.7.6.2 and things work fine (because the library is really in there, and not symlinked like in r4).
# Tom Wijsman <TomWij@gentoo.org> (18 Sep 2013) # Temporarily masked due to QA issue during attempts to unbundle dependencies; # we need to check the jar contents to check for differences, especially the # stax dependency seems to be problematic in this regard but we'll check all of # them to ensure that unbundling doesn't hurt some missed functionality. # Bug #471942 tracks the progress of these unbundling efforts. >=app-admin/ec2-api-tools-1.6.7.2-r4
Tom, just FYI. I got bitten by the bugs in -r4. ec2-run-instances didn't work anymore: Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/stax2/XMLInputFactory2 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:792) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at javax.xml.stream.FactoryFinder.getProviderClass(FactoryFinder.java:118) at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:179) at javax.xml.stream.FactoryFinder.findJarServiceProvider(FactoryFinder.java:367) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:289) at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:213) at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:153) at org.codehaus.xfire.util.STAXUtils.<clinit>(STAXUtils.java:48) at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:54) at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.getByteArrayRequestEntity(CommonsHttpMessageSender.java:422) at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:360) at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123) at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48) at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79) at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114) at org.codehaus.xfire.client.Client.invoke(Client.java:336) at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77) at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57) at com.sun.proxy.$Proxy12.runInstances(Unknown Source) at com.amazon.aes.webservices.client.Jec2Impl.runInstances(Jec2Impl.java:1252) at com.amazon.aes.webservices.client.cmd.RunInstances.invokeOnline(RunInstances.java:461) at com.amazon.aes.webservices.client.cmd.BaseCmd.invoke(BaseCmd.java:1040) at com.amazon.aes.webservices.client.cmd.RunInstances.main(RunInstances.java:520) Caused by: java.lang.ClassNotFoundException: org.codehaus.stax2.XMLInputFactory2 at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 36 more
Does -r5 revision work?
CCing treecleaners
I'm in favour of masking this package altogether. Nobody seems to care about it and neither do I, to be honest. Unless someone steps up before this week-end, I will mask it.
commit 9f4a307 (HEAD, master) Author: Patrice Clement <monsieurp@gentoo.org> Date: Sun Feb 7 10:56:35 2016 +0000 app-admin/ec2-api-tools: Removal. Fixes bug 471942. delete mode 100644 app-admin/ec2-api-tools/Manifest delete mode 100644 app-admin/ec2-api-tools/ec2-api-tools-1.6.7.2-r5.ebuild delete mode 100644 app-admin/ec2-api-tools/metadata.xml
