[jira] (MDEPLOY-174) [REGRESSION] url not required anymore, causing a NullPointerException
[
https://jira.codehaus.org/browse/MDEPLOY-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342458#comment-342458
]
Jordan Zimmerman commented on MDEPLOY-174:
--
When will there be a release of 2.9? This is a blocker for me.
> [REGRESSION] url not required anymore, causing a NullPointerException
> -
>
> Key: MDEPLOY-174
> URL: https://jira.codehaus.org/browse/MDEPLOY-174
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Markus KARG
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 2.9
>
>
> My POM.xml is rather empty, mostly contains only this:
> {code:xml}
>
> maven-deploy-plugin
> 2.8.1
>
> ${project.groupId}
> ${project.artifactId}
> ${project.version}
> zip
> ../target/dist/DITA-OT2.0.M1_minimal_bin.zip
>
>
>
> deploy
>
> deploy-file
>
>
>
>
> {code}
> When I do "mvn -X deploy" the result is a crash of Maven:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default) on
> project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file (default)
> on project dita-ot-minimal: Execution default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.1:deploy-file failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.protocol(MavenArtifactRepository.java:219)
> at
> org.apache.maven.artifact.repository.MavenArtifactRepository.(MavenArtifactRepository.java:79)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createArtifactRepository(DefaultArtifactRepositoryFactory.java:129)
> at
> org.apache.maven.repository.legacy.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:78)
> at
> org.apache.maven.artifact.repository.DefaultArtifactRepositoryFactory.createDeploymentArtifactRepository(DefaultArtifactRepositoryFactory.java:67)
> at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:233)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342460#comment-342460
]
Michael Zav'yalov commented on MNG-5435:
I've tested -llr with Maven 3.1.1 on my project. This magic works. But it
definately looks like a workaround. Do you know the root cause of the problem?
The option description is not understandable for me :-)
I've tested also Maven 3.2.1 - the same result: works with -llr, fails without
it.
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module SUCCESS [1.327s]
> [INFO] bar-module SUCCESS [0.090s]
> [INFO] baz-module FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr
> artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve
> dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The
> following artifacts could not be resolved:
> com.acme
[jira] (MRESOURCES-144) if filter file does not exist it should optionally ignore it, not just throw an exception
[
https://jira.codehaus.org/browse/MRESOURCES-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342473#comment-342473
]
Deepak Panchal commented on MRESOURCES-144:
---
I also want to have such a feature. The use case in my case is I want the
developers to optionally specific their local settings that will override the
default which is either specified as default proeprties in the pom file itself
or within another filter proeprties file.
Having an option to ignore missing makes this possible.
> if filter file does not exist it should optionally ignore it, not just throw
> an exception
> -
>
> Key: MRESOURCES-144
> URL: https://jira.codehaus.org/browse/MRESOURCES-144
> Project: Maven Resources Plugin
> Issue Type: Improvement
>Affects Versions: 2.4.3
>Reporter: richard stevenson
>Assignee: Olivier Lamy
>Priority: Minor
> Attachments: maven-filter.patch
>
>
> If you have a list of filter files
>
> a.properties
> b.properties
> ${prop.name}.properties
>
> It would be nice to tell the resources plugin to optioanlly ignore a file if
> it does not exist. Currently get the following stack trace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Error loading
> property f
> ile 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
> 0)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error loading
> propert
> y file 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:269)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Error
> load
> ing property file 'D:\projects\.../src/main/filters/a.properties'
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:274)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFi
> lterWrappers(DefaultMavenFileFilter.java:199)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filt
> erResources(DefaultMavenResourcesFiltering.java:162)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:265)
> ... 19 more
> Caused by: java.io.FileNotFoundException:
> D:\projects\.../src/main/filters/a.fil
> ter.properties
> at
> org.apache.maven.shared.filtering.PropertyUtils.loadPropertyFile(Prop
> ertyUtils.java:65)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:269)
> ... 22 more
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-144) if filter file does not exist it should optionally ignore it, not just throw an exception
[
https://jira.codehaus.org/browse/MRESOURCES-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342473#comment-342473
]
Deepak Panchal edited comment on MRESOURCES-144 at 3/6/14 8:25 AM:
---
I also want to have such a feature. The use case in my case is I want the
developers to optionally specify their local settings that will override the
default which is either specified as default proeprties in the pom file itself
or within another filter proeprties file.
Having an option to ignore missing makes this possible.
was (Author: deepan):
I also want to have such a feature. The use case in my case is I want the
developers to optionally specific their local settings that will override the
default which is either specified as default proeprties in the pom file itself
or within another filter proeprties file.
Having an option to ignore missing makes this possible.
> if filter file does not exist it should optionally ignore it, not just throw
> an exception
> -
>
> Key: MRESOURCES-144
> URL: https://jira.codehaus.org/browse/MRESOURCES-144
> Project: Maven Resources Plugin
> Issue Type: Improvement
>Affects Versions: 2.4.3
>Reporter: richard stevenson
>Assignee: Olivier Lamy
>Priority: Minor
> Attachments: maven-filter.patch
>
>
> If you have a list of filter files
>
> a.properties
> b.properties
> ${prop.name}.properties
>
> It would be nice to tell the resources plugin to optioanlly ignore a file if
> it does not exist. Currently get the following stack trace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Error loading
> property f
> ile 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
> 0)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error loading
> propert
> y file 'D:\projects\.../src/main/filters/a.filter.properties'
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:269)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Error
> load
> ing property file 'D:\projects\.../src/main/filters/a.properties'
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.loadProperti
> es(DefaultMavenFileFilter.java:274)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFi
> lterWrappers(DefaultMavenFileFilter.java:199)
> at
> org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filt
> erResources(DefaultMavenResourcesFiltering.java:162)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo
> .java:265)
> ... 19 more
> Caused by: java.io.FileNotFoundException:
> D:\projects\.../src/main/filters/a.fil
> ter.properties
> at
> org.apache.maven.shared.filtering.PropertyUtils.loadProperty
[jira] (MNG-5594) Show current/total project number in reactor during build
Grzegorz Grzybek created MNG-5594:
-
Summary: Show current/total project number in reactor during build
Key: MNG-5594
URL: https://jira.codehaus.org/browse/MNG-5594
Project: Maven 2 & 3
Issue Type: Improvement
Components: General
Affects Versions: 3.2.x
Reporter: Grzegorz Grzybek
While building long projects, containing hundreds of modules it would be nice
to see how far did we get.
For example, the build might look like this:
{noformat}
...
[INFO]
[INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
[INFO]
[INFO]
...
[INFO]
[INFO]
[INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
[INFO]
[INFO]
...
{noformat}
Please find attached a [naive implementation^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated MNG-5594:
--
Attachment: project-progress.diff
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a [naive implementation^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated MNG-5594:
--
Description:
While building long projects, containing hundreds of modules it would be nice
to see how far did we get.
For example, the build might look like this:
{noformat}
...
[INFO]
[INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
[INFO]
[INFO]
...
[INFO]
[INFO]
[INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
[INFO]
[INFO]
...
{noformat}
Please find attached a naive implementation here: [^project-progress.diff].
was:
While building long projects, containing hundreds of modules it would be nice
to see how far did we get.
For example, the build might look like this:
{noformat}
...
[INFO]
[INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
[INFO]
[INFO]
...
[INFO]
[INFO]
[INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
[INFO]
[INFO]
...
{noformat}
Please find attached a [naive implementation^project-progress.diff].
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342476#comment-342476
]
Jason van Zyl commented on MNG-5435:
I don't know what's happening yet but I can explain how the repository tracking
works. The _remote.repositories file tracks the origin repository of the
artifact so if you have retrieved artifact A from one run of Maven from
repository X, and you run the build again after changing your settings.xml to
point to another repository Y which does not contain A Maven, while using the
enhanced local repository manager, considers this a failure because artifact A
is not reachable in Y. The purpose of this feature is to make sure that a build
that works for you locally works for everyone on your team with the configured
repositories.
Either the repository ids are not matching up between the the repositories
being used or there might be a concurrency issue. Not sure without trying out
your test case. Most likely the repository ids not matching up.
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module ...
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342481#comment-342481
]
Michael Zav'yalov commented on MNG-5435:
This should not be concurrency problem - I tested it with single core enabled
on my computer for the process and it does not affect the result.
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module SUCCESS [1.327s]
> [INFO] bar-module SUCCESS [0.090s]
> [INFO] baz-module FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr
> artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve
> dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The
> following artifacts could not be resolved:
> com.acme:foo-module:jar:4.0.0-SNAPSHOT,
> com.acme:bar-module:jar:4.0.0-SNAPSHOT: Could not find artifact
> com.acme:foo-module:jar:4.0.0-SNAPSHOT -> [Help 1
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342488#comment-342488
]
Jason van Zyl commented on MNG-5435:
Can you try adding pluginRepositories to you settings.xml for your mirror as
outlined here:
http://books.sonatype.com/nexus-book/reference/maven-sect-single-group.html
I think you're getting different repository ids being used.
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module SUCCESS [1.327s]
> [INFO] bar-module SUCCESS [0.090s]
> [INFO] baz-module FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr
> artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve
> dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The
> following artifacts could not be resolved:
> com.acme:foo-module:jar:4.0.0-SNAPSHOT,
> com.acme:bar-module:jar:4.0.0-SNAPSHOT
[jira] (MCHECKSTYLE-221) ResourceIncludes default value is wrong
[ https://jira.codehaus.org/browse/MCHECKSTYLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342510#comment-342510 ] Dennis Lundberg commented on MCHECKSTYLE-221: - This is a documentation issue. The value is correct. > ResourceIncludes default value is wrong > --- > > Key: MCHECKSTYLE-221 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-221 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.11 >Reporter: Arlo Louis O'Keeffe >Priority: Minor > Fix For: 2.12 > > > The default value for resourceIncludes is supposed to be \*\*\/\*.properties > but in fact it is \*\*/\*.properties. > You can verify in the generated maven site: > https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#resourceIncludes > An easy workaround is to simply define resourceIncludes yourself. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-221) ResourceIncludes default value is wrong
[ https://jira.codehaus.org/browse/MCHECKSTYLE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHECKSTYLE-221: Fix Version/s: 2.12 Assignee: Dennis Lundberg > ResourceIncludes default value is wrong > --- > > Key: MCHECKSTYLE-221 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-221 > Project: Maven Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.11 >Reporter: Arlo Louis O'Keeffe >Assignee: Dennis Lundberg >Priority: Minor > Fix For: 2.12 > > > The default value for resourceIncludes is supposed to be \*\*\/\*.properties > but in fact it is \*\*/\*.properties. > You can verify in the generated maven site: > https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#resourceIncludes > An easy workaround is to simply define resourceIncludes yourself. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5273) Transitive dependencies with scope provided ending up in the final artifact
[
https://jira.codehaus.org/browse/MNG-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342513#comment-342513
]
Roman Arkadijovych Muntyanu commented on MNG-5273:
--
I believe the issue indeed might be related to MNG-5255
> Transitive dependencies with scope provided ending up in the final artifact
> ---
>
> Key: MNG-5273
> URL: https://jira.codehaus.org/browse/MNG-5273
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.3, 3.0.4
> Environment: Windows 7, Sun OS 5.1
>Reporter: Ian Phipps
>Assignee: Jason van Zyl
>
> Marking jaxws-rt as a provided dependency:
> {noformat}
> com.sun.xml.ws
> jaxws-rt
> 2.1.4
> provided
> {noformat}
> Correctly resolves jaxb-impl as a provided dependency (dependency:tree output
> from 3.0.3 and 3.0.4):
> {noformat}[INFO] +- com.sun.xml.ws:jaxws-rt:jar:2.1.4:provided
> [INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:provided
> [INFO] | +- com.sun.xml.stream.buffer:streambuffer:jar:0.7:provided
> [INFO] | +- com.sun.xml.stream:sjsxp:jar:1.0.1:provided
> [INFO] | +- org.jvnet.staxex:stax-ex:jar:1.2:provided
> [INFO] | +- com.sun.org.apache.xml.internal:resolver:jar:20050927:provided
> [INFO] | \- org.jvnet:mimepull:jar:1.2:provided {noformat}
> But for some reason, in Maven 3 (tried 3.0.3 and 3.0.4), using a packaging
> type of "war", jaxb-impl-2.1.7 ends up in the final artifact.
> It is correctly omitted from the final artifact in maven 2.x.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5273) Transitive dependencies with scope provided ending up in the final artifact
[
https://jira.codehaus.org/browse/MNG-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342513#comment-342513
]
Roman Arkadijovych Muntyanu edited comment on MNG-5273 at 3/6/14 4:42 PM:
--
I believe in our case the issue indeed might be related to MNG-5255
was (Author: coldserenity):
I believe the issue indeed might be related to MNG-5255
> Transitive dependencies with scope provided ending up in the final artifact
> ---
>
> Key: MNG-5273
> URL: https://jira.codehaus.org/browse/MNG-5273
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.3, 3.0.4
> Environment: Windows 7, Sun OS 5.1
>Reporter: Ian Phipps
>Assignee: Jason van Zyl
>
> Marking jaxws-rt as a provided dependency:
> {noformat}
> com.sun.xml.ws
> jaxws-rt
> 2.1.4
> provided
> {noformat}
> Correctly resolves jaxb-impl as a provided dependency (dependency:tree output
> from 3.0.3 and 3.0.4):
> {noformat}[INFO] +- com.sun.xml.ws:jaxws-rt:jar:2.1.4:provided
> [INFO] | +- com.sun.xml.bind:jaxb-impl:jar:2.1.7:provided
> [INFO] | +- com.sun.xml.stream.buffer:streambuffer:jar:0.7:provided
> [INFO] | +- com.sun.xml.stream:sjsxp:jar:1.0.1:provided
> [INFO] | +- org.jvnet.staxex:stax-ex:jar:1.2:provided
> [INFO] | +- com.sun.org.apache.xml.internal:resolver:jar:20050927:provided
> [INFO] | \- org.jvnet:mimepull:jar:1.2:provided {noformat}
> But for some reason, in Maven 3 (tried 3.0.3 and 3.0.4), using a packaging
> type of "war", jaxb-impl-2.1.7 ends up in the final artifact.
> It is correctly omitted from the final artifact in maven 2.x.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-580) Allow "fail fast" or stop running on first failure
[ https://jira.codehaus.org/browse/SUREFIRE-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342514#comment-342514 ] Gili commented on SUREFIRE-580: --- Please add TestNG to the list of components. This should be fixed for both frameworks. > Allow "fail fast" or stop running on first failure > -- > > Key: SUREFIRE-580 > URL: https://jira.codehaus.org/browse/SUREFIRE-580 > Project: Maven Surefire > Issue Type: New Feature > Components: Junit 4.x support >Reporter: Paul Curren > > We have some slow Selenium builds. Waiting for indication of failure can take > a long time. It would be helpful if there was an option to finish the test > run on the first failure. > We could configure this on some of our slower builds so improve the speed of > the feedback loop in the cases where there are failures. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated MNG-5594:
--
Priority: Minor (was: Major)
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
>Priority: Minor
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
