[GitHub] [maven-resolver] rfscholte commented on a change in pull request #83: [MRESOLVER-151] Enforce a checksum policy to be provided explicitly

[GitBox]

rfscholte commented on a change in pull request #83:
URL: https://github.com/apache/maven-resolver/pull/83#discussion_r548436414



##
File path: 
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultChecksumPolicyProviderTest.java
##
@@ -133,10 +135,12 @@ public void 
testGetEffectiveChecksumPolicy_UnknownPolicies()
 { RepositoryPolicy.CHECKSUM_POLICY_IGNORE, 
RepositoryPolicy.CHECKSUM_POLICY_IGNORE } };
 for ( String[] testCase : testCases )
 {
-assertEquals( "unknown vs " + testCase[1], testCase[0],
-  provider.getEffectiveChecksumPolicy( session, 
CHECKSUM_POLICY_UNKNOWN, testCase[1] ) );
-assertEquals( "unknown vs " + testCase[1], testCase[0],
-  provider.getEffectiveChecksumPolicy( session, 
testCase[1], CHECKSUM_POLICY_UNKNOWN ) );
+IllegalArgumentException e = assertThrows( 
IllegalArgumentException.class,
+() -> provider.getEffectiveChecksumPolicy( session, 
CHECKSUM_POLICY_UNKNOWN, testCase[1] ) );
+assertThat( e.getMessage(), is("Unsupported policy: unknown") );

Review comment:
   I didn't notice the static import of `assertThrows`, which is caused by 
an existing wildcard import. Please make imports explicit.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (MEAR-212) Failed to initialize ear modules: Unknown artifact type[mar] for addressing

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195901#comment-17195901
 ] 

Marat Abrarov edited comment on MEAR-212 at 12/24/20, 7:34 AM:
---

[~dahoffer], could [that 
workaround|https://issues.apache.org/jira/browse/MEAR-216?focusedCommentId=17195895&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17195895]
 (custom type mapping of EAR modules) from MEAR-216 work for you?


was (Author: abrarovm):
[~dahoffer], could that workaround (custom type mapping of EAR modules) from 
MEAR-216 work for you?

> Failed to initialize ear modules: Unknown artifact type[mar] for addressing
> ---
>
> Key: MEAR-212
> URL: https://issues.apache.org/jira/browse/MEAR-212
> Project: Maven EAR Plugin
>  Issue Type: New Feature
>Affects Versions: 2.10
>Reporter: David Hoffer
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> I'm trying to generate and ear file but I'm getting the following message:  
> Failed to initialize ear modules: Unknown artifact type[mar] for addressing  
> (full debug stack trace is below)
> However I don't have any mar artifacts in my dependencies.  What I do have is 
> a war that has 4 mar files added as resources and I'm making a ear with the 
> skinny war feature.
> Why would the ear plugin give this error when it has no nothing to do with 
> the mar resources in the war...or perhaps this error has nothing to do with 
> those resources, not sure.
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml 
> (default-generate-application-xml) on project coreservices-ear: Failed to 
> initialize ear modules: Unknown artifact type[mar] for addressing -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml 
> (default-generate-application-xml) on project coreservices-ear: Failed to 
> initialize ear modules
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>   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:606)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to 
> initialize ear modules
>   at 
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
>   at 
> org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>   ... 19 more
> Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown 
> artifact type[mar] for addressing
>   at 
> org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
>   at 
> org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
>   ... 22 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] eolivelli merged pull request #262: Refer to correct property in skipping-tests doc

[GitBox]

eolivelli merged pull request #262:
URL: https://github.com/apache/maven-surefire/pull/262


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-surefire] eolivelli commented on pull request #262: Refer to correct property in skipping-tests doc

[GitBox]

eolivelli commented on pull request #262:
URL: https://github.com/apache/maven-surefire/pull/262#issuecomment-750789170


   I believe that this correction is valid. Merging.
   thank you @qerub 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-ear-plugin] mabrarov commented on pull request #32: remove deprecated methods by not stubbing value objects

[GitBox]

mabrarov commented on pull request #32:
URL: https://github.com/apache/maven-ear-plugin/pull/32#issuecomment-750788357


   I'll need next 24-48 hrs to complete with review of this PR. I haven't 
forgotten about it :) Just busy with my job duties.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254423#comment-17254423
 ] 

Marat Abrarov commented on MEAR-166:


[~afloom], 

I opened [pull request #33|https://github.com/apache/maven-ear-plugin/pull/33] 
to implement this feature request. Your review and testing is appreciated.

> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://issues.apache.org/jira/browse/MEAR-166
> Project: Maven EAR Plugin
>  Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
>  Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: EAR without EJB dependencies.patch, MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it 
> does leave 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies 
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic 
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's 
> dependencies should go to EAR's lib.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-ear-plugin] mabrarov opened a new pull request #33: [MEAR-166] Handling EAR modules of all types when modifying Class-Path and when skinnyWars / skinnyModules is used

[GitBox]

mabrarov opened a new pull request #33:
URL: https://github.com/apache/maven-ear-plugin/pull/33


   [MEAR-166] - Removing EAR modules of all types when skinnyWars / 
skinnyModules is on. Updating reference to the EAR modules of all types in the 
Class-Path entry of MANIFEST.mf when modifying that entry.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-ear-plugin] mabrarov commented on pull request #31: [MEAR-294] Removal of provided artifacts from the Class-Path entry of MANIFEST.mf

[GitBox]

mabrarov commented on pull request #31:
URL: https://github.com/apache/maven-ear-plugin/pull/31#issuecomment-750737024


   What about closing 
[MEAR-294](https://issues.apache.org/jira/browse/MEAR-294)?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-deploy-plugin] philsttr edited a comment on pull request #15: [MDEPLOY-265] Maintain backwards compatibility for alt*DeploymentRepository in id::default::url format

[GitBox]

philsttr edited a comment on pull request #15:
URL: 
https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750715075


   Correct.
   
   And to clarify 'you' in your statement... the infrastructure teams handle 
the updates to CI, settings.xml, and artifactory.  It's transparent to 
developers.  Devs don't need to know anything about this stuff.  All they need 
to know is to create a maven project, and the artifacts are deployed where they 
are supposed to go automatically.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-deploy-plugin] philsttr commented on pull request #15: [MDEPLOY-265] Maintain backwards compatibility for alt*DeploymentRepository in id::default::url format

[GitBox]

philsttr commented on pull request #15:
URL: 
https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750715075


   Correct 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Assigned] (MNG-6561) New RepositorySystem implementation as replacement of deprecated from maven-compat

[Sylwester Lachiewicz (Jira)]

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

Sylwester Lachiewicz reassigned MNG-6561:
-

Assignee: (was: Sylwester Lachiewicz)

> New RepositorySystem implementation as replacement of deprecated from 
> maven-compat
> --
>
> Key: MNG-6561
> URL: https://issues.apache.org/jira/browse/MNG-6561
> Project: Maven
>  Issue Type: Improvement
>Reporter: Sylwester Lachiewicz
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Create a component that will replace 
> org.apache.maven.repository.RepositorySystem implementation from maven-compat 
> module to keep backward compatibility with Maven 2.x plugins.
> While testing MNG-5995 and with deleted maven-compat.jar - a compilation of 
> basic project failed with error:
>  
> {code:java}
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ my-app ---
> [WARNING] Error injecting: org.apache.maven.plugin.compiler.CompilerMojo
> com.google.inject.ProvisionException: Unable to provision, see the following 
> errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was 
> bound.
> while locating org.apache.maven.plugin.compiler.CompilerMojo
> 1 error
> at com.google.inject.internal.InternalProvisionException.toProvisionException 
> (InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1053)
> at com.google.inject.internal.InjectorImpl.getInstance 
> (InjectorImpl.java:1086)
> at org.eclipse.sisu.space.AbstractDeferredClass.get 
> (AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision 
> (ProviderInternalFactory.java:85)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision 
> (InternalFactoryToInitializableAdapter.java:57)
> at com.google.inject.internal.ProviderInternalFactory$1.call 
> (ProviderInternalFactory.java:66)
> at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision 
> (ProvisionListenerStackCallback.java:112)
> at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision 
> (ProvisionListenerStackCallback.java:127)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision 
> (ProvisionListenerStackCallback.java:66)
> at com.google.inject.internal.ProviderInternalFactory.circularGet 
> (ProviderInternalFactory.java:61)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get 
> (InternalFactoryToInitializableAdapter.java:47)
> at com.google.inject.internal.InjectorImpl$1.get (InjectorImpl.java:1050)
> at org.eclipse.sisu.inject.Guice4$1.get (Guice4.java:162)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue (LazyBeanEntry.java:81)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue (LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup 
> (DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup 
> (DefaultPlexusContainer.java:255)
> at 
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo 
> (DefaultMavenPluginManager.java:520)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:124)
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile 
> (default-compile) on project my-app: Execution default-compile of goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile failed: Unable 
> to load the mojo 'compile' (or one of its required components) from the 
> plugin 'org.apache.maven.plugins:maven-compiler-plugin:3.8.0': 
> com.google.inject.ProvisionException: Unable to provision, see the following 
> errors:
> [ERROR]
> [ERROR] 1) No implementation for c was bound.
> [ERROR] while locating org.apache.maven.plugin.compiler.CompilerMojo
> [ERROR] at 
> ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.0, 
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@6e5e91e4] (via 
> modules: org.eclipse.sisu.wire.WireModule -> 
> org.eclipse.sisu.plexus.PlexusBindingModule)
> [ERROR] while locating org.apache.maven.plugin.Mojo annotated with 
> @com.google.inject.name.Named(value="org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile")
> [ERROR]
> [ERROR] 1 error
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint: 
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile{code}
> Sometimes we can change usages of 
> _org.apache.maven.repository.RepositorySystem_ to 
> _org.apache.maven.bridge.MavenRepositorySystem_



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MPLUGINTESTING-64) broken links on website

[Sylwester Lachiewicz (Jira)]

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

Sylwester Lachiewicz closed MPLUGINTESTING-64.
--
Resolution: Fixed

> broken links on website
> ---
>
> Key: MPLUGINTESTING-64
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-64
> Project: Maven Plugin Testing
>  Issue Type: Bug
>Reporter: Samael Bate
>Priority: Major
> Fix For: 3.4.0
>
>
> Some links on 
> [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/] are 
> invalid.
>  
> On the 
> [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html]
>  page the github url is 
> [https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/]
>  but it should simply be [https://github.com/apache/maven-plugin-testing/]
>  
> Also on the 
> [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/issue-tracking.html]
>  page it has a link to [http://jira.codehaus.org/browse/MPLUGINTESTING] which 
> is wrong as it should point to this Jira



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MPLUGINTESTING-64) broken links on website

[Sylwester Lachiewicz (Jira)]

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

Sylwester Lachiewicz updated MPLUGINTESTING-64:
---
Fix Version/s: 3.4.0

> broken links on website
> ---
>
> Key: MPLUGINTESTING-64
> URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-64
> Project: Maven Plugin Testing
>  Issue Type: Bug
>Reporter: Samael Bate
>Priority: Major
> Fix For: 3.4.0
>
>
> Some links on 
> [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/] are 
> invalid.
>  
> On the 
> [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html]
>  page the github url is 
> [https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/]
>  but it should simply be [https://github.com/apache/maven-plugin-testing/]
>  
> Also on the 
> [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/issue-tracking.html]
>  page it has a link to [http://jira.codehaus.org/browse/MPLUGINTESTING] which 
> is wrong as it should point to this Jira



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNGSITE-393) Remove references to Maven 2.x

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254347#comment-17254347
 ] 

Hudson commented on MNGSITE-393:


Build succeeded in Jenkins: Maven » Maven TLP » maven-scm » master #21

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-scm/job/master/21/

> Remove references to Maven 2.x
> --
>
> Key: MNGSITE-393
> URL: https://issues.apache.org/jira/browse/MNGSITE-393
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Maven 3.x is over a decade old now and we're talking about Maven 4. It's time 
> to clean out all the random discussion here and there about how Maven 2.x did 
> things, differences between Maven 2 and 3, what works in Maven 3 but not 2, 
> etc. 
> Assume Maven 3.0 as the minimum, probably Maven 3.1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-deploy-plugin] michael-o commented on pull request #15: [MDEPLOY-265] Maintain backwards compatibility for alt*DeploymentRepository in id::default::url format

[GitBox]

michael-o commented on pull request #15:
URL: 
https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750643033


   OK, let me summarize: You update at most 5 CI servers for new URLs instead 
to manipulate the corporate POM and then need to update all dependend projects 
(thousands)?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-6054) Remove super POM plugin management section

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254345#comment-17254345
 ] 

Hudson commented on MNG-6054:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #74

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/74/

> Remove super POM plugin management section
> --
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Affects Versions: 3.0-alpha-1, 3.3.9, 3.6.3
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.
> see [http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html]
> {code:xml}
> 
>   
>   
>   
> 
>   maven-antrun-plugin
>   1.3
> 
> 
>   maven-assembly-plugin
>   2.2-beta-5
> 
> 
>   maven-dependency-plugin
>   2.8
> 
> 
>   maven-release-plugin
>   2.5.3
> 
>   
> {code}
> or 
> http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?revision=1004205&view=markup



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-deploy-plugin] philsttr commented on pull request #15: [MDEPLOY-265] Maintain backwards compatibility for alt*DeploymentRepository in id::default::url format

[GitBox]

philsttr commented on pull request #15:
URL: 
https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750633631


   We have one shared artifactory instance to which all artifacts are 
published.  All CI servers use the same `settings.xml` file, which causes 
artifacts to publish to the same repositories on the shared artifactory 
instance.  The [example 
settings.xml](https://github.com/apache/maven-deploy-plugin/files/5731992/settings.xml.txt)
 file shows that artifacts are published to one of three repositories on the 
shared artifactory instance (either `maven-releases`, `maven-snapshots`, or 
`maven-combined`)
   
   We prefer to centrally manage the distribution settings on our CI servers 
via `settings.xml` files rather than poms.  We do this mainly because we have 
few CI servers (less than 5), and many poms (thousands).   If/when we need to 
change these settings, it's a trivial task to update the CI servers.  By 
comparison, to update all the poms would be a monumental task of distributed 
effort across many dev teams and release cycles.  It's just not a scalable 
solution.   Note that this isn't just a theoretical exercise.  We have had to 
update these settings several times over the past few years due to changes to 
our artifactory infrastructure. 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo merged pull request #113: replace deprecated methods

[GitBox]

elharo merged pull request #113:
URL: https://github.com/apache/maven-scm/pull/113


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo merged pull request #116: [MNGSITE-393] remove reference to Maven 2

[GitBox]

elharo merged pull request #116:
URL: https://github.com/apache/maven-scm/pull/116


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-integration-testing] michael-o commented on a change in pull request #79: [MNG-7022] Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos ba…

[GitBox]

michael-o commented on a change in pull request #79:
URL: 
https://github.com/apache/maven-integration-testing/pull/79#discussion_r548323950



##
File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4338OptionalMojosTest.java
##
@@ -35,7 +35,7 @@
 
 public MavenITmng4338OptionalMojosTest()
 {
-super( "[3.0,)" );
+super( "[3.0,3.7.0)" );

Review comment:
   Done locally





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Closed] (MNG-6054) Remove super POM plugin management section

[Michael Osipov (Jira)]

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

Michael Osipov closed MNG-6054.
---
Fix Version/s: (was: 4.0.x-candidate)
   (was: needing-scrub-3.4.0-fallout)
   4.0.0-alpha-1
   4.0.0
   Resolution: Fixed

Fixed with 
[d2adab7bf3c2591c38adde729d11923d4c95052c|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=d2adab7bf3c2591c38adde729d11923d4c95052c].

> Remove super POM plugin management section
> --
>
> Key: MNG-6054
> URL: https://issues.apache.org/jira/browse/MNG-6054
> Project: Maven
>  Issue Type: Task
>Affects Versions: 3.0-alpha-1, 3.3.9, 3.6.3
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The super POM contains various plugins in the plugin management not part of 
> any default lifecycle. These should be removed from the super POM.
> see [http://maven.apache.org/ref/3.5.2/maven-model-builder/super-pom.html]
> {code:xml}
> 
>   
>   
>   
> 
>   maven-antrun-plugin
>   1.3
> 
> 
>   maven-assembly-plugin
>   2.2-beta-5
> 
> 
>   maven-dependency-plugin
>   2.8
> 
> 
>   maven-release-plugin
>   2.5.3
> 
>   
> {code}
> or 
> http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml?revision=1004205&view=markup



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] asfgit closed pull request #410: [MNG-6054] Remove super POM plugin management section

[GitBox]

asfgit closed pull request #410:
URL: https://github.com/apache/maven/pull/410


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNGSITE-393) Remove references to Maven 2.x

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254323#comment-17254323
 ] 

Hudson commented on MNGSITE-393:


Build succeeded in Jenkins: Maven » Maven TLP » maven-scm » elharo-patch-1 #2

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-scm/job/elharo-patch-1/2/

> Remove references to Maven 2.x
> --
>
> Key: MNGSITE-393
> URL: https://issues.apache.org/jira/browse/MNGSITE-393
> Project: Maven Project Web Site
>  Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Maven 3.x is over a decade old now and we're talking about Maven 4. It's time 
> to clean out all the random discussion here and there about how Maven 2.x did 
> things, differences between Maven 2 and 3, what works in Maven 3 but not 2, 
> etc. 
> Assume Maven 3.0 as the minimum, probably Maven 3.1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MJAVADOC-667) Broken links in Javadoc comments

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254322#comment-17254322
 ] 

Hudson commented on MJAVADOC-667:
-

Build unstable in Jenkins: Maven » Maven TLP » maven-javadoc-plugin » master #29

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-javadoc-plugin/job/master/29/

> Broken links in Javadoc comments
> 
>
> Key: MJAVADOC-667
> URL: https://issues.apache.org/jira/browse/MJAVADOC-667
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Reporter: Oscar Farga
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.1
>
>
> Some class references in the javadocs comments are pointing to the wrong 
> package
> ./apidocs/org/apache/maven/plugin/javadoc/options/Group.html
> where it should be
> /apidocs/org/apache/maven/plugins/javadoc/options/Group.html
> There are 11 occurrences of this bug in the AbstractJavadocMojo and 1 in the 
> faq.apt file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-scm] elharo merged pull request #112: fix typos in JavaDoc

[GitBox]

elharo merged pull request #112:
URL: https://github.com/apache/maven-scm/pull/112


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo commented on a change in pull request #113: replace deprecated methods

[GitBox]

elharo commented on a change in pull request #113:
URL: https://github.com/apache/maven-scm/pull/113#discussion_r548315532



##
File path: 
maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/AbstractScmMojo.java
##
@@ -445,7 +446,7 @@ public void checkResult( ScmResult result )
 getLog().error( result.getCommandOutput() == null ? "" : 
result.getCommandOutput() );
 
 throw new MojoExecutionException(
-"Command failed." + StringUtils.defaultString( 
result.getProviderMessage() ) );

Review comment:
   done





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo merged pull request #114: [SCM-949] listStyle --> itemsStyle

[GitBox]

elharo merged pull request #114:
URL: https://github.com/apache/maven-scm/pull/114


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo merged pull request #117: link no longer relevant

[GitBox]

elharo merged pull request #117:
URL: https://github.com/apache/maven-scm/pull/117


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Closed] (MJAVADOC-667) Broken links in Javadoc comments

[Michael Osipov (Jira)]

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

Michael Osipov closed MJAVADOC-667.
---
Resolution: Fixed

Fixed with 
[b3ee7016231f31c95e3777e823b9eb40fe6b4bed|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=b3ee7016231f31c95e3777e823b9eb40fe6b4bed].

> Broken links in Javadoc comments
> 
>
> Key: MJAVADOC-667
> URL: https://issues.apache.org/jira/browse/MJAVADOC-667
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Reporter: Oscar Farga
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.1
>
>
> Some class references in the javadocs comments are pointing to the wrong 
> package
> ./apidocs/org/apache/maven/plugin/javadoc/options/Group.html
> where it should be
> /apidocs/org/apache/maven/plugins/javadoc/options/Group.html
> There are 11 occurrences of this bug in the AbstractJavadocMojo and 1 in the 
> faq.apt file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-javadoc-plugin] asfgit closed pull request #64: [MJAVADOC-667] Fix broken links in Javadocs comments and site page.

[GitBox]

asfgit closed pull request #64:
URL: https://github.com/apache/maven-javadoc-plugin/pull/64


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Assigned] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Michael Osipov (Jira)]

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

Michael Osipov reassigned MRESOLVER-153:


Assignee: Michael Osipov

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
> concurrent writes on the {{resolver-status.properties}} file in our tests and 
> causes the error during the {{Properties#load()}} method wich then throws the 
> above error. See this screenshot on how these files look like (cannot add the 
> text here as {{null}} characters aren't shown):
>  !screenshot-1.png! 
> When enab

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254307#comment-17254307
 ] 

Michael Osipov commented on MRESOLVER-153:
--

First of all, thank you for testing! Please provide the exact command you have 
supplied to Maven. I do not fully understand this statement:
bq. Readding the thread synchronization to the TrackingFileManager would solve 
this race condition
To which thread synchronization do you refer exactly?

Looking at your IT (thanks) my best guess is that plugin-api 2.0 and maven-core 
2.0 have intersecting dependencies and since five threads are used to download 
them they interleave. Since you understood the reasoning behind this reverting 
MRESOLVER-132 will cause more problems: it fails on bad-lock/non-lock FS, 
imposes double locks as well as expensive intern/canonical calculations.

* Can you try {{-Daether.metadataResolver.threads=1}} for testing purposes?
* Why do you pass {{-Daether.updateCheckManager.sessionState=false}}? What 
happens when you leave this out?

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.co

[jira] [Updated] (MJAVADOC-667) Broken links in Javadoc comments

[Michael Osipov (Jira)]

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

Michael Osipov updated MJAVADOC-667:

Fix Version/s: 3.2.1

> Broken links in Javadoc comments
> 
>
> Key: MJAVADOC-667
> URL: https://issues.apache.org/jira/browse/MJAVADOC-667
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Reporter: Oscar Farga
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.2.1
>
>
> Some class references in the javadocs comments are pointing to the wrong 
> package
> ./apidocs/org/apache/maven/plugin/javadoc/options/Group.html
> where it should be
> /apidocs/org/apache/maven/plugins/javadoc/options/Group.html
> There are 11 occurrences of this bug in the AbstractJavadocMojo and 1 in the 
> faq.apt file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MJAVADOC-667) Broken links in Javadoc comments

[Michael Osipov (Jira)]

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

Michael Osipov updated MJAVADOC-667:

Summary: Broken links in Javadoc comments  (was: Broken links in javadoc 
comments)

> Broken links in Javadoc comments
> 
>
> Key: MJAVADOC-667
> URL: https://issues.apache.org/jira/browse/MJAVADOC-667
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Reporter: Oscar Farga
>Priority: Minor
>
> Some class references in the javadocs comments are pointing to the wrong 
> package
> ./apidocs/org/apache/maven/plugin/javadoc/options/Group.html
> where it should be
> /apidocs/org/apache/maven/plugins/javadoc/options/Group.html
> There are 11 occurrences of this bug in the AbstractJavadocMojo and 1 in the 
> faq.apt file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (MJAVADOC-667) Broken links in Javadoc comments

[Michael Osipov (Jira)]

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

Michael Osipov reassigned MJAVADOC-667:
---

Assignee: Michael Osipov

> Broken links in Javadoc comments
> 
>
> Key: MJAVADOC-667
> URL: https://issues.apache.org/jira/browse/MJAVADOC-667
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Reporter: Oscar Farga
>Assignee: Michael Osipov
>Priority: Minor
>
> Some class references in the javadocs comments are pointing to the wrong 
> package
> ./apidocs/org/apache/maven/plugin/javadoc/options/Group.html
> where it should be
> /apidocs/org/apache/maven/plugins/javadoc/options/Group.html
> There are 11 occurrences of this bug in the AbstractJavadocMojo and 1 in the 
> faq.apt file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] michael-o commented on a change in pull request #416: [MNG-4660] Increase usefulness of logging (2)

[GitBox]

michael-o commented on a change in pull request #416:
URL: https://github.com/apache/maven/pull/416#discussion_r548293341



##
File path: maven-core/src/main/java/org/apache/maven/ReactorReader.java
##
@@ -263,15 +271,28 @@ private boolean isPackagedArtifactUpToDate( MavenProject 
project, File packagedA
 while ( iterator.hasNext() )
 {
 Path outputFile = iterator.next();
+
+if ( Files.isDirectory(  outputFile ) )
+{
+continue;
+}
+
 long outputFileLastModified = Files.getLastModifiedTime( 
outputFile ).toMillis();
 if ( outputFileLastModified > artifactLastModified )
 {
-LOGGER.warn(
-"Packaged artifact for {} is not up-to-date 
compared to the build output directory; "
-  + "file {} is more recent than {}.",
-project.getArtifactId(),
-relativizeOutputFile( outputFile ), 
relativizeOutputFile( packagedArtifactFile.toPath() )
-);
+File alternative = determineLooseDirectoryForArtifact( 
project, artifact );
+if ( alternative != null )
+{
+LOGGER.warn( "File {} is more recent than the packaged 
artifact for {}; using {} instead",

Review comment:
   Please put args to logging in single quotes if they are non-numbers or 
collections.

##
File path: maven-core/src/main/java/org/apache/maven/ReactorReader.java
##
@@ -263,15 +271,28 @@ private boolean isPackagedArtifactUpToDate( MavenProject 
project, File packagedA
 while ( iterator.hasNext() )
 {
 Path outputFile = iterator.next();
+
+if ( Files.isDirectory(  outputFile ) )
+{
+continue;
+}
+
 long outputFileLastModified = Files.getLastModifiedTime( 
outputFile ).toMillis();
 if ( outputFileLastModified > artifactLastModified )
 {
-LOGGER.warn(
-"Packaged artifact for {} is not up-to-date 
compared to the build output directory; "
-  + "file {} is more recent than {}.",
-project.getArtifactId(),
-relativizeOutputFile( outputFile ), 
relativizeOutputFile( packagedArtifactFile.toPath() )
-);
+File alternative = determineLooseDirectoryForArtifact( 
project, artifact );
+if ( alternative != null )
+{
+LOGGER.warn( "File {} is more recent than the packaged 
artifact for {}; using {} instead",
+relativizeOutputFile( outputFile ), 
project.getArtifactId(),
+relativizeOutputFile( alternative.toPath() ) );
+}
+else
+{
+LOGGER.warn( "File {} is more recent than the packaged 
artifact for {}; "
++ "cannot use a loose directory for this type 
of artifact",

Review comment:
   I have a bit of a problem with this: where is the defition of a "loose 
directory"?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (MNG-7029) Remove super POM release profile

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254285#comment-17254285
 ] 

Michael Osipov edited comment on MNG-7029 at 12/23/20, 10:19 PM:
-

Then we will need to wait for MNG-7051. Is that what you are waiting for?


was (Author: michael-o):
Then we will need to wait for MNG-7051.

> Remove super POM release profile
> 
>
> Key: MNG-7029
> URL: https://issues.apache.org/jira/browse/MNG-7029
> Project: Maven
>  Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> The release profile has been deprecated for a long time with scheduled for 
> removal. This ticket formally represents this task.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7029) Remove super POM release profile

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254285#comment-17254285
 ] 

Michael Osipov commented on MNG-7029:
-

Then we will need to wait for MNG-7051.

> Remove super POM release profile
> 
>
> Key: MNG-7029
> URL: https://issues.apache.org/jira/browse/MNG-7029
> Project: Maven
>  Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> The release profile has been deprecated for a long time with scheduled for 
> removal. This ticket formally represents this task.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-deploy-plugin] michael-o commented on pull request #15: [MDEPLOY-265] Maintain backwards compatibility for alt*DeploymentRepository in id::default::url format

[GitBox]

michael-o commented on pull request #15:
URL: 
https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750494533


   Sorry for the confusion. There was a nasty typo in my question. I wll 
rephrase: How do you know/decide on the CI server to which hosted repo a 
deployment will go and why is not possible to have that kind of information 
staticially in the POMs?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MEAR-294) JAR with provided scope should be removed from Class-Path entry of EAR module MANIFEST.mf

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254283#comment-17254283
 ] 

Hudson commented on MEAR-294:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven-ear-plugin » master #53

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/53/

> JAR with provided scope should be removed from Class-Path entry of EAR module 
> MANIFEST.mf
> -
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
> Fix For: 3.2.0
>
>
> JAR dependency of EAR with provided scope should be removed from 
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or 
> {{skinnyModules}} option is turned on or if EAR module doesn't contain all of 
> its dependencies (like EJB module). This issue looks to be a bug of solution 
> of MEAR-243 bug.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-scm] michael-o commented on a change in pull request #113: replace deprecated methods

[GitBox]

michael-o commented on a change in pull request #113:
URL: https://github.com/apache/maven-scm/pull/113#discussion_r548278697



##
File path: 
maven-scm-plugin/src/main/java/org/apache/maven/scm/plugin/AbstractScmMojo.java
##
@@ -445,7 +446,7 @@ public void checkResult( ScmResult result )
 getLog().error( result.getCommandOutput() == null ? "" : 
result.getCommandOutput() );
 
 throw new MojoExecutionException(
-"Command failed." + StringUtils.defaultString( 
result.getProviderMessage() ) );

Review comment:
   The full stop should be replaced by a colon followed by a space.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] michael-o commented on pull request #92: [SCM-928] added scm type 'mount-repos' to support google repo tool for checkout manifest.xml

[GitBox]

michael-o commented on pull request #92:
URL: https://github.com/apache/maven-scm/pull/92#issuecomment-750489898


   I'll need time to process this.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-ear-plugin] elharo merged pull request #31: [MEAR-294] Removal of provided artifacts from the Class-Path entry of MANIFEST.mf

[GitBox]

elharo merged pull request #31:
URL: https://github.com/apache/maven-ear-plugin/pull/31


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7024) Directory instead of file in an artifact

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254261#comment-17254261
 ] 

Michael Osipov commented on MNG-7024:
-

I like Robert's clean separation idea.

> Directory instead of file in an artifact
> 
>
> Key: MNG-7024
> URL: https://issues.apache.org/jira/browse/MNG-7024
> Project: Maven
>  Issue Type: Bug
>Reporter: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.x-candidate
>
>
> When trying to build camel assembly with maven 3.7.0-SNAPSHOT, I hit the 
> following exception
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.0.0:single (bin) on project 
> apache-camel: Failed to create assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:3.0.0:single (bin) on 
> project apache-camel: Failed to create assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:218)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:159)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:151)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:115)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:79)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:64)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:131)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create 
> assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file.
> at org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute 
> (AbstractAssemblyMojo.java:530)
> at org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute 
> (SingleAssemblyMojo.java:58)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:136)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:159)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:151)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:115)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:79)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:64)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:131)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  

[jira] [Commented] (MNG-7032) Option -B still showing formatting when used with --version

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254259#comment-17254259
 ] 

Michael Osipov commented on MNG-7032:
-

Will look it again. As far as I remember it was a bit tricky because we 
actually have to defer the installation of Jansi until we can evaluate CLI. 
[~gnodet] told me this.

> Option -B still showing formatting when used with --version
> ---
>
> Key: MNG-7032
> URL: https://issues.apache.org/jira/browse/MNG-7032
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line, Logging
>Affects Versions: 3.6.3
> Environment: Running Ubuntu 20.04.1 LTS (Focal Fossa)
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: /opt/java/jdk-11.0.8+10
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-54-generic", arch: "amd64", family: "unix"
>Reporter: Christian Koop
>Priority: Major
>  Labels: easyfix
> Fix For: 4.0.x-candidate
>
>
> When running {{mvn -B --version}} the first line ({{'Apache Maven 3.6.3'}}) 
> is written in bold although the option {{-B}} should have stripped that as it 
> does with color in combination with other options.
> This causes an issue when logging to a file as the ASCII escape sequence is 
> written to it in plain text (causing confusion).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] michael-o commented on a change in pull request #415: [MNG-7032] do not print colours for --version when in batch mode.

[GitBox]

michael-o commented on a change in pull request #415:
URL: https://github.com/apache/maven/pull/415#discussion_r548254291



##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -433,6 +433,8 @@ void cli( CliRequest cliRequest )
 
 if ( cliRequest.commandLine.hasOption( CLIManager.VERSION ) )
 {
+// MNG-7032: Also disable colours if in batch mode

Review comment:
   This comment is redundant because we have commit messages and blames.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-resolver] michael-o commented on a change in pull request #83: [MRESOLVER-151] Enforce a checksum policy to be provided explicitly

[GitBox]

michael-o commented on a change in pull request #83:
URL: https://github.com/apache/maven-resolver/pull/83#discussion_r548251877



##
File path: 
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultChecksumPolicyProviderTest.java
##
@@ -124,7 +124,7 @@ public void 
testGetEffectiveChecksumPolicy_DifferentPolicies()
 }
 }
 
-@Test
+@Test( expected = IllegalArgumentException.class )

Review comment:
   Yepp, that's true. Will change!





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-surefire] sullis opened a new pull request #329: ci: JDK 8, JDK 11, JDK 15

[GitBox]

sullis opened a new pull request #329:
URL: https://github.com/apache/maven-surefire/pull/329


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MCOMPILER-447) Unable to compile modularized test for a multi-version jar that is not a java module by default

[Claudio Corsi (Jira)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254237#comment-17254237
 ] 

Claudio Corsi commented on MCOMPILER-447:
-

For some reason my email reply did not cause this issue to be updated.  So here 
is my response to the above question.

 

[~bmarwell]

No worries, I looked at the aforementioned link and gave it a try. I was able 
to use that technique but it seems wrong that someone would have to go through 
all of that trouble to create a multi-version jar file. Especially one that is 
a combination like the one that I am trying to create/use. The first part of 
this first will remove the need to add such a configuration within the pom 
file. It would make the pom file cleaner and more like what is expected.

As for a use-case, you can take the added pom file that is part of the 
MCOMPLIER-447 integration test. To reproduce this case, you only would need to 
use the compile-java-9 and test-compile-java-9 executions at:

https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/pom.xml#L57
https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/pom.xml#L83

To not reproduce the other issue mentioned in this issue. You need to comment 
out the Logger.getLogger call within the Test.java file at

https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/src/test/test9/org/bar/Test.java#L29

> Unable to compile modularized test for a multi-version jar that is not a java 
> module by default
> ---
>
> Key: MCOMPILER-447
> URL: https://issues.apache.org/jira/browse/MCOMPILER-447
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Claudio Corsi
>Priority: Blocker
>
> I have a single module project that is creating a mult-version jar file.  By 
> default the multi-version jar is not a java module because it is being built 
> for jdk 7 or newer.  The multi-version jar does contain a java module 
> definition within the /META-INF/versions/9 directory.  I am trying to create 
> a integration test that uses the java module of the code.  When I tried 
> building the module tests I got the UnsupportedOperationException with the 
> message:
>  
>   Can't compile test sources when main sources are missing a module descriptor
>  
> The issue was that the main module does not contain a module descriptor but 
> the test does contain a module descriptor. 
>  
> I then forked a copy of the maven compiler plugin.  I created an integration 
> test and was able to fix this issue.  The issue was that I needed to find the 
> latest version of the java-module for the module generated multi-version jar 
> file.  This because the module descriptor and was added to the javac command.
>  
> I then tried to build my test source again and this time it stated that it 
> was not able to find a class because it is part of a jar file that does not 
> contain any java module definition.  I updated the integration test and was 
> able to add another fix to the forked copy that resolved that issue.  The 
> issue was that all non-java-module jar files should be included as part of 
> the class path.  They were all being included as part of the module path.
>  
> I then used the fixed jar file to build my project and it failed again 
> because of it accessing a unnamed module.  I had to finally update my pom to 
> include a --add-reads command line option.  I will not try to add a fix to 
> this issue since this issue has a workaround unlike the other two that didn't.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (ARCHETYPE-490) Required property default value incorrect when using system property

[Benjamin Marwell (Jira)]

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

Benjamin Marwell updated ARCHETYPE-490:
---
Description: 
When performing a generation while passing in artifactId, groupId, or version 
as a system property, required property default values using velocity 
expressions are evaluated incorrectly.

As an example, I have an archetype with groupId com.apache and artifactId 
automation-archetype. If I attempt to generate using the following command:

mvn archetype:generate -DarchetypeGroupId=com.apache 
-DarchetypeArtifactId=automation-archetype -DartifactId=hello-world-automation

And I have a required property defined as:
{code:xml}

  ${artifactId.replace("-", "_")}
{code}
Then the resulting property is evaluated to automation_archetype instead of 
hello_world_automation.

This changed from version 2.2 to 2.3 by a patch introduced in ARCHETYPE-397.

Proposed additional patch is attached.

  was:
When performing a generation while passing in artifactId, groupId, or version 
as a system property, required property default values using velocity 
expressions are evaluated incorrectly.

As an example, I have an archetype with groupId com.apache and artifactId 
automation-archetype. If I attempt to generate using the following command:

mvn archetype:generate -DarchetypeGroupId=com.apache 
-DarchetypeArtifactId=automation-archetype -DartifactId=hello-world-automation

And I have a required property defined as:


${artifactId.replace("-", "_")}


Then the resulting property is evaluated to automation_archetype instead of 
hello_world_automation.

This changed from version 2.2 to 2.3 by a patch introduced in ARCHETYPE-397.

Proposed additional patch is attached.


> Required property default value incorrect when using system property
> 
>
> Key: ARCHETYPE-490
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-490
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Generator, Plugin
>Affects Versions: 2.3, 2.4
>Reporter: Christopher Rowland
>Priority: Major
>  Labels: easyfix, newbie, patch
> Attachments: ARCHETYPE-490.patch
>
>
> When performing a generation while passing in artifactId, groupId, or version 
> as a system property, required property default values using velocity 
> expressions are evaluated incorrectly.
> As an example, I have an archetype with groupId com.apache and artifactId 
> automation-archetype. If I attempt to generate using the following command:
> mvn archetype:generate -DarchetypeGroupId=com.apache 
> -DarchetypeArtifactId=automation-archetype -DartifactId=hello-world-automation
> And I have a required property defined as:
> {code:xml}
> 
>   ${artifactId.replace("-", "_")}
> {code}
> Then the resulting property is evaluated to automation_archetype instead of 
> hello_world_automation.
> This changed from version 2.2 to 2.3 by a patch introduced in ARCHETYPE-397.
> Proposed additional patch is attached.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (ARCHETYPE-400) method DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final String filePath, final Context context) doesn't work when two tokens are close to each other

[Benjamin Marwell (Jira)]

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

Benjamin Marwell resolved ARCHETYPE-400.

Resolution: Duplicate

> method DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final String 
> filePath, final Context context) doesn't work when two tokens are close to 
> each other
> 
>
> Key: ARCHETYPE-400
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-400
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Romain Douet
>Priority: Minor
>  Labels: GoodForNewContributors
>
> Hello,
> In a maven archetype we can use properties in filepaths which are replaced 
> when the archetype is generated.
> e.g.:
> Properties :
> * int1FirstMaj = Inscription
> * nameMaj = TEST
> {code:java}
> filepath = __int1FirstMajnameMaj__RemoteService.java
> {code}
> The method {{DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final 
> String filePath, final Context context)}} use the delimiter '{{\_\_}}' to 
> replace the properties. 
> So, after the build, my filepath should be : 
> {{InscriptionTESTRemoteService.java}}
> The problem is the following:
>  - The method looks for the start delimiter index which is 0 in my exemple 
> and the end delimiter index which is 14. 
>  - It replaces {{\_\_int1FirstMaj\_\_}} with 'Inscription'. My filepath is 
> now 'Inscription__nameMaj__RemoteService.java'.
>  - The method changes the start index value to : start = end + 
> DELIMITER.length() + 1; So the start index is now : 14+2+1=17
>  - For the second property {{\_\_nameMaj\_\_}} the method looks for the start 
> delimiter index from the new start index (17). But the delimiter for the 
> property {{\_\_nameMaj\_\_}} is at the index 11 so the property 
> {{\_\_nameMaj\_\_}} is never found nor replaced.
>  
>  To fix this issue, we have to replace the line 403 in the file 
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator from :
> {code:java}
>   start = end + DELIMITER.length() + 1;
> {code}
>  to :
> {code:java}
>   start = start +contextPropertyValue.length();
> {code}
>   
>   contextPropertyValue being the value of the propety 'int1FirstMaj' which is 
> 'Inscription'. The new start index becomes 0+11=11 and the next property 
> {{\_\_nameMaj\_\_}} will be found and replaced.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7024) Directory instead of file in an artifact

[Robert Scholte (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254223#comment-17254223
 ] 

Robert Scholte commented on MNG-7024:
-

Looking closer at this, it exposes the problem of a workaround that was 
probably introduced in Maven 3: abusing the project-artifact to temporary 
attach the outputDirectory, so the compiler of other modules can pick it up for 
their classpath.
This is probably the right moment to split this into two:
- artifacts can only attach regular files, no more directories.
- we need some kind of "internal dependency instance" that will refer to the 
MavenProject. Plugins such as the maven-compiler-plugin must be able to build 
up the classpath based on both types of dependencies.

> Directory instead of file in an artifact
> 
>
> Key: MNG-7024
> URL: https://issues.apache.org/jira/browse/MNG-7024
> Project: Maven
>  Issue Type: Bug
>Reporter: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.x-candidate
>
>
> When trying to build camel assembly with maven 3.7.0-SNAPSHOT, I hit the 
> following exception
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.0.0:single (bin) on project 
> apache-camel: Failed to create assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:3.0.0:single (bin) on 
> project apache-camel: Failed to create assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:218)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:159)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:151)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:115)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:79)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:64)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:131)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create 
> assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file.
> at org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute 
> (AbstractAssemblyMojo.java:530)
> at org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute 
> (SingleAssemblyMojo.java:58)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:136)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:159)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:151)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:115)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModul

[jira] [Commented] (MNG-7024) Directory instead of file in an artifact

[Robert Scholte (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254218#comment-17254218
 ] 

Robert Scholte commented on MNG-7024:
-

{code:xml}

assembly


!noassembly



apache-camel


{code}
This explains why it is active by default

> Directory instead of file in an artifact
> 
>
> Key: MNG-7024
> URL: https://issues.apache.org/jira/browse/MNG-7024
> Project: Maven
>  Issue Type: Bug
>Reporter: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.x-candidate
>
>
> When trying to build camel assembly with maven 3.7.0-SNAPSHOT, I hit the 
> following exception
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:3.0.0:single (bin) on project 
> apache-camel: Failed to create assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-assembly-plugin:3.0.0:single (bin) on 
> project apache-camel: Failed to create assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:218)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:159)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:151)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:115)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:79)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:64)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:131)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main 
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to create 
> assembly: Error adding file 
> 'org.apache.camel:camel-spring:jar:3.7.0-SNAPSHOT' to archive: 
> /Users/gnodet/work/git/camel/components/camel-spring/target/classes isn't a 
> file.
> at org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute 
> (AbstractAssemblyMojo.java:530)
> at org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute 
> (SingleAssemblyMojo.java:58)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:136)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:159)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:151)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:115)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:79)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>  (SingleThreadedBuilder.java:64)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:131)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:319)
> at org.ap

[jira] [Updated] (ARCHETYPE-400) method DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final String filePath, final Context context) doesn't work when two tokens are close to each other

[Benjamin Marwell (Jira)]

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

Benjamin Marwell updated ARCHETYPE-400:
---
Description: 
Hello,

In a maven archetype we can use properties in filepaths which are replaced when 
the archetype is generated.

e.g.:
Properties :
* int1FirstMaj = Inscription
* nameMaj = TEST


{code:java}
filepath = __int1FirstMajnameMaj__RemoteService.java
{code}


The method {{DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final 
String filePath, final Context context)}} use the delimiter '{{\_\_}}' to 
replace the properties. 

So, after the build, my filepath should be : 
{{InscriptionTESTRemoteService.java}}

The problem is the following:
 - The method looks for the start delimiter index which is 0 in my exemple and 
the end delimiter index which is 14. 
 - It replaces {{\_\_int1FirstMaj\_\_}} with 'Inscription'. My filepath is now 
'Inscription__nameMaj__RemoteService.java'.
 - The method changes the start index value to : start = end + 
DELIMITER.length() + 1; So the start index is now : 14+2+1=17
 - For the second property {{\_\_nameMaj\_\_}} the method looks for the start 
delimiter index from the new start index (17). But the delimiter for the 
property {{\_\_nameMaj\_\_}} is at the index 11 so the property 
{{\_\_nameMaj\_\_}} is never found nor replaced.
 
 To fix this issue, we have to replace the line 403 in the file 
org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator from :

{code:java}
  start = end + DELIMITER.length() + 1;
{code}

 to :

{code:java}
  start = start +contextPropertyValue.length();
{code}
  
  contextPropertyValue being the value of the propety 'int1FirstMaj' which is 
'Inscription'. The new start index becomes 0+11=11 and the next property 
{{\_\_nameMaj\_\_}} will be found and replaced.

  was:
Hello,

In a maven archetype we can use properties in filepaths which are replaced when 
the archetype is generated.

e.g.:
Properties :
- int1FirstMaj = Inscription
- nameMaj = TEST

filepath = __int1FirstMajnameMaj__RemoteService.java

The method DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final String 
filePath, final Context context) use the delimiter '__' to replace the 
properties. 

So, after the build, my filepath should be : InscriptionTESTRemoteService.java

The problem is the following:
 - The method looks for the start delimiter index which is 0 in my exemple and 
the end delimiter index which is 14. 
 - It replaces '__int1FirstMaj__' with 'Inscription'. My filepath is now 
'Inscription__nameMaj__RemoteService.java'.
 - The method changes the start index value to : start = end + 
DELIMITER.length() + 1; So the start index is now : 14+2+1=17
 - For the second property '__nameMaj__' the method looks for the start 
delimiter index from the new start index (17). But the delimiter for the 
property '__nameMaj__' is at the index 11 so the property '__nameMaj__' is 
never found nor replaced.
 
 To fix this issue, we have to replace the line 403 in the file 
org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator from :
  start = end + DELIMITER.length() + 1;
 to :
  start = start +contextPropertyValue.length();
  
  contextPropertyValue being the value of the propety 'int1FirstMaj' which is 
'Inscription'. The new start index becomes 0+11=11 and the next property 
'__nameMaj__' will be found and replaced.


> method DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final String 
> filePath, final Context context) doesn't work when two tokens are close to 
> each other
> 
>
> Key: ARCHETYPE-400
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-400
> Project: Maven Archetype
>  Issue Type: Bug
>  Components: Generator
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Romain Douet
>Priority: Minor
>  Labels: GoodForNewContributors
>
> Hello,
> In a maven archetype we can use properties in filepaths which are replaced 
> when the archetype is generated.
> e.g.:
> Properties :
> * int1FirstMaj = Inscription
> * nameMaj = TEST
> {code:java}
> filepath = __int1FirstMajnameMaj__RemoteService.java
> {code}
> The method {{DefaultFilesetArchetypeGenerator.replaceFilenameTokens(final 
> String filePath, final Context context)}} use the delimiter '{{\_\_}}' to 
> replace the properties. 
> So, after the build, my filepath should be : 
> {{InscriptionTESTRemoteService.java}}
> The problem is the following:
>  - The method looks for the start delimiter index which is 0 in my exemple 
> and the end delimiter index which is 14. 
>  - It replaces {{\_\_int1FirstMaj\_\_}} with 'Inscription'. My filepath is 
> now 'Inscription__nameMaj__RemoteService.java'.

[jira] [Closed] (MCOMPILER-441) NullPointerException if module-info.java exports non-existing package

[Benjamin Marwell (Jira)]

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

Benjamin Marwell closed MCOMPILER-441.
--
Resolution: Cannot Reproduce

Could not reproduce, closing

> NullPointerException if module-info.java exports non-existing package
> -
>
> Key: MCOMPILER-441
> URL: https://issues.apache.org/jira/browse/MCOMPILER-441
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0, 3.8.0, 3.8.1
>Reporter: Benjamin Marwell
>Priority: Major
>  Labels: beginner, beginner-friendly, easy, easy-fix, easyfix
>
> * Create a java9+ project with src/main/java/module-info.java.
>  * Export a package 
>  * NPE occurs instead of a useful error message.
> Stacktrace and test case will follow.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] mthmulders commented on a change in pull request #414: [MNG-4660] Increase usefulness of logging

[GitBox]

mthmulders commented on a change in pull request #414:
URL: https://github.com/apache/maven/pull/414#discussion_r548119367



##
File path: maven-core/src/main/java/org/apache/maven/ReactorReader.java
##
@@ -266,7 +266,12 @@ private boolean isPackagedArtifactUpToDate( MavenProject 
project, File packagedA
 long outputFileLastModified = Files.getLastModifiedTime( 
outputFile ).toMillis();
 if ( outputFileLastModified > artifactLastModified )
 {
-logger.warn( "Packaged artifact is not up-to-date compared 
to the build output directory" );
+LOGGER.warn(
+"Packaged artifact for {} is not up-to-date 
compared to the build output directory; "

Review comment:
   Since this PR is already merged, I've created a follow-up where we can 
discuss the actual message: https://github.com/apache/maven/pull/416.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-integration-testing] mthmulders opened a new pull request #91: [MNG-4660] Increase usefulness of logging (2)

[GitBox]

mthmulders opened a new pull request #91:
URL: https://github.com/apache/maven-integration-testing/pull/91


   When the user resumes a build, they could see a message "Packaged artifact 
is not up-to-date compared to the build output directory". This could even be 
logged multiple times for one build. It was unclear why it was logged and what 
a user could do to address it. This test accompanies apache/maven#416.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] mthmulders opened a new pull request #416: [MNG-4660] Increase usefulness of logging (2)

[GitBox]

mthmulders opened a new pull request #416:
URL: https://github.com/apache/maven/pull/416


   When the user resumes a build (MNG-4660), they could see a message "Packaged 
artifact is not up-to-date compared to the build output directory". This could 
even be logged multiple times for one build. It was unclear why it was logged 
and what a user could do to address it. This change adds a little bit of detail 
to that message so it becomes more clear to the user what has happened and 
where to look for solutions.
   
   The integration test is updated as well.
   
   ICLA and CCLA signed.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7032) Option -B still showing formatting when used with --version

[Benjamin Marwell (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254158#comment-17254158
 ] 

Benjamin Marwell commented on MNG-7032:
---

NVM, the same NPE test failure is there on master when using OpenJ9.

> Option -B still showing formatting when used with --version
> ---
>
> Key: MNG-7032
> URL: https://issues.apache.org/jira/browse/MNG-7032
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line, Logging
>Affects Versions: 3.6.3
> Environment: Running Ubuntu 20.04.1 LTS (Focal Fossa)
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: /opt/java/jdk-11.0.8+10
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-54-generic", arch: "amd64", family: "unix"
>Reporter: Christian Koop
>Priority: Major
>  Labels: easyfix
> Fix For: 4.0.x-candidate
>
>
> When running {{mvn -B --version}} the first line ({{'Apache Maven 3.6.3'}}) 
> is written in bold although the option {{-B}} should have stripped that as it 
> does with color in combination with other options.
> This causes an issue when logging to a file as the ASCII escape sequence is 
> written to it in plain text (causing confusion).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7032) Option -B still showing formatting when used with --version

[Benjamin Marwell (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254157#comment-17254157
 ] 

Benjamin Marwell commented on MNG-7032:
---

The PR will deal with both, but unrelated tests fail and I get an NPE locally 
where I would least expect it.

> Option -B still showing formatting when used with --version
> ---
>
> Key: MNG-7032
> URL: https://issues.apache.org/jira/browse/MNG-7032
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line, Logging
>Affects Versions: 3.6.3
> Environment: Running Ubuntu 20.04.1 LTS (Focal Fossa)
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: /opt/java/jdk-11.0.8+10
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-54-generic", arch: "amd64", family: "unix"
>Reporter: Christian Koop
>Priority: Major
>  Labels: easyfix
> Fix For: 4.0.x-candidate
>
>
> When running {{mvn -B --version}} the first line ({{'Apache Maven 3.6.3'}}) 
> is written in bold although the option {{-B}} should have stripped that as it 
> does with color in combination with other options.
> This causes an issue when logging to a file as the ASCII escape sequence is 
> written to it in plain text (causing confusion).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] bmarwell commented on pull request #415: [MNG-7032] do not print colours for --version when in batch mode.

[GitBox]

bmarwell commented on pull request #415:
URL: https://github.com/apache/maven/pull/415#issuecomment-750395178


   Huh, I need some help with the tests.
   I do not think any IT should fail because of my change, but they did fail: 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/2/testReport/
   
   On the other hand, I get an NPE locally – in 
`MavenCliTest.testStyleColors:340`. I really cannot explain what is going on 
here. Is `cli` being nulled? If so, why?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] bmarwell opened a new pull request #415: [MNG-7032] do not print colours for --version when in batch mode.

[GitBox]

bmarwell opened a new pull request #415:
URL: https://github.com/apache/maven/pull/415


   This PR will fix MNG-7032: ANSI will not be used when using both 
`--batch-mode` and `--version`.
   This is a bug because with batch mode, ANSI colours should not be used.
   
   The tests works on a char level: By comparing the stripped and the 
non-stripped version, the test would fail if they differed. Or put in another 
way: If the sysout-version contained ANSI colour information, it would not 
match the stripped version.
   ---
   
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [X] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) filed 
  for the change (usually before you start working on it).  Trivial 
changes like typos do not 
  require a JIRA issue.  Your pull request should address just this 
issue, without 
  pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line 
and body.
- [X] Format the pull request title like `[MNG-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MNG-XXX` with the appropriate JIRA issue. Best 
practice
  is to use the JIRA issue title in the pull request title and in the 
first line of the 
  commit message.
- [X] Write a pull request description that is detailed enough to 
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more 
thorough check will 
  be performed on your pull request automatically.
- [X] You have run the [Core IT][core-its] successfully.
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License 
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 
2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
- [ ] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
- [ ] In any other case, please file an [Apache Individual Contributor 
License Agreement](https://www.apache.org/licenses/icla.pdf).
   
   [core-its]: https://maven.apache.org/core-its/core-it-suite/
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (ARCHETYPE-556) Property in default-value is not replaced when using automated mode

[Tushar (Jira)]

[ 
https://issues.apache.org/jira/browse/ARCHETYPE-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254144#comment-17254144
 ] 

Tushar commented on ARCHETYPE-556:
--

I am able to repro this in batch mode on my maven installation version 3.6.3  
(maven-archetype-plugin version 3.2.0)

> Property in default-value is not replaced when using automated mode
> ---
>
> Key: ARCHETYPE-556
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-556
> Project: Maven Archetype
>  Issue Type: Bug
>Reporter: Olivier Cailloux
>Assignee: Robert Scholte
>Priority: Major
>
> In {{archetype-metadata.xml}} I have:
> {code:xml}
> 
>   ${groupId}.${artifactId}
> 
> {code}
> This default value is used correctly when using mvn archetype in interactive 
> mode, but it is used incorrectly when using mvn archetype -B. In that case, 
> the value of package is literally ${groupId}.${artifactId} with no 
> replacement.
> To reproduce, type:
> {code:java}
> mvn -B archetype:generate -DarchetypeGroupId=io.github.oliviercailloux 
> -DarchetypeArtifactId=java-se-1.8-archetype -DgroupId=mygroupid 
> -DartifactId=myartifactid
> {code}
> then {{ls a/src/main/java/}}. Observe that the directory is literally 
> {{$\{groupId}}} instead of the expected {{mygroupid}}.
> This archetype is published to Maven Central and its source code is 
> [here|https://github.com/oliviercailloux/java-se-1.8-archetype].
> Possibly related: 490, comment of 397.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-deploy-plugin] philsttr commented on pull request #15: [MDEPLOY-265] Maintain backwards compatibility for alt*DeploymentRepository in id::default::url format

[GitBox]

philsttr commented on pull request #15:
URL: 
https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750388269


   > the target repo does not depend on the group/artifact id, but no the CI 
server performing actions?
   
   (I do not quite understand the question, but I'll attempt to answer what I 
think you are asking.  If this does not answer your question, please clarify 
the question.)
   
   Each of our many repos define their dependencies and plugins, and version of 
each.  They are free to use whatever they need.  They are currently using 
various versions of the maven-deploy-plugin  (but not 3.0.0-M1, since that 
broke compatibility).
   
   The CI server does not define dependencies, plugins, or versions.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254137#comment-17254137
 ] 

Hudson commented on MNG-4660:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #73

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/73/

> Use of --resume-from in multi-module project fails with missing inter-module 
> dependencies
> -
>
> Key: MNG-4660
> URL: https://issues.apache.org/jira/browse/MNG-4660
> Project: Maven
>  Issue Type: Bug
>  Components: Reactor and workspace
>Affects Versions: 2.2.1, 3.0-beta-1
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_17
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"
>Reporter: Brian Ferris
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Attachments: modules-parent.tar.gz
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> In a simple multi-module project with a parent pom "modules-parent", two sub 
> modules "module-a" and "module-b", where B depends on A, I've not been able 
> to get the Maven "--resume-from" feature to work.
> Specifically, I expect:
> > mvn --resume-from module-b test
> would resume execution of the "test" goal in "module-b".  Instead it fails 
> with a missing artifact error:
> > [INFO] Failed to resolve artifact.
> > 
> > Missing:
> > --
> > 1) org.test:module-a:jar:0.0.1-SNAPSHOT
> Why isn't Maven resolving the within-multi-module dependency?  I've attached 
> a simple project that reproduces the problem with Maven 2.2.1 and Maven 
> 3.0-beta-1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] rfscholte commented on a change in pull request #414: [MNG-4660] Increase usefulness of logging

[GitBox]

rfscholte commented on a change in pull request #414:
URL: https://github.com/apache/maven/pull/414#discussion_r548026211



##
File path: maven-core/src/main/java/org/apache/maven/ReactorReader.java
##
@@ -266,7 +266,12 @@ private boolean isPackagedArtifactUpToDate( MavenProject 
project, File packagedA
 long outputFileLastModified = Files.getLastModifiedTime( 
outputFile ).toMillis();
 if ( outputFileLastModified > artifactLastModified )
 {
-logger.warn( "Packaged artifact is not up-to-date compared 
to the build output directory" );
+LOGGER.warn(
+"Packaged artifact for {} is not up-to-date 
compared to the build output directory; "

Review comment:
   One other thing I was missing is: which one is used?
   Could this be compressed to something like: 
   
   For ARTIFACTID the jar is older than o.a.m.some.File.class: using 
target/classes.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-integration-testing] mthmulders closed pull request #90: [MNG-4660] Increase usefulness of logging

[GitBox]

mthmulders closed pull request #90:
URL: https://github.com/apache/maven-integration-testing/pull/90


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-integration-testing] mthmulders commented on pull request #90: [MNG-4660] Increase usefulness of logging

[GitBox]

mthmulders commented on pull request #90:
URL: 
https://github.com/apache/maven-integration-testing/pull/90#issuecomment-750358703


   Merged in acbb518ac.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] mthmulders closed pull request #414: [MNG-4660] Increase usefulness of logging

[GitBox]

mthmulders closed pull request #414:
URL: https://github.com/apache/maven/pull/414


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] mthmulders commented on pull request #414: [MNG-4660] Increase usefulness of logging

[GitBox]

mthmulders commented on pull request #414:
URL: https://github.com/apache/maven/pull/414#issuecomment-750357666


   Merged in 7e21a52.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-integration-testing] rfscholte commented on a change in pull request #79: [MNG-7022] Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos ba…

[GitBox]

rfscholte commented on a change in pull request #79:
URL: 
https://github.com/apache/maven-integration-testing/pull/79#discussion_r548011136



##
File path: 
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4338OptionalMojosTest.java
##
@@ -35,7 +35,7 @@
 
 public MavenITmng4338OptionalMojosTest()
 {
-super( "[3.0,)" );
+super( "[3.0,3.7.0)" );

Review comment:
   can be pushed to 4.0.0-alpha-1 :)





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-7029) Remove super POM release profile

[Robert Scholte (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254121#comment-17254121
 ] 

Robert Scholte commented on MNG-7029:
-

Only if the activation of non-existing profiles breaks the build, we can accept 
this change.
Otherwise a lot of invalid releases will be created, because by default the 
maven-release-plugin activates this release profile.

> Remove super POM release profile
> 
>
> Key: MNG-7029
> URL: https://issues.apache.org/jira/browse/MNG-7029
> Project: Maven
>  Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> The release profile has been deprecated for a long time with scheduled for 
> removal. This ticket formally represents this task.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

[Tibor Digana (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254120#comment-17254120
 ] 

Tibor Digana commented on SUREFIRE-1546:


[~reitzmichnicht] I believe that the property {{junit5.version}} has no null 
but we can continue with isolated project.
I can isolate the detailed test in a separate GitHub project where you and me 
can investigate this issue more clearly.
So I will send you a link with the project.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

[Tibor Digana (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254120#comment-17254120
 ] 

Tibor Digana edited comment on SUREFIRE-1546 at 12/23/20, 3:09 PM:
---

[~reitzmichnicht] I believe that the property {{junit5.version}} has no null 
value but we can continue with isolated project.
I can isolate the detailed test in a separate GitHub project where you and me 
can investigate this issue more clearly.
So I will send you a link with the project.


was (Author: tibor17):
[~reitzmichnicht] I believe that the property {{junit5.version}} has no null 
but we can continue with isolated project.
I can isolate the detailed test in a separate GitHub project where you and me 
can investigate this issue more clearly.
So I will send you a link with the project.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-integration-testing] mthmulders opened a new pull request #90: [MNG-4660] Increase usefulness of logging

[GitBox]

mthmulders opened a new pull request #90:
URL: https://github.com/apache/maven-integration-testing/pull/90


   When the user resumes a build, they could see a message "Packaged artifact 
is not up-to-date compared to the build output directory". This could even be 
logged multiple times for one build. It was unclear why it was logged and what 
a user could do to address it. This test accompanies 
https://github.com/apache/maven/pull/414.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven] mthmulders opened a new pull request #414: [MNG-4660] Increase usefulness of logging

[GitBox]

mthmulders opened a new pull request #414:
URL: https://github.com/apache/maven/pull/414


   When the user resumes a build (MNG-4660), they could see a message "Packaged 
artifact is not up-to-date compared to the build output directory". This could 
even be logged multiple times for one build. It was unclear why it was logged 
and what a user could do to address it. This change adds a little bit of detail 
to that message so it becomes more clear to the user what has happened and 
where to look for solutions.
   
   The integration test is updated as well.
   
   ICLA and CCLA signed.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Closed] (MSHARED-968) Exclude module-info.java from default checkstyle checks

[Sylwester Lachiewicz (Jira)]

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

Sylwester Lachiewicz closed MSHARED-968.

Resolution: Fixed

> Exclude module-info.java from default checkstyle checks
> ---
>
> Key: MSHARED-968
> URL: https://issues.apache.org/jira/browse/MSHARED-968
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-resources
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: maven-shared-resources-3
>
>
> https://stackoverflow.com/questions/46495576/how-to-exclude-module-info-java-from-checkstyle-plugin-checks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHARED-968) Exclude module-info.java from default checkstyle checks

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254104#comment-17254104
 ] 

Hudson commented on MSHARED-968:


Build succeeded in Jenkins: Maven » Maven TLP » maven-shared-resources » master 
#17

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-shared-resources/job/master/17/

> Exclude module-info.java from default checkstyle checks
> ---
>
> Key: MSHARED-968
> URL: https://issues.apache.org/jira/browse/MSHARED-968
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-resources
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: maven-shared-resources-3
>
>
> https://stackoverflow.com/questions/46495576/how-to-exclude-module-info-java-from-checkstyle-plugin-checks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHARED-968) Exclude module-info.java from default checkstyle checks

[Sylwester Lachiewicz (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254101#comment-17254101
 ] 

Sylwester Lachiewicz commented on MSHARED-968:
--

Done in 
[5fbc3eb45e747f17cccd193e5e4b1828b87c91dd|https://gitbox.apache.org/repos/asf?p=maven-shared-resources.git;a=commit;h=5fbc3eb45e747f17cccd193e5e4b1828b87c91dd]
 based on [https://checkstyle.sourceforge.io/config_filefilters.html] samples

> Exclude module-info.java from default checkstyle checks
> ---
>
> Key: MSHARED-968
> URL: https://issues.apache.org/jira/browse/MSHARED-968
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-resources
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> https://stackoverflow.com/questions/46495576/how-to-exclude-module-info-java-from-checkstyle-plugin-checks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (MSHARED-968) Exclude module-info.java from default checkstyle checks

[Sylwester Lachiewicz (Jira)]

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

Sylwester Lachiewicz reassigned MSHARED-968:


Assignee: Sylwester Lachiewicz

> Exclude module-info.java from default checkstyle checks
> ---
>
> Key: MSHARED-968
> URL: https://issues.apache.org/jira/browse/MSHARED-968
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-resources
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
>
> https://stackoverflow.com/questions/46495576/how-to-exclude-module-info-java-from-checkstyle-plugin-checks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHARED-968) Exclude module-info.java from default checkstyle checks

[Sylwester Lachiewicz (Jira)]

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

Sylwester Lachiewicz updated MSHARED-968:
-
Fix Version/s: maven-shared-resources-3

> Exclude module-info.java from default checkstyle checks
> ---
>
> Key: MSHARED-968
> URL: https://issues.apache.org/jira/browse/MSHARED-968
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-resources
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: maven-shared-resources-3
>
>
> https://stackoverflow.com/questions/46495576/how-to-exclude-module-info-java-from-checkstyle-plugin-checks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSHARED-968) Exclude module-info.java from checkstyle checks

[Sylwester Lachiewicz (Jira)]

Sylwester Lachiewicz created MSHARED-968:


 Summary: Exclude module-info.java from checkstyle checks
 Key: MSHARED-968
 URL: https://issues.apache.org/jira/browse/MSHARED-968
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-shared-resources
Reporter: Sylwester Lachiewicz


https://stackoverflow.com/questions/46495576/how-to-exclude-module-info-java-from-checkstyle-plugin-checks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHARED-968) Exclude module-info.java from default checkstyle checks

[Sylwester Lachiewicz (Jira)]

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

Sylwester Lachiewicz updated MSHARED-968:
-
Summary: Exclude module-info.java from default checkstyle checks  (was: 
Exclude module-info.java from checkstyle checks)

> Exclude module-info.java from default checkstyle checks
> ---
>
> Key: MSHARED-968
> URL: https://issues.apache.org/jira/browse/MSHARED-968
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-resources
>Reporter: Sylwester Lachiewicz
>Priority: Minor
>
> https://stackoverflow.com/questions/46495576/how-to-exclude-module-info-java-from-checkstyle-plugin-checks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-resolver] rfscholte commented on a change in pull request #83: [MRESOLVER-151] Enforce a checksum policy to be provided explicitly

[GitBox]

rfscholte commented on a change in pull request #83:
URL: https://github.com/apache/maven-resolver/pull/83#discussion_r547974159



##
File path: 
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultChecksumPolicyProviderTest.java
##
@@ -124,7 +124,7 @@ public void 
testGetEffectiveChecksumPolicy_DifferentPolicies()
 }
 }
 
-@Test
+@Test( expected = IllegalArgumentException.class )

Review comment:
   With the change it'll exit with the first testcase and the first assert, 
making the rest useless.
   Better replace every `assertEquals` with something like
   
   IllegalArgumentException ex = assertThrows( 
IllegalArgumentException.class, () -> 
provider.getEffectiveChecksumPolicy(.) );
   assertThat( ex.getMessage(), is(...))





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo opened a new pull request #117: link no longer relevant

[GitBox]

elharo opened a new pull request #117:
URL: https://github.com/apache/maven-scm/pull/117


   @michael-o



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

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

Guy Brand updated MRESOLVER-153:

Attachment: screenshot-1.png

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
> concurrent writes on the {{resolver-status.properties}} file in our tests and 
> causes the error during the {{Properties#load()}} method wich then throws the 
> above error. See this screenshot on how these files look like (cannot add the 
> text here as {{null}} characters aren't shown):
> When enabling debug log we also see that the {{DefaultMetadataResolver}} 
> threads

[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

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

Guy Brand updated MRESOLVER-153:

Description: 
In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} after 
[this 
commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
 we face the following error:
{code:java}
[main] [INFO] 

[main] [INFO] BUILD FAILURE
[main] [INFO] 

[main] [INFO] Total time: 0.243 s
[main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
[main] [INFO] 

[main] [ERROR] Malformed \u encoding.
java.lang.IllegalArgumentException: Malformed \u encoding.
 at java.util.Properties.loadConvert (Properties.java:675)
 at java.util.Properties.load0 (Properties.java:451)
 at java.util.Properties.load (Properties.java:404)
 at org.eclipse.aether.internal.impl.TrackingFileManager.read 
(TrackingFileManager.java:56)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
(DefaultUpdateCheckManager.java:511)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
(DefaultUpdateCheckManager.java:250)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
(DefaultMetadataResolver.java:302)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
(DefaultMetadataResolver.java:181)
 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
(DefaultRepositorySystem.java:277)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
 (DefaultPluginVersionResolver.java:134)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
(DefaultPluginVersionResolver.java:97)
 at 
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
 (LifecyclePluginResolver.java:67)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:104)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:86)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:92)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
 at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke (Method.java:566)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
{code}
It's not consistently failing and OSX based CI agents fail more often than 
Linux or Windows ones. After some investigations we saw that as part of 
https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
been removed on the {{TrackingFileManager}} 
([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
concurrent writes on the {{resolver-status.properties}} file in our tests and 
causes the error during the {{Properties#load()}} method wich then throws the 
above error. See this screenshot on how these files look like (cannot add the 
text here as {{null}} characters aren't shown):

 !screenshot-1.png! 

When enabling debug log we also see that the {{DefaultMetadataResolver}} 
threads try to write concurrently to this file:
{code:java}
[DefaultMetadataResolver-0-0] [INFO] Downloading from custom-repo2: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-2] [INFO] Downloading from central-proxy: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [INFO] Downloading from custom-repo: 
https://repository.apache.org/snapshots/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [DEBUG] Writing tracking file 
/.../core-it-suite/target/test-cla

[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

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

Guy Brand updated MRESOLVER-153:

Description: 
In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} after 
[this 
commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
 we face the following error:
{code:java}
[main] [INFO] 

[main] [INFO] BUILD FAILURE
[main] [INFO] 

[main] [INFO] Total time: 0.243 s
[main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
[main] [INFO] 

[main] [ERROR] Malformed \u encoding.
java.lang.IllegalArgumentException: Malformed \u encoding.
 at java.util.Properties.loadConvert (Properties.java:675)
 at java.util.Properties.load0 (Properties.java:451)
 at java.util.Properties.load (Properties.java:404)
 at org.eclipse.aether.internal.impl.TrackingFileManager.read 
(TrackingFileManager.java:56)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
(DefaultUpdateCheckManager.java:511)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
(DefaultUpdateCheckManager.java:250)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
(DefaultMetadataResolver.java:302)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
(DefaultMetadataResolver.java:181)
 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
(DefaultRepositorySystem.java:277)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
 (DefaultPluginVersionResolver.java:134)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
(DefaultPluginVersionResolver.java:97)
 at 
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
 (LifecyclePluginResolver.java:67)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:104)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:86)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:92)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
 at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke (Method.java:566)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
{code}
It's not consistently failing and OSX based CI agents fail more often than 
Linux or Windows ones. After some investigations we saw that as part of 
https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
been removed on the {{TrackingFileManager}} 
([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
concurrent writes on the {{resolver-status.properties}} file in our tests and 
causes the error during the {{Properties#load()}} method wich then throws the 
above error. See this screenshot on how these files look like (cannot add the 
text here as {{null}} characters aren't shown):



When enabling debug log we also see that the {{DefaultMetadataResolver}} 
threads try to write concurrently to this file:
{code:java}
[DefaultMetadataResolver-0-0] [INFO] Downloading from custom-repo2: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-2] [INFO] Downloading from central-proxy: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [INFO] Downloading from custom-repo: 
https://repository.apache.org/snapshots/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [DEBUG] Writing tracking file 
/.../core-it-suite/target/test-classes/mng--concur

[jira] [Created] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

Guy Brand created MRESOLVER-153:
---

 Summary: resolver-status.properties file is corrupted due to 
concurrent writes
 Key: MRESOLVER-153
 URL: https://issues.apache.org/jira/browse/MRESOLVER-153
 Project: Maven Resolver
  Issue Type: Bug
  Components: Resolver
Affects Versions: 1.6.1
 Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
Reporter: Guy Brand


In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} after 
[this 
commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
 we face the following error:
{code:java}
[main] [INFO] 

[main] [INFO] BUILD FAILURE
[main] [INFO] 

[main] [INFO] Total time: 0.243 s
[main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
[main] [INFO] 

[main] [ERROR] Malformed \u encoding.
java.lang.IllegalArgumentException: Malformed \u encoding.
 at java.util.Properties.loadConvert (Properties.java:675)
 at java.util.Properties.load0 (Properties.java:451)
 at java.util.Properties.load (Properties.java:404)
 at org.eclipse.aether.internal.impl.TrackingFileManager.read 
(TrackingFileManager.java:56)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
(DefaultUpdateCheckManager.java:511)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
(DefaultUpdateCheckManager.java:250)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
(DefaultMetadataResolver.java:302)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
(DefaultMetadataResolver.java:181)
 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
(DefaultRepositorySystem.java:277)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
 (DefaultPluginVersionResolver.java:134)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
(DefaultPluginVersionResolver.java:97)
 at 
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
 (LifecyclePluginResolver.java:67)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:104)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:86)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:92)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
 at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke (Method.java:566)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
{code}
It's not consistently failing and OSX based CI agents fail more often than 
Linux or Windows ones. After some investigations we saw that as part of 
https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
been removed on the {{TrackingFileManager}} 
([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
concurrent writes on the {{resolver-status.properties}} file in our tests and 
causes the error during the {{Properties#load()}} method wich then throws the 
above error. See this screenshot on how these files look like (cannot add the 
text here as {{null}} characters aren't shown):

When enabling debug log we also see that the {{DefaultMetadataResolver}} 
threads try to write concurrently to this file:
{code:java}
[DefaultMetadataResolver-0-0] [INFO] Downloading from custom-repo2: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-2] [INFO] Downloading from central-proxy: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [I

[GitHub] [maven-scm] elharo opened a new pull request #116: [MNGSITE-393] remove reference to Maven 2

[GitBox]

elharo opened a new pull request #116:
URL: https://github.com/apache/maven-scm/pull/116


   @hboutemy



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo opened a new pull request #115: Prereq

[GitBox]

elharo opened a new pull request #115:
URL: https://github.com/apache/maven-scm/pull/115


   @slachiewicz 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo opened a new pull request #114: [MSCM-949] listStyle --> itemsStyle

[GitBox]

elharo opened a new pull request #114:
URL: https://github.com/apache/maven-scm/pull/114


   @slachiewicz 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Assigned] (SCM-949) xml.listStyle' for field element is deprecated: use 'xml.itemsStyle'

[Elliotte Rusty Harold (Jira)]

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

Elliotte Rusty Harold reassigned SCM-949:
-

Assignee: Elliotte Rusty Harold

> xml.listStyle' for field element is deprecated: use 'xml.itemsStyle'
> 
>
> Key: SCM-949
> URL: https://issues.apache.org/jira/browse/SCM-949
> Project: Maven SCM
>  Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Minor
>
> Several warnings like this in the build
>  
> [INFO] Working on model: src/main/mdo/maven-scm-local-metadata.mdo
> [WARNING] attribute 'xml.listStyle' for field element is deprecated: use 
> 'xml.itemsStyle' in association instead



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-scm] elharo merged pull request #111: deps: update to JUnit 4.13.1

[GitBox]

elharo merged pull request #111:
URL: https://github.com/apache/maven-scm/pull/111


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-scm] elharo opened a new pull request #113: replace deprecated methods

[GitBox]

elharo opened a new pull request #113:
URL: https://github.com/apache/maven-scm/pull/113


   @slachiewicz 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (SCM-949) xml.listStyle' for field element is deprecated: use 'xml.itemsStyle'

[Elliotte Rusty Harold (Jira)]

Elliotte Rusty Harold created SCM-949:
-

 Summary: xml.listStyle' for field element is deprecated: use 
'xml.itemsStyle'
 Key: SCM-949
 URL: https://issues.apache.org/jira/browse/SCM-949
 Project: Maven SCM
  Issue Type: Improvement
Reporter: Elliotte Rusty Harold


Several warnings like this in the build

 

[INFO] Working on model: src/main/mdo/maven-scm-local-metadata.mdo
[WARNING] attribute 'xml.listStyle' for field element is deprecated: use 
'xml.itemsStyle' in association instead



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-scm] elharo opened a new pull request #112: fix typos in JavaDoc

[GitBox]

elharo opened a new pull request #112:
URL: https://github.com/apache/maven-scm/pull/112


   @michael-o 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MEAR-292) skipClassPathModification option should prevent adding Class-Path entry into MANIFEST.mf

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254068#comment-17254068
 ] 

Hudson commented on MEAR-292:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven-ear-plugin » mear-294 #2

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/mear-294/2/

> skipClassPathModification option should prevent adding Class-Path entry into 
> MANIFEST.mf
> 
>
> Key: MEAR-292
> URL: https://issues.apache.org/jira/browse/MEAR-292
> Project: Maven EAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Windows 10 x64
>Reporter: Marat Abrarov
>Priority: Major
> Fix For: 3.2.0
>
>
> It looks like there is a bug in implementation of 
> {{skipClassPathModification}} option introduced in MEAR-182 - if 
> {{skipClassPathModification}} is {{true}} and original MANIFEST.mf of EAR 
> module artifact has no {{Class-Path}} entry, then empty {{Class-Path}} entry 
> is added into EAR module. I believe that {{Class-Path}} entry should not be 
> added in this case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MEAR-294) JAR with provided scope should be removed from Class-Path entry of EAR module MANIFEST.mf

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254067#comment-17254067
 ] 

Hudson commented on MEAR-294:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven-ear-plugin » mear-294 #2

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/mear-294/2/

> JAR with provided scope should be removed from Class-Path entry of EAR module 
> MANIFEST.mf
> -
>
> Key: MEAR-294
> URL: https://issues.apache.org/jira/browse/MEAR-294
> Project: Maven EAR Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Marat Abrarov
>Priority: Major
> Fix For: 3.2.0
>
>
> JAR dependency of EAR with provided scope should be removed from 
> {{Class-Path}} entry of MANIFEST.mf of EAR module if {{skinnyWars}} or 
> {{skinnyModules}} option is turned on or if EAR module doesn't contain all of 
> its dependencies (like EJB module). This issue looks to be a bug of solution 
> of MEAR-243 bug.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MNG-7057) the param style of javadoc

[DONG BING (Jira)]

DONG BING created MNG-7057:
--

 Summary: the param style of javadoc 
 Key: MNG-7057
 URL: https://issues.apache.org/jira/browse/MNG-7057
 Project: Maven
  Issue Type: Bug
Reporter: DONG BING


As stated in the document of 
[this|[https://www.oracle.com/technical-resources/articles/java/javadoc-tool.html#@param],]
  *Dashes or other punctuation should not be inserted before the description*.

 

For javadoc of  
`maven-core/src/main/java/org/apache/maven/project/ReactorModelPool.java`, the 
param should not end with a comma.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)