[jira] (SCM-767) mockito should be under test scope, not compile scope for accurev provider
[ https://jira.codehaus.org/browse/SCM-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-767. Resolution: Fixed fixed at https://git-wip-us.apache.org/repos/asf/maven-scm/repo?p=maven-scm.git;a=commit;h=3b4695a81d97271a7b13ed64cc50103d9a73e20b > mockito should be under test scope, not compile scope for accurev provider > --- > > Key: SCM-767 > URL: https://jira.codehaus.org/browse/SCM-767 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-accurev >Affects Versions: 1.9.1 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.9.2 > > > will use this opportunity to promote mockito to dedenencyManagement using > version 1.9.5, since there are a number of providers also using it during test -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-769) Unable to load maven-scm-provider-vss with Eclipse's M2E
[ https://jira.codehaus.org/browse/SCM-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-769. Resolution: Fixed Fix Version/s: 1.9.2 Assignee: Dan Tran fixed at http://git-wip-us.apache.org/repos/asf/maven-scm/commit/e98f3345 > Unable to load maven-scm-provider-vss with Eclipse's M2E > > > Key: SCM-769 > URL: https://jira.codehaus.org/browse/SCM-769 > Project: Maven SCM > Issue Type: Task > Components: maven-scm-provider-vss >Affects Versions: 1.9.1 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 1.9.2 > > > This provider must use a old version of modello-maven-plugin that is not > compatible with M2E and there for it generated source does not get loaded > with eclipse. > Will get maven pom to use build helper to attach the generated source and M2E > will be happy -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-769) Unable to load maven-scm-provider-vss with Eclipse's M2E
Dan Tran created SCM-769: Summary: Unable to load maven-scm-provider-vss with Eclipse's M2E Key: SCM-769 URL: https://jira.codehaus.org/browse/SCM-769 Project: Maven SCM Issue Type: Task Components: maven-scm-provider-vss Affects Versions: 1.9.1 Reporter: Dan Tran This provider must use a old version of modello-maven-plugin that is not compatible with M2E and there for it generated source does not get loaded with eclipse. Will get maven pom to use build helper to attach the generated source and M2E will be happy -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5592) Maven Dependency Resolution Locks up
[
https://jira.codehaus.org/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350449#comment-350449
]
Mark Derricutt commented on MNG-5592:
-
Anyone know if this is still valid in a post 3.2.2 Maven world? Just came
across it in my inbox - I've not seen the problem arise since but not sure if
Aether was updated since this was raised?
> Maven Dependency Resolution Locks up
>
>
> Key: MNG-5592
> URL: https://jira.codehaus.org/browse/MNG-5592
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.1.1, 3.2.1
> Environment: OS/X, Java 7 and Java 8
>Reporter: Mark Derricutt
> Attachments: mng-5592-simplified.zip, mng-5592.zip, MNG-5592.zip
>
>
> One one of my larger integration projects that involves A LOT of version
> ranges across a broad range of dependencies I'm seeing that Maven locks up
> resolving dependencies.
> I've recently seen this in 3.1.1 but it's happening more and more often under
> 3.2.1.
> It appears that Eclipse Aether is falling into a circular loop somewhere and
> locking up.
> {code}
> "main" #1 prio=5 os_prio=31 tid=0x7f966b001000 nid=0x1903 runnable
> [0x000103559000]
>java.lang.Thread.State: RUNNABLE
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver$ConflictContext.isIncluded(ConflictResolver.java:1062)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector$1.accept(NearestVersionSelector.java:145)
> at
> org.eclipse.aether.util.graph.visitor.PathRecordingDependencyVisitor.visitEnter(PathRecordingDependencyVisitor.java:88)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:324)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure(NearestVersionSelector.java:149)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.backtrack(NearestVersionSelector.java:111)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.selectVersion(NearestVersionSelector.java:84)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:187)
> at
> org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:275)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> 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:108)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
>
[jira] (MNG-624) automatic parent versioning
[ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-624: --- Component/s: FDPFC > automatic parent versioning > --- > > Key: MNG-624 > URL: https://jira.codehaus.org/browse/MNG-624 > Project: Maven > Issue Type: Improvement > Components: FDPFC, Inheritance and Interpolation >Reporter: Brett Porter >Priority: Blocker > Fix For: Issues to be reviewed for 4.x > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-182) Upgrade to PMD 5.1.2
[ https://jira.codehaus.org/browse/MPMD-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MPMD-182: - Description: Updated to 5.1.2 in [r1613787|http://svn.apache.org/viewvc?view=revision&revision=1613787]. Summary: Upgrade to PMD 5.1.2 (was: Upgrade to PMD 5.1.1) > Upgrade to PMD 5.1.2 > > > Key: MPMD-182 > URL: https://jira.codehaus.org/browse/MPMD-182 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Olivier Lamy >Assignee: Dennis Lundberg > Fix For: 3.2 > > > Updated to 5.1.2 in > [r1613787|http://svn.apache.org/viewvc?view=revision&revision=1613787]. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
