[jira] [Commented] (MPLUGIN-524) "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null" with Nexus Staging plugin
[
https://issues.apache.org/jira/browse/MPLUGIN-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17861247#comment-17861247
]
Arjan Tijms commented on MPLUGIN-524:
-
> We consider the plugin as useless these days
Just wondering, is nexus-staging-maven-plugin useless? How else are we supposed
to release to Sonatype? All our jobs for Eclipse EE4J and Jakarta EE use the
nexus-staging-maven-plugin.
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix() is null"
> with Nexus Staging plugin
>
>
> Key: MPLUGIN-524
> URL: https://issues.apache.org/jira/browse/MPLUGIN-524
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
>Affects Versions: 3.13.0
>Reporter: Tristan Tarrant
>Priority: Major
>
> While attempting to release a plugin with nexus-staging-maven-plugin, I get
> the following exception:
> {noformat}
> [ERROR] Failed to execute goal
> org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.13:deploy
> (injected-nexus-deploy) on project proto-schema-compatibility-maven-plugin:
> Failed to update metadata org.infinispan.maven-plugins/maven-metadata.xml:
> Cannot invoke "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getP refix()" is null
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update
> metadata org.infinispan.maven-plugins/maven-metadata.xml: Cannot invoke
> "String.equals(Object)" because the return value of
> "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null
> at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute
> (DeployMojo.java:216)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at
[jira] [Commented] (MDEP-732) unpack - artifactItem type attribute ignored
[
https://issues.apache.org/jira/browse/MDEP-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483991#comment-17483991
]
Arjan Tijms commented on MDEP-732:
--
Just a ping, any updates here?
> unpack - artifactItem type attribute ignored
>
>
> Key: MDEP-732
> URL: https://issues.apache.org/jira/browse/MDEP-732
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 3.1.2
>Reporter: Zoltán Forgó
>Priority: Major
>
> If an existing artifact which has other types (e.g. test-jar) needs to be
> unpacked the type attribute is getting ignored. Always jar type used.
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.1.2
>
>
> share-tests
> generate-test-sources
>
> unpack
>
>
>
>
> io.github.zforgo.stackoverflow
> shared-tests
> 0.1.0-SNAPSHOT
> test-jar
>
> ${project.build.directory}/alternateLocation
>
>
>
>
>
>
> {code}
> While running {{mvn install}} the log says
> {noformat}
> [INFO]
> [INFO] --- maven-dependency-plugin:3.1.2:unpack (share-tests) @ project ---
> [INFO] Configured Artifact:
> io.github.zforgo.stackoverflow:shared-tests:0.1.0-SNAPSHOT:test-jar
> [INFO] Unpacking [...]
> shared-tests/0.1.0-SNAPSHOT/shared-tests-0.1.0-SNAPSHOT.jar to [...] with
> includes "" and excludes ""
> [INFO]
> {noformat}
> It seems {{ArtifactItem}} was configured well but the {{Artifact}} is wrong.
> After some debugging it seems {{AbstractFromConfigurationMojo}} didn't set
> type attribute when creating {{Artifact}} from {{ArtifactItem}}.
> Related code:
> {code:java}
> protected Artifact getArtifact( ArtifactItem artifactItem )
> throws MojoExecutionException
> {
> Artifact artifact;
> try
> {
> // ...
> ProjectBuildingRequest buildingRequest =
> newResolveArtifactProjectBuildingRequest();
> if ( localRepositoryDirectory != null )
> {
> buildingRequest =
> repositoryManager.setLocalRepositoryBasedir(
> buildingRequest, localRepositoryDirectory );
> }
> // Map dependency to artifact coordinate
> DefaultArtifactCoordinate coordinate = new
> DefaultArtifactCoordinate();
> coordinate.setGroupId( artifactItem.getGroupId() );
> coordinate.setArtifactId( artifactItem.getArtifactId() );
> coordinate.setVersion( artifactItem.getVersion() );
> coordinate.setClassifier( artifactItem.getClassifier() );
> final String extension;
> ArtifactHandler artifactHandler =
> artifactHandlerManager.getArtifactHandler( artifactItem.getType() );
> //...
> }
> catch ( ArtifactResolverException e )
> {
> throw new MojoExecutionException( "Unable to find/resolve
> artifact.", e );
> }
> return artifact;
> }{code}
> The {{DefaultArtifactCoordinate}} sets type to {{jar}} and there is no place
> where it was updated. Because of this wrong artifact will be unpacked.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661436#comment-16661436 ] Arjan Tijms edited comment on MNG-6399 at 10/23/18 11:03 PM: - I also think it would be a good idea to say something about baseline version updated in some formal way. Before long we'll be on Java 24, and if Maven would still be restricted to Java 7 it would feel completely antiquated, which on its turn would hinder new developers coming into the project. Just think of you wanting to contribute to a project today. You clone its source, ready to inspect it and find out where to start. Then horrors of horrors, it appears to be Java 1.0! Not even the collection framework would be there, everything being Vector and Hashtable, and that all because the maintainer 15 years ago saw zero benefit in updating tot Java 1.1. was (Author: arjan.tijms): I also think it would be a good idea to say something about baseline version updated in some formal way. Before long we'll be on Java 24, and if Maven would still be restricted to Java 7 it would feel completely antiquated, which on its turn would hinder new developers coming into the project. Just think of you wanting to contribute to a project today. You clone its source, ready to inspect it and find out where to start. Then horrors of horrors, it appears to be Java 1.0! Not even the collection framework would be there, everyone being Vector and Hashtable, and that all because the maintainer 15 years ago saw zero benefit in updating tot Java 1.1. > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661436#comment-16661436 ] Arjan Tijms commented on MNG-6399: -- I also think it would be a good idea to say something about baseline version updated in some formal way. Before long we'll be on Java 24, and if Maven would still be restricted to Java 7 it would feel completely antiquated, which on its turn would hinder new developers coming into the project. Just think of you wanting to contribute to a project today. You clone its source, ready to inspect it and find out where to start. Then horrors of horrors, it appears to be Java 1.0! Not even the collection framework would be there, everyone being Vector and Hashtable, and that all because the maintainer 15 years ago saw zero benefit in updating tot Java 1.1. > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.6.x-candidate > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1457) trimStackTrace should be disabled by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16493220#comment-16493220
]
Arjan Tijms commented on SUREFIRE-1457:
---
+1 for disabling `trimStackTrace` by default.
How would changing the default exactly break compatibility? Are there tools out
there that parse the log and expect a trimmed stack trace?
> trimStackTrace should be disabled by default
>
>
> Key: SUREFIRE-1457
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1457
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.21.2
>Reporter: Réda Housni Alaoui
>Assignee: Tibor Digana
>Priority: Critical
>
> We are using Jenkins at work.
> Each time we had test failures, stack trace were incomplete and therefore
> totally useless.
> I just discovered {{trimStackTrace}} option.
> IMO, the fact that this option is currently enabled by default is a total non
> sense.
> Now we have to change the pom.xml of every projects of the company to have a
> correct default.
> IMO, and I think I am not the only one here, trimStackTrace should be
> disabled by default.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
