[jira] [Commented] (MRESOLVER-142) maven does not honour configured in some cases
[ https://issues.apache.org/jira/browse/MRESOLVER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318894#comment-17318894 ] Igor Fedorenko commented on MRESOLVER-142: -- Sorry, it's been awhile, I don't recall any details about this issue, feel free to close. > maven does not honour configured in some cases > - > > Key: MRESOLVER-142 > URL: https://issues.apache.org/jira/browse/MRESOLVER-142 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Igor Fedorenko >Priority: Major > Fix For: waiting-for-feedback > > > There appear to be a bug in artifact descriptor cache implemented in aether > DefaultDependencyCollector. The cache allows use of cached descriptors when > descriptor parent(s) are not accessible from any enabled repository. > This is particularly problematic during multithreaded builds, where timing of > individual module project builds is not guaranteed, and the invalid artifact > descriptor cache implementation can result in infrequent and hard to > troubleshoot dependency resolution failures. > I'll provide small standalone example project that demonstrates the problem > shortly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216783#comment-17216783 ] Igor Fedorenko commented on MNG-6995: - Maven would need to read the aggregator pom in order to find all modules being aggregated and their respective configured Core Extensions. This alone would require non-trivial changes to how Maven Core, Core Extensions and aggregator pom interact. "Mutually exclusive" extensions are very likely to result in subtle build inconsistencies, e.g., stale build output files are not regenerated in _some_ cases, or build failures that happen depending on build order and timing. I don't see this as an acceptable failure mode for generally available Maven feature. > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: New Feature > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will currently be ignored. Only extensions defined in same directory as the > aggregator pom will be used and those extensions will not be invoked for the > modules, only for the aggregator itself. > Ideally modules should build with whatever core extensions they have defined. > Building a module as part of an aggregator should behave not differently than > building the module standalone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6995) Support core extensions in modules of aggregator projects
[ https://issues.apache.org/jira/browse/MNG-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17212773#comment-17212773 ] Igor Fedorenko commented on MNG-6995: - Core Extensions are discovered and loaded very early during the build, before Maven reads any projects files, iirc. This gives Core Extensions same capabilities (mostly) as if they were part of Maven installation, but also means Core Extensions resolution and instantiation cannot rely on anything in pom.xml. Core Extensions are global to the build, and aggregator project can conceivably include modules with mutually exclusive extensions. Hope this helps. > Support core extensions in modules of aggregator projects > - > > Key: MNG-6995 > URL: https://issues.apache.org/jira/browse/MNG-6995 > Project: Maven > Issue Type: New Feature > Components: Class Loading >Affects Versions: 3.6.3 >Reporter: mike duigou >Priority: Major > > If you have defined core extensions using the MNG-5771 .mvn/extensions.xml > mechanism and then include the module in an aggregator pom the extensions > will currently be ignored. Only extensions defined in same directory as the > aggregator pom will be used and those extensions will not be invoked for the > modules, only for the aggregator itself. > Ideally modules should build with whatever core extensions they have defined. > Building a module as part of an aggregator should behave not differently than > building the module standalone. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5552) Classified artifacts are missing from ${project.artifactMap}
[
https://issues.apache.org/jira/browse/MNG-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169527#comment-17169527
]
Igor Fedorenko commented on MNG-5552:
-
No, I don't remember much about this issue, sorry.
> Classified artifacts are missing from ${project.artifactMap}
>
>
> Key: MNG-5552
> URL: https://issues.apache.org/jira/browse/MNG-5552
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Igor Fedorenko
>Assignee: Michael Osipov
>Priority: Major
> Labels: needs-attention
> Fix For: 3.x / Backlog
>
>
> Classified artifacts are missing from {{$\{project.artifactMap}}}, so I can't
> inject them all in my plugins or use
> {{$\{project.artifactMap(group:artifact:classifier)}}} to pick individual
> dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814378#comment-16814378
]
Igor Fedorenko commented on MNG-6604:
-
I have not looked at Maven for several years now, so can't comment on the
current state of affairs. Here is what I remember from the distant past
talari-local-repo is broken, don't use use it.
[https://github.com/takari/takari-local-repository/issues/5]
[https://github.com/takari/takari-local-repository/issues/4.]
-Daether.connector.resumeDownload=false may help workaround aether local repo
concurrency bugs.
You probably want to use [https://github.com/takari/takari-smart-builder] to
build on multiple threads. [https://github.com/takari/concurrent-build-logger]
maybe useful too.
Good luck.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140389#comment-16140389 ] Igor Fedorenko commented on MNG-6209: - Not sure I understand the question. The changes were reviewed and merged to master long time ago. Are you saying current 3.5.1 snapshot is still affected by the problem? > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6275) ServiceLoaderFactory can't find implementations via ClassRealm
[
https://issues.apache.org/jira/browse/MNG-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16139975#comment-16139975
]
Igor Fedorenko commented on MNG-6275:
-
I don't have time to do proper analysis of this, but this change will likely
cause problems in m2e, plugin testing, jenkins and other embedded usecases,
where contents of system classloader is generally unknown and can contain
classes that either collide or confuse plugins in some other ways (e.g.
random/unrelated components visible to plugins in only some environments, which
will be very hard to troubleshoot).
PS: didn't we agree to get all core changes reviewed and +1'ed by at least one
other developer before pushing to master?
> ServiceLoaderFactory can't find implementations via ClassRealm
> --
>
> Key: MNG-6275
> URL: https://issues.apache.org/jira/browse/MNG-6275
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.1
>
>
> Spotted this issue via MANTRUN-200. The reason is that in the
> {{DefaultClassRealmManager}} a new realm is created where the parent
> classLoader is {{null}}. This implies that the bootstrap classloader is used
> as parent.
> With Java8 nashorn has become an extension and is not part of the bootstrap
> classloader anymore.
> It is kind of strange that we want the bootstrap classloader here, it makes
> more sense if the system classloader is used (but with Java 7 and older
> versions of Java this was not an issue, both worked fine).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037505#comment-16037505 ] Igor Fedorenko commented on MNG-6209: - Agree with Hervé. Thread context classloader use is a bug in maven assembly plugin and needs to be fixed there. > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036921#comment-16036921 ] Igor Fedorenko commented on MNG-6209: - Why does assembly plugin use Thread.currentThread().getContextClassLoader() to retrieve assembly.xml descriptor? If the descriptor is located in the same jar as the plugin (or at least in the same classloader), getClass().getClassLoader() seems like the proper way to get the descriptor, no? > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036858#comment-16036858 ] Igor Fedorenko commented on MNG-6209: - I am not familiar with maven assembly plugin implementation, sorry. Do you think you can provide Maven IT that shows the problem? > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023724#comment-16023724 ] Igor Fedorenko commented on MNG-6233: - My apologies, I assumed I addressed all concerned about my change here already and didn't ask on the mailing list. Let me do that now and I'll revert my change if I don't get +1s (or get -1s) within 72 hours. I am not sure what you mean by "merged Jason Dillon's changed with this PR". The change I propose fully converts maven-resolver-provider to jsr330 annotations, which means only jsr330 codepaths are used after the change and our existing ITs prove everything works. In other words, it is not possible to implement jsr330 conversion (i.e. this change) without fixing Jason's problem too, so this change really supersedes PR 116. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko resolved MNG-6233. - Resolution: Fixed Fix Version/s: (was: 3.5.1-candidate) 3.5.1 Submitted the fix as https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=66fc74d6296ea0a33f8a9712dc5ed5eb3affd529 > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-6233: --- Assignee: Igor Fedorenko > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16015056#comment-16015056 ] Igor Fedorenko commented on MNG-6233: - Pushed proposed change to https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/MNG-6233_maven-resolver-provider-jsr330. Let me know if you agree/disagree to include this change in 3.5.1. Like I said, we've used this in our local version of maven for some time now without any problems. All ITs pass for me locally too. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011187#comment-16011187 ] Igor Fedorenko commented on MNG-6233: - We already have plenty of jsr330 components in maven, so this is my no means new in Maven. I was slowly replacing plexus annotations with jsr330 over last few years, but if anyone feels like doing bulk conversion I won't object ;-) [~rfscholte] maven does not do classpath scanning for jsr330 components, check how plexus container is created in MavenCli. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16011125#comment-16011125 ] Igor Fedorenko commented on MNG-6233: - I don't believe IT is justified here. The change completely removes plexus-annotations support from the project and I think it is proof enough the two annotations are not being used simultaneously. From what I recall, the plan has always been to fully migrate to jsr330, we just never spent the time to do that. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
Igor Fedorenko created MNG-6233: --- Summary: maven-resolver-provider mixes jsr330 and plexus annotations Key: MNG-6233 URL: https://issues.apache.org/jira/browse/MNG-6233 Project: Maven Issue Type: Bug Affects Versions: 3.5.0, 3.3.9 Reporter: Igor Fedorenko Fix For: 3.5.1-candidate Mixed annotations confuse guice/sisu and result in hard to troubleshoot and impossible to workaround problems in applications that embed Maven core runtime, like m2e and gshell. I believe plugins annotations where left in the code by mistake so the plan is to update the code to use jsr330 exclusively and completely remove plexus annotations. This change is fully transparent to the users (and we've been using it internally for couple of months now). See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1697#comment-1697
]
Igor Fedorenko commented on MNG-6210:
-
These files don't exist in the git repository
https://git1-us-west.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources;h=ee55a631383994f02c25f1e67190b6c937297def;hb=HEAD.
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.5.1
>
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1690#comment-1690
]
Igor Fedorenko commented on MNG-6210:
-
I've shortened the test project file names some, if you still can't clone the
repo I suggest using shorter local path, something like "/d/work/maven-its". I
also suggest you add MINGW64 build to Apache Maven Jenkins, which is really the
only way to guarantee MINGW64 does not regress in the future.
https://git1-us-west.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=a9857509453b42ad9b26fad80d5c421de0a2c50e
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.5.1
>
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979498#comment-15979498
]
Igor Fedorenko commented on MNG-6210:
-
The problem is, I have no way to test if the shortened paths are short enough
or not.
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.5.1
>
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979425#comment-15979425
]
Igor Fedorenko commented on MNG-6210:
-
What is "git bash"? If this is windows/cygwin, I don't have access to a system
where I can test this and don't want to make blind changes. Do you think you
can rename the test projects to work in your environment and I'll be happy to
review and merge your changes.
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.5.1
>
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko resolved MNG-6209. - Resolution: Fixed fixed in master > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MNG-6209: Fix Version/s: 3.5.1 > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1 > > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko resolved MNG-6210.
-
Resolution: Fixed
fixed in master
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.5.1
>
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko updated MNG-6210:
Affects Version/s: 3.3.1
3.3.3
3.3.9
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.5.1
>
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko updated MNG-6210:
Fix Version/s: 3.5.1
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
> Fix For: 3.5.1
>
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15968146#comment-15968146
]
Igor Fedorenko commented on MNG-6210:
-
Proposed fix:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=30644f05c7be0e390b139c58a1159a2131dec74c
Integration test:
https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=66f162a4bd4daea1c86c1bda328b63484bed53de
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966247#comment-15966247 ] Igor Fedorenko commented on MNG-6209: - The proposed fix: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=53a2af8ee11fc3f4aa829193b99cde95a3f04735 The corresponding IT: https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=f476ac3d4567312dcd9ea0975ce5cba84ddcb1ec > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
[
https://issues.apache.org/jira/browse/MNG-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko reassigned MNG-6210:
---
Assignee: Igor Fedorenko
> can't load @SessionScoped/@MojoExecutionScoped components from
> .mvn/extensions.xml
> --
>
> Key: MNG-6210
> URL: https://issues.apache.org/jira/browse/MNG-6210
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Reporter: Igor Fedorenko
>Assignee: Igor Fedorenko
>
> The build fails with the exception below if Maven core extensions defined in
> .mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
> components
> {code}
> [WARNING]
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]]
> com.google.inject.CreationException: Unable to create injector, see the
> following errors:
> 1) No scope is bound to org.apache.maven.SessionScoped.
> at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown
> Source)
> at
> ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
> parent: ClassRealm[plexus.core, parent: null]] (via modules:
> org.eclipse.sisu.wire.WireModule ->
> org.eclipse.sisu.plexus.PlexusBindingModule)
> 1 error
> at
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
> at
> com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
> at
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
> at com.google.inject.Guice.createInjector(Guice.java:96)
> at com.google.inject.Guice.createInjector(Guice.java:73)
> at com.google.inject.Guice.createInjector(Guice.java:62)
> at
> org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
> at
> org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
> at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
[ https://issues.apache.org/jira/browse/MNG-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-6209: --- Assignee: Igor Fedorenko > inconsistent activation of components from multiple extensions=true plugins > --- > > Key: MNG-6209 > URL: https://issues.apache.org/jira/browse/MNG-6209 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.3.1, 3.3.3, 3.3.9 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > > This is a regression introduced by the fix for MNG-5742. When multiple > extensions=true plugins configured in the build, when mojos from one such > plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6210) can't load @SessionScoped/@MojoExecutionScoped components from .mvn/extensions.xml
Igor Fedorenko created MNG-6210:
---
Summary: can't load @SessionScoped/@MojoExecutionScoped components
from .mvn/extensions.xml
Key: MNG-6210
URL: https://issues.apache.org/jira/browse/MNG-6210
Project: Maven
Issue Type: Bug
Components: Class Loading
Reporter: Igor Fedorenko
The build fails with the exception below if Maven core extensions defined in
.mvn/extensions.xml includes any @SessionScoped or MojoExecutionScoped
components
{code}
[WARNING]
ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
parent: ClassRealm[plexus.core, parent: null]]
com.google.inject.CreationException: Unable to create injector, see the
following errors:
1) No scope is bound to org.apache.maven.SessionScoped.
at io.takari.maven.workspace.GenerationsWorkspaceReader.class(Unknown Source)
at
ClassRealm[coreExtension>io.takari.maven:takari-workspace-reader:0.3.31-SNAPSHOT,
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
1 error
at
com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:466)
at
com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
at
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
at com.google.inject.Guice.createInjector(Guice.java:96)
at com.google.inject.Guice.createInjector(Guice.java:73)
at com.google.inject.Guice.createInjector(Guice.java:62)
at
org.codehaus.plexus.DefaultPlexusContainer.addPlexusInjector(DefaultPlexusContainer.java:481)
at
org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:460)
at
org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:435)
at org.apache.maven.cli.MavenCli.container(MavenCli.java:568)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:287)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MNG-6209) inconsistent activation of components from multiple extensions=true plugins
Igor Fedorenko created MNG-6209: --- Summary: inconsistent activation of components from multiple extensions=true plugins Key: MNG-6209 URL: https://issues.apache.org/jira/browse/MNG-6209 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.3.9, 3.3.3, 3.3.1 Reporter: Igor Fedorenko This is a regression introduced by the fix for MNG-5742. When multiple extensions=true plugins configured in the build, when mojos from one such plugin are executed, components from other extensions are ignored. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5836) logging config is overwritten by $M2_HOME/lib/ext/*.jar
[
https://issues.apache.org/jira/browse/MNG-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15798262#comment-15798262
]
Igor Fedorenko commented on MNG-5836:
-
Better late than never, right? :-)
I originally wanted to provide default concurrent-safe logging configuration as
part of https://github.com/takari/concurrent-build-logger . There is a number
of example configuration files under src/main/distro/conf/logging/logback.xml
if you want to try it.
> logging config is overwritten by $M2_HOME/lib/ext/*.jar
> ---
>
> Key: MNG-5836
> URL: https://issues.apache.org/jira/browse/MNG-5836
> Project: Maven
> Issue Type: Bug
>Reporter: Igor Fedorenko
>Assignee: Hervé Boutemy
> Fix For: 3.4.0
>
>
> If one of the jars in {{$M2_HOME/lib/ext/*.jar}} happens to have
> {{simplelogger.properties}}, that configuration file masks logging
> configuration under {{$M2_HOME/conf/logging}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5927) maven does not honour configured in some cases
[ https://issues.apache.org/jira/browse/MNG-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14995315#comment-14995315 ] Igor Fedorenko commented on MNG-5927: - Pushed axample project to https://github.com/ifedorenko/MNG-5927-dependency-parent-repository > maven does not honour configured in some cases > - > > Key: MNG-5927 > URL: https://issues.apache.org/jira/browse/MNG-5927 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Igor Fedorenko > > There appear to be a bug in artifact descriptor cache implemented in aether > DefaultDependencyCollector. The cache allows use of cached descriptors when > descriptor parent(s) are not accessible from any enabled repository. > This is particularly problematic during multithreaded builds, where timing of > individual module project builds is not guaranteed, and the invalid artifact > descriptor cache implementation can result in infrequent and hard to > troubleshoot dependency resolution failures. > I'll provide small standalone example project that demonstrates the problem > shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5927) maven does not honour configured in some cases
Igor Fedorenko created MNG-5927: --- Summary: maven does not honour configured in some cases Key: MNG-5927 URL: https://issues.apache.org/jira/browse/MNG-5927 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Reporter: Igor Fedorenko There appear to be a bug in artifact descriptor cache implemented in aether DefaultDependencyCollector. The cache allows use of cached descriptors when descriptor parent(s) are not accessible from any enabled repository. This is particularly problematic during multithreaded builds, where timing of individual module project builds is not guaranteed, and the invalid artifact descriptor cache implementation can result in infrequent and hard to troubleshoot dependency resolution failures. I'll provide small standalone example project that demonstrates the problem shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build
[
https://issues.apache.org/jira/browse/MNG-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948570#comment-14948570
]
Igor Fedorenko commented on MNG-5727:
-
I didn't want to change how maven handles unused invalid
elements, so reporting problems with invalid seems like the
right way to fix InvalidArtifactRTException. For example, I don't see why the
following pom.xml should be considered invalid
{code}
4.0.0
test
versionless-managed-dependency.xml
0.0.1-SNAPSHOT
junit
junit
4.12
junit
junit
test
{code}
> unexpected InvalidArtifactRTException from ProjectBuilder#build
> ---
>
> Key: MNG-5727
> URL: https://issues.apache.org/jira/browse/MNG-5727
> Project: Maven
> Issue Type: Bug
>Reporter: Igor Fedorenko
> Fix For: 3.2.5
>
>
> Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in
> InvalidArtifactRTException below if project pom.xml has managed dependency
> without . Although the pom is invalid, I expected to get
> ProjectBuildingException that includes location of problematic dependency,
> similar to what I get during command line build.
> {code}
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact
> {org.apache.maven.its:a:null:jar}: The version cannot be empty.
> at
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
> at
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:123)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
> at
> org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
> at
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build
[
https://issues.apache.org/jira/browse/MNG-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14949815#comment-14949815
]
Igor Fedorenko commented on MNG-5727:
-
This is how Maven appears to work now and I think the current behaviour makes
sense.
> unexpected InvalidArtifactRTException from ProjectBuilder#build
> ---
>
> Key: MNG-5727
> URL: https://issues.apache.org/jira/browse/MNG-5727
> Project: Maven
> Issue Type: Bug
>Reporter: Igor Fedorenko
> Fix For: 3.2.5
>
>
> Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in
> InvalidArtifactRTException below if project pom.xml has managed dependency
> without . Although the pom is invalid, I expected to get
> ProjectBuildingException that includes location of problematic dependency,
> similar to what I get during command line build.
> {code}
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact
> {org.apache.maven.its:a:null:jar}: The version cannot be empty.
> at
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
> at
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:123)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
> at
> org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
> at
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build
[
https://issues.apache.org/jira/browse/MNG-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko closed MNG-5727.
---
Resolution: Fixed
Fix Version/s: 3.2.5
I am not sure what attached project you refer to. The test project I committed
as part of [1] includes entry without element.
The test project is expected to fail with ProjectBuildingException, which is
ensured by the regression test introduced as part of the commit.
This issue was specifically about InvalidArtifactRTException, which is fixed
now, so I am closing this issue as such.
[1]
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=ce6f0bfdb527e20c3afbd76b9c742e07b13d25b2
> unexpected InvalidArtifactRTException from ProjectBuilder#build
> ---
>
> Key: MNG-5727
> URL: https://issues.apache.org/jira/browse/MNG-5727
> Project: Maven
> Issue Type: Bug
>Reporter: Igor Fedorenko
> Fix For: 3.2.5
>
>
> Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in
> InvalidArtifactRTException below if project pom.xml has managed dependency
> without . Although the pom is invalid, I expected to get
> ProjectBuildingException that includes location of problematic dependency,
> similar to what I get during command line build.
> {code}
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact
> {org.apache.maven.its:a:null:jar}: The version cannot be empty.
> at
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
> at
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:123)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
> at
> org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
> at
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPLUGIN-271) Usage of defaultValues for a List.. Parameter seemed not to be working
[
https://issues.apache.org/jira/browse/MPLUGIN-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706682#comment-14706682
]
Igor Fedorenko commented on MPLUGIN-271:
This bug is not specific to maven-plugin-annotations, I think it makes sense to
move it to MNG jira, where users can find it more easily.
Usage of defaultValues for a List.. Parameter seemed not to be working
Key: MPLUGIN-271
URL: https://issues.apache.org/jira/browse/MPLUGIN-271
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-annotations
Affects Versions: 3.3
Reporter: Karl Heinz Marbaise
Priority: Critical
Currently the following seemed to be not working:
{code:java}
@Parameter( defaultValue = */pom.xml )
private ListString pomIncludes;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643440#comment-14643440
]
Igor Fedorenko commented on MNG-5771:
-
@Yuri I meant d...@maven.apache.org maven development list, not m2e dev list.
sorry for the confusion.
improved user-configurable core extensions mechanism
Key: MNG-5771
URL: https://issues.apache.org/jira/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: igorfie
Fix For: 3.3.1
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
{{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
mechanisms is user friendly. In both cases, the user is expected to manually
locate and download all required jar file. In both cases, this has to be done
on all systems where the extensions are needed. In both cases, all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
to specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code:xml}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MNG-5836) logging config is overwritten by $M2_HOME/lib/ext/*.jar
[ https://issues.apache.org/jira/browse/MNG-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5836. --- Resolution: Won't Fix You didn't provide an example that shows why moving conf/logging to the top of the list is a bad idea. I do think having default logging configuration inside lib/ext/maven-ext-logback.jar would make things easier to configure for the user, but have it your way, I don't feel strongly enough about this. logging config is overwritten by $M2_HOME/lib/ext/*.jar --- Key: MNG-5836 URL: https://issues.apache.org/jira/browse/MNG-5836 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko If one of the jars in $M2_HOME/lib/ext/*.jar happens to have simplelogger.properties, that configuration file masks logging configuration under $M2_HOME/conf/logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5836) logging config is overwritten by $M2_HOME/lib/ext/*.jar
[
https://issues.apache.org/jira/browse/MNG-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14573921#comment-14573921
]
Igor Fedorenko commented on MNG-5836:
-
Just to be clear, do you suggest that current order of m2.conf entries is
correct and desirable?
{code}
[plexus.core]
optionally ${maven.home}/lib/ext/*.jar
load ${maven.home}/lib/*.jar
load ${maven.home}/conf/logging
{code}
Can you elaborate why?
I can't think of a case when having conf/logging as the last entry in the list
is preferable. This is the place where users can change logging configuration,
so I expect it to have highest priority regardless of of anything else present
on classpath. For example, if conf/logging is the first entry, the logging
library could provide default configuration, which the user would still be able
override through explicit configuration.
logging config is overwritten by $M2_HOME/lib/ext/*.jar
---
Key: MNG-5836
URL: https://issues.apache.org/jira/browse/MNG-5836
Project: Maven
Issue Type: Bug
Reporter: Igor Fedorenko
If one of the jars in $M2_HOME/lib/ext/*.jar happens to have
simplelogger.properties, that configuration file masks logging configuration
under $M2_HOME/conf/logging
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5836) logging config is overwritten by $M2_HOME/lib/ext/*.jar
[ https://issues.apache.org/jira/browse/MNG-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14573190#comment-14573190 ] Igor Fedorenko commented on MNG-5836: - Hmm. Yes, this is kinda my point, $M2_HOME/conf/logging should be the logging configuration used by maven regardless of what is included in custom libraries. In practical terms this means we need to change order of m2.conf entries, which I'll do when I get back to regular office. logging config is overwritten by $M2_HOME/lib/ext/*.jar --- Key: MNG-5836 URL: https://issues.apache.org/jira/browse/MNG-5836 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko If one of the jars in $M2_HOME/lib/ext/*.jar happens to have simplelogger.properties, that configuration file masks logging configuration under $M2_HOME/conf/logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5836) logging config is overwritten by $M2_HOME/lib/ext/*.jar
Igor Fedorenko created MNG-5836: --- Summary: logging config is overwritten by $M2_HOME/lib/ext/*.jar Key: MNG-5836 URL: https://issues.apache.org/jira/browse/MNG-5836 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko If one of the jars in $M2_HOME/lib/ext/*.jar happens to have simplelogger.properties, that configuration file masks logging configuration under $M2_HOME/conf/logging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5771) improved user-configurable core extensions mechanism
[
https://issues.apache.org/jira/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530545#comment-14530545
]
Igor Fedorenko commented on MNG-5771:
-
I don't think settings.xml in project basedir is a good idea. User settings are
meant to provide environment specific configuration, like user credentials,
which cannot be shared across different build system.
Using ~/.m2/settings.xml to configure extensions is not a good idea because it
will break earlier versions of maven. I don't have strong opinion about
~/.m2/extension.xml (or something like that). It is probably okay to for
environment specific extensions, like your custom repository extension,
assuming I understood your usercase correctly. I have no immediate plans to
implement this myself, however.
As a side note, questions like this are better asked on m2e-dev mailing list,
where they will be visible to a wider audience of interested developers.
improved user-configurable core extensions mechanism
Key: MNG-5771
URL: https://issues.apache.org/jira/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: igorfie
Fix For: 3.3.1
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
{{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
mechanisms is user friendly. In both cases, the user is expected to manually
locate and download all required jar file. In both cases, this has to be done
on all systems where the extensions are needed. In both cases, all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
to specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code:xml}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MNG-5793) same class realm registered both with plugin and extensions realm caches
Igor Fedorenko created MNG-5793: --- Summary: same class realm registered both with plugin and extensions realm caches Key: MNG-5793 URL: https://jira.codehaus.org/browse/MNG-5793 Project: Maven Issue Type: Bug Components: Class Loading, Embedding Affects Versions: 3.3.1 Reporter: Igor Fedorenko This is a regression introduced by fix for MNG-5742. Although there is only one realm for plugins with extensions=true now, the realm is registered with both plugin realm and extensions realm caches. This make it impossible to properly dispose of unused realms when maven is embedded in a long-running application like m2e or maven shell. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5793) same class realm registered both with plugin and extensions realm caches
[ https://jira.codehaus.org/browse/MNG-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5793. --- Resolution: Fixed Fix Version/s: 3.3.2 Assignee: Igor Fedorenko https://git-wip-us.apache.org/repos/asf?p=maven.gita=searchh=HEADst=commits=MNG-5793 same class realm registered both with plugin and extensions realm caches Key: MNG-5793 URL: https://jira.codehaus.org/browse/MNG-5793 Project: Maven Issue Type: Bug Components: Class Loading, Embedding Affects Versions: 3.3.1 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.3.2 This is a regression introduced by fix for MNG-5742. Although there is only one realm for plugins with extensions=true now, the realm is registered with both plugin realm and extensions realm caches. This make it impossible to properly dispose of unused realms when maven is embedded in a long-running application like m2e or maven shell. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364859#comment-364859
]
Igor Fedorenko commented on MNG-5771:
-
The new mechanisms allows configuration to be persisted inside project source
tree, something that was not possible before. The extensions are configured in
terms of groupId/artifactId/version and should be easier to manage. The new
mechanism also has cleaner classloading model, so different extensions can have
different dependencies.
user-configurable core extensions mechanism
---
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: Igor Fedorenko
Fix For: 3.3.0
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
{{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
mechanisms is user friendly. In both cases, the user is expected to manually
locate and download all required jar file. In both cases, this has to be done
on all systems where the extensions are needed. In both cases, all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
to specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code:xml}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5771) improved user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko updated MNG-5771:
Summary: improved user-configurable core extensions mechanism (was:
user-configurable core extensions mechanism)
improved user-configurable core extensions mechanism
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: Igor Fedorenko
Fix For: 3.3.0
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
{{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
mechanisms is user friendly. In both cases, the user is expected to manually
locate and download all required jar file. In both cases, this has to be done
on all systems where the extensions are needed. In both cases, all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
to specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code:xml}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5771) improved user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364861#comment-364861
]
Igor Fedorenko commented on MNG-5771:
-
Fair enough. Updated jira description to indicate this is an improvement to
rudimentary implementation that already existed in earlier maven versions.
improved user-configurable core extensions mechanism
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: Igor Fedorenko
Fix For: 3.3.0
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
{{$M2_HOME/lib/ext directory}}. It is also possible to specify component jars
using {{-Dmaven.ext.class.path}} command line parameter. Neither of the
mechanisms is user friendly. In both cases, the user is expected to manually
locate and download all required jar file. In both cases, this has to be done
on all systems where the extensions are needed. In both cases, all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new {{$\{maven.projectBasedir\}/.mvn/extensions.xml}} descriptor
to specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code:xml}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using {{META-INF/maven/extension.xml}} descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5783) cobertura-maven-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory
[
https://jira.codehaus.org/browse/MNG-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko reassigned MNG-5783:
---
Assignee: Igor Fedorenko
cobertura-maven-plugin:instrument failing NoClassDefFoundError:
org/slf4j/LoggerFactory
---
Key: MNG-5783
URL: https://jira.codehaus.org/browse/MNG-5783
Project: Maven
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Herve Boutemy
Assignee: Igor Fedorenko
Priority: Critical
Fix For: 3.3.0
Attachments: build-3.2.5.log, build-3.3.0-SNAPSHOT.log
testing cobertura-maven-plugin from svn
http://mojo.codehaus.org/cobertura-maven-plugin/
IT pass with Maven 3.2.5 but fail with 3.3.0-SNAPSHOT
(not the same issue as MNG-5779)
{noformat}[DEBUG] /bin/sh -c /opt/jdk1.7.0_71/jre/bin/java
-Dlog4j.configuration=file:/tmp/log4j1560920244563737852config.properties
-Xmx1024m net.sourceforge.cobertura.instrument.InstrumentMain --commandsfile
/tmp/cobertura.4914644993417176752.cmdline
[DEBUG] exit code: 1
[DEBUG]
[DEBUG] Standard error from the Cobertura task:
[DEBUG]
[ERROR] Exception in thread main java.lang.NoClassDefFoundError:
org/slf4j/LoggerFactory
at
net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.init(InstrumentMain.java:165)
at
net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.init(InstrumentMain.java:164)
at
net.sourceforge.cobertura.instrument.InstrumentMain.clinit(InstrumentMain.java:66)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 3 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5783) cobertura-maven-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory
[
https://jira.codehaus.org/browse/MNG-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko closed MNG-5783.
---
Resolution: Fixed
Maven 3.2.5 and earlier did not filter slf4j and javax.inject from plugin and
build extension realms, which resulted in the same classes available from
multiple classloaders and caused in hard to debug build failures in some cases.
To fix that I've added slf4j and javax.inject to the list of artifacts exported
by Maven core, which broke cobertura and probably other plugins that use
${plugin.artifacts} to setup classpath of external jvm and need slf4j.
The solution is to move core artifact from plugin dependency resolver to class
realm manager. This way ${plugin.artifacts} will include all plugin
compile/runtime dependencies, but class realms will only include artifacts
unique to the plugin.
As a result of the fix some plugins will resolve additional artifact jars from
remote repositories. This should not cause problems in practice because
corresponding artifact poms are already resolved during the build. If this does
cause problems, unwanted dependencies can be blocked both from consuming
projects pom.xml using plugin dependencies elements, or, more permanently, by
plugin developers by using scope=provided.
Fix
https://git-wip-us.apache.org/repos/asf?p=maven.gita=searchh=HEADst=commits=MNG-5783
IT
https://git1-us-west.apache.org/repos/asf?p=maven-integration-testing.gita=searchh=HEADst=commits=MNG-5783
cobertura-maven-plugin:instrument failing NoClassDefFoundError:
org/slf4j/LoggerFactory
---
Key: MNG-5783
URL: https://jira.codehaus.org/browse/MNG-5783
Project: Maven
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Herve Boutemy
Assignee: Igor Fedorenko
Priority: Critical
Fix For: 3.3.0
Attachments: build-3.2.5.log, build-3.3.0-SNAPSHOT.log
testing cobertura-maven-plugin from svn
http://mojo.codehaus.org/cobertura-maven-plugin/
IT pass with Maven 3.2.5 but fail with 3.3.0-SNAPSHOT
(not the same issue as MNG-5779)
{noformat}[DEBUG] /bin/sh -c /opt/jdk1.7.0_71/jre/bin/java
-Dlog4j.configuration=file:/tmp/log4j1560920244563737852config.properties
-Xmx1024m net.sourceforge.cobertura.instrument.InstrumentMain --commandsfile
/tmp/cobertura.4914644993417176752.cmdline
[DEBUG] exit code: 1
[DEBUG]
[DEBUG] Standard error from the Cobertura task:
[DEBUG]
[ERROR] Exception in thread main java.lang.NoClassDefFoundError:
org/slf4j/LoggerFactory
at
net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.init(InstrumentMain.java:165)
at
net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.init(InstrumentMain.java:164)
at
net.sourceforge.cobertura.instrument.InstrumentMain.clinit(InstrumentMain.java:66)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 3 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-410) Verifier mishandles systemProperties
Igor Fedorenko created MSHARED-410: -- Summary: Verifier mishandles systemProperties Key: MSHARED-410 URL: https://jira.codehaus.org/browse/MSHARED-410 Project: Maven Shared Components Issue Type: Bug Components: maven-verifier Reporter: Igor Fedorenko Verifier#setSystemProperties are not passed as system properties but as maven regular -D command line arguments. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-410) Verifier mishandles systemProperties
[ https://jira.codehaus.org/browse/MSHARED-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MSHARED-410. -- Resolution: Fixed Fix Version/s: maven-verifier-1.6 Assignee: Igor Fedorenko http://svn.apache.org/viewvc?view=revisionrevision=1662485 Verifier mishandles systemProperties Key: MSHARED-410 URL: https://jira.codehaus.org/browse/MSHARED-410 Project: Maven Shared Components Issue Type: Bug Components: maven-verifier Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: maven-verifier-1.6 Verifier#setSystemProperties are not passed as system properties but as maven regular -D command line arguments. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5767) project-specific default jvm options and command line parameters
[ https://jira.codehaus.org/browse/MNG-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=364141#comment-364141 ] Igor Fedorenko commented on MNG-5767: - Correct. Options apply for entire codebase. The same options are used regardless if the build is started at the root of the codebase or from one of the submodules. project-specific default jvm options and command line parameters Key: MNG-5767 URL: https://jira.codehaus.org/browse/MNG-5767 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Some of the projects builds I work on require special jvm options, like minimal -Xmx value, and specific command line parameters, like --builder. Currently, I have to manually configure these every time run the build, which is rather annoying and error prone. This manual configuration also makes it harder for new or external developers to build the projects and many simply give up trying after mvn package does not work from the first try. This enhancement request proposes to introduce two new optional configuration files .mvn/jvm.config and .mvn/maven.config, located at the base directory of project source tree. If present, these files will provide default jvm and maven options. Because these files are part of the project source tree, they will be present in all project checkouts and will be automatically used every time the project is build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5768) specify execution-id for direct plugin goal invocation from command line
[ https://jira.codehaus.org/browse/MNG-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5768. --- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=ee7dbab69dd87d219031b0715105527cdbf12639 specify execution-id for direct plugin goal invocation from command line Key: MNG-5768 URL: https://jira.codehaus.org/browse/MNG-5768 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 When invoking plugin goal from command line, it is possible to configure the goal using special 'default-cli' pom.xml execution id. This has two obvious limitations. First, it is not possible to have more than one configuration for command line use. Second, it is not possible to share configuration between direct plugin invocation and execution bound to lifecycle phase. To address this, I propose to extend direct plugin invocation syntax to allow optional @execution-id parameter, e.g., org.apache.maven.plugins:maven-remote-resources-plugin:1.0:process@executionId. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5767) project-specific default jvm options and command line parameters
[ https://jira.codehaus.org/browse/MNG-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5767. --- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8ed9a1caa8890773b45c6c408a4e40acf4f4b0fd project-specific default jvm options and command line parameters Key: MNG-5767 URL: https://jira.codehaus.org/browse/MNG-5767 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Some of the projects builds I work on require special jvm options, like minimal -Xmx value, and specific command line parameters, like --builder. Currently, I have to manually configure these every time run the build, which is rather annoying and error prone. This manual configuration also makes it harder for new or external developers to build the projects and many simply give up trying after mvn package does not work from the first try. This enhancement request proposes to introduce two new optional configuration files .mvn/jvm.config and .mvn/maven.config, located at the base directory of project source tree. If present, these files will provide default jvm and maven options. Because these files are part of the project source tree, they will be present in all project checkouts and will be automatically used every time the project is build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
Igor Fedorenko created MNG-5771:
---
Summary: user-configurable core extensions mechanism
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
$M2_HOME/lib/ext directory. It is also possible to specify component jars using
-Dmaven.ext.class.path command line parameter. Neither of the mechanisms is
user friendly. In both cases the user is expected to manually locate and
download all required jar file. In both cases this has to be done on all
systems where the extensions are needed. In both cases all extra jars are
loaded into single classloader so all extensions must agree of the same set of
dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko updated MNG-5771:
Fix Version/s: 3.2.6
user-configurable core extensions mechanism
---
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Fix For: 3.2.6
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
$M2_HOME/lib/ext directory. It is also possible to specify component jars
using -Dmaven.ext.class.path command line parameter. Neither of the
mechanisms is user friendly. In both cases the user is expected to manually
locate and download all required jar file. In both cases this has to be done
on all systems where the extensions are needed. In both cases all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko reassigned MNG-5771:
---
Assignee: Igor Fedorenko
user-configurable core extensions mechanism
---
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: Igor Fedorenko
Fix For: 3.2.6
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
$M2_HOME/lib/ext directory. It is also possible to specify component jars
using -Dmaven.ext.class.path command line parameter. Neither of the
mechanisms is user friendly. In both cases the user is expected to manually
locate and download all required jar file. In both cases this has to be done
on all systems where the extensions are needed. In both cases all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5771) user-configurable core extensions mechanism
[
https://jira.codehaus.org/browse/MNG-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko closed MNG-5771.
---
Resolution: Fixed
reading extension exported packages and artifacts from
META-INF/maven/extension.xml descriptor
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8631d79ca3b2f08a610196ac04a7b7cde4832c4a
loading user-defined core extensions from
${maven.projectBasedir}/.mvn/extensions.xml
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6efacdb3fc5e8369fa3586c0603184dc785303da
user-configurable core extensions mechanism
---
Key: MNG-5771
URL: https://jira.codehaus.org/browse/MNG-5771
Project: Maven
Issue Type: Improvement
Components: Class Loading
Reporter: Igor Fedorenko
Assignee: Igor Fedorenko
Fix For: 3.2.6
As of version 3.2.5 maven provides two mechanisms to contribute additional
components to maven core runtime. It is possible to add component jars to
$M2_HOME/lib/ext directory. It is also possible to specify component jars
using -Dmaven.ext.class.path command line parameter. Neither of the
mechanisms is user friendly. In both cases the user is expected to manually
locate and download all required jar file. In both cases this has to be done
on all systems where the extensions are needed. In both cases all extra jars
are loaded into single classloader so all extensions must agree of the same
set of dependencies.
This jira is to track changes needed to make it possible to configure core
extensions in terms of groupId/artifactId/version and share set of required
extensions across multiple systems.
More specifically,
* introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to
specify list of extensions. Initially, the descriptor will only allow
specification of extension groupId/artifactId/version, but can be extended to
support dependency includes/excludes mechanism and configuration parameters
later
{code}
?xml version=1.0 encoding=UTF-8?
extensions
extension
groupId.../groupId
artifactId.../artifactId
version.../version
/extension
extension.../extension
...
/extensions
{code}
* change maven to read and load core extensions in separate class realms as
part of plexus container setup.
* provide mechanism for extensions to declare exported artifacts and packages
using META-INF/maven/extension.xml descriptor.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5772) upgrade to sisu 0.3.0 and sisu guice 3.2.5
Igor Fedorenko created MNG-5772: --- Summary: upgrade to sisu 0.3.0 and sisu guice 3.2.5 Key: MNG-5772 URL: https://jira.codehaus.org/browse/MNG-5772 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko just to keep dependencies current -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5772) upgrade to sisu 0.3.0 and sisu guice 3.2.5
[ https://jira.codehaus.org/browse/MNG-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5772. --- Resolution: Fixed Fix Version/s: 3.2.6 Assignee: Igor Fedorenko https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bdb4c32ec4acd734d1e385731ae2f67e8ed0d4ac upgrade to sisu 0.3.0 and sisu guice 3.2.5 -- Key: MNG-5772 URL: https://jira.codehaus.org/browse/MNG-5772 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 just to keep dependencies current -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5767) project-specific default jvm options and command line parameters
Igor Fedorenko created MNG-5767: --- Summary: project-specific default jvm options and command line parameters Key: MNG-5767 URL: https://jira.codehaus.org/browse/MNG-5767 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Some of the projects builds I work on require special jvm options, like minimal -Xmx value, and specific command line parameters, like --builder. Currently, I have to manually configure these every time run the build, which is rather annoying and error prone. This manual configuration also makes it harder for new or external developers to build the projects and many simply give up trying after mvn package does not work from the first try. This enhancement request proposes to introduce two new optional configuration files .mvn/jvm.config and .mvn/maven.config, located at the base directory of project source tree. If present, these files will provide default jvm and maven options. Because these files are part of the project source tree, they will be present in all project checkouts and will be automatically used every time the project is build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5767) project-specific default jvm options and command line parameters
[ https://jira.codehaus.org/browse/MNG-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5767: --- Assignee: Igor Fedorenko project-specific default jvm options and command line parameters Key: MNG-5767 URL: https://jira.codehaus.org/browse/MNG-5767 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Some of the projects builds I work on require special jvm options, like minimal -Xmx value, and specific command line parameters, like --builder. Currently, I have to manually configure these every time run the build, which is rather annoying and error prone. This manual configuration also makes it harder for new or external developers to build the projects and many simply give up trying after mvn package does not work from the first try. This enhancement request proposes to introduce two new optional configuration files .mvn/jvm.config and .mvn/maven.config, located at the base directory of project source tree. If present, these files will provide default jvm and maven options. Because these files are part of the project source tree, they will be present in all project checkouts and will be automatically used every time the project is build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5767) project-specific default jvm options and command line parameters
[ https://jira.codehaus.org/browse/MNG-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MNG-5767: Fix Version/s: 3.2.6 project-specific default jvm options and command line parameters Key: MNG-5767 URL: https://jira.codehaus.org/browse/MNG-5767 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Fix For: 3.2.6 Some of the projects builds I work on require special jvm options, like minimal -Xmx value, and specific command line parameters, like --builder. Currently, I have to manually configure these every time run the build, which is rather annoying and error prone. This manual configuration also makes it harder for new or external developers to build the projects and many simply give up trying after mvn package does not work from the first try. This enhancement request proposes to introduce two new optional configuration files .mvn/jvm.config and .mvn/maven.config, located at the base directory of project source tree. If present, these files will provide default jvm and maven options. Because these files are part of the project source tree, they will be present in all project checkouts and will be automatically used every time the project is build. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5768) specify execution-id for direct plugin goal invocation from command line
Igor Fedorenko created MNG-5768: --- Summary: specify execution-id for direct plugin goal invocation from command line Key: MNG-5768 URL: https://jira.codehaus.org/browse/MNG-5768 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko When invoking plugin goal from command line, it is possible to configure the goal using special 'default-cli' pom.xml execution id. This has two obvious limitations. First, it is not possible to have more than one configuration for command line use. Second, it is not possible to share configuration between direct plugin invocation and execution bound to lifecycle phase. To address this, I propose to extend direct plugin invocation syntax to allow optional @execution-id parameter, e.g., org.apache.maven.plugins:maven-remote-resources-plugin:1.0:process@executionId. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5768) specify execution-id for direct plugin goal invocation from command line
[ https://jira.codehaus.org/browse/MNG-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5768: --- Assignee: Igor Fedorenko specify execution-id for direct plugin goal invocation from command line Key: MNG-5768 URL: https://jira.codehaus.org/browse/MNG-5768 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 When invoking plugin goal from command line, it is possible to configure the goal using special 'default-cli' pom.xml execution id. This has two obvious limitations. First, it is not possible to have more than one configuration for command line use. Second, it is not possible to share configuration between direct plugin invocation and execution bound to lifecycle phase. To address this, I propose to extend direct plugin invocation syntax to allow optional @execution-id parameter, e.g., org.apache.maven.plugins:maven-remote-resources-plugin:1.0:process@executionId. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5768) specify execution-id for direct plugin goal invocation from command line
[ https://jira.codehaus.org/browse/MNG-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MNG-5768: Fix Version/s: 3.2.6 specify execution-id for direct plugin goal invocation from command line Key: MNG-5768 URL: https://jira.codehaus.org/browse/MNG-5768 Project: Maven Issue Type: Improvement Reporter: Igor Fedorenko Fix For: 3.2.6 When invoking plugin goal from command line, it is possible to configure the goal using special 'default-cli' pom.xml execution id. This has two obvious limitations. First, it is not possible to have more than one configuration for command line use. Second, it is not possible to share configuration between direct plugin invocation and execution bound to lifecycle phase. To address this, I propose to extend direct plugin invocation syntax to allow optional @execution-id parameter, e.g., org.apache.maven.plugins:maven-remote-resources-plugin:1.0:process@executionId. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5766) LifecycleModuleBuilder effectively swallows runtime exceptions and errors
Igor Fedorenko created MNG-5766: --- Summary: LifecycleModuleBuilder effectively swallows runtime exceptions and errors Key: MNG-5766 URL: https://jira.codehaus.org/browse/MNG-5766 Project: Maven Issue Type: Bug Components: Errors Reporter: Igor Fedorenko When RuntimeException or Error is thrown during project build, I expect reactor build to halt, the project to be mark as FAILED in the build summary and original Throwable stacktrace printed if maven was started with --errors. Current behaviour is inconsistent and depending on builder used and location of the original throw statement, the failure can be completely ignored. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5766) LifecycleModuleBuilder effectively swallows runtime exceptions and errors
[ https://jira.codehaus.org/browse/MNG-5766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5766. --- Resolution: Fixed Fix Version/s: 3.2.6 Assignee: Igor Fedorenko https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=cd52e5b51e8e986b6daea8c0b56dd61968410695 LifecycleModuleBuilder effectively swallows runtime exceptions and errors - Key: MNG-5766 URL: https://jira.codehaus.org/browse/MNG-5766 Project: Maven Issue Type: Bug Components: Errors Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 When RuntimeException or Error is thrown during project build, I expect reactor build to halt, the project to be mark as FAILED in the build summary and original Throwable stacktrace printed if maven was started with --errors. Current behaviour is inconsistent and depending on builder used and location of the original throw statement, the failure can be completely ignored. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5762) execution request populate ignores plugin repositories
[ https://jira.codehaus.org/browse/MNG-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5762: --- Assignee: Igor Fedorenko execution request populate ignores plugin repositories -- Key: MNG-5762 URL: https://jira.codehaus.org/browse/MNG-5762 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Seems like on oversight. DefaultMavenExecutionRequestPopulator correctly populates request remote repositories but completely ignores plugin artifact repositories. Although this does not affect normal build (settings profiles are injected into project model, bypassing request), it is desirable to have access to plugin repositories in some integration scenarios. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5762) execution request populate ignores plugin repositories
Igor Fedorenko created MNG-5762: --- Summary: execution request populate ignores plugin repositories Key: MNG-5762 URL: https://jira.codehaus.org/browse/MNG-5762 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko Seems like on oversight. DefaultMavenExecutionRequestPopulator correctly populates request remote repositories but completely ignores plugin artifact repositories. Although this does not affect normal build (settings profiles are injected into project model, bypassing request), it is desirable to have access to plugin repositories in some integration scenarios. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5762) execution request populate ignores plugin repositories
[ https://jira.codehaus.org/browse/MNG-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5762. --- Resolution: Fixed Fix Version/s: 3.2.6 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d745f8c47506bd93d4ae9eca830db50ad40ba61d execution request populate ignores plugin repositories -- Key: MNG-5762 URL: https://jira.codehaus.org/browse/MNG-5762 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Seems like on oversight. DefaultMavenExecutionRequestPopulator correctly populates request remote repositories but completely ignores plugin artifact repositories. Although this does not affect normal build (settings profiles are injected into project model, bypassing request), it is desirable to have access to plugin repositories in some integration scenarios. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5757) update aether to 1.0.2
Igor Fedorenko created MNG-5757: --- Summary: update aether to 1.0.2 Key: MNG-5757 URL: https://jira.codehaus.org/browse/MNG-5757 Project: Maven Issue Type: Task Reporter: Igor Fedorenko -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5757) update aether to 1.0.2
[ https://jira.codehaus.org/browse/MNG-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5757. --- Resolution: Fixed Assignee: Igor Fedorenko https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=3db19368aac10fad6b61346946cdcbe998c54117 update aether to 1.0.2 -- Key: MNG-5757 URL: https://jira.codehaus.org/browse/MNG-5757 Project: Maven Issue Type: Task Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5752) avoid hardcoded system classloader references
Igor Fedorenko created MNG-5752: --- Summary: avoid hardcoded system classloader references Key: MNG-5752 URL: https://jira.codehaus.org/browse/MNG-5752 Project: Maven Issue Type: Improvement Affects Versions: 3.2.5 Reporter: Igor Fedorenko Use of hardcoded system classloader as parent of plugin and project extensions realms makes it hard/impossible to run maven in advanced classloading environments, like eclipse maven development tools and integration test harnesses, where system classloader may contain unknown/undesired classes. See https://github.com/takari/takari-plugin-testing-project/blob/master/classloading.md for more detailed explanation of the problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5752) avoid hardcoded system classloader references
[ https://jira.codehaus.org/browse/MNG-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5752. --- Resolution: Fixed Fix Version/s: 3.2.6 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bb4988496a0e3b50ee5a1922bcd54f731eb2d5b2 avoid hardcoded system classloader references - Key: MNG-5752 URL: https://jira.codehaus.org/browse/MNG-5752 Project: Maven Issue Type: Improvement Affects Versions: 3.2.5 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Use of hardcoded system classloader as parent of plugin and project extensions realms makes it hard/impossible to run maven in advanced classloading environments, like eclipse maven development tools and integration test harnesses, where system classloader may contain unknown/undesired classes. See https://github.com/takari/takari-plugin-testing-project/blob/master/classloading.md for more detailed explanation of the problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5752) avoid hardcoded system classloader references
[ https://jira.codehaus.org/browse/MNG-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5752: --- Assignee: Igor Fedorenko avoid hardcoded system classloader references - Key: MNG-5752 URL: https://jira.codehaus.org/browse/MNG-5752 Project: Maven Issue Type: Improvement Affects Versions: 3.2.5 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Use of hardcoded system classloader as parent of plugin and project extensions realms makes it hard/impossible to run maven in advanced classloading environments, like eclipse maven development tools and integration test harnesses, where system classloader may contain unknown/undesired classes. See https://github.com/takari/takari-plugin-testing-project/blob/master/classloading.md for more detailed explanation of the problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
[ https://jira.codehaus.org/browse/MNG-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reopened MNG-5742: - MojoDescriptors of extensions plugins are not fully/correctly setup after this change. inconsistent classloading for extensions=true plugins - Key: MNG-5742 URL: https://jira.codehaus.org/browse/MNG-5742 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.2.1, 3.2.5 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Maven creates two class realms for build extensions plugins. One realm is used to contribute core extensions and the other to execute plugins goals. The two realms have slightly different classpath, with extensions realm not seeing classes from other extensions and not resolving reactor dependencies. The two realms are mostly independent and have duplicate copies of components, including duplicate copies of singletons. This results in multiple invocation of singleton components in some cases. This also results inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
[ https://jira.codehaus.org/browse/MNG-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5742. --- Resolution: Fixed https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6ab41ee8d3f82af456031b13d3a3e1d5834043dc inconsistent classloading for extensions=true plugins - Key: MNG-5742 URL: https://jira.codehaus.org/browse/MNG-5742 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.2.1, 3.2.5 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Maven creates two class realms for build extensions plugins. One realm is used to contribute core extensions and the other to execute plugins goals. The two realms have slightly different classpath, with extensions realm not seeing classes from other extensions and not resolving reactor dependencies. The two realms are mostly independent and have duplicate copies of components, including duplicate copies of singletons. This results in multiple invocation of singleton components in some cases. This also results inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
[ https://jira.codehaus.org/browse/MNG-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5742. --- Resolution: Fixed Reworked the code to use the same class realm to load both core extensions components and plugin mojos. The fix https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=1420d61c05f0719ff59417430906954a4cc58ff6 Corresponding integration test https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=d4a340e6202d486c57adc2019924c03e28ffc975 inconsistent classloading for extensions=true plugins - Key: MNG-5742 URL: https://jira.codehaus.org/browse/MNG-5742 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.2.1, 3.2.5 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Maven creates two class realms for build extensions plugins. One realm is used to contribute core extensions and the other to execute plugins goals. The two realms have slightly different classpath, with extensions realm not seeing classes from other extensions and not resolving reactor dependencies. The two realms are mostly independent and have duplicate copies of components, including duplicate copies of singletons. This results in multiple invocation of singleton components in some cases. This also results inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
Igor Fedorenko created MNG-5742: --- Summary: inconsistent classloading for extensions=true plugins Key: MNG-5742 URL: https://jira.codehaus.org/browse/MNG-5742 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.2.5, 3.2.1 Reporter: Igor Fedorenko Maven creates two class realms for build extensions plugins. One realm is used to contribute core extensions and the other to execute plugins goals. The two realms have slightly different classpath, with extensions realm not seeing classes from other extensions and not resolving reactor dependencies. The two realms are mostly independent and have duplicate copies of components, including duplicate copies of singletons. This results in multiple invocation of singleton components in some cases. This also results inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
[ https://jira.codehaus.org/browse/MNG-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5742: --- Assignee: Igor Fedorenko inconsistent classloading for extensions=true plugins - Key: MNG-5742 URL: https://jira.codehaus.org/browse/MNG-5742 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.2.1, 3.2.5 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Maven creates two class realms for build extensions plugins. One realm is used to contribute core extensions and the other to execute plugins goals. The two realms have slightly different classpath, with extensions realm not seeing classes from other extensions and not resolving reactor dependencies. The two realms are mostly independent and have duplicate copies of components, including duplicate copies of singletons. This results in multiple invocation of singleton components in some cases. This also results inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5742) inconsistent classloading for extensions=true plugins
[ https://jira.codehaus.org/browse/MNG-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko updated MNG-5742: Fix Version/s: 3.2.6 inconsistent classloading for extensions=true plugins - Key: MNG-5742 URL: https://jira.codehaus.org/browse/MNG-5742 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.2.1, 3.2.5 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.6 Maven creates two class realms for build extensions plugins. One realm is used to contribute core extensions and the other to execute plugins goals. The two realms have slightly different classpath, with extensions realm not seeing classes from other extensions and not resolving reactor dependencies. The two realms are mostly independent and have duplicate copies of components, including duplicate copies of singletons. This results in multiple invocation of singleton components in some cases. This also results inconsistent/unexpected component wiring. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGINTESTING-44) support maven 3.2.4
[ https://jira.codehaus.org/browse/MPLUGINTESTING-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MPLUGINTESTING-44. Resolution: Fixed Fix Version/s: 3.3.0 Assignee: Igor Fedorenko Implemented. https://git-wip-us.apache.org/repos/asf?p=maven-plugin-testing.gita=searchh=HEADst=commits=MPLUGINTESTING-44 support maven 3.2.4 --- Key: MPLUGINTESTING-44 URL: https://jira.codehaus.org/browse/MPLUGINTESTING-44 Project: Maven Plugin Testing Issue Type: Bug Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.3.0 Need to update maven-plugin-testing-harness to work with maven 3.2.4. The incompatibility was introduced as part of MNG-5695 fix and boils down to class name change of one of internal classes and different way to setup MojoExecutionScope. Given the nature of the changes in maven, I plan to update maven-plugin-testing-harness version to 3.3.0 (up from 3.2.x) and to require maven 3.2.4. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build
Igor Fedorenko created MNG-5727:
---
Summary: unexpected InvalidArtifactRTException from
ProjectBuilder#build
Key: MNG-5727
URL: https://jira.codehaus.org/browse/MNG-5727
Project: Maven
Issue Type: Bug
Reporter: Igor Fedorenko
Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in
InvalidArtifactRTException below if project pom.xml has managed dependency
without version. Although the pom is invalid, I expected to get
ProjectBuildingException that includes location of problematic dependency,
similar to what I get during command line build.
{code}
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{org.apache.maven.its:a:null:jar}: The version cannot be empty.
at
org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
at
org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:123)
at
org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
at
org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
at
org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
at
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
...
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGINTESTING-44) support maven 3.2.4
Igor Fedorenko created MPLUGINTESTING-44: Summary: support maven 3.2.4 Key: MPLUGINTESTING-44 URL: https://jira.codehaus.org/browse/MPLUGINTESTING-44 Project: Maven Plugin Testing Issue Type: Bug Reporter: Igor Fedorenko Need to update maven-plugin-testing-harness to work with maven 3.2.4. The incompatibility was introduced as part of MNG-5695 fix and boils down to class name change of one of internal classes and different way to setup MojoExecutionScope. Given the nature of the changes in maven, I plan to update maven-plugin-testing-harness version to 3.3.0 (up from 3.2.x) and to require maven 3.2.4. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5669) same pom.xml is read multiple times
[ https://jira.codehaus.org/browse/MNG-5669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354586#comment-354586 ] Igor Fedorenko commented on MNG-5669: - Related regression reported against maven 3.2.3 http://mail-archives.apache.org/mod_mbox/maven-dev/201410.mbox/browser same pom.xml is read multiple times --- Key: MNG-5669 URL: https://jira.codehaus.org/browse/MNG-5669 Project: Maven Issue Type: Bug Affects Versions: 3.2.3 Reporter: Igor Fedorenko The same parent pom.xml is read multiple times during single ProjectBuilder#build invocation. This is a performance regression introduced in 3.2.3-SNAPSHOT. I do not know how much this affects real-world build performance. ~ ProjectBuilder#build(File,ModelSource,...) first constructs project model then initializes MavenProject instance. When project model is constructed, all local and remote parent pom.xml files are read and stored in model cache during ModelBuilder#readParent. The cache uses GAV keys. Only parent models are stored in the cache. The model of the project being being is not cached. When MavenProject instance is initialized, ProjectBuilder#build is called recursively to create parent MavenProject instances. There are appears to be two problems * ModelCache used to create original project Model is not passed to the recursive ProjectBuilder#build invocation. * ProjectBuilder#build does not use ModelCache for the project being built. During recursive invocation, this means the cache is never used to load parent pom.xml models cached during outer ProjectBuilder#build invocation. The solution is to introduce additional short-lived model cached keyed by pom.xml file location (project GAV is not known when ProjectBuilder#build is called). Alternatively, introduce ProjectBuilder#buildParent that will use the model cache. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-269) maven-plugin-tools-annotations does not work in builds which don't package
[
https://jira.codehaus.org/browse/MPLUGIN-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko updated MPLUGIN-269:
---
Summary: maven-plugin-tools-annotations does not work in builds which don't
package (was: ArchiverException: The source must not be a directory inside
m2e workspace)
maven-plugin-tools-annotations does not work in builds which don't package
--
Key: MPLUGIN-269
URL: https://jira.codehaus.org/browse/MPLUGIN-269
Project: Maven Plugin Tools
Issue Type: Bug
Components: maven-plugin-tools-annotations
Reporter: Igor Fedorenko
When running descriptor goal inside m2e workspace, I get the following
exception for plugin projects that depend on other plugin projects.
{code}
org.apache.maven.plugin.PluginExecutionException: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.3:descriptor failed: The
source must not be a directory.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
at
org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:328)
at
org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1355)
at
org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
at
org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1353)
at
org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
at
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:132)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:149)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:97)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must
not be a directory.
at
org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185)
at
org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:118)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClassesFromSourcesJar(JavaAnnotationsMojoDescriptorExtractor.java:220)
at
org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanJavadoc(JavaAnnotationsMojoDescriptorExtractor.java:172)
at
[jira] (MNG-5695) inconsistent custom scope bindings
[ https://jira.codehaus.org/browse/MNG-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5695: --- Assignee: Igor Fedorenko inconsistent custom scope bindings -- Key: MNG-5695 URL: https://jira.codehaus.org/browse/MNG-5695 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko Assignee: Igor Fedorenko Session scope is only available for maven core and core extensions components (i.e. -Dmaven.ext.class.path stuff), but does not work for components from maven plugins. Mojo execution scope works for components from maven plugins but not for maven core and core extensions. Need to consistently bind custom scopes in all realms. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5695) inconsistent custom scope bindings
Igor Fedorenko created MNG-5695: --- Summary: inconsistent custom scope bindings Key: MNG-5695 URL: https://jira.codehaus.org/browse/MNG-5695 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko Session scope is only available for maven core and core extensions components (i.e. -Dmaven.ext.class.path stuff), but does not work for components from maven plugins. Mojo execution scope works for components from maven plugins but not for maven core and core extensions. Need to consistently bind custom scopes in all realms. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5695) inconsistent custom scope bindings
[ https://jira.codehaus.org/browse/MNG-5695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5695. --- Resolution: Fixed Fix Version/s: 3.2.4 Should be fixed now main: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=b80fb7d7ce46c67cc2caa4e136430add83535e23 tests: https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=b80fb7d7ce46c67cc2caa4e136430add83535e23 inconsistent custom scope bindings -- Key: MNG-5695 URL: https://jira.codehaus.org/browse/MNG-5695 Project: Maven Issue Type: Bug Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.2.4 Session scope is only available for maven core and core extensions components (i.e. -Dmaven.ext.class.path stuff), but does not work for components from maven plugins. Mojo execution scope works for components from maven plugins but not for maven core and core extensions. Need to consistently bind custom scopes in all realms. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5562) Upgrade Aether 1.0 when available
[ https://jira.codehaus.org/browse/MNG-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-5562. --- Resolution: Fixed Fix Version/s: 3.2.4 Upgrade Aether 1.0 when available - Key: MNG-5562 URL: https://jira.codehaus.org/browse/MNG-5562 Project: Maven Issue Type: Task Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0-alpha-1, 3.1.0, 3.1.1 Reporter: Robert Scholte Assignee: Igor Fedorenko Priority: Minor Fix For: 3.2.4 Attachments: aether-upgrade.patch Aether-0.9.0-M4 fixes a couple of issues, for instance MDEP-405/MNG-5366 Upgrading is a bit tricky due to changed artifacts, see http://wiki.eclipse.org/Aether/New_and_Noteworthy#Transporters The attached patch contains the upgrade. Jason advises to wait for Aether-1.0, which should be coming Real Soon (tm) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5562) Upgrade Aether 1.0 when available
[ https://jira.codehaus.org/browse/MNG-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-5562: --- Assignee: Igor Fedorenko Upgrade Aether 1.0 when available - Key: MNG-5562 URL: https://jira.codehaus.org/browse/MNG-5562 Project: Maven Issue Type: Task Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0-alpha-1, 3.1.0, 3.1.1 Reporter: Robert Scholte Assignee: Igor Fedorenko Priority: Minor Fix For: 3.2.4 Attachments: aether-upgrade.patch Aether-0.9.0-M4 fixes a couple of issues, for instance MDEP-405/MNG-5366 Upgrading is a bit tricky due to changed artifacts, see http://wiki.eclipse.org/Aether/New_and_Noteworthy#Transporters The attached patch contains the upgrade. Jason advises to wait for Aether-1.0, which should be coming Real Soon (tm) -- 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:all-tabpanel
]
Igor Fedorenko reassigned MNG-5592:
---
Assignee: Igor Fedorenko
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
Assignee: Igor Fedorenko
Fix For: 3.2.4
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)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at
[jira] (MNG-5592) Maven Dependency Resolution Locks up
[
https://jira.codehaus.org/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko closed MNG-5592.
---
Resolution: Fixed
Fix Version/s: 3.2.4
Fixed by upgrading to aether 1.0
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=2909b5a329fd946796428a8e7f46034bc3bcbd2f
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
Assignee: Igor Fedorenko
Fix For: 3.2.4
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)
at
[jira] (MNG-5562) Upgrade Aether 1.0 when available
[ https://jira.codehaus.org/browse/MNG-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351951#comment-351951 ] Igor Fedorenko commented on MNG-5562: - Implemented in https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=2909b5a329fd946796428a8e7f46034bc3bcbd2f Upgrade Aether 1.0 when available - Key: MNG-5562 URL: https://jira.codehaus.org/browse/MNG-5562 Project: Maven Issue Type: Task Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0-alpha-1, 3.1.0, 3.1.1 Reporter: Robert Scholte Assignee: Igor Fedorenko Priority: Minor Fix For: 3.2.4 Attachments: aether-upgrade.patch Aether-0.9.0-M4 fixes a couple of issues, for instance MDEP-405/MNG-5366 Upgrading is a bit tricky due to changed artifacts, see http://wiki.eclipse.org/Aether/New_and_Noteworthy#Transporters The attached patch contains the upgrade. Jason advises to wait for Aether-1.0, which should be coming Real Soon (tm) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5366) [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4
[ https://jira.codehaus.org/browse/MNG-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=351953#comment-351953 ] Igor Fedorenko commented on MNG-5366: - This maybe fixed by the new aether I just integrated in maven, but hard to tell for sure without example project or unit test to demonstrate the original problem. [Regression] resolveAlways does not force dependency resolution in Maven 3.0.4 -- Key: MNG-5366 URL: https://jira.codehaus.org/browse/MNG-5366 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.4, 3.0.5, 3.1.0, 3.1.1, 3.2.1, 3.2.2 Reporter: Paul Gier Fix For: Issues to be reviewed for 4.x Using Maven 3.0.4, artifacts can only be resolved a single time during the build lifecycle using the Maven 2.x dependency resolution API. Using resolver.resolveAlways() should force re-resolution of the artifact, however if the artifact was already resolved once during the build, then it will not be re-resolved even when calling resolveAlways(). This works as expected in Maven 3.0.0-3.0.3, and the artifact is re-resolved. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5677) Fine-grained cache management
Igor Fedorenko created MNG-5677: --- Summary: Fine-grained cache management Key: MNG-5677 URL: https://jira.codehaus.org/browse/MNG-5677 Project: Maven Issue Type: Bug Components: Embedding Reporter: Igor Fedorenko Maven maintains a number of caches to improve performance and memory utilization when multiple projects reference the same resource (artifact metadata, class realms, etc). m2e needs a way to flush these caches on per-project basis. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
