[jira] [Commented] (MNG-7138) Proper verify of plugin configuration Bean set method call
[
https://issues.apache.org/jira/browse/MNG-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17405121#comment-17405121
]
Stuart McCulloch commented on MNG-7138:
---
Yes, MNG-5013 introduced this feature - it's only used when we're
configuring a bean with scalar value (in which case we delegate to the
bean's "set" method)
> Proper verify of plugin configuration Bean set method call
> --
>
> Key: MNG-7138
> URL: https://issues.apache.org/jira/browse/MNG-7138
> Project: Maven
> Issue Type: Improvement
> Components: Integration Tests
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> When we use custom {{Bean}} as {{plugin}} parameter configuration, {{set}}
> method of {{Bean}} is only called for default value.
> Example:
> {code:java}
> public class MyMojo extends AbstractMojo
> {
>@Parameter
> private Bean beanParam;
> }
> {code}
> {code:java}
> public class Bean
> {
>private String field1;
>private String field2;
>public void set(String value) {
> this.field1 = value;
>}
> }
> {code}
>
> And configuration with fields name:
> {code:xml}
>
>
> value1
> value2
>
>
> {code}
> in this case {{Bean.set}} is not called.
>
> When we have:
> {code:xml}
>
>value
>
> {code}
> {{Bean.set}} is called.
>
> I will fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
[
https://issues.apache.org/jira/browse/MNG-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16178780#comment-16178780
]
Stuart McCulloch commented on MNG-5981:
---
This was fixed in Maven 3.5.0 by the commit mentioned in the previous
comment (after it was reopened) so upgrade to at least 3.5.0 to pick up the
fix.
> Plexus lifecycle could be activated too late during overlapping parallel
> requests
> -
>
> Key: MNG-5981
> URL: https://issues.apache.org/jira/browse/MNG-5981
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.1, 3.3.3, 3.3.9
>Reporter: Stuart McCulloch
> Fix For: needing-scrub-3.4.0-fallout
>
>
> A user reported seeing NPEs when running a particular project in parallel:
> http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
> This was tracked down to the way we defer lifecycle activation for components
> (potentially) involved in dependency injection cycles (A->B->A). This bug is
> only triggered by specific lookup sequences when running parallel builds.
> The key fix was to move when we start cycle detection to the first scoped
> component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
> (since a cycle can only ever involve scoped components - unscoped/per-lookup
> components can never repeat)
> The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot
> when we inject a circular dependency proxy (which is when when we need to
> defer activation until the end of the cycle to allow that proxy to be
> populated). Previously the code was overly pessimistic when considering what
> might end up as a cycle.
> Sisu 0.3.3 contains both these fixes:
> https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
> Previous releases can be patched by replacing the old org.eclipse.sisu.inject
> and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6172) Precedence of command-line system property options has changed
Stuart McCulloch created MNG-6172:
-
Summary: Precedence of command-line system property options has
changed
Key: MNG-6172
URL: https://issues.apache.org/jira/browse/MNG-6172
Project: Maven
Issue Type: Bug
Components: Command Line
Reporter: Stuart McCulloch
The current state of master (what will eventually become 3.5.0) has reversed
the precedence of command-line system property options compared to previous
releases of Maven.
For example, running this command with a basic project:
{code}
mvn -Dmaven.repo.local=/tmp/aaa -Dmaven.repo.local=/tmp/zzz validate
{code}
using current master will cause {{/tmp/aaa}} to be created (first-one-wins),
whereas for all previous releases of Maven {{/tmp/zzz}} would have been created
(last-one-wins)
This has the potential to break CI builds which relied on the previous
last-one-wins behaviour.
This was introduced by the fix for MNG-6078
https://github.com/apache/maven/commit/ca4303031357a7decaee8de770b71fb2c2fedd28
- by reversing the whole array the precedence between options on the same
command line has been reversed, not just the relationship between
.mvn/maven.config options and command line options.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (WAGON-469) wagon-http does not enable Expect-Continue by default
[
https://issues.apache.org/jira/browse/WAGON-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736635#comment-15736635
]
Stuart McCulloch commented on WAGON-469:
Suggested patch: https://github.com/apache/maven-wagon/pull/31
> wagon-http does not enable Expect-Continue by default
> -
>
> Key: WAGON-469
> URL: https://issues.apache.org/jira/browse/WAGON-469
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.10
>Reporter: Stuart McCulloch
>
> According to
> http://maven.apache.org/guides/mini/guide-http-settings.html#The_Basics PUT
> requests made with the HTTP wagon will enable Expect-Continue support by
> default.
> However testing shows that when no {{}} is provided in
> settings.xml Expect-Continue support is not enabled by wagon-http for PUT
> requests.
> Similarly, when an empty {{}} section is provided in
> settings.xml, Expect-Continue support is not enabled by wagon-http for PUT
> requests.
> Only when a {{}} section like:
> {code:xml}
>
>
>
> http.protocol.expect-continue
> %b,true
>
>
>
> {code}
> is provided in settings.xml is Expect-Continue support enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (WAGON-469) wagon-http does not enable Expect-Continue by default
Stuart McCulloch created WAGON-469:
--
Summary: wagon-http does not enable Expect-Continue by default
Key: WAGON-469
URL: https://issues.apache.org/jira/browse/WAGON-469
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.10
Reporter: Stuart McCulloch
According to
http://maven.apache.org/guides/mini/guide-http-settings.html#The_Basics PUT
requests made with the HTTP wagon will enable Expect-Continue support by
default.
However testing shows that when no {{}} is provided in
settings.xml Expect-Continue support is not enabled by wagon-http for PUT
requests.
Similarly, when an empty {{}} section is provided in
settings.xml, Expect-Continue support is not enabled by wagon-http for PUT
requests.
Only when a {{}} section like:
{code:xml}
http.protocol.expect-continue
%b,true
{code}
is provided in settings.xml is Expect-Continue support enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5805) Custom packaging types: configuring DefaultLifecycleMapping mojo executions
[
https://issues.apache.org/jira/browse/MNG-5805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15660390#comment-15660390
]
Stuart McCulloch commented on MNG-5805:
---
note the MNG-5805 style of lifecycle configuration should go inside:
{code:xml}
foo
{code}
rather than:
{code:xml}
foo
{code}
There was a bug in Maven 3.3.9 where it also accepted MNG-5805 style
configuration using {{}} but this broke backwards compatibility with
plugins like flexmojos (see https://issues.apache.org/jira/browse/MNG-5958 for
more details)
If you stick with {{}} then your MNG-5805 lifecycle
configuration will work with 3.3.9 and 3.4.0+
An example of the new lifecycle configuration can be seen in
https://github.com/apache/maven-integration-testing/blob/master/core-it-support/core-it-plugins/mng5805-extension/src/main/resources/META-INF/plexus/components.xml
> Custom packaging types: configuring DefaultLifecycleMapping mojo executions
> ---
>
> Key: MNG-5805
> URL: https://issues.apache.org/jira/browse/MNG-5805
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Reporter: Anton Tanasenko
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.3.9
>
>
> Currently, DefaultLifecycleMapping does not support mapping phases to goals
> with a custom configuration (see
> maven-core/src/main/resources/META-INF/plexus/default-bindings.xml). It is
> impossible to bind, say, an assembly plugin to 'package' phase within a
> custom packaging type, since assembly plugin requires a meaningful
> configuration to be set.
> At my job, we have a number of poms, each serving a purpose of defining a
> lifecycle for a particular type of project (there's one for jar, a couple for
> wars and several more for other types of deployable artifacts).
> Now that I somewhat understand maven's lifecycle, It seems natural to convert
> such poms to custom packaging types, leaving only a single parent with global
> config and pluginManagement. But it is currently impossible, since we are
> using mostly standard plugins (only occasional dedicated ones) to configure
> projects' lifecycles.
> I did some digging around and put together a relatively straightforward
> change to maven-core:
> https://github.com/apache/maven/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
> It both introduces support for specifying configuration and dependencies for
> mojo executions:
> {code:xml}
>
>
>
> org.apache.maven.plugins:maven-install-plugin:2.4:install
> ...
> ...
>
>
> ...
>
>
>
> {code}
> as well as retains support for existing mapping syntax:
> {code:xml}
> org.apache.maven.plugins:maven-install-plugin:2.4:install,
> ...
> {code}
> I will put together some its (as well as make sure that existing are running
> ok) and create a pull request for both. Also, there are a couple of changes
> that break API in org/apache/maven/lifecycle/Lifecycle.java and
> org/apache/maven/lifecycle/mapping/Lifecycle.java. How critical is it to
> mantain compatibility in those two?
> ITS:
> https://github.com/apache/maven-integration-testing/compare/master...atanasenko:mng-5805-lifecycle-mojo-config?w=1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6084) Support JSR250 annotations
[
https://issues.apache.org/jira/browse/MNG-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15482818#comment-15482818
]
Stuart McCulloch commented on MNG-6084:
---
Note: any mojos which have {{@PreDestroy}} methods will be disposed as soon as
they're done (Maven tells the container about this explicitly in
DefaultMavenPluginManager.java line 759) whereas leftover components which have
{{@PreDestroy}} methods will be disposed at the end of the build. (The next
container release should be more aggressive about disposing of non-mojo
components.)
> Support JSR250 annotations
> --
>
> Key: MNG-6084
> URL: https://issues.apache.org/jira/browse/MNG-6084
> Project: Maven
> Issue Type: New Feature
> Components: core
>Affects Versions: 3.3.9
>Reporter: Dan Tran
>
> JSR330 ( @Named, @Singeton, etc) currently supported for plugin development.
> Would like to see JSR250 as well(@PostConstruct, etc)
> Detail discussion is at
> http://maven.40175.n5.nabble.com/Maven-Plugin-and-JSR330-td5879508.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6084) Support JSR250 annotations
[
https://issues.apache.org/jira/browse/MNG-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15482791#comment-15482791
]
Stuart McCulloch commented on MNG-6084:
---
Support for JSR250 lifecycle annotations can be enabled in the
{{ContainerConfiguration}}, configured in
{{maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java}}:
{code}
ContainerConfiguration cc = new DefaultContainerConfiguration()
.setClassWorld( cliRequest.classWorld )
.setRealm( containerRealm )
.setClassPathScanning( PlexusConstants.SCANNING_INDEX )
.setAutoWiring( true )
.setJSR250Lifecycle( true )// <--- enable support for
@PostConstruct and @PreDestroy
.setName( "maven" );
{code}
You may also want to add {{javax.annotation}} to the list of packages exported
to plugins from Maven core, defined in
{{maven-core/src/main/resources/META-INF/maven/extension.xml}}:
{code}
javax.annotation.*
{code}
otherwise it will use the package from the current JRE, which might not have it
(ie. Java 7 and earlier) or might hide it by default (Jigsaw)
> Support JSR250 annotations
> --
>
> Key: MNG-6084
> URL: https://issues.apache.org/jira/browse/MNG-6084
> Project: Maven
> Issue Type: New Feature
> Components: core
>Affects Versions: 3.3.9
>Reporter: Dan Tran
>
> JSR330 ( @Named, @Singeton, etc) currently supported for plugin development.
> Would like to see JSR250 as well(@PostConstruct, etc)
> Detail discussion is at
> http://maven.40175.n5.nabble.com/Maven-Plugin-and-JSR330-td5879508.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5981) Plexus lifecycle could be activated too late during overlapping parallel requests
Stuart McCulloch created MNG-5981:
-
Summary: Plexus lifecycle could be activated too late during
overlapping parallel requests
Key: MNG-5981
URL: https://issues.apache.org/jira/browse/MNG-5981
Project: Maven
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.3.9, 3.3.3, 3.3.1
Reporter: Stuart McCulloch
A user reported seeing NPEs when running a particular project in parallel:
http://www.mail-archive.com/users%40felix.apache.org/msg17072.html
This was tracked down to the way we defer lifecycle activation for components
(potentially) involved in dependency injection cycles (A->B->A). This bug is
only triggered by specific lookup sequences when running parallel builds.
The key fix was to move when we start cycle detection to the first scoped
component in the lookup: https://bugs.eclipse.org/bugs/show_bug.cgi?id=487090
(since a cycle can only ever involve scoped components - unscoped/per-lookup
components can never repeat)
The accuracy was also improved by using {{Scopes.isCircularProxy}} to spot when
we inject a circular dependency proxy (which is when when we need to defer
activation until the end of the cycle to allow that proxy to be populated).
Previously the code was overly pessimistic when considering what might end up
as a cycle.
Sisu 0.3.3 contains both these fixes:
https://wiki.eclipse.org/Sisu/Changelog#Release_0.3.3
Previous releases can be patched by replacing the old org.eclipse.sisu.inject
and org.eclipse.sisu.plexus jars with the ones from the 0.3.3 release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
[ https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085448#comment-15085448 ] Stuart McCulloch commented on MNG-5958: --- https://github.com/apache/maven/pull/77 > java.lang.String cannot be cast to > org.apache.maven.lifecycle.mapping.LifecyclePhase > > > Key: MNG-5958 > URL: https://issues.apache.org/jira/browse/MNG-5958 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.3.9 > Environment: win 8.1 >Reporter: Meytal Genah >Priority: Minor > > Our app uses flex mojo. > We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get: > [ERROR] Internal error: java.lang.ClassCastException: java.lang.String cannot > be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > java.lang.ClassCastException: java.lang.String cannot be cast to > org.apache.maven.lifecycle.mapping.LifecyclePhas > e > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > 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:497) > 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) > Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to > org.apache.maven.lifecycle.mapping.LifecyclePhase > at > org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119) > at > org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411) > at > org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419) > at > org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410) > at > org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83) > at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) > ... 11 more > I didn’t see anyone encountering the same problem. Maybe it is related to the > fix of https://issues.apache.org/jira/browse/MNG-5805. > Also, according to the stack trace, the invalid casting is in this line: > LifecyclePhase goals = goalsForLifecyclePhase.getValue(); > this is the content of the pom.xml: > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > >com.myapp.plugin > GUI > trunk > > myapp-war > 1.0 > war > Plugin GUI WAR > > myapp-ui > > > org.apache.maven.plugins > mave
[jira] [Issue Comment Deleted] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
[ https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated MNG-5958: -- Comment: was deleted (was: https://github.com/apache/maven/pull/77) > java.lang.String cannot be cast to > org.apache.maven.lifecycle.mapping.LifecyclePhase > > > Key: MNG-5958 > URL: https://issues.apache.org/jira/browse/MNG-5958 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.3.9 > Environment: win 8.1 >Reporter: Meytal Genah >Priority: Minor > > Our app uses flex mojo. > We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get: > [ERROR] Internal error: java.lang.ClassCastException: java.lang.String cannot > be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > java.lang.ClassCastException: java.lang.String cannot be cast to > org.apache.maven.lifecycle.mapping.LifecyclePhas > e > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) > 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:497) > 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) > Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to > org.apache.maven.lifecycle.mapping.LifecyclePhase > at > org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119) > at > org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451) > at > org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626) > at > org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411) > at > org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419) > at > org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410) > at > org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83) > at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) > ... 11 more > I didn’t see anyone encountering the same problem. Maybe it is related to the > fix of https://issues.apache.org/jira/browse/MNG-5805. > Also, according to the stack trace, the invalid casting is in this line: > LifecyclePhase goals = goalsForLifecyclePhase.getValue(); > this is the content of the pom.xml: > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > >com.myapp.plugin > GUI > trunk > > myapp-war > 1.0 > war > Plugin GUI WAR > > myapp-ui > > > org.apache.maven.plugins > maven-compiler-plugin >
[jira] [Commented] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
[
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085440#comment-15085440
]
Stuart McCulloch commented on MNG-5958:
---
PS. the following minimal pom.xml recreates the issue - with the above patch
the exception no longer occurs:
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
org.example
mng-958
1.0
swf
org.sonatype.flexmojos
flexmojos-maven-plugin
4.0-RC2
true
{code}
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
>
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Priority: Minor
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> [ERROR] Internal error: java.lang.ClassCastException: java.lang.String cannot
> be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> 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:497)
> 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)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411)
> at
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
> at
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> ... 11 more
> I didn’t see anyone encountering the same problem. Maybe it is related to the
> fix of https://issues.apache.org/jira/browse/MNG-5805.
> Also, according to the stack trace, the invalid casting is in this line:
> LifecyclePhase goals = goalsForLifecyclePhase.getValue();
> this is the content of the pom.xml:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/
[jira] [Commented] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
[
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15085416#comment-15085416
]
Stuart McCulloch commented on MNG-5958:
---
The issue appears to be that
org.sonatype.flexmojos:flexmojos-maven-plugin:4.0-RC2 has its own
implementation of org/apache/maven/lifecycle/mapping/LifecycleMapping.java and
this has been affected by the changes in
https://issues.apache.org/jira/browse/MNG-5805
While binary compatibility was restored for getPhases it wasn't for setPhases,
which means that flexmojos-maven-plugin is pushing a map of Strings directly
into the internal lifecyclePhases map which is now declared as
Map. Unfortunately this mismatch isn't detected during
the push because of generic type erasure, it's only when Maven trues to
retrieve one of the values from the map and treats it as a LifecyclePhase that
an exception occurs.
The following patch should restore binary compatibility for the setPhases
method:
{code}
diff --git
a/maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java
b/maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java
index d2b6d6c..c14cf94 100644
--- a/maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java
+++ b/maven-core/src/main/java/org/apache/maven/lifecycle/mapping/Lifecycle.java
@@ -106,8 +106,13 @@ public void setLifecyclePhases( Map lifecyclePhases )
}
@Deprecated
-public void setPhases( Map phases )
+public void setPhases( Map phases )
{
-setLifecyclePhases( phases );
+Map lphases = new LinkedHashMap<>();
+for ( Map.Entry e: phases.entrySet() )
+{
+lphases.put( e.getKey(), new LifecyclePhase( e.getValue() ) );
+}
+setLifecyclePhases( lphases );
}
}
{code}
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
>
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Priority: Minor
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> [ERROR] Internal error: java.lang.ClassCastException: java.lang.String cannot
> be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> 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:497)
> 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)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
>
[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-tabpanel&focusedCommentId=14744553#comment-14744553
]
Stuart McCulloch commented on MPLUGIN-271:
--
I've cherry-picked the fix back to Sisu/Plexus 0.3.2 which is now available on
central.
> 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 List pomIncludes;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5440) default-value on mojo parameter of type collection or array effectively make parameter read-only
[
https://issues.apache.org/jira/browse/MNG-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14744552#comment-14744552
]
Stuart McCulloch commented on MNG-5440:
---
I've cherry-picked the fix back to Sisu/Plexus 0.3.2 which is now available on
central.
> default-value on mojo parameter of type collection or array effectively make
> parameter read-only
>
>
> Key: MNG-5440
> URL: https://issues.apache.org/jira/browse/MNG-5440
> Project: Maven
> Issue Type: Bug
>Reporter: Jan Sievers
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mojoParamsBug.zip
>
>
> If you use default-value on collection or array mojo parameters like
> {code:java}
> /**
> * @parameter default-value="foo,bar"
> */
> private List param1;
> {code}
> the default value will always win over pom.xml configuration.
> See demo project attached.
> Steps to reproduce:
> 1. {{mvn install}} on the demo project
> 2. {{mvn compile -f test-pom.xml -X -e}} on the demo project
> you can see in the debug log that mojo configuration
> {noformat}[DEBUG] Configuration:
>
>
> non-default value1 param1
> non-default value2 param1
>
>
> non-default value1 param2
> non-default value2 param2
>
> {noformat}
> will not be aplied correctly:
> {noformat}[DEBUG] Configuring mojo
> 'mojoParamsBug:mojoParamsBug:0.0.1-SNAPSHOT:demo' with basic configurator -->
> [DEBUG] (f) param1 = [foo, bar]
> [DEBUG] (f) param2 = [baz]
> [DEBUG] -- end configuration --
> [INFO] param1: [foo, bar]
> [INFO] param2: [baz]{noformat}
> If default values for srrays/collection are not supported, this should fail
> the build in step 1. above.
> If they are supported, the configurator should be fixed to actually allow
> configuring non-default values.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MSHADE-183) Getting "Error creating shaded jar: java.util.jar.Attributes cannot be cast to java.lang.String" error when using ManifestResourceTransformer with Maven 3.2.5
[
https://issues.apache.org/jira/browse/MSHADE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569153#comment-14569153
]
Stuart McCulloch edited comment on MSHADE-183 at 6/2/15 2:36 PM:
-
https://issues.apache.org/jira/browse/MSHADE-168 describes why this error is
happening. The correct generic signature for that field should really be
{{Map}} but {{Map}} works just as well, since
the value is passed directly into the Attributes instance which accepts any
type at compile time (but checks the value is a string at runtime) as discussed
in MSHADE-168.
was (Author: mcculls):
https://issues.apache.org/jira/browse/MSHADE-168 describes why this error is
happening. The correct generic signature for that field should really be
{{Map}} but {{Map}} works just as well, since
the value is passed directly into the Attributes instance which accepts any
type.
> Getting "Error creating shaded jar: java.util.jar.Attributes cannot be cast
> to java.lang.String" error when using ManifestResourceTransformer with Maven
> 3.2.5
> --
>
> Key: MSHADE-183
> URL: https://issues.apache.org/jira/browse/MSHADE-183
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Chris Heisterkamp
>Assignee: Karl Heinz Marbaise
> Fix For: 2.4
>
> Attachments: manifest_resource_transformer_error.diff
>
>
> If you are using the {{ManifestResourceTransformer}} with empty values in the
> configuration you will get a {{"Error creating shaded jar:
> java.util.jar.Attributes cannot be cast to java.lang.String"}} error with
> Maven 3.2.5.
> Here as an example config that causes the problem
> {code:xml}
>
>
>
> implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
>
> com.mycompany.app.App
>
>
>
>
>
> {code}
> I'm not sure what changed in populating the manifestEntries map but it looks
> like the {{manifestEntries.entrySet()}} in {{ManifestResourceTransformer}} is
> now getting back {{Attributes}} objects for the {{null}} values instead of
> {{null}}. When the transformer calls {{getValue()}} on the {{Attributes}}
> object you get the error.
> The fix was to make manifestEntries a {{Map}} instead of
> {{Map}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-168) ManifestResourceTransformer manifestEntries map declares wrong generic type
[ https://issues.apache.org/jira/browse/MSHADE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569172#comment-14569172 ] Stuart McCulloch commented on MSHADE-168: - Closing as this has been fixed independently by MSHADE-183 > ManifestResourceTransformer manifestEntries map declares wrong generic type > --- > > Key: MSHADE-168 > URL: https://issues.apache.org/jira/browse/MSHADE-168 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Stuart McCulloch > Attachments: ManifestResourceTransformer_manifestEntries.patch > > > The ManifestResourceTransformer class declares a map called manifestEntries > with a signature of Map. This is incorrect because at > runtime this map is actually only ever populated with String values. > Furthermore the only place where these map values are used is: > https://github.com/apache/maven-plugins/blob/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/ManifestResourceTransformer.java#L106 > and while the signature of Attributes.put accepts values of any type, the > javadoc states that values are checked that they are Strings at runtime: > http://docs.oracle.com/javase/7/docs/api/java/util/jar/Attributes.html#put(java.lang.Object,%20java.lang.Object) > In fact it turns out that you can change the manifestEntries Map signature to > use any type for the value without getting a compile error - and at runtime > it's ignored by the code populating the configuration. I only happened to > notice this discrepancy when investigating a related issue involving a > stricter version of the plexus MapConverter that checks generic bounds when > populating maps: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=429369 > The correct signature of manifestEntries should be Map -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSHADE-168) ManifestResourceTransformer manifestEntries map declares wrong generic type
[ https://issues.apache.org/jira/browse/MSHADE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch closed MSHADE-168. --- Resolution: Duplicate > ManifestResourceTransformer manifestEntries map declares wrong generic type > --- > > Key: MSHADE-168 > URL: https://issues.apache.org/jira/browse/MSHADE-168 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Stuart McCulloch > Attachments: ManifestResourceTransformer_manifestEntries.patch > > > The ManifestResourceTransformer class declares a map called manifestEntries > with a signature of Map. This is incorrect because at > runtime this map is actually only ever populated with String values. > Furthermore the only place where these map values are used is: > https://github.com/apache/maven-plugins/blob/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/ManifestResourceTransformer.java#L106 > and while the signature of Attributes.put accepts values of any type, the > javadoc states that values are checked that they are Strings at runtime: > http://docs.oracle.com/javase/7/docs/api/java/util/jar/Attributes.html#put(java.lang.Object,%20java.lang.Object) > In fact it turns out that you can change the manifestEntries Map signature to > use any type for the value without getting a compile error - and at runtime > it's ignored by the code populating the configuration. I only happened to > notice this discrepancy when investigating a related issue involving a > stricter version of the plexus MapConverter that checks generic bounds when > populating maps: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=429369 > The correct signature of manifestEntries should be Map -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSHADE-183) Getting "Error creating shaded jar: java.util.jar.Attributes cannot be cast to java.lang.String" error when using ManifestResourceTransformer with Maven 3.2.5
[
https://issues.apache.org/jira/browse/MSHADE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569153#comment-14569153
]
Stuart McCulloch commented on MSHADE-183:
-
https://issues.apache.org/jira/browse/MSHADE-168 describes why this error is
happening. The correct generic signature for that field should really be
{{Map}} but {{Map}} works just as well, since
the value is passed directly into the Attributes instance which accepts any
type.
> Getting "Error creating shaded jar: java.util.jar.Attributes cannot be cast
> to java.lang.String" error when using ManifestResourceTransformer with Maven
> 3.2.5
> --
>
> Key: MSHADE-183
> URL: https://issues.apache.org/jira/browse/MSHADE-183
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Chris Heisterkamp
>Assignee: Karl Heinz Marbaise
> Fix For: 2.4
>
> Attachments: manifest_resource_transformer_error.diff
>
>
> If you are using the {{ManifestResourceTransformer}} with empty values in the
> configuration you will get a {{"Error creating shaded jar:
> java.util.jar.Attributes cannot be cast to java.lang.String"}} error with
> Maven 3.2.5.
> Here as an example config that causes the problem
> {code:xml}
>
>
>
> implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
>
> com.mycompany.app.App
>
>
>
>
>
> {code}
> I'm not sure what changed in populating the manifestEntries map but it looks
> like the {{manifestEntries.entrySet()}} in {{ManifestResourceTransformer}} is
> now getting back {{Attributes}} objects for the {{null}} values instead of
> {{null}}. When the transformer calls {{getValue()}} on the {{Attributes}}
> object you get the error.
> The fix was to make manifestEntries a {{Map}} instead of
> {{Map}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MSHARED-53) Maven2OsgiConverter can leak JarFiles
[ https://jira.codehaus.org/browse/MSHARED-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch reopened MSHARED-53: - Re-opening because the JarFile leak still exists and there's a patch attached to the issue that fixes the problem. Is anything else needed before the patch can be applied? > Maven2OsgiConverter can leak JarFiles > - > > Key: MSHARED-53 > URL: https://jira.codehaus.org/browse/MSHARED-53 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-osgi >Reporter: Stuart McCulloch >Priority: Minor > Attachments: MOD > > > The default Maven2OsgiConverter can leak JarFiles, because they are sometimes > opened but never closed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-463) order versions when selecting archetype in batch mode
Stuart McCulloch created ARCHETYPE-463: -- Summary: order versions when selecting archetype in batch mode Key: ARCHETYPE-463 URL: https://jira.codehaus.org/browse/ARCHETYPE-463 Project: Maven Archetype Issue Type: Improvement Components: Plugin Affects Versions: 2.2 Reporter: Stuart McCulloch ARCHETYPE-325 added sorting of archetypes by version when running in interactive mode. However when running in batch mode, if the archetype version is not defined the plugin just takes the first entry in the catalog that matches the requested archetypeGroupId and archetypeArtifactId. This might not be the latest archetype version depending on the catalog ordering. Ideally the DefaultArchetypeSelector would use a similar approach to that used in ARCHETYPE-325 to find the latest version for a given groupId and artifactId in the catalog and then use that as the archetypeVersion. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5534) Update to Sisu 0.1.0 and Guice 3.1.6
[ https://jira.codehaus.org/browse/MNG-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348938#comment-348938 ] Stuart McCulloch commented on MNG-5534: --- FYI, latest releases are Sisu 0.2.1 and Guice 3.2.2 (note you can also update to the latest version of Guava with this version of Guice) > Update to Sisu 0.1.0 and Guice 3.1.6 > > > Key: MNG-5534 > URL: https://jira.codehaus.org/browse/MNG-5534 > Project: Maven > Issue Type: Improvement >Reporter: Mikolaj Izdebski >Assignee: Jason van Zyl > Attachments: 0001-Update-to-Sisu-0.1.0-and-Guice-3.1.6.patch, > upgrade_to_eclipse_sisu_0.1.1.patch > > > Please update to Eclipse Sisu 0.1.0 and Sisu Guice 3.1.6. > Sisu depends on Guice, but dependency scope changed from "compile" to > "provided" in Sisu 0.1.0. As a Sisu user, Maven needs to have runtime > dependency on Guice. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5620) LinkageError when CDI is in the classpath
[ https://jira.codehaus.org/browse/MNG-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=347979#comment-347979 ] Stuart McCulloch commented on MNG-5620: --- I listed the various solutions in http://markmail.org/message/deh5q7tk5fwa35yo (ie. narrow the export, widen the export, or remove the export) along with what it does and why you might want to keep it exported: http://markmail.org/message/5ba2hz7unavrlkmt - and last I heard Igor wanted it kept exported: http://markmail.org/message/xvq4ku32cvxcxsai But it's up to you whether to export it or not, if you don't export it then it just disables that feature. > LinkageError when CDI is in the classpath > -- > > Key: MNG-5620 > URL: https://jira.codehaus.org/browse/MNG-5620 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.1.0-alpha-1, 3.1.0, 3.1.1, 3.2.1 >Reporter: Martin Grigorov >Assignee: Jason van Zyl > > We have troubles use 'mvn jetty:run' for > https://github.com/apache/wicket/tree/master/wicket-examples after upgrading > to Maven 3.1.0+. > It fails with: > 2014-04-17 16:22:57.160:WARN:oejuc.AbstractLifeCycle:FAILED > org.mortbay.jetty.plugin.JettyServer@44e5b006: java.lang.LinkageError: loader > constraint violation: when resolving overridden method > "org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;" > the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of > the current class, org/jboss/weld/Weld, and its superclass loader (instance > of org/codehaus/plexus/classworlds/realm/ClassRealm), have different Class > objects for the type tion/Annotation;)Ljavax/enterprise/inject/Instance; used > in the signature > java.lang.LinkageError: loader constraint violation: when resolving > overridden method > "org.jboss.weld.Weld.select(Ljavax/enterprise/util/TypeLiteral;[Ljava/lang/annotation/Annotation;)Ljavax/enterprise/inject/Instance;" > the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of > the current class, org/jboss/weld/Weld, and its superclass loader (instance > of org/codehaus/plexus/classworlds/realm/ClassRealm), have different Class > objects for the type tion/Annotation;)Ljavax/enterprise/inject/Instance; used > in the signature > at > org.jboss.weld.servlet.StaticWeldProvider$WeldSingleton.(StaticWeldProvider.java:29) > at > org.jboss.weld.servlet.StaticWeldProvider.getCDI(StaticWeldProvider.java:49) > at javax.enterprise.inject.spi.CDI.current(CDI.java:60) > at > org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:85) > at > org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34) > at > org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:171) > at > org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:733) > ... > The issue is not new. We just noticed that when using 3.0.5 it runs fine so > it should be some change in Maven itself. > I've found that another user had the same issue: > http://stackoverflow.com/a/18168215/497381 > How to reproduce: > 1) git clone https://github.com/apache/wicket.git > 2) mvn install (just to have all dependencies) > 3) cd wicket-examples > 4) mvn jetty:run (fails with 3.1.0+) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-168) ManifestResourceTransformer manifestEntries map declares wrong generic type
[ https://jira.codehaus.org/browse/MSHADE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345924#comment-345924 ] Stuart McCulloch commented on MSHADE-168: - Opened https://github.com/apache/maven-plugins/pull/22 > ManifestResourceTransformer manifestEntries map declares wrong generic type > --- > > Key: MSHADE-168 > URL: https://jira.codehaus.org/browse/MSHADE-168 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Stuart McCulloch > Attachments: ManifestResourceTransformer_manifestEntries.patch > > > The ManifestResourceTransformer class declares a map called manifestEntries > with a signature of Map. This is incorrect because at > runtime this map is actually only ever populated with String values. > Furthermore the only place where these map values are used is: > https://github.com/apache/maven-plugins/blob/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/ManifestResourceTransformer.java#L106 > and while the signature of Attributes.put accepts values of any type, the > javadoc states that values are checked that they are Strings at runtime: > http://docs.oracle.com/javase/7/docs/api/java/util/jar/Attributes.html#put(java.lang.Object,%20java.lang.Object) > In fact it turns out that you can change the manifestEntries Map signature to > use any type for the value without getting a compile error - and at runtime > it's ignored by the code populating the configuration. I only happened to > notice this discrepancy when investigating a related issue involving a > stricter version of the plexus MapConverter that checks generic bounds when > populating maps: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=429369 > The correct signature of manifestEntries should be Map -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5534) Update to Sisu 0.1.0 and Guice 3.1.6
[ https://jira.codehaus.org/browse/MNG-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344850#comment-344850 ] Stuart McCulloch commented on MNG-5534: --- Note that if/when maven core upgrades to Sisu 0.2.x or later, MSHADE-168 should also be applied to fix an incorrect generics declaration in the shade plugin. > Update to Sisu 0.1.0 and Guice 3.1.6 > > > Key: MNG-5534 > URL: https://jira.codehaus.org/browse/MNG-5534 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.1.2 >Reporter: Mikolaj Izdebski >Assignee: Jason van Zyl > Attachments: 0001-Update-to-Sisu-0.1.0-and-Guice-3.1.6.patch, > upgrade_to_eclipse_sisu_0.1.1.patch > > > Please update to Eclipse Sisu 0.1.0 and Sisu Guice 3.1.6. > Sisu depends on Guice, but dependency scope changed from "compile" to > "provided" in Sisu 0.1.0. As a Sisu user, Maven needs to have runtime > dependency on Guice. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-168) ManifestResourceTransformer manifestEntries map declares wrong generic type
Stuart McCulloch created MSHADE-168: --- Summary: ManifestResourceTransformer manifestEntries map declares wrong generic type Key: MSHADE-168 URL: https://jira.codehaus.org/browse/MSHADE-168 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Stuart McCulloch Attachments: ManifestResourceTransformer_manifestEntries.patch The ManifestResourceTransformer class declares a map called manifestEntries with a signature of Map. This is incorrect because at runtime this map is actually only ever populated with String values. Furthermore the only place where these map values are used is: https://github.com/apache/maven-plugins/blob/trunk/maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/resource/ManifestResourceTransformer.java#L106 and while the signature of Attributes.put accepts values of any type, the javadoc states that values are checked that they are Strings at runtime: http://docs.oracle.com/javase/7/docs/api/java/util/jar/Attributes.html#put(java.lang.Object,%20java.lang.Object) In fact it turns out that you can change the manifestEntries Map signature to use any type for the value without getting a compile error - and at runtime it's ignored by the code populating the configuration. I only happened to notice this discrepancy when investigating a related issue involving a stricter version of the plexus MapConverter that checks generic bounds when populating maps: https://bugs.eclipse.org/bugs/show_bug.cgi?id=429369 The correct signature of manifestEntries should be Map -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342302#comment-342302
]
Stuart McCulloch commented on MNG-5591:
---
Just to confirm that this behaviour is expected. When you lookup a role the
Plexus semantics are that the "default" hint has highest priority, followed by
any other hints - no guarantee is given to the order of these secondary hints.
(although the ordering typically reflects the realm order where the
implementation was bound, and the order of the class on the realm classpath).
Note that in the latest Sisu release you can use @Priority(int) to explicitly
enforce ordering between components.
> Installing workspace reader triggers MNG-5503
> -
>
> Key: MNG-5591
> URL: https://jira.codehaus.org/browse/MNG-5591
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.2.1
>Reporter: Mikolaj Izdebski
>Assignee: Igor Fedorenko
> Fix For: 3.2.2
>
> Attachments:
> 0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch,
> dummy-extension.tar.gz
>
>
> It looks like Maven 3.2.1 introduced a regression. Installing
> extension which provides workspace reader triggers MNG-5503.
> Maven resolves artifacts from reactor, workspace, repositories (in
> that order). In standard Maven distribution there is no workspace,
> but Maven provides an extension point which allows extensions to
> install workspace reader by providing a component with role
> {{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
> Installing workspace reader extension in Maven 3.2.1 triggers a
> regression - Maven fails to resolve artifacts produced by reactor
> build (MNG-5503). Even though artifact is present in reactor Maven
> queries workspace about it and if artifact is not found there it
> continues with repositories. Expected behaviour is resolving artifact
> from reactor.
> Steps to reproduce this:
> 1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
> 2) download dummy-extension.tar.gz and build it with {{mvn package}}
> 3) download reproducer for MNG-5503 from:
> https://bugzilla.redhat.com/attachment.cgi?id=784786
> 4) try to build reproducer project, it succeeds
> 5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
> 6) try to build reproducer project, it fails
> When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4171) The XML resulting from a property of java.util.Properties is a lot more clumsy than that for Map
[ https://jira.codehaus.org/browse/MNG-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338184#comment-338184 ] Stuart McCulloch commented on MNG-4171: --- Both formats are supported for Properties by inspecting the XML and parsing it appropriately (Maven 3.0.3 onwards) > The XML resulting from a property of java.util.Properties is a lot more > clumsy than that for Map > > > Key: MNG-4171 > URL: https://jira.codehaus.org/browse/MNG-4171 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugin API >Affects Versions: 2.1.0 >Reporter: Benson Margulies > Fix For: 3.2 > > > Map parameters have this convenient XML mapping > >value > > The corresponding syntax for Properties is much more verbose: > > xy > > This seems like punishment to the plugin user. In my case, I am internally > targetting an API that uses Properties, so it was really convenient to just > declare at that type. However, the XML is so clumsy that I'm now going to go > change it to a map and manually populate a Properties object. I wish that > there was some @ to allow me to declare the variable as Properties and get > the Map syntax. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4171) The XML resulting from a property of java.util.Properties is a lot more clumsy than that for Map
[ https://jira.codehaus.org/browse/MNG-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338177#comment-338177 ] Stuart McCulloch commented on MNG-4171: --- FYI this was fixed a few years back under https://issues.sonatype.org/browse/SISU-61 and is available in Maven 3.0.3 onwards. > The XML resulting from a property of java.util.Properties is a lot more > clumsy than that for Map > > > Key: MNG-4171 > URL: https://jira.codehaus.org/browse/MNG-4171 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugin API >Affects Versions: 2.1.0 >Reporter: Benson Margulies > Fix For: 3.2 > > > Map parameters have this convenient XML mapping > >value > > The corresponding syntax for Properties is much more verbose: > > xy > > This seems like punishment to the plugin user. In my case, I am internally > targetting an API that uses Properties, so it was really convenient to just > declare at that type. However, the XML is so clumsy that I'm now going to go > change it to a map and manually populate a Properties object. I wish that > there was some @ to allow me to declare the variable as Properties and get > the Map syntax. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-407) wagon-maven-plugin ITs fail with missing class: org.apache.commons.io.IOUtils
[ https://jira.codehaus.org/browse/WAGON-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338168#comment-338168 ] Stuart McCulloch commented on WAGON-407: I believe so, either by updating the shade includes list or by changing it over to excludes (which might be more robust to future changes in the transitive dependencies). > wagon-maven-plugin ITs fail with missing class: org.apache.commons.io.IOUtils > - > > Key: WAGON-407 > URL: https://jira.codehaus.org/browse/WAGON-407 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Reporter: Stuart McCulloch > > See http://www.mail-archive.com/users@maven.apache.org/msg132210.html thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-407) wagon-maven-plugin ITs fail with missing class: org.apache.commons.io.IOUtils
[ https://jira.codehaus.org/browse/WAGON-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated WAGON-407: --- Summary: wagon-maven-plugin ITs fail with missing class: org.apache.commons.io.IOUtils (was: Wagon ITs fail with missing class: org.apache.commons.io.IOUtils) > wagon-maven-plugin ITs fail with missing class: org.apache.commons.io.IOUtils > - > > Key: WAGON-407 > URL: https://jira.codehaus.org/browse/WAGON-407 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Reporter: Stuart McCulloch > > See http://www.mail-archive.com/users@maven.apache.org/msg132210.html thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-407) Wagon ITs fail with missing class: org.apache.commons.io.IOUtils
[ https://jira.codehaus.org/browse/WAGON-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=337575#comment-337575 ] Stuart McCulloch commented on WAGON-407: My analysis: Looks like a shading issue in maven-wagon/wagon-providers/wagon-http: https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=blob;f=wagon-providers/wagon-http/pom.xml;h=1fd61e34da435024062a566f6bd68410d98fdc67;hb=HEAD#l87 It doesn?t shade in commons-io, commons-lang, or jsoup; despite wagon-http-shared switching from plexus-utils to commons-lang/io, and over to jsoup as the HTML parser: https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=ec65719a https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=02681881 [INFO] --- maven-shade-plugin:1.4:shade (default) @ wagon-http --- [INFO] Excluding org.apache.maven.wagon:wagon-http-shared:jar:2.6-SNAPSHOT from the shaded jar. [INFO] Excluding org.jsoup:jsoup:jar:1.7.2 from the shaded jar. [INFO] Excluding commons-lang:commons-lang:jar:2.6 from the shaded jar. [INFO] Excluding commons-io:commons-io:jar:2.2 from the shaded jar. [INFO] Including org.apache.httpcomponents:httpclient:jar:4.3.1 in the shaded jar. [INFO] Including commons-codec:commons-codec:jar:1.6 in the shaded jar. [INFO] Including commons-logging:commons-logging:jar:1.1.3 in the shaded jar. [INFO] Including org.apache.httpcomponents:httpcore:jar:4.3 in the shaded jar. [INFO] Excluding org.apache.maven.wagon:wagon-provider-api:jar:2.6-SNAPSHOT from the shaded jar. [INFO] Excluding org.codehaus.plexus:plexus-utils:jar:3.0.8 from the shaded jar. [INFO] Attaching shaded artefact. It might be less fragile to just exclude unwanted dependencies in the wagon-http shade configuration, rather than have to keep the list of includes in sync? As to why the IT passes with M2 but fails with M3... wagon-http is included in the distribution lib (uber jar for M2, separate jar for M3) so M2 is using an older version of wagon that doesn?t suffer from the above issue. (NOTE: adding commons-io, commons-lang, and jsoup jars to the M3 distribution lib is a workaround for this issue) > Wagon ITs fail with missing class: org.apache.commons.io.IOUtils > > > Key: WAGON-407 > URL: https://jira.codehaus.org/browse/WAGON-407 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Reporter: Stuart McCulloch > > See http://www.mail-archive.com/users@maven.apache.org/msg132210.html thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-407) Wagon ITs fail with missing class: org.apache.commons.io.IOUtils
[ https://jira.codehaus.org/browse/WAGON-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=337574#comment-337574 ] Stuart McCulloch commented on WAGON-407: Original problem reported on list: None of the goals in ?wagon-maven-plugin? work http://mojo.codehaus.org/wagon-maven-plugin/plugin-info.html Have anyone used any of these goals before? https://svn.codehaus.org/mojo/trunk/mojo/wagon-maven-plugin/src/it/http-download/pom.xml [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for org.codehaus.mojo:wagon-maven-plugin:pom:testing [WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:wagon-maven-plugin is missing. @ line 16, column 21 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] [INFO] Building wagon-maven-plugin testing [INFO] [INFO] [INFO] --- wagon-maven-plugin:1.0-beta-4:list (http-list) @ wagon-maven-plugin --- [INFO] Scanning remote file system: http://repo1.maven.org/maven2/commons-dbutils/commons-dbutils ... [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 7.598s [INFO] Finished at: Sun Dec 15 21:29:01 PST 2013 [INFO] Final Memory: 6M/123M [INFO] [ERROR] Failed to execute goal org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list (http-list) on project wagon-maven-plugin: Execution http-list of goal org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list failed: A required class was missing while executing org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:list: org/apache/commons/io/IOUtils [ERROR] - [ERROR] realm =plugin>org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/Users/nsankaran/.m2/raptor2/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-4/wagon-maven-plugin-1.0-beta-4.jar [ERROR] urls[1] = file:/Users/nsankaran/.m2/raptor2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar [ERROR] urls[2] = file:/Users/nsankaran/.m2/raptor2/org/apache/maven/shared/file-management/1.2.1/file-management-1.2.1.jar [ERROR] urls[3] = file:/Users/nsankaran/.m2/raptor2/org/apache/maven/shared/maven-shared-io/1.1/maven-shared-io-1.1.jar [ERROR] Number of foreign imports: 1 [ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]] [ERROR] [ERROR] -: org.apache.commons.io.IOUtils [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException > Wagon ITs fail with missing class: org.apache.commons.io.IOUtils > > > Key: WAGON-407 > URL: https://jira.codehaus.org/browse/WAGON-407 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Reporter: Stuart McCulloch > > See http://www.mail-archive.com/users@maven.apache.org/msg132210.html thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-407) Wagon ITs fail with missing class: org.apache.commons.io.IOUtils
Stuart McCulloch created WAGON-407: -- Summary: Wagon ITs fail with missing class: org.apache.commons.io.IOUtils Key: WAGON-407 URL: https://jira.codehaus.org/browse/WAGON-407 Project: Maven Wagon Issue Type: Bug Components: wagon-http Reporter: Stuart McCulloch See http://www.mail-archive.com/users@maven.apache.org/msg132210.html thread -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5534) Update to Sisu 0.1.0 and Guice 3.1.6
[ https://jira.codehaus.org/browse/MNG-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated MNG-5534: -- Attachment: upgrade_to_eclipse_sisu_0.1.1.patch Sample simplified patch. Could make it even simpler if the repeated direct dependencies were dropped in favour of indirect transitive dependencies (for example via maven-core) but there may be a valid reason for repeating them. > Update to Sisu 0.1.0 and Guice 3.1.6 > > > Key: MNG-5534 > URL: https://jira.codehaus.org/browse/MNG-5534 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Mikolaj Izdebski > Attachments: 0001-Update-to-Sisu-0.1.0-and-Guice-3.1.6.patch, > upgrade_to_eclipse_sisu_0.1.1.patch > > > Please update to Eclipse Sisu 0.1.0 and Sisu Guice 3.1.6. > Sisu depends on Guice, but dependency scope changed from "compile" to > "provided" in Sisu 0.1.0. As a Sisu user, Maven needs to have runtime > dependency on Guice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5534) Update to Sisu 0.1.0 and Guice 3.1.6
[ https://jira.codehaus.org/browse/MNG-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336551#comment-336551 ] Stuart McCulloch commented on MNG-5534: --- Note: patch can be simplified by moving the 'aopalliance' exclusion to the 'dependencyManagement' section of the parent pom. > Update to Sisu 0.1.0 and Guice 3.1.6 > > > Key: MNG-5534 > URL: https://jira.codehaus.org/browse/MNG-5534 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Mikolaj Izdebski > Attachments: 0001-Update-to-Sisu-0.1.0-and-Guice-3.1.6.patch > > > Please update to Eclipse Sisu 0.1.0 and Sisu Guice 3.1.6. > Sisu depends on Guice, but dependency scope changed from "compile" to > "provided" in Sisu 0.1.0. As a Sisu user, Maven needs to have runtime > dependency on Guice. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5518) @Parameter annotation requires property element to use command-line -D
[
https://jira.codehaus.org/browse/MNG-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333130#comment-333130
]
Stuart McCulloch commented on MNG-5518:
---
According to http://maven.apache.org/developers/mojo-api-specification.html the
javadoc-style @parameter had the following behaviour:
"NOTE: If neither default-value nor expression are specified, the parameter
can only be configured from the POM. The use of '${' and '}' is required to
delimit actual expressions which may be evaluated"
Also in the Java5 annotation the 'expression' attribute was renamed to
'property' and the need for '${' and '}' was dropped:
https://jira.codehaus.org/browse/MPLUGIN-196
So there is some consistency here in that it is possible to define a parameter
that cannot be overridden from the command-line, and an additional attribute is
required ('expression'/'default-value' for the javadoc annotation, 'property'
for the Java5 annotation) to enable the command-line support.
> @Parameter annotation requires property element to use command-line -D
> --
>
> Key: MNG-5518
> URL: https://jira.codehaus.org/browse/MNG-5518
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.4, 3.1.0
> Environment: Windows 7 Pro 64 bit, JDK 1.7.0_40
>Reporter: Robert Patrick
> Attachments: annotations.zip
>
>
> When writing a plugin using the Maven Java annotations, the @Parameter
> annotation currently requires the property element to allow the goal to
> receive configuration information from the command-line using
> -DparamName=value even though the goal works fine without it when using a POM.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5518) @Parameter annotation requires property element to use command-line -D
[
https://jira.codehaus.org/browse/MNG-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333130#comment-333130
]
Stuart McCulloch edited comment on MNG-5518 at 9/21/13 7:23 PM:
According to http://maven.apache.org/developers/mojo-api-specification.html the
javadoc-style @parameter had the following behaviour:
"NOTE: If neither default-value nor expression are specified, the parameter
can only be configured from the POM. The use of '$\{' and '}' is required to
delimit actual expressions which may be evaluated"
Also in the Java5 annotation the 'expression' attribute was renamed to
'property' and the need for '$\{' and '}' was dropped:
https://jira.codehaus.org/browse/MPLUGIN-196
So there is some consistency here in that it is possible to define a parameter
that cannot be overridden from the command-line, and an additional attribute is
required ('expression'/'default-value' for the javadoc annotation, 'property'
for the Java5 annotation) to enable the command-line support.
was (Author: mcculls):
According to http://maven.apache.org/developers/mojo-api-specification.html
the javadoc-style @parameter had the following behaviour:
"NOTE: If neither default-value nor expression are specified, the parameter
can only be configured from the POM. The use of '${' and '}' is required to
delimit actual expressions which may be evaluated"
Also in the Java5 annotation the 'expression' attribute was renamed to
'property' and the need for '${' and '}' was dropped:
https://jira.codehaus.org/browse/MPLUGIN-196
So there is some consistency here in that it is possible to define a parameter
that cannot be overridden from the command-line, and an additional attribute is
required ('expression'/'default-value' for the javadoc annotation, 'property'
for the Java5 annotation) to enable the command-line support.
> @Parameter annotation requires property element to use command-line -D
> --
>
> Key: MNG-5518
> URL: https://jira.codehaus.org/browse/MNG-5518
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.4, 3.1.0
> Environment: Windows 7 Pro 64 bit, JDK 1.7.0_40
>Reporter: Robert Patrick
> Attachments: annotations.zip
>
>
> When writing a plugin using the Maven Java annotations, the @Parameter
> annotation currently requires the property element to allow the goal to
> receive configuration information from the command-line using
> -DparamName=value even though the goal works fine without it when using a POM.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5519) org.apache.maven.plugins.annotations.Parameter has incorrect RetentionPolicy
[
https://jira.codehaus.org/browse/MNG-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333129#comment-333129
]
Stuart McCulloch commented on MNG-5519:
---
This appears to be a duplicate of MNG-5520
> org.apache.maven.plugins.annotations.Parameter has incorrect RetentionPolicy
>
>
> Key: MNG-5519
> URL: https://jira.codehaus.org/browse/MNG-5519
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.5
> Environment: JDK 1.7
> MAVEN 3.0.5
>Reporter: Martin Gainty
>
> package org.apache.maven.plugins.annotations;
> import java.lang.annotation.RetentionPolicy;
> @Documented
> @Retention( RetentionPolicy.CLASS )
> @Target( { ElementType.FIELD } )
> @Inherited
> public @interface Parameter
> RetentionPolicy parameters:
> CLASS
> Annotations are to be recorded in the class file by the compiler but need NOT
> be retained by the VM at run time.
>
> RUNTIME
> Annotations are to be recorded in the class file by the compiler and
> RETAINED by the VM at run time, so they may be read reflectively.
>
> SOURCE
> Annotations are to be discarded by the compiler.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5520) RuntimePolicy is incorrect for org.apache.maven.plugins.annotations.Parameter
[
https://jira.codehaus.org/browse/MNG-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333114#comment-333114
]
Stuart McCulloch commented on MNG-5520:
---
IIRC those Java5 annotations are only used by the maven-plugin-plugin to
generate META-INF/maven/plugin.xml and are not used by the core Maven runtime,
in which case a retention policy of CLASS is ok:
http://svn.apache.org/viewvc?view=revision&revision=1338003
The main benefit of using them is that if you extend a Maven plugin then the
maven-plugin-plugin can see the Java5 annotations retained in the class file,
whereas javadoc annotations are only in the source.
See http://jira.codehaus.org/browse/MPLUGIN-56 for the original use-case
> RuntimePolicy is incorrect for org.apache.maven.plugins.annotations.Parameter
> -
>
> Key: MNG-5520
> URL: https://jira.codehaus.org/browse/MNG-5520
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.4
> Environment: JDK 1.7
> MAVN 3.0.5
>Reporter: Martin Gainty
>Priority: Minor
> Attachments: RobertPatrickAnnotationsTest.zip
>
>
> looks like we need to hire you to check our code..(provided you work for free)
> package org.apache.maven.plugins.annotations;
> import java.lang.annotation.RetentionPolicy;
> @Documented
> @Retention( RetentionPolicy.CLASS )
> @Target( { ElementType.FIELD } )
> @Inherited
> public @interface Parameter
> RetentionPolicy parameters:
> CLASS
> Annotations are to be recorded in the class file by the compiler but need NOT
> be retained by the VM at run time.
>
> RUNTIME
> Annotations are to be recorded in the class file by the compiler and
> RETAINED by the VM at run time, so they may be read reflectively.
>
> SOURCE
> Annotations are to be discarded by the compiler.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
[
https://jira.codehaus.org/browse/MNG-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329836#comment-329836
]
Stuart McCulloch commented on MNG-5042:
---
Just to close the loop; the fix is available in Maven 3.0.4, 3.0.5, and 3.1.0
> Regression: CloningClassLoader causes StackOverflowError in groovy
> --
>
> Key: MNG-5042
> URL: https://jira.codehaus.org/browse/MNG-5042
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Patrick Staton
> Attachments: test-plug.zip
>
>
> I am unable to use a groovy class as a plexus component in maven 3 because
> groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
> which in turn calls classloader.loadClass(beanClass.getName() +
> BEANINFO_SUFFIX) (the class name is "FooBar$__plexus2") which in turn causes
> CloningClassLoader to create a new clone of the class named
> "FooBar$__plexus2BeanInfo". When "FooBar$__plexusBeanInfo" is instantiated
> groovy's the meta class mechanism again calls
> Introspector.getBeanInfo() on "FooBar$__plexus2".
> Example stack trace:
> {code}at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspecto
[jira] (MNG-5495) API incompatibility causes Swagger Maven Plugin (and others) to fail under Maven 3.1.0
[
https://jira.codehaus.org/browse/MNG-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329526#comment-329526
]
Stuart McCulloch commented on MNG-5495:
---
I've staged milestone 5 of Eclipse-Sisu which contains the fix for this issue:
https://oss.sonatype.org/content/repositories/orgeclipsesisu-1010/org/eclipse/sisu/org.eclipse.sisu.plexus/0.0.0.M5/
https://oss.sonatype.org/content/repositories/orgeclipsesisu-1008/org/eclipse/sisu/org.eclipse.sisu.inject/0.0.0.M5/
PS. if anyone happens to be using the old Sonatype-Sisu APIs they might also
like to try the staged 2.4.2 release:
https://repository.sonatype.org/content/repositories/sonatype_org-1021/org/sonatype/sisu/sisu-inject-plexus/2.4.2/
https://repository.sonatype.org/content/repositories/sonatype_org-1021/org/sonatype/sisu/sisu-inject-bean/2.4.2/
this now delegates to Eclipse-Sisu - only a subset of the API is supported, but
it should cover all known use-cases.
Let me know if you spot any problems (sisu-us...@eclipse.org) otherwise I'll
push this to Central later tomorrow.
> API incompatibility causes Swagger Maven Plugin (and others) to fail under
> Maven 3.1.0
> --
>
> Key: MNG-5495
> URL: https://jira.codehaus.org/browse/MNG-5495
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Brett Porter
> Fix For: 3.1.1
>
>
> {code}
> ERROR] Failed to execute goal
> com.github.kongchen:swagger-maven-plugin:1.1.1:generate (default) on project
> maestro-webapp: An API incompatibility was encountered during configuration
> of mojo com.github.kongchen:swagger-maven-plugin:1.1.1:generate:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.component.configurator.converters.special.ClassRealmConverter.(Lorg/codehaus/classworlds/ClassRealm;)V
> [ERROR] -
> [ERROR] realm =plugin>com.github.kongchen:swagger-maven-plugin:1.1.1
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/brett/.m2/repository/com/github/kongchen/swagger-maven-plugin/1.1.1/swagger-maven-plugin-1.1.1.jar
> [ERROR] urls[1] =
> file:/Users/brett/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5097) @parameter using 'property' to allow custom naming convention, throws a NPE if the parameter is defined, but empty.
[
https://jira.codehaus.org/browse/MNG-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329432#comment-329432
]
Stuart McCulloch commented on MNG-5097:
---
FYI, this is now fixed in Maven 3.1.0
> @parameter using 'property' to allow custom naming convention, throws a NPE
> if the parameter is defined, but empty.
> ---
>
> Key: MNG-5097
> URL: https://jira.codehaus.org/browse/MNG-5097
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0.3
> Environment: Gentoo Linux, amd64, multicore.
>Reporter: rydnr
>Priority: Minor
> Attachments: build.log, empty-string-npe.zip
>
>
> The test case (not JUnit) is attached.
> If a Maven plugin runs within Maven 3.0.3, and defines
> /**
> * @parameter property="abc"
> */
> private String somethingDifferentThanAbc;
> public void setAbc(String value) {
> somethingDifferentThanAbc = value;
> }
> Works for non-empty values:
> abc-value
> But throws a NPE in
> org.codehaus.plexus.component.configurator.converters.ComponentValueSetter:331
>
> (fieldTypeConverter is null) with empty values:
>
> It works in Maven 2.x. It works if you declare the
> property with no naming conventions:
> private String abc;
> As a side note, the plexus classes being used are not the ones declared in
> the pom, but the ones bundled within
> $MAVEN_HOME/lib/sisu-inject-plexus-2.1.1.jar.
> I couldn't find sisu-inject-plexus-2.1.1-sources.jar anywhere, but the
> repository itself is fortunately available at
> https://github.com/sonatype/sisu.git
> And then within
> /sisu-inject/containers/guice-plexus/guice-plexus-shim/src/main/java/
> I could have try to post a patch, but I'm not really sure about why this
> corner case is producing plexus-container's misbehavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5453) Update Maven 3 build to use Eclipse/Sisu
[ https://jira.codehaus.org/browse/MNG-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch closed MNG-5453. - Resolution: Fixed Fix Version/s: 3.1.0 Patch applied in https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=2c2bf6e6e5b06c35a935ca69c5dcb54b381baf46 > Update Maven 3 build to use Eclipse/Sisu > > > Key: MNG-5453 > URL: https://jira.codehaus.org/browse/MNG-5453 > Project: Maven 2 & 3 > Issue Type: Task > Components: Bootstrap & Build >Reporter: Stuart McCulloch > Fix For: 3.1.0 > > > Eclipse/Sisu is now able to run Maven3 (trunk) without requiring the legacy > configurators bundled as part of the original Sisu build. These were the only > classes that couldn't be moved to Eclipse as I wasn't 100% sure about their > IP history. > Instead the 0.0.0.M2 milestone of Eclipse/Sisu includes new configurators > written from scratch that build on Sisu's bean reflection/converter code. > These new configurators were written (and tested) indirectly by looking at > the behaviour of the old configurators while running various ITs, so it's > possible that some inconsistencies remain. > So while the build passes all ITs locally, it would be worthwhile getting > wider testing to make sure that I haven't accidentally regressed anything > with the new configurator code :) > PS. the Eclipse/Sisu artifacts don't shade their internal dependencies > (unlike the original Sisu bundles) so you'll see additional jars in lib, such > as asm and guava. Also note that the guava dependency version is managed to > be 11.0.2, which is the last known Java5 compatible release. > [patch will be sent via pull-request] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321910#comment-321910
]
Stuart McCulloch edited comment on MNG-5445 at 3/13/13 8:27 AM:
Patch applied by Olivier Lamy in
https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=c9eecc8f0c220da665a448d5f3579f533b03119f
Verified, thanks!
was (Author: mcculls):
Verified, thanks!
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch closed MNG-5445.
-
Resolution: Fixed
Verified, thanks!
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5453) Update Maven 3 build to use Eclipse/Sisu
[ https://jira.codehaus.org/browse/MNG-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321908#comment-321908 ] Stuart McCulloch edited comment on MNG-5453 at 3/13/13 8:19 AM: Correct, marked this issue as superceding MNG-5352 (I don't have enough karma to close that issue). was (Author: mcculls): Correct, marked this issue as superceding MNG-5352 > Update Maven 3 build to use Eclipse/Sisu > > > Key: MNG-5453 > URL: https://jira.codehaus.org/browse/MNG-5453 > Project: Maven 2 & 3 > Issue Type: Task > Components: Bootstrap & Build >Reporter: Stuart McCulloch > > Eclipse/Sisu is now able to run Maven3 (trunk) without requiring the legacy > configurators bundled as part of the original Sisu build. These were the only > classes that couldn't be moved to Eclipse as I wasn't 100% sure about their > IP history. > Instead the 0.0.0.M2 milestone of Eclipse/Sisu includes new configurators > written from scratch that build on Sisu's bean reflection/converter code. > These new configurators were written (and tested) indirectly by looking at > the behaviour of the old configurators while running various ITs, so it's > possible that some inconsistencies remain. > So while the build passes all ITs locally, it would be worthwhile getting > wider testing to make sure that I haven't accidentally regressed anything > with the new configurator code :) > PS. the Eclipse/Sisu artifacts don't shade their internal dependencies > (unlike the original Sisu bundles) so you'll see additional jars in lib, such > as asm and guava. Also note that the guava dependency version is managed to > be 11.0.2, which is the last known Java5 compatible release. > [patch will be sent via pull-request] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5453) Update Maven 3 build to use Eclipse/Sisu
[ https://jira.codehaus.org/browse/MNG-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321873#comment-321873 ] Stuart McCulloch commented on MNG-5453: --- Patch submitted under https://github.com/apache/maven/pull/2 > Update Maven 3 build to use Eclipse/Sisu > > > Key: MNG-5453 > URL: https://jira.codehaus.org/browse/MNG-5453 > Project: Maven 2 & 3 > Issue Type: Task > Components: Bootstrap & Build >Reporter: Stuart McCulloch > > Eclipse/Sisu is now able to run Maven3 (trunk) without requiring the legacy > configurators bundled as part of the original Sisu build. These were the only > classes that couldn't be moved to Eclipse as I wasn't 100% sure about their > IP history. > Instead the 0.0.0.M2 milestone of Eclipse/Sisu includes new configurators > written from scratch that build on Sisu's bean reflection/converter code. > These new configurators were written (and tested) indirectly by looking at > the behaviour of the old configurators while running various ITs, so it's > possible that some inconsistencies remain. > So while the build passes all ITs locally, it would be worthwhile getting > wider testing to make sure that I haven't accidentally regressed anything > with the new configurator code :) > PS. the Eclipse/Sisu artifacts don't shade their internal dependencies > (unlike the original Sisu bundles) so you'll see additional jars in lib, such > as asm and guava. Also note that the guava dependency version is managed to > be 11.0.2, which is the last known Java5 compatible release. > [patch will be sent via pull-request] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5446) AM/PM inconsistency in mng-3827 and mng-3864 ITs?
[
https://jira.codehaus.org/browse/MNG-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321872#comment-321872
]
Stuart McCulloch commented on MNG-5446:
---
I don't believe it causes MNG-5213 as that piece of code doesn't appear to use
the Date configurator, but it could be that there is a similar conversion bug
lurking in the execution time code. Has anyone been able to recreate MNG-5213
or does it only happen very rarely? (Would be useful to know if it only happens
on certain days, like when daylight saving comes in.)
> AM/PM inconsistency in mng-3827 and mng-3864 ITs?
> -
>
> Key: MNG-5446
> URL: https://jira.codehaus.org/browse/MNG-5446
> Project: Maven 2 & 3
> Issue Type: Test
> Components: Integration Tests
>Reporter: Stuart McCulloch
>Priority: Minor
>
> The mng-3827 and mng-3864 ITs both include the following Date parameter in
> their plugin test configuration:
> {code}
> 2008-11-09 11:59:03.0 PM
> {code}
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3827/pom.xml#L63
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3864/pom.xml#L69
> This parameter is then expected to be written out as:
> {code}
> 2008-11-09 11:59:03
> {code}
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3827PluginConfigTest.java#L72
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3864PerExecPluginConfigTest.java#L72
> This looks odd - I would expect "23:59:03" since the time is being written
> back out without the AM/PM flag and {code}System.err.println(new
> Date());{code} uses the 24 hour clock on my local JVM.
> I suspect there's a long-standing bug in the Plexus DateConverter where it
> parses the date using a SimpleDateFormat of "-MM-dd HH:mm:ss.S a" for
> values with an AM/PM flag. This format uses 'HH' to parse the hour as 'Hour
> in day (0-23)' rather than 'hh' to parse it as 'Hour in am/pm (1-12)', which
> would explain why "11:59:03.0 PM" is written back as "11:59:03" and not
> "23:59:03".
> If that's the case then I'd like to suggest the dateParam in the mng-3827 and
> mng-3864 ITs is changed to:
> {code}
> 2008-11-09 11:59:03.0 AM
> {code}
> because that way the result would still match the expected "11:59:03" string
> if/when the DateConverter is fixed (I'm doing some refactoring in the
> Sisu-Plexus internals to improve re-use which touches on configuration).
> AFAICT these ITs don't appear to be testing this specific Date conversion
> behaviour (ie. silently ignoring / dropping the PM flag), but if this isn't
> the case and the current behaviour should be maintained for legacy reasons
> then I'd also like to know.
> Thanks in advance!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5453) Update Maven 3 build to use Eclipse/Sisu
Stuart McCulloch created MNG-5453: - Summary: Update Maven 3 build to use Eclipse/Sisu Key: MNG-5453 URL: https://jira.codehaus.org/browse/MNG-5453 Project: Maven 2 & 3 Issue Type: Task Components: Bootstrap & Build Reporter: Stuart McCulloch Eclipse/Sisu is now able to run Maven3 (trunk) without requiring the legacy configurators bundled as part of the original Sisu build. These were the only classes that couldn't be moved to Eclipse as I wasn't 100% sure about their IP history. Instead the 0.0.0.M2 milestone of Eclipse/Sisu includes new configurators written from scratch that build on Sisu's bean reflection/converter code. These new configurators were written (and tested) indirectly by looking at the behaviour of the old configurators while running various ITs, so it's possible that some inconsistencies remain. So while the build passes all ITs locally, it would be worthwhile getting wider testing to make sure that I haven't accidentally regressed anything with the new configurator code :) PS. the Eclipse/Sisu artifacts don't shade their internal dependencies (unlike the original Sisu bundles) so you'll see additional jars in lib, such as asm and guava. Also note that the guava dependency version is managed to be 11.0.2, which is the last known Java5 compatible release. [patch will be sent via pull-request] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5446) AM/PM inconsistency in mng-3827 and mng-3864 ITs?
[
https://jira.codehaus.org/browse/MNG-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321687#comment-321687
]
Stuart McCulloch commented on MNG-5446:
---
Proposed patch: https://github.com/apache/maven-integration-testing/pull/3
> AM/PM inconsistency in mng-3827 and mng-3864 ITs?
> -
>
> Key: MNG-5446
> URL: https://jira.codehaus.org/browse/MNG-5446
> Project: Maven 2 & 3
> Issue Type: Test
> Components: Integration Tests
>Reporter: Stuart McCulloch
>Priority: Minor
>
> The mng-3827 and mng-3864 ITs both include the following Date parameter in
> their plugin test configuration:
> {code}
> 2008-11-09 11:59:03.0 PM
> {code}
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3827/pom.xml#L63
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3864/pom.xml#L69
> This parameter is then expected to be written out as:
> {code}
> 2008-11-09 11:59:03
> {code}
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3827PluginConfigTest.java#L72
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3864PerExecPluginConfigTest.java#L72
> This looks odd - I would expect "23:59:03" since the time is being written
> back out without the AM/PM flag and {code}System.err.println(new
> Date());{code} uses the 24 hour clock on my local JVM.
> I suspect there's a long-standing bug in the Plexus DateConverter where it
> parses the date using a SimpleDateFormat of "-MM-dd HH:mm:ss.S a" for
> values with an AM/PM flag. This format uses 'HH' to parse the hour as 'Hour
> in day (0-23)' rather than 'hh' to parse it as 'Hour in am/pm (1-12)', which
> would explain why "11:59:03.0 PM" is written back as "11:59:03" and not
> "23:59:03".
> If that's the case then I'd like to suggest the dateParam in the mng-3827 and
> mng-3864 ITs is changed to:
> {code}
> 2008-11-09 11:59:03.0 AM
> {code}
> because that way the result would still match the expected "11:59:03" string
> if/when the DateConverter is fixed (I'm doing some refactoring in the
> Sisu-Plexus internals to improve re-use which touches on configuration).
> AFAICT these ITs don't appear to be testing this specific Date conversion
> behaviour (ie. silently ignoring / dropping the PM flag), but if this isn't
> the case and the current behaviour should be maintained for legacy reasons
> then I'd also like to know.
> Thanks in advance!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321686#comment-321686
]
Stuart McCulloch commented on MNG-5445:
---
Reduced testcase (removes IT dependency on versions plugin)
https://github.com/apache/maven-integration-testing/pull/2
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5446) AM/PM inconsistency in mng-3827 and mng-3864 ITs?
Stuart McCulloch created MNG-5446:
-
Summary: AM/PM inconsistency in mng-3827 and mng-3864 ITs?
Key: MNG-5446
URL: https://jira.codehaus.org/browse/MNG-5446
Project: Maven 2 & 3
Issue Type: Test
Components: Integration Tests
Reporter: Stuart McCulloch
Priority: Minor
The mng-3827 and mng-3864 ITs both include the following Date parameter in
their plugin test configuration:
{code}
2008-11-09 11:59:03.0 PM
{code}
https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3827/pom.xml#L63
https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3864/pom.xml#L69
This parameter is then expected to be written out as:
{code}
2008-11-09 11:59:03
{code}
https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3827PluginConfigTest.java#L72
https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3864PerExecPluginConfigTest.java#L72
This looks odd - I would expect "23:59:03" since the time is being written back
out without the AM/PM flag and {code}System.err.println(new Date());{code} uses
the 24 hour clock on my local JVM.
I suspect there's a long-standing bug in the Plexus DateConverter where it
parses the date using a SimpleDateFormat of "-MM-dd HH:mm:ss.S a" for
values with an AM/PM flag. This format uses 'HH' to parse the hour as 'Hour in
day (0-23)' rather than 'hh' to parse it as 'Hour in am/pm (1-12)', which would
explain why "11:59:03.0 PM" is written back as "11:59:03" and not "23:59:03".
If that's the case then I'd like to suggest the dateParam in the mng-3827 and
mng-3864 ITs is changed to:
{code}
2008-11-09 11:59:03.0 AM
{code}
because that way the result would still match the expected "11:59:03" string
if/when the DateConverter is fixed (I'm doing some refactoring in the
Sisu-Plexus internals to improve re-use which touches on configuration).
AFAICT these ITs don't appear to be testing this specific Date conversion
behaviour (ie. silently ignoring / dropping the PM flag), but if this isn't the
case and the current behaviour should be maintained for legacy reasons then I'd
also like to know.
Thanks in advance!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321468#comment-321468
]
Stuart McCulloch commented on MNG-5445:
---
PS. I'll send a follow-up patch for the issues on the grid resolving the
versions-maven-plugin (I'm creating a new IT mojo with a distillation of the
original problem).
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321452#comment-321452
]
Stuart McCulloch commented on MNG-5445:
---
Minimal patch: https://github.com/apache/maven/pull/1
IT: https://github.com/apache/maven-integration-testing/pull/1
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
Stuart McCulloch created MNG-5445:
-
Summary: Missing PathTranslator @Requirement in
org.apache.maven.project.interpolation.StringSearchModelInterpolator
Key: MNG-5445
URL: https://jira.codehaus.org/browse/MNG-5445
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0.4
Reporter: Stuart McCulloch
In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
PathTranslator requirement defined in the following components.xml:
https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
In Maven 3.x this component became part of the maven-compat module, and while
other components had their XML requirements turned into @Requirement
annotations, this was not done for the PathTranslator field declared in
StringSearchModelInterpolator's superclass:
https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
Suggested patch:
{code}
diff --git
a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
index c77aebd..2190267 100644
---
a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
+++
b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
@@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
import org.apache.maven.project.DefaultProjectBuilderConfiguration;
import org.apache.maven.project.ProjectBuilderConfiguration;
import org.apache.maven.project.path.PathTranslator;
+import org.codehaus.plexus.component.annotations.Requirement;
import org.codehaus.plexus.interpolation.AbstractValueSource;
import org.codehaus.plexus.interpolation.InterpolationException;
import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
@@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
}
+@Requirement
private PathTranslator pathTranslator;
private Interpolator interpolator;
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5430) use wagon 2.4
[ https://jira.codehaus.org/browse/MNG-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320009#comment-320009 ] Stuart McCulloch edited comment on MNG-5430 at 2/19/13 12:48 PM: - In case anyone wonders what exactly was fixed in Wagon 2.4: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10335&version=18697 was (Author: mcculls): In case anyone wonders what exactly was fixed in Wagon 2.4: http://jira.codehaus.org/browse/WAGON/fixforversion/18697 > use wagon 2.4 > - > > Key: MNG-5430 > URL: https://jira.codehaus.org/browse/MNG-5430 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.0.5, 3.1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5430) use wagon 2.4
[ https://jira.codehaus.org/browse/MNG-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320009#comment-320009 ] Stuart McCulloch commented on MNG-5430: --- In case anyone wonders what exactly was fixed in Wagon 2.4: http://jira.codehaus.org/browse/WAGON/fixforversion/18697 > use wagon 2.4 > - > > Key: MNG-5430 > URL: https://jira.codehaus.org/browse/MNG-5430 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.0.5, 3.1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318715#comment-318715 ] Stuart McCulloch commented on MPLUGIN-240: -- Martin, can you attach a complete zip of your example? (ie. not just the pom.xml) Would make debugging/testing easier... > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318523#comment-318523 ] Stuart McCulloch commented on MPLUGIN-240: -- Also looking at that stacktrace it's actually failing to find the component with role=ModelloGenerator and hint=java (this lookup is made from inside modello code), which has nothing to do with the Maven plugin manager and AbstractMojo. It's just that modello uses the term 'plugin' in its error message which confuses the matter, while it's really just doing a simple Plexus lookup of a component. Now I can't say for sure why the lookup fails until I get that zip of your project tree, but looking at your pom.xml I see you've added the modello plugin as a dependency to various other Maven plugins (such as compiler and surefire). This doesn't seem right and could be messing up the classloader space causing the lookup failure (because they'll likely end up with a local copy of those classes rather than importing them). Try removing all those dependencies you've added directly to the compiler and surefire plugin configurations and see if that helps. > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318522#comment-318522
]
Stuart McCulloch edited comment on MPLUGIN-240 at 2/1/13 6:33 PM:
--
If I use 'mvn generate-sources' with that pom.xml I get the following error
because it's looking for other files that weren't attached to this issue:
{code}
[ERROR] Failed to execute goal
org.codehaus.modello:modello-maven-plugin:1.1:java (default) on project
commons-feedparser: Couldn't find file.
/private/tmp/src/main/mdo/pluginRequirements.mdo (No such file or directory) ->
[Help 1]
{code}
I assume you have a modified version of the commons-feedparser project, if so
could you please upload a complete zip of your local project tree or point to
the relevant branch on svn, thanks. Basically I need to have the exact same
setup that you used with 'mvn generate-sources' to recreate this issue.
was (Author: mcculls):
If I use 'mvn generate-sources' with that pom.xml I get the following error:
{code}
[ERROR] Failed to execute goal
org.codehaus.modello:modello-maven-plugin:1.1:java (default) on project
commons-feedparser: Couldn't find file.
/private/tmp/src/main/mdo/pluginRequirements.mdo (No such file or directory) ->
[Help 1]
{code}
I assume you have a modified version of the commons-feedparser project, if so
could you please upload a complete zip of your local project tree or point to
the relevant branch on svn, thanks.
> PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
> ---
>
> Key: MPLUGIN-240
> URL: https://jira.codehaus.org/browse/MPLUGIN-240
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
> Environment: maven 3.0.2 modello-maven-plugin-1.5
>Reporter: Martin Gainty
> Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318522#comment-318522
]
Stuart McCulloch commented on MPLUGIN-240:
--
If I use 'mvn generate-sources' with that pom.xml I get the following error:
{code}
[ERROR] Failed to execute goal
org.codehaus.modello:modello-maven-plugin:1.1:java (default) on project
commons-feedparser: Couldn't find file.
/private/tmp/src/main/mdo/pluginRequirements.mdo (No such file or directory) ->
[Help 1]
{code}
I assume you have a modified version of the commons-feedparser project, if so
could you please upload a complete zip of your local project tree or point to
the relevant branch on svn, thanks.
> PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
> ---
>
> Key: MPLUGIN-240
> URL: https://jira.codehaus.org/browse/MPLUGIN-240
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
> Environment: maven 3.0.2 modello-maven-plugin-1.5
>Reporter: Martin Gainty
> Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318477#comment-318477 ] Stuart McCulloch commented on MPLUGIN-240: -- Please attach a zip of the test project that recreates the problem. Also note that the exception stack trace shows it is actually being thrown from shared code in AbstractModelloGeneratorMojo, not the plugin manager which suggests that mojo has been found and executed and the issue is actually something that happens during execution of the mojo. Do you have the complete stack trace available? > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5376) Account for changes between the Apple and Oracle JDKs on OSX
[
https://jira.codehaus.org/browse/MNG-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314362#comment-314362
]
Stuart McCulloch commented on MNG-5376:
---
FYI, this change results in some oddities on OSX 10.6.8 because
/System/Library/Java/JavaVirtualMachines/CurrentJDK (used in the new script)
does not exist whereas
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK (used in the
old script) does:
{code}
readlink: illegal option -- f
usage: readlink [-n] [file ...]
Warning: JAVA_HOME environment variable is not set.
[INFO] Scanning for projects...
...etc...
{code}
Suggest both locations should be checked for the sake of backwards
compatibility.
> Account for changes between the Apple and Oracle JDKs on OSX
>
>
> Key: MNG-5376
> URL: https://jira.codehaus.org/browse/MNG-5376
> Project: Maven 2 & 3
> Issue Type: Task
>Reporter: Jason van Zyl
>Assignee: Jason van Zyl
> Fix For: 3.1.0
>
>
> With the arrival of Java 7 on OSX the directory locations and naming has
> changed. Some changes need to be made in the launch scripts to account for
> the changes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5206) plexus container never disposed
[ https://jira.codehaus.org/browse/MNG-5206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch updated MNG-5206: -- Attachment: MNG-5206.20111206.patch AFAICT the 'container' member variable in MavenCli is only used by the ITs, hence it will never get set when Maven is called from the command-line (this variable could also do with a more specific name imho). The attached patch will dispose of per-request containers while still allowing the ITs to use a cached container for multiple requests. You could also consider adding a dispose method to dispose of the cached container which could be used by the ITs if necessary. With this patch, the component from the example plugin is disposed as expected. > plexus container never disposed > --- > > Key: MNG-5206 > URL: https://jira.codehaus.org/browse/MNG-5206 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.3 >Reporter: Jan Sievers > Attachments: MNG-5206.20111206.patch, MNG-5206.patch, > plexusDisposeBug.zip > > > When I use a plexus component which implements > org.codehaus.plexus.personality.plexus.lifecycle.phase.Disposable, dispose() > is never called. > Since maven is creating the plexus container, it should also dispose it (on > maven session end?). > Also see discussion on sisu-dev: > http://dev.eclipse.org/mhonarc/lists/sisu-dev/msg1.html > Attached sample project demonstrates the issue. > Steps to reproduce: > 1. 'mvn install' sample project > 2. Use the test mojo: 'mvn > org.apache.maven.plugins.test:plexusDisposeBug:0.0.1-SNAPSHOT:test' > => plexus component is injected but never disposed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
[
http://jira.codehaus.org/browse/MNG-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261607#action_261607
]
Stuart McCulloch commented on MNG-5042:
---
Fixed in
https://github.com/sonatype/sisu/commit/ac276392dc8f5b3b734c830a6bcd839d22c706fd
- will be available in sisu-inject 2.2.1
> Regression: CloningClassLoader causes StackOverflowError in groovy
> --
>
> Key: MNG-5042
> URL: http://jira.codehaus.org/browse/MNG-5042
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Patrick Staton
> Attachments: test-plug.zip
>
>
> I am unable to use a groovy class as a plexus component in maven 3 because
> groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
> which in turn calls classloader.loadClass(beanClass.getName() +
> BEANINFO_SUFFIX) (the class name is "FooBar$__plexus2") which in turn causes
> CloningClassLoader to create a new clone of the class named
> "FooBar$__plexus2BeanInfo". When "FooBar$__plexusBeanInfo" is instantiated
> groovy's the meta class mechanism again calls
> Introspector.getBeanInfo() on "FooBar$__plexus2".
> Example stack trace:
> {code}at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspec
[jira] Commented: (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
[
http://jira.codehaus.org/browse/MNG-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260706#action_260706
]
Stuart McCulloch commented on MNG-5042:
---
Patrick - any chance of getting a test/example project that shows this
exception?
> Regression: CloningClassLoader causes StackOverflowError in groovy
> --
>
> Key: MNG-5042
> URL: http://jira.codehaus.org/browse/MNG-5042
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Patrick Staton
>
> I am unable to use a groovy class as a plexus component in maven 3 because
> groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
> which in turn calls classloader.loadClass(beanClass.getName() +
> BEANINFO_SUFFIX) (the class name is "FooBar$__plexus2") which in turn causes
> CloningClassLoader to create a new clone of the class named
> "FooBar$__plexus2BeanInfo". When "FooBar$__plexusBeanInfo" is instantiated
> groovy's the meta class mechanism again calls
> Introspector.getBeanInfo() on "FooBar$__plexus2".
> Example stack trace:
> {code}at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Int
[jira] Commented: (MNG-5042) Regression: CloningClassLoader causes StackOverflowError in groovy
[
http://jira.codehaus.org/browse/MNG-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260056#action_260056
]
Stuart McCulloch commented on MNG-5042:
---
If you could attach a test project that recreates the error that would be great
(improves the odds of getting this fixed).
> Regression: CloningClassLoader causes StackOverflowError in groovy
> --
>
> Key: MNG-5042
> URL: http://jira.codehaus.org/browse/MNG-5042
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0, 3.0.1, 3.0.2, 3.0.3
>Reporter: Patrick Staton
>
> I am unable to use a groovy class as a plexus component in maven 3 because
> groovy's metaclass mechanism calls Introspector.getBeanInfo() in constructors
> which in turn calls classloader.loadClass(beanClass.getName() +
> BEANINFO_SUFFIX) (the class name is "FooBar$__plexus2") which in turn causes
> CloningClassLoader to create a new clone of the class named
> "FooBar$__plexus2BeanInfo". When "FooBar$__plexusBeanInfo" is instantiated
> groovy's the meta class mechanism again calls
> Introspector.getBeanInfo() on "FooBar$__plexus2".
> Example stack trace:
> {code}at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
> at java.beans.Introspector.(Introspector.java:380)
> at java.beans.Introspector.getBeanInfo(Introspector.java:167)
> at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
> at java.security.AccessController.doPrivileged(Native Method)
> at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
> at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
> at
> org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
> at
> sis.buildtools.SisMapVersionsPhase.$getStaticMetaClass(VersionsMojo.groovy)
> at sis.buildtools.SisMapVersionsPhase.(VersionsMojo.groovy:692)
> at
> sis.buildtools.SisMapVersionsPhase$__plexus2BeanInfo.(Unknown Source)
> at sun.reflect.GeneratedConstructorAccessor5.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at java.beans.Introspector.instantiate(Introspector.java:1449)
> at java.beans.Introspector.findExplicitBeanInfo(Introspector.java:431)
[jira] Commented: (MNG-5027) Problem executing custom surefire implementation in Maven 3.0.3-RC1
[ http://jira.codehaus.org/browse/MNG-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257916#action_257916 ] Stuart McCulloch commented on MNG-5027: --- Hi Paul - could you add a direct link to the source of your patched surefire plugin? I couldn't find it from the above links - thanks. > Problem executing custom surefire implementation in Maven 3.0.3-RC1 > --- > > Key: MNG-5027 > URL: http://jira.codehaus.org/browse/MNG-5027 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Paul Gier > Attachments: build.log > > > There seems to be a regression between Maven 3.0.2 to 3.0.3-RC1. When > executing the jboss-as build [1] the build fails during execution of our > custom implementation of the surefire plugin [2]. > [1]https://github.com/jbossas/jboss-as > [2]http://community.jboss.org/wiki/JBossModulesSurefirePlugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4884) Guice provision errors
[ http://jira.codehaus.org/browse/MNG-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242329#action_242329 ] Stuart McCulloch edited comment on MNG-4884 at 11/7/10 7:26 AM: The container issue to turn this error into a warning is: https://issues.sonatype.org/browse/SISU-18 was (Author: mcculls): The container issue to turn this error into a warning is: https://issues.sonatype.org/browse/SISU-20 > Guice provision errors > -- > > Key: MNG-4884 > URL: http://jira.codehaus.org/browse/MNG-4884 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0 > Environment: windows vista sp2 32 bits on a hp dv5 laptop >Reporter: Ricardo > Attachments: debug.log > > > Please find attached the debug log as requested by the url presented on the > error itself -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4884) Guice provision errors
[ http://jira.codehaus.org/browse/MNG-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242329#action_242329 ] Stuart McCulloch commented on MNG-4884: --- The container issue to turn this error into a warning is: https://issues.sonatype.org/browse/SISU-20 > Guice provision errors > -- > > Key: MNG-4884 > URL: http://jira.codehaus.org/browse/MNG-4884 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0 > Environment: windows vista sp2 32 bits on a hp dv5 laptop >Reporter: Ricardo > Attachments: debug.log > > > Please find attached the debug log as requested by the url presented on the > error itself -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-506) Maven3 conflict with plexus-archiver
[ http://jira.codehaus.org/browse/MSITE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236334#action_236334 ] Stuart McCulloch commented on MSITE-506: Updating the site plugin copy of the plexus-archiver jar won't make any difference, it is still separate from the copy in the javadoc plugin realm. In order for string-based Plexus lookups to work the TCCL must be set to the plugin realm when invoking plugin specific code. This is the same for the original Plexus container as well as the new adapter. The container has to have some way to disambiguate a pure string role into an actual type and this is done by looking at the TCCL to see what realms are visible in the context of the request. This is why Maven core always sets the TCCL to the plugin realm before calling plugin code, and the site plugin has to do the same when calling report code. > Maven3 conflict with plexus-archiver > > > Key: MSITE-506 > URL: http://jira.codehaus.org/browse/MSITE-506 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-2 > Environment: Apache Maven 3.0-SNAPSHOT (r999839; 2010-09-22 > 11:43:26+0200) > Java version: 1.7.0-ea > Java home: /home/pether/tools/jdk1.7.0/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-25-generic" arch: "amd64" Family: "unix" >Reporter: Pether Sorling >Assignee: Olivier Lamy > Fix For: 3.0-beta-3 > > Attachments: testmaven3.zip > > > Verson 2.7 and 2.8-SNAPSHOT have some issues with maven3. Works with 2.6.1, > different version of plexus archiver conflicts with maven. > failed to get Reports: > org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus5 cannot be cast to > org.codehaus.plexus.archiver.UnArchiver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4833) Maven3 conflict with plexus-archiver
[
http://jira.codehaus.org/browse/MNG-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236249#action_236249
]
Stuart McCulloch commented on MNG-4833:
---
OK, here's the problem:
The maven-site-plugin calls the canGenerateReport method of the JavadocReport
without setting the TCCL or lookupRealm to the maven-javadoc-plugin realm. This
means any (string-based) Plexus component lookup requests will use the site
plugin context. As the stack trace below shows, the JavadocReport looks up an
UnArchiver while processing the canGenerateReport request. Because it is using
the site plugin context and not the javadoc plugin context, the ZipUnArchiver
it finds is not classloader compatible (it is doing a pure string-based lookup
so we only find out about the incompatibility when the value is assigned).
Solution:
Presumably canGenerateReport implementations are allowed to lookup Plexus
components, so the maven-site-plugin must set the TCCL to the appropriate realm
before calling the method and reset it afterwards (as it already does for
isMavenReport). Otherwise the maven-javadoc-plugin would have to set (and
reset) the TCCL itself when looking up the UnArchiver - unless of course they
could switch to a type-based role lookup instead of the existing string-based
one.
Either way, this is something that needs to be resolved between the site and
javadoc plugins.
{code}
at
org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getUnArchiver(DefaultArchiverManager.java:76)
at
org.apache.maven.plugin.javadoc.resolver.ResourceResolver.resolveAndUnpack(ResourceResolver.java:357)
at
org.apache.maven.plugin.javadoc.resolver.ResourceResolver.resolveFromArtifacts(ResourceResolver.java:302)
at
org.apache.maven.plugin.javadoc.resolver.ResourceResolver.resolveDependencySourcePaths(ResourceResolver.java:143)
at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getDependencySourcePaths(AbstractJavadocMojo.java:2169)
at
org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getSourcePaths(AbstractJavadocMojo.java:2058)
at
org.apache.maven.plugin.javadoc.JavadocReport.canGenerateReport(JavadocReport.java:213)
at
org.apache.maven.plugins.site.DefaultMavenReportExecutor.canGenerateReport(DefaultMavenReportExecutor.java:272)
at
org.apache.maven.plugins.site.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:254)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:208)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
{code}
> Maven3 conflict with plexus-archiver
>
>
> Key: MNG-4833
> URL: http://jira.codehaus.org/browse/MNG-4833
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0-beta-3
> Environment: Apache Maven 3.0-SNAPSHOT (r999839; 2010-09-22
> 11:43:26+0200)
> Java version: 1.7.0-ea
> Java home: /home/pether/tools/jdk1.7.0/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.32-25-generic" arch: "amd64" Family: "unix"
>Reporter: Pether Sorling
> Attachments: testmaven3.zip
>
>
> Verson 2.7 and 2.8-SNAPSHOT have some issues with maven3. Works with 2.6.1,
> different version of plexus archiver conflicts with maven.
> failed to get Reports:
> org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus5 cannot be cast to
> org.codehaus.plexus.archiver.UnArchiver
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4833) Maven3 conflict with plexus-archiver
[ http://jira.codehaus.org/browse/MNG-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236227#action_236227 ] Stuart McCulloch commented on MNG-4833: --- Interestingly I get the exact same ClassCastException when I swap out Guice and put back the old Plexus container, which suggests it's not a straightforward compatibility issue. > Maven3 conflict with plexus-archiver > > > Key: MNG-4833 > URL: http://jira.codehaus.org/browse/MNG-4833 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-3 > Environment: Apache Maven 3.0-SNAPSHOT (r999839; 2010-09-22 > 11:43:26+0200) > Java version: 1.7.0-ea > Java home: /home/pether/tools/jdk1.7.0/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-25-generic" arch: "amd64" Family: "unix" >Reporter: Pether Sorling > Attachments: testmaven3.zip > > > Verson 2.7 and 2.8-SNAPSHOT have some issues with maven3. Works with 2.6.1, > different version of plexus archiver conflicts with maven. > failed to get Reports: > org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus5 cannot be cast to > org.codehaus.plexus.archiver.UnArchiver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4833) Maven3 conflict with plexus-archiver
[ http://jira.codehaus.org/browse/MNG-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236207#action_236207 ] Stuart McCulloch commented on MNG-4833: --- PS. the reason this doesn't show up with maven-javadoc-plugin 2.6.1 is because the error is triggered by the new ResourceResolver added in 2.7. > Maven3 conflict with plexus-archiver > > > Key: MNG-4833 > URL: http://jira.codehaus.org/browse/MNG-4833 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-3 > Environment: Apache Maven 3.0-SNAPSHOT (r999839; 2010-09-22 > 11:43:26+0200) > Java version: 1.7.0-ea > Java home: /home/pether/tools/jdk1.7.0/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-25-generic" arch: "amd64" Family: "unix" >Reporter: Pether Sorling > Attachments: testmaven3.zip > > > Verson 2.7 and 2.8-SNAPSHOT have some issues with maven3. Works with 2.6.1, > different version of plexus archiver conflicts with maven. > failed to get Reports: > org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus5 cannot be cast to > org.codehaus.plexus.archiver.UnArchiver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-293) Maven3 conflict with plexus-archiver
[ http://jira.codehaus.org/browse/MJAVADOC-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236127#action_236127 ] Stuart McCulloch commented on MJAVADOC-293: --- thanks, I can recreate the exception using your example project (I don't have the JIRA rights to assign this issue to myself, but in case anyone is reading this I will work on this issue tomorrow) > Maven3 conflict with plexus-archiver > > > Key: MJAVADOC-293 > URL: http://jira.codehaus.org/browse/MJAVADOC-293 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.7, 2.8 > Environment: Apache Maven 3.0-SNAPSHOT (r999839; 2010-09-22 > 11:43:26+0200) > Java version: 1.7.0-ea > Java home: /home/pether/tools/jdk1.7.0/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-25-generic" arch: "amd64" Family: "unix" >Reporter: Pether Sorling > Attachments: testmaven3.zip > > > Verson 2.7 and 2.8-SNAPSHOT have some issues with maven3. Works with 2.6.1, > different version of plexus archiver conflicts with maven. > failed to get Reports: > org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus5 cannot be cast to > org.codehaus.plexus.archiver.UnArchiver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-293) Maven3 conflict with plexus-archiver
[ http://jira.codehaus.org/browse/MJAVADOC-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236067#action_236067 ] Stuart McCulloch commented on MJAVADOC-293: --- I can't recreate this locally and I was also able to build the 2.8-SNAPSHOT of the javadoc plugin with the latest Maven 3.0-RC1 binary (including UTs and ITs) so it's probably something specific to your project configuration. A detailed build log or (even better) an example project would really help identify the problem. > Maven3 conflict with plexus-archiver > > > Key: MJAVADOC-293 > URL: http://jira.codehaus.org/browse/MJAVADOC-293 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.7, 2.8 > Environment: Apache Maven 3.0-SNAPSHOT (r999839; 2010-09-22 > 11:43:26+0200) > Java version: 1.7.0-ea > Java home: /home/pether/tools/jdk1.7.0/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-25-generic" arch: "amd64" Family: "unix" >Reporter: Pether Sorling > > Verson 2.7 and 2.8-SNAPSHOT have some issues with maven3. Works with 2.6.1, > different version of plexus archiver conflicts with maven. > failed to get Reports: > org.codehaus.plexus.archiver.zip.ZipUnArchiver$__plexus5 cannot be cast to > org.codehaus.plexus.archiver.UnArchiver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4818) NPE in legacy.DefaultWagonManager.getArtifact
[ http://jira.codehaus.org/browse/MNG-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235758#action_235758 ] Stuart McCulloch commented on MNG-4818: --- I can't recreate this error with 3.0-RC1 (https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/) Can you try to recreate it with that release? Also in your test were you using a clean snapshot build of Maven3 or did you have local changes? > NPE in legacy.DefaultWagonManager.getArtifact > - > > Key: MNG-4818 > URL: http://jira.codehaus.org/browse/MNG-4818 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0 > Environment: At revision 998131; 1.6.0_21 (32-bit); win7ent-x64 >Reporter: Matthew Daniel > Attachments: bug.log > > > 1. mvn archetype:create (with your favorite -DgroupId etc) > 2. add some non-local dependency to the pom (I used commons-jexl:2.0.1) > 3. mvn idea:idea > 4. kaboom > The problem is that the Logger is declared as @Requirement but it is > evidently not being provided (any path leading to a logging statement yields > the NPE) > I regret that I don't know enough plexus-voodoo to even create a TestCase for > this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4810) Maven cannot build if loaded in a classloader that is not backed by a real JAR file / classpath
[
http://jira.codehaus.org/browse/MNG-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=235530#action_235530
]
Stuart McCulloch commented on MNG-4810:
---
This should already be fixed in the RC1 build - it now uses the more
classloader friendly getResources() to find components.xml. (The other method
called findEntries is used when the container is scanning for files according
to a pattern like *.class, in which case you can't use getResources and must
rely on introspecting the URLs - but for M3 we're still using XML directed
injection)
> Maven cannot build if loaded in a classloader that is not backed by a real
> JAR file / classpath
> ---
>
> Key: MNG-4810
> URL: http://jira.codehaus.org/browse/MNG-4810
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0-beta-3
> Environment: Mac OSX & Linux, Java 1.6, Maven 3 beta 3
>Reporter: Lincoln Baxter, III
> Attachments: arquillian-maven-bug.tar.gz
>
>
> Maven fails to find required class files (resulting in null pointer
> exceptions) because the ClassLoader implementation in which it was loaded
> does not meet maven's assumptions of what type of information a ClassLoader
> URL should return.
> (From another perspective, that ClassLoader does not behave like a normal
> ClassLoader, but maven should probably not be contstrained to classloaders
> that provide their information as if they were backed by a JAR file; not all
> classloaders are going to use those semantics, as provided in this example,
> when the URLClassSpace instance loaded by the DefaultPlexusContainer attempts
> to read the "/MANIFEST.ML" out of a non-jar-based classloader.
> Please run example tests in attached project.
> I attempted to patch this by ignoring exceptions when attempting to pull
> manifests, but it appears that maven uses those manifests to populate some
> kind of bean container (I'm guessing guice which is abstracted via a plexus
> facade.)
> Then I attempted to modify the URLClassLoader instance in which the
> application was actually running, in order to provide a manifest, but it
> appears that maven is still just processing "Class-Path" elements and
> attempting to source those files directly, which might not work (but I had
> trouble getting this to work, so it may just have been something I was doing
> wrong.)
> If I knew more about why maven was trying to use the classloader in this way,
> I might be able to give more insightful thought into the nature/potential
> solutions of/for this issue. I do know that maven is making some assumptions
> about how the internals of classloaders are working, here in URLClassSpace:
> `
> private static String[] getClassPathEntries( final URL url )
> throws IOException
> {
> final URL manifestURL;
> if ( url.getPath().endsWith( "/" ) )
> {
> manifestURL = new URL( url, MANIFEST_ENTRY );
> }
> else
> {
> manifestURL = new URL( "jar:" + url + "!/" + MANIFEST_ENTRY );
> }
> final InputStream in = manifestURL.openStream();
> try
> {
> final String classPath = new Manifest( in
> ).getMainAttributes().getValue( "Class-Path" );
> return null != classPath ? classPath.split( " " ) : NO_ENTRIES;
> }
> finally
> {
> in.close();
> }
> }
> `
> I hope I have provided enough information, and that the attached test-case
> provides useful.
> Just run the attached project via 'mvn test' or 'mvn package' and you'll see
> the issue.
> Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4793) Unable to obtain archiver for extension 'zip'
[
http://jira.codehaus.org/browse/MNG-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234142#action_234142
]
Stuart McCulloch commented on MNG-4793:
---
Fixed in
http://github.com/sonatype/sisu/commit/4efc10f500dba7a4acfe91d782eebf71ff1f5d79
The problem was in container code that sets the TCCL for components with
lifecycles (contextualizable, initializable, etc.). The TCCL should be set to
whatever realm the component belongs to, in order for string-based lookups to
work as expected from lifecycle methods.
Unfortunately this container code did not take into account the possibility of
proxy classes, where the real component class (and the associated realm) is
further up the class hierarchy. The fix is to search the hierarchy until we
find a class which was loaded by a realm - and if we don't find one then we
just leave the TCCL set to the last context realm.
[Note: the proxy class in this case was one generated by the container for
situations where the same component implementation is used multiple times for
different hints - we need a way to disambiguate between each use of the
implementation when performing custom injection in Guice, and creating thin
proxies was the easiest way to achieve this as the custom injection is
performed per-type]
> Unable to obtain archiver for extension 'zip'
> -
>
> Key: MNG-4793
> URL: http://jira.codehaus.org/browse/MNG-4793
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-beta-3
> Environment: maven-3-beta-2, maven-3-beta-3
>Reporter: Paul Gier
> Attachments: build.log
>
>
> There seems to be a regression in maven-3-beta-3 related to the assembly
> plugin. When building a multi-module project using Maven 3-beta-3 I get the
> error "Unable to obtain archiver for extension 'zip'". This error does not
> happen with Maven 3-beta-2.
> I wasn't able to reproduce this problem with a smaller project. The source
> can be checked out from the jboss repo
> {code}
> svn co -r 107936 http://anonsvn.jboss.org/repos/jbossas/trunk
> {code}
> The problem can be seen running building certain modules.
> {code}
> mvn clean install -pl deployment,server,osgi/zip
> {code}
> I will try to narrow down the problem further if I have some time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4793) Unable to obtain archiver for extension 'zip'
[
http://jira.codehaus.org/browse/MNG-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234083#action_234083
]
Stuart McCulloch commented on MNG-4793:
---
Recreated locally, investigating...
> Unable to obtain archiver for extension 'zip'
> -
>
> Key: MNG-4793
> URL: http://jira.codehaus.org/browse/MNG-4793
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0-beta-3
> Environment: maven-3-beta-2, maven-3-beta-3
>Reporter: Paul Gier
> Attachments: build.log
>
>
> There seems to be a regression in maven-3-beta-3 related to the assembly
> plugin. When building a multi-module project using Maven 3-beta-3 I get the
> error "Unable to obtain archiver for extension 'zip'". This error does not
> happen with Maven 3-beta-2.
> I wasn't able to reproduce this problem with a smaller project. The source
> can be checked out from the jboss repo
> {code}
> svn co -r 107936 http://anonsvn.jboss.org/repos/jbossas/trunk
> {code}
> The problem can be seen running building certain modules.
> {code}
> mvn clean install -pl deployment,server,osgi/zip
> {code}
> I will try to narrow down the problem further if I have some time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4786) [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE
[ http://jira.codehaus.org/browse/MNG-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233795#action_233795 ] Stuart McCulloch commented on MNG-4786: --- Fixed in spice-inject-plexus-1.3.4.1 (r2845) ... the issue was that objects created from non-java component factories weren't being processed properly. > [regression] Ant-based mojo using maven-script-ant:2.1.0+ cause NPE > --- > > Key: MNG-4786 > URL: http://jira.codehaus.org/browse/MNG-4786 > Project: Maven 2 & 3 > Issue Type: Bug > Environment: 3.0-beta-3 (staging) >Reporter: Vincent Latombe > Attachments: antmojo.zip, NPE.log > > > Testing latest beta-3 available in staging, I get an NPE when calling one of > my plugins that use the ant wrapper (described at > http://www.sonatype.com/books/mhandbook/reference/ch04s04.html) > Here is a sample plugin project that use this feature (I took the one > available in Maven book). > Compile it, then call > mvn org.sonatype.mavenbook.plugins:firstant-maven-plugin:echo -Dmessage=world > -e > This works with 2.2.1/beta-2 but throws an NPE with beta-3 (see attached logs) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4785) NPE in dependency resolution code for TC plugin
[
http://jira.codehaus.org/browse/MNG-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233716#action_233716
]
Stuart McCulloch commented on MNG-4785:
---
Looks like the DsoSurefireMojo spawns a child thread that uses the legacy Maven
resolution API. The new beta uses a threadlocal (see
org.apache.maven.plugin.internal.DefaultLegacySupport) to provide access to the
Maven session from legacy components, but of course this threadlocal is only
valid for the executing mojo thread - not the spawned child thread.
Changing DefaultLegacySupport to use an InheritableThreadLocal should solve
this NPE, but I'm not sure what impact this would have wrt. cleanup of the
Maven session given that Maven has no knowledge of the child thread...
> NPE in dependency resolution code for TC plugin
> ---
>
> Key: MNG-4785
> URL: http://jira.codehaus.org/browse/MNG-4785
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0-beta-3
> Environment: OS X 10.6
>Reporter: Oleg Gusakov
> Attachments: m3tctest.tgz
>
>
> Terracotta Maven plugin 1.4.0 test produces NPE in 3.0-beta-3, but works fine
> in 3.0-beta-2
> {code}
> [ERROR] [node0]
> java.lang.NullPointerException
> at
> org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:149)
> at
> org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:139)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:237)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:219)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:584)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:192)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:451)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:307)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:301)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:280)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:258)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
> at
> org.terracotta.maven.plugins.tc.DsoArtifactResolverImpl.resolveArtifact(DsoArtifactResolverImpl.java:145)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo.addArtifact(DsoSurefireMojo.java:775)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo.constructSurefireBooter(DsoSurefireMojo.java:548)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.runSurefire(DsoSurefireMojo.java:434)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.run(DsoSurefireMojo.java:417)
> at java.lang.Thread.run(Thread.java:637)
> [INFO] All nodes completed
> [INFO]
>
> [INFO] Stopping DSO Server
> [INFO] [dso stop] 2010-08-30 11:10:42,625 INFO - Terracotta 3.1.0, as of
> 20090821-080813 (Revision 13442 by cru...@su10mo5 from 3.1)
> [INFO] OK
> [{code}
> Test project - attached
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4785) NPE in dependency resolution code for TC plugin
[
http://jira.codehaus.org/browse/MNG-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233712#action_233712
]
Stuart McCulloch commented on MNG-4785:
---
I've just recreated this particular NPE with the re-spun beta-3 so it looks
like there is still a bug:
{code}
[ERROR] [node0]
java.lang.NullPointerException
at
org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:185)
at
org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:175)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:237)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:219)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:584)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:192)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:451)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:307)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:301)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:280)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:258)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
at
org.terracotta.maven.plugins.tc.DsoArtifactResolverImpl.resolveArtifact(DsoArtifactResolverImpl.java:145)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo.addArtifact(DsoSurefireMojo.java:775)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo.constructSurefireBooter(DsoSurefireMojo.java:548)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.runSurefire(DsoSurefireMojo.java:434)
at
org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.run(DsoSurefireMojo.java:417)
at java.lang.Thread.run(Thread.java:619)
{code}
> NPE in dependency resolution code for TC plugin
> ---
>
> Key: MNG-4785
> URL: http://jira.codehaus.org/browse/MNG-4785
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0-beta-3
> Environment: OS X 10.6
>Reporter: Oleg Gusakov
> Attachments: m3tctest.tgz
>
>
> Terracotta Maven plugin 1.4.0 test produces NPE in 3.0-beta-3, but works fine
> in 3.0-beta-2
> {code}
> [ERROR] [node0]
> java.lang.NullPointerException
> at
> org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:149)
> at
> org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:139)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:237)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:219)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:584)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:192)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:451)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:307)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:301)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:280)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:258)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
> at
> org.terracotta.maven.plugins.tc.DsoArtifactResolverImpl.resolveArtifact(DsoArtifactResolverImpl.java:145
[jira] Commented: (MNG-4785) NPE in dependency resolution code for TC plugin
[
http://jira.codehaus.org/browse/MNG-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=233710#action_233710
]
Stuart McCulloch commented on MNG-4785:
---
Could you double-check you're using the re-spun maven-3.0-beta-3, because the
stack trace attached to MNG-4785 doesn't match the code in aether-1.2.
It does however match code in the previous aether release from the earlier
maven-3.0-beta-3 attempt (which had a known NPE issue, hence the respin).
https://repository.apache.org/content/repositories/maven-157/org/apache/maven/apache-maven/3.0-beta-3/
> NPE in dependency resolution code for TC plugin
> ---
>
> Key: MNG-4785
> URL: http://jira.codehaus.org/browse/MNG-4785
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0-beta-3
> Environment: OS X 10.6
>Reporter: Oleg Gusakov
> Attachments: m3tctest.tgz
>
>
> Terracotta Maven plugin 1.4.0 test produces NPE in 3.0-beta-3, but works fine
> in 3.0-beta-2
> {code}
> [ERROR] [node0]
> java.lang.NullPointerException
> at
> org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:149)
> at
> org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:139)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:237)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:219)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:584)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:192)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:451)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:307)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:301)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:280)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:258)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
> at
> org.terracotta.maven.plugins.tc.DsoArtifactResolverImpl.resolveArtifact(DsoArtifactResolverImpl.java:145)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo.addArtifact(DsoSurefireMojo.java:775)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo.constructSurefireBooter(DsoSurefireMojo.java:548)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.runSurefire(DsoSurefireMojo.java:434)
> at
> org.terracotta.maven.plugins.tc.DsoSurefireMojo$SurefireThread.run(DsoSurefireMojo.java:417)
> at java.lang.Thread.run(Thread.java:637)
> [INFO] All nodes completed
> [INFO]
>
> [INFO] Stopping DSO Server
> [INFO] [dso stop] 2010-08-30 11:10:42,625 INFO - Terracotta 3.1.0, as of
> 20090821-080813 (Revision 13442 by cru...@su10mo5 from 3.1)
> [INFO] OK
> [{code}
> Test project - attached
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4669) Adjust the expected message string in MavenITmng2690MojoLoadingErrorsTest
Adjust the expected message string in MavenITmng2690MojoLoadingErrorsTest - Key: MNG-4669 URL: http://jira.codehaus.org/browse/MNG-4669 Project: Maven 2 & 3 Issue Type: Wish Components: Integration Tests Affects Versions: 3.0-beta-1 Reporter: Stuart McCulloch Priority: Minor Attachments: MavenITmng2690MojoLoadingErrorsTest_Message.patch The current MavenITmng2690MojoLoadingErrorsTest expects the following message: "(?i).*required class was missing during (mojo )?configuration.*" in the mvn output when executing a mojo with a field that has a missing class. This pattern does not quite match the error when running with Guice, because Guice detects the missing class slightly earlier (before Maven configuration) while scanning the declared fields for @Inject annotations. The following pattern matches both Plexus and Guice error messages: "(?i).*required class (i|wa)s missing( during (mojo )?configuration)?.*" any chance the attached patch could be applied to the MavenITmng2690MojoLoadingErrorsTest? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4665) Missing component test class from maven-it-plugin-class-loader project?
Missing component test class from maven-it-plugin-class-loader project? --- Key: MNG-4665 URL: http://jira.codehaus.org/browse/MNG-4665 Project: Maven 2 & 3 Issue Type: Task Components: Integration Tests Affects Versions: 3.0-beta-1 Reporter: Stuart McCulloch Attachments: MAVEN_3_IT_PATCHES_FOR_GUICE.txt When running the Maven3 ITs with the new Guice-Plexus container I see a couple of failures involving the maven-it-plugin-class-loader. This is because the InstanceofMojo declares a requirement with a role of "org.apache.maven.plugin.coreit.Component" and this class is not available in the plugin or any of its dependencies. This doesn't cause a problem with Plexus because components are matched using String identities, whereas because Guice is type-safe we automatically detect the missing class during requirement lookup/injection. So is this missing role class part of the test? If not then can the class be added (see attached patch). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4664) Minor patches needed to run Maven3 with the replacement Guice-Plexus container
Minor patches needed to run Maven3 with the replacement Guice-Plexus container -- Key: MNG-4664 URL: http://jira.codehaus.org/browse/MNG-4664 Project: Maven 2 & 3 Issue Type: Task Components: General Affects Versions: 3.0-beta-1 Reporter: Stuart McCulloch Attachments: MAVEN_3_CORE_PATCHES_FOR_GUICE.txt The attached patch contains two minor changes that are a pre-req for running Maven3 with the new Guice-Plexus container: 1) Fix incorrect role setting in LifecyclePluginAnalyzerImpl (test also updated to lookup the role) 2) Rework ConcurrentBuildLogger to use JDK classes for the multimap instead of google-collections The last change is because while the Plexus container requires google-collections, the new Guice-Plexus container has no such dependency. Adding google-collections (~600k) to the distribution just for this single use of a multimap doesn't seem to be worthwhile imho. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2359) bndlib 0.0.311
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166965#action_166965 ] Stuart McCulloch commented on MAVENUPLOAD-2359: --- FYI, this is a pre-req for the next release of the maven-bundle-plugin. > bndlib 0.0.311 > -- > > Key: MAVENUPLOAD-2359 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2359 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Stuart McCulloch > > Stable version of the Bnd Tool library, contains fixes for various > inconsistencies when calculating versions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2359) bndlib 0.0.311
bndlib 0.0.311 -- Key: MAVENUPLOAD-2359 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2359 Project: Maven Upload Requests Issue Type: Task Reporter: Stuart McCulloch Stable version of the Bnd Tool library, contains fixes for various inconsistencies when calculating versions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2187) Upload bndlib 0.0.264
Upload bndlib 0.0.264 - Key: MAVENUPLOAD-2187 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2187 Project: Maven Upload Requests Issue Type: Wish Reporter: Stuart McCulloch Latest release of the BND library, which now requires Java5 to run (I'm still working on getting Peter to setup an rsync'able location...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-53) Maven2OsgiConverter can leak JarFiles
Maven2OsgiConverter can leak JarFiles - Key: MSHARED-53 URL: http://jira.codehaus.org/browse/MSHARED-53 Project: Maven Shared Components Issue Type: Bug Components: maven-osgi Reporter: Stuart McCulloch Priority: Minor Attachments: MOD The default Maven2OsgiConverter can leak JarFiles, because they are sometimes opened but never closed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3042) Extending a Mojo Class and used in a new Mojo Project, parameter fields in the parent mojo are not set, this disables reuse of existing mojo project.
[ http://jira.codehaus.org/browse/MNG-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124544 ] Stuart McCulloch commented on MNG-3042: --- FYI, you only need to propagate values using reflection if you override the field, ie. you declare a field in your mojo that "hides" a field of the same name in original mojo. You only usually need to do this if you need to change the default, or want access to the field - although in the latter case you could use reflection to read the field rather than override it. ( interestingly, if the overridden field is a @parameter then your new field will be injected instead of the original - but if it's an @component then it appears the original field is injected rather than the original ) Note that you can read and write private fields using reflection - you just need to use setAccessible(true) on the field to make it accessible, as shown in: http://www.ops4j.org/projects/pax/construct/maven-pax-plugin/xref/org/ops4j/pax/construct/util/ReflectMojo.html btw, in the maven-pax-plugin I extend a number of different mojos and override a couple of private fields, so I know this works in practice. > Extending a Mojo Class and used in a new Mojo Project, parameter fields in > the parent mojo are not set, this disables reuse of existing mojo project. > - > > Key: MNG-3042 > URL: http://jira.codehaus.org/browse/MNG-3042 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Reporter: Leopoldo Agdeppa III > Fix For: Reviewed Pending Version Assignment > > > I have an Existing maven-plugin-a and I want to extend its functionality and > put it in maven-plugin-b, so what i did is I put the the maven-plugin-a as a > dependecy in maven-plugin-b and extended the mojo class from A, the issue on > this is that paramter fields from A is not set, when I used plugin-B, I think > this disables reusing and extending of mojos -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1871) Upload bndlib 0.0.226
Upload bndlib 0.0.226 - Key: MAVENUPLOAD-1871 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1871 Project: maven-upload-requests Issue Type: Task Reporter: Stuart McCulloch bndlib 0.0.226 contains a number of improvements that would help fix some maven-bundle-plugin related issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1824) Upload bndlib 0.0.213
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115159 ] Stuart McCulloch commented on MAVENUPLOAD-1824: --- thanks - the new upload works > Upload bndlib 0.0.213 > - > > Key: MAVENUPLOAD-1824 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1824 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stuart McCulloch >Assignee: Carlos Sanchez > > bndlib 0.0.213 removes some caching of class data that was causing the > bundle-plugin to use large amounts of memory when processing jars such as > xalan and xerces (for instance Felix Commons "xml-apis" memory usage drops > from 80mb to 18mb using this new bndlib). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-1824) Upload bndlib 0.0.213
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart McCulloch reopened MAVENUPLOAD-1824: --- Hi Carlos - the uploaded jarfile seems to be corrupted: Downloading: http://repo1.maven.org/maven2/biz/aQute/bndlib/0.0.213/bndlib-0.0.213.pom 907b downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '0f249b491f51a0e24ce1b8230a732e8b03000e46'; remote = '0621edc14db6c8690a4b3e4f228938d61f5e3949' - RETRYING Downloading: http://repo1.maven.org/maven2/biz/aQute/bndlib/0.0.213/bndlib-0.0.213.pom 907b downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '0f249b491f51a0e24ce1b8230a732e8b03000e46'; remote = '0621edc14db6c8690a4b3e4f228938d61f5e3949' - IGNORING Downloading: http://repo1.maven.org/maven2/biz/aQute/bndlib/0.0.203/bndlib-0.0.203.pom 886b downloaded Downloading: http://repo1.maven.org/maven2/biz/aQute/bndlib/0.0.213/bndlib-0.0.213.jar 145K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '6731586ac0faf7eef9c0e3a53faa576a362f8840'; remote = '7a1d669a2be2439e9b3d8c1b5d4b9795e5b01cdb' - RETRYING Downloading: http://repo1.maven.org/maven2/biz/aQute/bndlib/0.0.213/bndlib-0.0.213.jar 145K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '6731586ac0faf7eef9c0e3a53faa576a362f8840'; remote = '7a1d669a2be2439e9b3d8c1b5d4b9795e5b01cdb' - IGNORING [INFO] [compiler:compile] [INFO] Compiling 8 source files to /home/stuart/Code/felix/bundleplugin/target/classes count = 0, total = 65 ...etc... > Upload bndlib 0.0.213 > - > > Key: MAVENUPLOAD-1824 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1824 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stuart McCulloch >Assignee: Carlos Sanchez > > bndlib 0.0.213 removes some caching of class data that was causing the > bundle-plugin to use large amounts of memory when processing jars such as > xalan and xerces (for instance Felix Commons "xml-apis" memory usage drops > from 80mb to 18mb using this new bndlib). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1824) Upload bndlib 0.0.213
Upload bndlib 0.0.213 - Key: MAVENUPLOAD-1824 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1824 Project: maven-upload-requests Issue Type: Task Reporter: Stuart McCulloch bndlib 0.0.213 removes some caching of class data that was causing the bundle-plugin to use large amounts of memory when processing jars such as xalan and xerces (for instance Felix Commons "xml-apis" memory usage drops from 80mb to 18mb using this new bndlib). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1775) Upload bndlib 0.0.205 to central repository (fixes bug introduced in 0.0.203)
Upload bndlib 0.0.205 to central repository (fixes bug introduced in 0.0.203) - Key: MAVENUPLOAD-1775 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1775 Project: maven-upload-requests Issue Type: Task Reporter: Stuart McCulloch sorry, need another upload to fix a bug introduced in Bnd 0.0.203 (see https://issues.apache.org/jira/browse/FELIX-401) thanks in advance - it's much appreciated! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1745) Upload bndlib 0.0.199 to central repository
Upload bndlib 0.0.199 to central repository --- Key: MAVENUPLOAD-1745 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1745 Project: maven-upload-requests Issue Type: Task Reporter: Stuart McCulloch Version 0.0.199 of the Bnd tool is needed to fix the following issue: https://issues.apache.org/jira/browse/FELIX-390 Thanks in advance! (perhaps Peter should start syncing his repository with central?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1730) Upload bndlib 0.0.190 to central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108716 ] Stuart McCulloch commented on MAVENUPLOAD-1730: --- FYI, since creating this request Peter has released several updates and the latest BND library version is now 0.0.198: http://www.aqute.biz/repo/biz/aQute/bnd/0.0.198 btw, this update is required by the Maven Bundle Plugin over at Felix which is why we need it on the central repository. > Upload bndlib 0.0.190 to central repository > --- > > Key: MAVENUPLOAD-1730 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1730 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stuart McCulloch > > Peter Kriens has released another update to his BND library: >http://www.aqute.biz/repo/biz/aQute/bnd/0.0.190 > could you upload it as usual to the central repo - thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
