Deprecating maven-plugin-cobertura
by Aleksandar Kurtakov
Hi everyone,
maven-plugin-cobertura is not named according to guidelines aka package name == upstream name (cobertura-maven-plugin http://mojo.codehaus.org/cobertura-maven-plugin/). It also failed to build in the latest mass rebuild (http://kojipkgs.fedoraproject.org//work/tasks/6330/4996330/build.log).
As I don't have any time to spend keeping it around nor it should stay named that way I think I plan to deprecated it soon. Attached is the list of packages that build require it on rawhide:
activemq-0:5.6.0-3.fc19.src
animal-sniffer-0:1.9-3.fc19.src
antlr-maven-plugin-0:2.2-8.fc19.src
apache-commons-dbcp-0:1.4-12.fc19.src
apache-commons-jci-0:1.0-7.fc19.src
apt-maven-plugin-0:1.0-0.5.alpha4.fc19.src
buildnumber-maven-plugin-0:1.2-1.fc19.src
checkstyle-0:5.6-3.fc19.src
ehcache-parent-0:2.3-4.fc19.src
ehcache-sizeof-agent-0:1.0.1-2.fc18.src
exec-maven-plugin-0:1.2.1-10.fc19.src
google-gson-0:2.2.2-4.fc19.src
javacc-maven-plugin-0:2.6-14.fc19.src
jboss-classfilewriter-0:1.0.3-3.fc19.src
jboss-common-core-0:2.2.18-9.fc19.src
jboss-ejb-3.1-api-0:1.0.2-6.fc19.src
jboss-ejb-client-0:1.0.5-5.fc19.src
jboss-iiop-client-0:1.0.0-6.fc19.src
jboss-interceptor-0:2.0.0-6.fc19.src
jboss-interceptors-1.1-api-0:1.0.2-0.5.20120319git49a904.fc19.src
jboss-invocation-0:1.1.1-6.fc19.src
jboss-jad-1.2-api-0:1.0.1-5.fc19.src
jboss-jaxrpc-1.1-api-0:1.0.1-3.fc19.src
jboss-jaxws-2.2-api-0:2.0.2-0.4.20120507gitd6937f.fc19.src
jboss-jms-1.1-api-0:1.0.1-5.fc19.src
jboss-logging-tools-0:1.0.0-5.fc19.src
jboss-logmanager-0:1.2.2-5.fc19.src
jboss-logmanager-log4j-0:1.0.0-7.fc19.src
jboss-negotiation-0:2.2.0-9.SP1.fc19.src
jboss-remote-naming-0:1.0.2-6.fc19.src
jboss-remoting-jmx-0:1.0.5-1.fc19.src
jboss-sasl-0:1.0.0-6.fc19.src
jboss-servlet-3.0-api-0:1.0.1-5.fc19.src
jboss-transaction-1.1-api-0:1.0.1-4.fc19.src
jboss-vfs-0:3.1.0-6.fc19.src
maven-anno-plugin-0:1.4.1-6.fc19.src
maven-deploy-plugin-0:2.7-3.fc18.src
maven-eclipse-plugin-0:2.9-2.fc18.src
maven-enforcer-0:1.2-4.fc19.src
maven-injection-plugin-0:1.0.2-8.fc19.src
maven-invoker-plugin-0:1.8-4.fc19.src
maven-plugin-build-helper-0:1.5-8.fc19.src
maven-plugin-cobertura-0:2.5.1-4.fc19.src
maven-shared-0:15-31.fc19.src
maven-war-plugin-0:2.3-4.fc19.src
mojo-signatures-0:1.1-0.11.svn11457.fc19.src
mule-0:2.0.2.20080813-7.fc19.src
native2ascii-maven-plugin-0:1.0-0.5.beta1.fc19.src
properties-maven-plugin-0:1.0-0.4.alpha2.fc19.src
qdox-0:1.12.1-2.fc19.src
resteasy-0:2.3.2-9.fc18.src
rmic-maven-plugin-0:1.2.1-1.fc19.src
spring-ldap-0:1.3.1-5.fc19.src
staxmapper-0:1.1.0-6.fc19.src
truezip-0:7.6.6-1.fc19.src
xml-maven-plugin-0:1.0-4.fc18.src
xnio-0:3.0.3-6.fc19.src
Someone interested should really introduce properly named (cobertura-maven-plugin) and using the latest guidelines. Please let me know if you want me to postpone its deprecation till you introduce the new one or you want to take it as is now.
Alexander Kurtakov
Red Hat Eclipse team
11 years, 1 month
[java/maven] Broken maven-shared-components pom in rawhide
by Tomas Radej
Hello to Fedora maven users,
By my error in judgment, most packages from maven-shared (like
maven-downloader, maven-artifact-resolver etc) are missing a
(Build)Requires on maven-shared, which provides the parent pom for
those, so a great number of your builds might fail because of that. I
am sorry for that and I am working on fixing the affected packages.
Thanks to all the folks who are helping me.
If your package build is failing in rawhide mock because of this, try
using Koji repos or build on Koji directly as many of the affected
packages have already been fixed and built there.
Regards, TR
--
Tomas Radej <tradej(a)redhat.com>
11 years, 2 months
Broken maven-shared-components pom in rawhide
by Tomas Radej
Hi everybody,
By my error in judgment, most packages from maven-shared (like maven-downloader, maven-artifact-resolver etc) are missing a (Build)Requires on maven-shared, which provides the parent pom for those, so a great number of your builds might fail because of that. I am sorry for that and I am working on fixing the affected packages. Thanks to all the folks who are helping me.
If your package build is failing in rawhide mock because of this, try using Koji repos or build on Koji directly as many of the affected packages have already been fixed and built there.
Regards, TR
--
Tomas Radej <tradej(a)redhat.com>
11 years, 2 months
Question about wagon-webdav build failure
by Orion Poplawski
guessencoding fails to build in rawhide but builds on F18. In the pom:
<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-webdav</artifactId>
<version>1.0-beta-2</version>
</extension>
</extensions>
...
Now, wagon-webdav does not appear to exist in Fedora, so I'm not surprised it
fails to build, but I'm curious as to why it builds okay in F18. maven change?
Anyway, suggestions on how to handle this? I'm not familiar with "extension"
as a pom entry.
Thanks!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
11 years, 2 months
Help with build issue
by Orion Poplawski
I'm trying to build my apache-rat package on Fedora 18 but the tests are
failing with the backtrace below. So it appears to me that the problem
is likely to be that
com.google.inject.internal.ProviderMethodsModule.getProviderMethods from
google-guice is not properly specifying its dependence on
aopalliance.jar from the aopalliance package. Is that the case? If so
(or not), how to fix? Thanks!
Running org.apache.rat.mp.RatCheckMojoTest
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 1.887
sec <<< FAILURE!
testIt1(org.apache.rat.mp.RatCheckMojoTest) Time elapsed: 1.634 sec
<<< ERROR!
java.lang.NoClassDefFoundError:
[Lorg/aopalliance/intercept/MethodInterceptor;
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
at java.lang.Class.getDeclaredMethods(Class.java:1810)
at
com.google.inject.internal.ProviderMethodsModule.getProviderMethods(ProviderMethodsModule.java:83)
at
com.google.inject.internal.ProviderMethodsModule.configure(ProviderMethodsModule.java:75)
at
com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:230)
at
com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:239)
at com.google.inject.spi.Elements.getElements(Elements.java:103)
at com.google.inject.spi.Elements.getElements(Elements.java:80)
at
org.sonatype.guice.bean.binders.MergedModule.configure(MergedModule.java:54)
at
com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:230)
at com.google.inject.spi.Elements.getElements(Elements.java:103)
at
com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:136)
at
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
at com.google.inject.Guice.createInjector(Guice.java:96)
at com.google.inject.Guice.createInjector(Guice.java:73)
at com.google.inject.Guice.createInjector(Guice.java:62)
at
org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:459)
at
org.codehaus.plexus.DefaultPlexusContainer.<init>(DefaultPlexusContainer.java:194)
at
org.codehaus.plexus.DefaultPlexusContainer.<init>(DefaultPlexusContainer.java:158)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.setupContainer(AbstractMojoTestCase.java:128)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.getContainer(AbstractMojoTestCase.java:141)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:87)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:95)
at
org.apache.maven.surefire.junit.JUnit3Provider.executeTestSet(JUnit3Provider.java:121)
at
org.apache.maven.surefire.junit.JUnit3Provider.invoke(JUnit3Provider.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.ClassNotFoundException:
org.aopalliance.intercept.MethodInterceptor
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)
... 46 more
Caused by: java.lang.ClassNotFoundException:
org.aopalliance.intercept.MethodInterceptor
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)
... 46 more
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
11 years, 2 months
openjdk and java security issues
by Linda Jacobson
Hello,
Will someone on this email list please answer these questions:
1. Oracle recently (2/1) released an emergency update to java se
7, that fixed most open security issues. Since openjdk is the reference
implementation for Java SE, does this mean that all updates are entered
into openjdk first?
2. Red Hat released a new version of openjdk 6, that fixed "many"
security bugs, as well as other issues. Does it fix all the ones fixed
by Oracle? The security holes are the same in openjdk 6 and openjdk 7.
3. What is the current status of openjdk 7, with respect to the
documented security vulnerabilities?
4. How do Red Hat and Oracle interact with respect to openjdk
releases, since I thought openjdk had its own people controlling releases?
Thank you.
Sincerely,
Linda Jacobson
11 years, 2 months