[maven-compiler-plugin] Possibly bug: annotationProcessorPath assuming classifier=processor
Hello,
I just faced a problem here using maven 3.6.1 and java11. The
compiler-plugin is assuming the classifier of a declared
annotationProcessorPath as "processor".
I've set my pom using this:
>
>
>
> maven-compiler-plugin
> ${maven-compiler.version}
>
>
>
> io.dekorate
>
> kubernetes-annotations
> 0.9-SNAPSHOT
>
>
>
>
>
>
But I'm getting an error:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project backend.core: Resolution of
> annotationProcessorPath dependencies failed: Missing:
> [ERROR] --
> [ERROR] 1) io.dekorate:kubernetes-annotations:jar:processor:0.9-SNAPSHOT
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=io.dekorate
> -DartifactId=kubernetes-annotations -Dversion=0.9-SNAPSHOT
> -Dclassifier=processor -Dpackaging=jar -Dfile=/path/to/file
Am I missing something or is it a bug?
thanks,
Cristiano
Re: Anyone had an error on Eclipse IDE after upgrade maven-jar-plugin to 3.1.2?
The short answer: I just love this IDE and everything that is behind it! I'm using it since I dropped the IBM VisualAge a long long time ago. ;-) In my daily working needs with Java, OSGi, Vertx and Maven I have no complains. it just give me what I need. Of course that are a bug here and there, but nothing that I can't bypass. And with the help of some plugins as SonarLint, Kaizen OpenApi editor, m2e, Mylin, DBeaver, Egit and some others it is just perfect for me. Btw, I just needed to install intelij once in order to integrate with an android app and I felt very uncomfortable with it. Would not use it if I have a choice. best regards, Cristiano On 08/06/2019 05:29, Tibor Digana wrote: > Why you use Eclipse. Use InteliJ IDEA. It is professional tool. Every > company has money to buy enterprise IDEA, the company wouln'd say no > because it is price you pay once and you can upgrade to major version > within whole year. You can use it forever without paying more after the > support period of one year you paid before. For instance I had IDEA 14 > since 2014 - 2019 without any issue in that tool. > > On Fri, Jun 7, 2019 at 3:32 PM Cristiano wrote: > >> Hello, >> >> Yesterday I did an upgrade on some dependencies and plugins of my >> company's master POM. >> >> I used the versions-plugin and changed many of the suggested ones. After >> conclude and build on CI without error, I ended up with a strange error >> in Eclipse IDE (ubuntu, 201903, jdk11) on every project that has it as >> its parent POM. >> >> The error has no description and its title is "Unknown". >> >> >> It took some time to track the culprit down and after I have downgraded >> the maven-jar-plugin to 3.1.1 the error was gone. >> >> I'm curious about this... >> >> best regards, >> >> >> Cristiano >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone had an error on Eclipse IDE after upgrade maven-jar-plugin to 3.1.2?
Thanks all, I've confirmed that upgrading this mavenarchiver connector and also m2e (thanks Mickael) resolved my issue. best regards, Cristiano On 10/06/2019 04:11, Anders Hammar wrote: > Please read the bug report [1], which was reference in the first reply to > this thread. It clearly explains that the problem is in the mavenarchiver > m2e connector/plugin. The simplest solution is to just update that plugin. > URL to update site is in the bug report. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=547340 > > /Anders > > On Mon, Jun 10, 2019 at 12:39 AM Alix Lourme wrote: > >> Hello Cristiano, >> >> Original root cause not analysed but: >> - Same problem here with Eclipse Oxygen (3a) + m2e - Maven Integration for >> Eclipse 1.8.3. >> - It works with Eclipse 2019-03 + m2e - Maven Integration for Eclipse >> 1.11.0 >> => m2e - Maven Integration for Eclipe plugin upgrade could be a solution >> >> Best regards >> >> Le dim. 9 juin 2019 à 00:07, Tibor Digana a >> écrit : >> >>> Hi Cristiano, >>> >>> I guess your architect who designed your company parent POM made everying >>> honestly right. >>> But we can prove or avoid the error on the tool if we simply add >> something, >>> then make a comparison test and we exclude added things which could not >>> change the outcome. >>> >>> Open the project in another tool, like Intellij IDEA or NetBeans and do >>> whta you expected in Ecplise, e.g. building the project. >>> If the project is built correctly, then it means Eclipse is not compliant >>> with the project. >>> If it would not work with IDEA nor NetBeans then maybe the architect did >>> not check the IDE tools even if he used commandline of Maven. >>> >>> The IntelliJ IDEA is usually very smart and understands configuration >>> parameters of Maven plugins, as well as repository settings and other >> Maven >>> specifics. >>> The best is to use default path in Maven local repo with these new tools >>> especially if their are new for you. >>> >>> Here in Maven OSS I also use IDEA and I am able to find issues nobody saw >>> before (using the Eclipse). These do not seem to be visible in Eclipse. >> You >>> know JetBrains improves the code analysis in every next version, so I >>> recommend this tool to every company and developer. >>> Pls try and exclude it if there is no positive influence. >>> >>> Cheers >>> Tibor17 >>> >>> >>> >>> On Fri, Jun 7, 2019 at 3:32 PM Cristiano wrote: >>> >>>> Hello, >>>> >>>> Yesterday I did an upgrade on some dependencies and plugins of my >>>> company's master POM. >>>> >>>> I used the versions-plugin and changed many of the suggested ones. >> After >>>> conclude and build on CI without error, I ended up with a strange error >>>> in Eclipse IDE (ubuntu, 201903, jdk11) on every project that has it as >>>> its parent POM. >>>> >>>> The error has no description and its title is "Unknown". >>>> >>>> >>>> It took some time to track the culprit down and after I have downgraded >>>> the maven-jar-plugin to 3.1.1 the error was gone. >>>> >>>> I'm curious about this... >>>> >>>> best regards, >>>> >>>> >>>> Cristiano >>>> >>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >> >> -- >> Alix Lourme >> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Anyone had an error on Eclipse IDE after upgrade maven-jar-plugin to 3.1.2?
Hello, Yesterday I did an upgrade on some dependencies and plugins of my company's master POM. I used the versions-plugin and changed many of the suggested ones. After conclude and build on CI without error, I ended up with a strange error in Eclipse IDE (ubuntu, 201903, jdk11) on every project that has it as its parent POM. The error has no description and its title is "Unknown". It took some time to track the culprit down and after I have downgraded the maven-jar-plugin to 3.1.1 the error was gone. I'm curious about this... best regards, Cristiano - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Possible bug in the ProjectBuilder (3.5.4) ?
Ok, I found where the problem was... :-)
Certainly I do not set necessary objects to new instance of
ProjectBuildingRequest that I was doing.
Once I have reused the instance provided by the MavenSession instance,
the errors gone !
ProjectBuildingRequest request = session.getProjectBuildingRequest();
best regards,
Cristiano
On 24/09/2018 21:17, Cristiano wrote:
Hello, I need some assistance in order to identify whether the issue
I'm facing is a bug or a missing feature.
I'm adding a goal to my plugin that must read a POM project from a
repository and get details about the dependencies declared on it.
In order to build the POM object I've created the method below that
are using Core's org.apache.maven.project.ProjectBuilder:
public MavenProject loadProject(Artifact artifact,
MavenSession session,
boolean pResolveDependencies) throws
ProjectBuildingException {
ProjectBuildingRequest request = new
DefaultProjectBuildingRequest();
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(
session.getCurrentProject().getRemoteArtifactRepositories());
request.setResolveDependencies(pResolveDependencies);
request.setRepositorySession(session.getRepositorySession());
request.setInactiveProfileIds(
Arrays.asList("when-building-java-using-java8")); ---> I
added this in order to try no get one of the errors reported.
return projectBuilder.build(artifact,
request).getProject();
}
In order to test it I'm trying to read this [pom]
https://search.maven.org/classic/#artifactdetails%7Cbr.com.c8tech.releng%7Cfpom-deps-felix%7C2.1%7Cpom.
This POM has declared a POM fragment:
br.com.c8tech.releng
2.1
fpom-deps-osgi
import
pom
And I'm using this code:
{
pom = loadProject(
new
DefaultArtifact("br.com.c8tech.releng:fpom-deps-felix:pom:2.1"),
true);
}
The error I'm getting from ProjectBuilder is about not being able
to get the versions declared in the imported POM ( declared in its
dependencyManagement) and also not being able to determine the
Java version of a profile activated by property.
Caused by: org.apache.maven.project.ProjectBuildingException:
Some problems were encountered while processing the POMs:
[ERROR] Failed to determine Java version for profile
when-building-java-using-java8 @
br.com.c8tech.releng:maven-parent-java:2.1,
/home/cvgaviao/.m2/repository/br/com/c8tech/releng/maven-parent-java/2.1/maven-parent-java-2.1.pom,
line 658, column 22
[ERROR] 'dependencies.dependency.version' for
net.java.dev.jna:jna:jar is missing. @
br.com.c8tech.releng:fpom-deps-felix:[unknown-version],
/home/cvgaviao/.m2/repository/br/com/c8tech/releng/fpom-deps-felix/2.1/fpom-deps-felix-2.1.pom,
line 329, column 21
[ERROR] 'dependencies.dependency.version' for
ch.qos.logback:logback-core:jar is missing. @
br.com.c8tech.releng:fpom-deps-felix:[unknown-version],
/home/cvgaviao/.m2/repository/br/com/c8tech/releng/fpom-deps-felix/2.1/fpom-deps-felix-2.1.pom,
line 337, column 21
could someone tell me if its a missing feature, a bug or maybe am I
missing something ?
thanks a lot,
Cristiano
Possible bug in the ProjectBuilder (3.5.4) ?
Hello, I need some assistance in order to identify whether the issue I'm
facing is a bug or a missing feature.
I'm adding a goal to my plugin that must read a POM project from a
repository and get details about the dependencies declared on it.
In order to build the POM object I've created the method below that are
using Core's org.apache.maven.project.ProjectBuilder:
public MavenProject loadProject(Artifact artifact,
MavenSession session,
boolean pResolveDependencies) throws
ProjectBuildingException {
ProjectBuildingRequest request = new
DefaultProjectBuildingRequest();
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(
session.getCurrentProject().getRemoteArtifactRepositories());
request.setResolveDependencies(pResolveDependencies);
request.setRepositorySession(session.getRepositorySession());
request.setInactiveProfileIds(
Arrays.asList("when-building-java-using-java8")); ---> I added
this in order to try no get one of the errors reported.
return projectBuilder.build(artifact,
request).getProject();
}
In order to test it I'm trying to read this [pom]
https://search.maven.org/classic/#artifactdetails%7Cbr.com.c8tech.releng%7Cfpom-deps-felix%7C2.1%7Cpom.
This POM has declared a POM fragment:
br.com.c8tech.releng
2.1
fpom-deps-osgi
import
pom
And I'm using this code:
{
pom = loadProject(
new
DefaultArtifact("br.com.c8tech.releng:fpom-deps-felix:pom:2.1"),
true);
}
The error I'm getting from ProjectBuilder is about not being able to
get the versions declared in the imported POM ( declared in its
dependencyManagement) and also not being able to determine the Java
version of a profile activated by property.
Caused by: org.apache.maven.project.ProjectBuildingException: Some
problems were encountered while processing the POMs:
[ERROR] Failed to determine Java version for profile
when-building-java-using-java8 @
br.com.c8tech.releng:maven-parent-java:2.1,
/home/cvgaviao/.m2/repository/br/com/c8tech/releng/maven-parent-java/2.1/maven-parent-java-2.1.pom,
line 658, column 22
[ERROR] 'dependencies.dependency.version' for
net.java.dev.jna:jna:jar is missing. @
br.com.c8tech.releng:fpom-deps-felix:[unknown-version],
/home/cvgaviao/.m2/repository/br/com/c8tech/releng/fpom-deps-felix/2.1/fpom-deps-felix-2.1.pom,
line 329, column 21
[ERROR] 'dependencies.dependency.version' for
ch.qos.logback:logback-core:jar is missing. @
br.com.c8tech.releng:fpom-deps-felix:[unknown-version],
/home/cvgaviao/.m2/repository/br/com/c8tech/releng/fpom-deps-felix/2.1/fpom-deps-felix-2.1.pom,
line 337, column 21
could someone tell me if its a missing feature, a bug or maybe am I
missing something ?
thanks a lot,
Cristiano
AbstractArtifactMetadata deprecation?
Hello, I'm developing a plugin where I need to download a file from a place and install it with a created pom for it in a local maven repository. while investigating how to do that I found that AbstractArtifactMetadata class is deprecated. It is there a replacement for it or a newest way to create and attach a pom to an artifact ? thanks, Cristiano - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Would be possible to inject com.google.inject.Injector in a mojo or other component?
Hi Stuart, thanks for the explanation ! the map solution also have fit well in my case. many thanks and best regards, Cristiano On 06-01-2016 19:50, Stuart McCulloch wrote: Hi Cristiano, Maven core doesn’t expose the “com.google.inject” package to plugins, which means the Injector class seen by your plugin is different to the class seen by core (this is due to classworlds isolation) which is why injecting the Injector is not currently possible. If the “com.google.inject” package was exposed from core then you would be able to inject the Injector, but there is a better way to get what you want without requiring this: @Inject private Map<String, Arcr> arcrs; This will inject a dynamic map of all components that implement Arcr, indexed by name. The map is lazy so instances of the components are only created when you attempt to get them: Arcr selectedArcr = arcrs.get(pTracker.getNamed()); -- Cheers, Stuart On Wednesday, 6 January 2016 at 19:27, Cristiano Gavião wrote: Hi, I have some components that implement the same interface. all of them are being properly registered by sisu. @Named(CommonMojoConstants.OCUS_PACKAGING) @Typed(Arcr.class) @Singleton public class IpArcrComponent implements Arcr I'm needing to control the injection in one specific case. normally I can use the Injector.getInstance: injector.getInstance(Key.get(Arcr.class, Names.named(pTracker.getNamed(; But I'm getting an error (com.google.inject.ProvisionException: Unable to provision) when trying to inject the Injector: @Inject private Injector injector; Its not allowed or am I missing something? thanks, Cristiano - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Strange problem with custom ArtifactHandler
Hello,
I'm facing a problem with a plugin that has a custom ArtifactHandler for
a custom packaging type. The custom class is being registered by sisu
and no problem was reported while running a build, except when a project
artifact has one artifact of this custom type as a dependency.
The problem is that maven is using the DefaultArtifactHandler for the
dependency and not the custom one and then I'm getting a
ClassCastException in my plugin.
This is how I declared the custom ArtifactHandler. The value of constant
is "ip.zip" :
@Named(CommonMojoConstants.IP_PACKAGING)
@Singleton
@Typed(value = { ArtifactHandler.class, ExtendedArtifactHandler.class })
public class IpArtifactHandler extends AbstractTypeHandler {
@Inject
public IpArtifactHandler() {
super(CommonMojoConstants.IP_PACKAGING);
setIncludesDependencies(true);
setExtension(CommonMojoConstants.IP_EXTENSION);
setLanguage(CommonMojoConstants.LANGUAGE_JAVA);
setAddedToClasspath(true);
}
I added a log to try understand what is happen before exception occur.
[WARN]
CONVERTING:org.apache.maven.artifact.handler.DefaultArtifactHandler
| distribution.ip.node
The interesting thing is that I have another custom ArtifactHandler and
it is working well. the unique relevant difference between both is the
type name. one has a dot and the other just a single word: "bundle":
[WARN]
CONVERTING:org.lunifera.maven.lib.mojo.handlers.BundleArtifactHandler |
org.apache.felix.scr
I want to investigate if the dot is the culprit. Could someone tell me
which class is responsible to set the ArtifactHandler for a dependency
object ?
thanks,
Cristiano
Re: Strange problem with custom ArtifactHandler
Well, is not the dot the culprit... I tried with another packaging name and I got the same result. I still don't know who injects the ArtifactHandler in the dependency... any idea ? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Strange problem with custom ArtifactHandler
After having lost many hours I finally found where the problem is likely
to be... :-(
maven is using aether for dependency resolution, but aether has not a
concept of packaging and extension as maven has. it only has extension.
as a workaround maven is saving the packaging type inside the aether's
DefaultArtifact properties map field. that is ok...
But the values saved in aether's class is not being used properly when
converting again to maven Artifact after resolution.
Instead of searching for an existent ArtifactHandle instance in the
current ArtifactHandlerManager instance a new one is being created in
RepositoryUtils:
org.apache.maven.artifact.Artifact toArtifact( Artifact artifact ){
ArtifactHandler handler = newHandler( artifact );
-
public static ArtifactHandler newHandler( Artifact artifact )
{
String type = artifact.getProperty(
ArtifactProperties.TYPE, artifact.getExtension() );
*DefaultArtifactHandler handler = new DefaultArtifactHandler( type );*
It is a bug or it was intentionally done this way?
Would be possible to inject com.google.inject.Injector in a mojo or other component?
Hi, I have some components that implement the same interface. all of them are being properly registered by sisu. @Named(CommonMojoConstants.OCUS_PACKAGING) @Typed(Arcr.class) @Singleton public class IpArcrComponent implements Arcr I'm needing to control the injection in one specific case. normally I can use the Injector.getInstance: injector.getInstance(Key.get(Arcr.class, Names.named(pTracker.getNamed(; But I'm getting an error (com.google.inject.ProvisionException: Unable to provision) when trying to inject the Injector: @Inject private Injector injector; Its not allowed or am I missing something? thanks, Cristiano
Re: found some errors running takari-lifecycle build with java 1.8
ok, done: https://github.com/takari/takari-lifecycle/issues/11 regards, Cristiano On 22-02-2015 00:22, Igor Fedorenko wrote: Looks like takari plugin test harness can't talk to one of your project's repositories. Can you please open issue at github so we don't spam this mailing list? -- Regards, Igor On 2015-02-21 19:44, Cristiano Gavião wrote: Hi again, In order to investigate a bit more this strange behavior, I downloaded the apache-maven archive by hand (from http://search.maven.org/#artifactdetails|org.apache.maven|apache-maven|3.2.3|pom). Note that this is not the version that I have currently installed in my linux. I'm using 3.2.5. I put this file with 7Mb in the local repository and then the takari-lifecycle tests passed properly. Then I removed apache-maven again and tried to build takari-lifecycle one more time. again it tried to download 3.2.3 (don't know why) and it ended corrupted. that failed the takari-lifecycle tests again. It seems that exists some issue related to downloading this apache-maven archive. regards, Cristiano On 21-02-2015 20:40, Cristiano Gavião wrote: Hi Igor, That is strange... I deleted all versions of apache-maven from local my repo. Then I built (package) the takari-lifecycle (without testing) and no version of apache-maven was downloaded. But when I tried mvn install, the version 3.2.3 was downloaded but it has only 178 bytes. Don't know if it was downloaded wrongly or the file was corrupted by other means. On 21-02-2015 18:48, Igor Fedorenko wrote: Looks like maven distribution gz is corrupted in your local repo. See if removing ~/.m2/repository/org/apache/maven/apache-maven directory will solve the problem for you. If not, file github issue like Jason suggested. -- Regards, Igor On 2015-02-21 16:08, Cristiano Gavião wrote: Hello, I'm trying to learn how to use the new testing tools provided by takari. Started by the tests in takari-lifecycle-plugin-its from github master branch. but I'm getting errors when running the build. I'm using maven 3.2.5 in linux with java 1.8.0_31: Tests in error: BasicTest.initializationError » IO Input is not in the .gz format CompileAnnotationProcessingTest.initializationError » IO Input is not in the CompileClasspathTest.initializationError » IO Input is not in the .gz format CompileMultimoduleTest.initializationError » IO Input is not in the .gz format FilteringResourcesTest.initializationError » IO Input is not in the .gz format MultimoduleSkipInstallDeployTest.initializationError » IO Input is not in the ... PomPackagingTest.initializationError » IO Input is not in the .gz format details of one run: Running io.tesla.maven.plugins.test.BasicTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 sec FAILURE! - in io.tesla.maven.plugins.test.BasicTest initializationError(io.tesla.maven.plugins.test.BasicTest) Time elapsed: 0.001 sec ERROR! java.io.IOException: Input is not in the .gz format at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:162) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:135) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:100) at io.takari.maven.testing.executor.junit.MavenVersionResolver.unarchive(MavenVersionResolver.java:70) at io.takari.maven.testing.executor.junit.MavenVersionResolver.resolve(MavenVersionResolver.java:60) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.getRunners(MavenJUnitTestRunner.java:131) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.init(MavenJUnitTestRunner.java:89) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) at org.apache.maven.surefire.junit4
Re: found some errors running takari-lifecycle build with java 1.8
Hi again, In order to investigate a bit more this strange behavior, I downloaded the apache-maven archive by hand (from http://search.maven.org/#artifactdetails|org.apache.maven|apache-maven|3.2.3|pom). Note that this is not the version that I have currently installed in my linux. I'm using 3.2.5. I put this file with 7Mb in the local repository and then the takari-lifecycle tests passed properly. Then I removed apache-maven again and tried to build takari-lifecycle one more time. again it tried to download 3.2.3 (don't know why) and it ended corrupted. that failed the takari-lifecycle tests again. It seems that exists some issue related to downloading this apache-maven archive. regards, Cristiano On 21-02-2015 20:40, Cristiano Gavião wrote: Hi Igor, That is strange... I deleted all versions of apache-maven from local my repo. Then I built (package) the takari-lifecycle (without testing) and no version of apache-maven was downloaded. But when I tried mvn install, the version 3.2.3 was downloaded but it has only 178 bytes. Don't know if it was downloaded wrongly or the file was corrupted by other means. On 21-02-2015 18:48, Igor Fedorenko wrote: Looks like maven distribution gz is corrupted in your local repo. See if removing ~/.m2/repository/org/apache/maven/apache-maven directory will solve the problem for you. If not, file github issue like Jason suggested. -- Regards, Igor On 2015-02-21 16:08, Cristiano Gavião wrote: Hello, I'm trying to learn how to use the new testing tools provided by takari. Started by the tests in takari-lifecycle-plugin-its from github master branch. but I'm getting errors when running the build. I'm using maven 3.2.5 in linux with java 1.8.0_31: Tests in error: BasicTest.initializationError » IO Input is not in the .gz format CompileAnnotationProcessingTest.initializationError » IO Input is not in the CompileClasspathTest.initializationError » IO Input is not in the .gz format CompileMultimoduleTest.initializationError » IO Input is not in the .gz format FilteringResourcesTest.initializationError » IO Input is not in the .gz format MultimoduleSkipInstallDeployTest.initializationError » IO Input is not in the ... PomPackagingTest.initializationError » IO Input is not in the .gz format details of one run: Running io.tesla.maven.plugins.test.BasicTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 sec FAILURE! - in io.tesla.maven.plugins.test.BasicTest initializationError(io.tesla.maven.plugins.test.BasicTest) Time elapsed: 0.001 sec ERROR! java.io.IOException: Input is not in the .gz format at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:162) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:135) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:100) at io.takari.maven.testing.executor.junit.MavenVersionResolver.unarchive(MavenVersionResolver.java:70) at io.takari.maven.testing.executor.junit.MavenVersionResolver.resolve(MavenVersionResolver.java:60) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.getRunners(MavenJUnitTestRunner.java:131) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.init(MavenJUnitTestRunner.java:89) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke
Re: found some errors running takari-lifecycle build with java 1.8
Hi Igor, That is strange... I deleted all versions of apache-maven from local my repo. Then I built (package) the takari-lifecycle (without testing) and no version of apache-maven was downloaded. But when I tried mvn install, the version 3.2.3 was downloaded but it has only 178 bytes. Don't know if it was downloaded wrongly or the file was corrupted by other means. On 21-02-2015 18:48, Igor Fedorenko wrote: Looks like maven distribution gz is corrupted in your local repo. See if removing ~/.m2/repository/org/apache/maven/apache-maven directory will solve the problem for you. If not, file github issue like Jason suggested. -- Regards, Igor On 2015-02-21 16:08, Cristiano Gavião wrote: Hello, I'm trying to learn how to use the new testing tools provided by takari. Started by the tests in takari-lifecycle-plugin-its from github master branch. but I'm getting errors when running the build. I'm using maven 3.2.5 in linux with java 1.8.0_31: Tests in error: BasicTest.initializationError » IO Input is not in the .gz format CompileAnnotationProcessingTest.initializationError » IO Input is not in the CompileClasspathTest.initializationError » IO Input is not in the .gz format CompileMultimoduleTest.initializationError » IO Input is not in the .gz format FilteringResourcesTest.initializationError » IO Input is not in the .gz format MultimoduleSkipInstallDeployTest.initializationError » IO Input is not in the ... PomPackagingTest.initializationError » IO Input is not in the .gz format details of one run: Running io.tesla.maven.plugins.test.BasicTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 sec FAILURE! - in io.tesla.maven.plugins.test.BasicTest initializationError(io.tesla.maven.plugins.test.BasicTest) Time elapsed: 0.001 sec ERROR! java.io.IOException: Input is not in the .gz format at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:162) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:135) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:100) at io.takari.maven.testing.executor.junit.MavenVersionResolver.unarchive(MavenVersionResolver.java:70) at io.takari.maven.testing.executor.junit.MavenVersionResolver.resolve(MavenVersionResolver.java:60) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.getRunners(MavenJUnitTestRunner.java:131) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.init(MavenJUnitTestRunner.java:89) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) would be these errors caused by java 8 ? regards, Cristiano - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
found some errors running takari-lifecycle build with java 1.8
Hello, I'm trying to learn how to use the new testing tools provided by takari. Started by the tests in takari-lifecycle-plugin-its from github master branch. but I'm getting errors when running the build. I'm using maven 3.2.5 in linux with java 1.8.0_31: Tests in error: BasicTest.initializationError » IO Input is not in the .gz format CompileAnnotationProcessingTest.initializationError » IO Input is not in the CompileClasspathTest.initializationError » IO Input is not in the .gz format CompileMultimoduleTest.initializationError » IO Input is not in the .gz format FilteringResourcesTest.initializationError » IO Input is not in the .gz format MultimoduleSkipInstallDeployTest.initializationError » IO Input is not in the ... PomPackagingTest.initializationError » IO Input is not in the .gz format details of one run: Running io.tesla.maven.plugins.test.BasicTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 sec FAILURE! - in io.tesla.maven.plugins.test.BasicTest initializationError(io.tesla.maven.plugins.test.BasicTest) Time elapsed: 0.001 sec ERROR! java.io.IOException: Input is not in the .gz format at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:162) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:135) at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:100) at io.takari.maven.testing.executor.junit.MavenVersionResolver.unarchive(MavenVersionResolver.java:70) at io.takari.maven.testing.executor.junit.MavenVersionResolver.resolve(MavenVersionResolver.java:60) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.getRunners(MavenJUnitTestRunner.java:131) at io.takari.maven.testing.executor.junit.MavenJUnitTestRunner.init(MavenJUnitTestRunner.java:89) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) would be these errors caused by java 8 ? regards, Cristiano
POM mixins ?
Hi, couple years ago I read an interview from Jason where he talk about pom mixins [1]. But I couldn't find any information about it since then. Was this feature already implemented ? thanks [1] - http://blog.sonatype.com/2010/03/eclipsemagazine-interview-with-jason-van-zyl - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
