Releasing Maven enforcer plugin

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Releasing Maven enforcer plugin

Enrico Olivelli
An user is asking for a release of the enforcer plugin

https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729

I can prepare the release

Thoughts?
Enrico
--


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: Releasing Maven enforcer plugin

Sylwester Lachiewicz
We have a few PRs on Github from community, maybe we can try to review and
include also?

+1 for release

BR
Sylwester

W dniu śr., 16.01.2019 o 14:32 Stephen Connolly <
[hidden email]> napisał(a):

> +1
>
> On Wed, 16 Jan 2019 at 12:56, Enrico Olivelli <[hidden email]> wrote:
>
> > An user is asking for a release of the enforcer plugin
> >
> > https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
> >
> > I can prepare the release
> >
> > Thoughts?
> > Enrico
> > --
> >
> >
> > -- Enrico Olivelli
> >
>
Reply | Threaded
Open this post in threaded view
|

suggestion regarding MJAVADOC-564 - javadoc:fix enforcing order of tags

Richard Sand
In reply to this post by Enrico Olivelli
Hi all - I'd like to provide a fix for MJAVADOC-564, where the
javadoc:fix goal will sometimes output the javadoc tags in incorrect
order. The problem occurs because of the way the fix goal initially
reads in the tags and then iterates over them to make the prescribed
corrections. There is an internal wrapper class inside the
AbstractFixJavadocMojo called JavaEntityTags that maintains various
state of the processing, including maintaining the original values of
all tags, the mappings of @param and @throws to values, etc. There is a
lot of logic in the mojo to keep track of original and updated values,
determining whether an update is necessary, etc., and I think that it
can be simplified by keeping an ordered, multi-valued map of all tags,
both the original and added/updated. My suggestion is to add a trivial
inner class called JavaEntityValue to hold both the original and updated
value, i.e.:

class JavaEntityValue {
      String originalValue;
      String updatedValue;
}

and then keep a multi-valued, ordered map in JavaEntityTags, e.g.

LinkedHashMap allTags <String,LinkedList<JavaEntityValue>>;

This will allow all of the existing logic inside the mojo to manipulate
the "allTags" map instead of directly writing to the output buffer, so
we can output all of the results at the very end of the mojo, output the
tags in the prescribed order, while still preserving the existing order
of all instances of a particular tag or any unknown tags.

I'd like to use common-collections4 (which will not override or conflict
with the existing collections dependency, which is 3.2.1) for the
"allTags" map to create this combined linked/multivalued map with its
decorators.

Any thoughts about this? If its ok I'll build it and issue a PR on the
current 3.1.0-SNAPSHOT master

Best regards,

Richard


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: suggestion regarding MJAVADOC-564 - javadoc:fix enforcing order of tags

rfscholte
It would be great if the fix-goal code could be simplified.
In fact I thought about moving code to a different package+classes, which  
should make it easier read, maintain and to unittest. But that's a huge  
task.
It is still a bit too abstract for me to see the complete picture.

The first thing I had in mind when reading this was the need for a  
comparator to reorder the tags.
Not sure if that would replace the need for common-collections4

I would suggest to give it a try.

thanks,
Robert

On Wed, 16 Jan 2019 20:13:05 +0100, Richard Sand <[hidden email]>  
wrote:

> Hi all - I'd like to provide a fix for MJAVADOC-564, where the  
> javadoc:fix goal will sometimes output the javadoc tags in incorrect  
> order. The problem occurs because of the way the fix goal initially  
> reads in the tags and then iterates over them to make the prescribed  
> corrections. There is an internal wrapper class inside the  
> AbstractFixJavadocMojo called JavaEntityTags that maintains various  
> state of the processing, including maintaining the original values of  
> all tags, the mappings of @param and @throws to values, etc. There is a  
> lot of logic in the mojo to keep track of original and updated values,  
> determining whether an update is necessary, etc., and I think that it  
> can be simplified by keeping an ordered, multi-valued map of all tags,  
> both the original and added/updated. My suggestion is to add a trivial  
> inner class called JavaEntityValue to hold both the original and updated  
> value, i.e.:
>
> class JavaEntityValue {
>       String originalValue;
>       String updatedValue;
> }
>
> and then keep a multi-valued, ordered map in JavaEntityTags, e.g.
>
> LinkedHashMap allTags <String,LinkedList<JavaEntityValue>>;
>
> This will allow all of the existing logic inside the mojo to manipulate  
> the "allTags" map instead of directly writing to the output buffer, so  
> we can output all of the results at the very end of the mojo, output the  
> tags in the prescribed order, while still preserving the existing order  
> of all instances of a particular tag or any unknown tags.
>
> I'd like to use common-collections4 (which will not override or conflict  
> with the existing collections dependency, which is 3.2.1) for the  
> "allTags" map to create this combined linked/multivalued map with its  
> decorators.
>
> Any thoughts about this? If its ok I'll build it and issue a PR on the  
> current 3.1.0-SNAPSHOT master
>
> Best regards,
>
> Richard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: suggestion regarding MJAVADOC-564 - javadoc:fix enforcing order of tags

Richard Sand
Comparator will help order the tags but we still want to preserve the order of found tags we aren’t fixing, such as if we aren’t fixing “see” tags and want to honor the original order of the existing see tags.

I’ll give it a shot

Sent from my iPhone

> On Jan 16, 2019, at 3:40 PM, Robert Scholte <[hidden email]> wrote:
>
> It would be great if the fix-goal code could be simplified.
> In fact I thought about moving code to a different package+classes, which should make it easier read, maintain and to unittest. But that's a huge task.
> It is still a bit too abstract for me to see the complete picture.
>
> The first thing I had in mind when reading this was the need for a comparator to reorder the tags.
> Not sure if that would replace the need for common-collections4
>
> I would suggest to give it a try.
>
> thanks,
> Robert
>
>> On Wed, 16 Jan 2019 20:13:05 +0100, Richard Sand <[hidden email]> wrote:
>>
>> Hi all - I'd like to provide a fix for MJAVADOC-564, where the javadoc:fix goal will sometimes output the javadoc tags in incorrect order. The problem occurs because of the way the fix goal initially reads in the tags and then iterates over them to make the prescribed corrections. There is an internal wrapper class inside the AbstractFixJavadocMojo called JavaEntityTags that maintains various state of the processing, including maintaining the original values of all tags, the mappings of @param and @throws to values, etc. There is a lot of logic in the mojo to keep track of original and updated values, determining whether an update is necessary, etc., and I think that it can be simplified by keeping an ordered, multi-valued map of all tags, both the original and added/updated. My suggestion is to add a trivial inner class called JavaEntityValue to hold both the original and updated value, i.e.:
>>
>> class JavaEntityValue {
>>      String originalValue;
>>      String updatedValue;
>> }
>>
>> and then keep a multi-valued, ordered map in JavaEntityTags, e.g.
>>
>> LinkedHashMap allTags <String,LinkedList<JavaEntityValue>>;
>>
>> This will allow all of the existing logic inside the mojo to manipulate the "allTags" map instead of directly writing to the output buffer, so we can output all of the results at the very end of the mojo, output the tags in the prescribed order, while still preserving the existing order of all instances of a particular tag or any unknown tags.
>>
>> I'd like to use common-collections4 (which will not override or conflict with the existing collections dependency, which is 3.2.1) for the "allTags" map to create this combined linked/multivalued map with its decorators.
>>
>> Any thoughts about this? If its ok I'll build it and issue a PR on the current 3.1.0-SNAPSHOT master
>>
>> Best regards,
>>
>> Richard
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Releasing Maven enforcer plugin

Tibor Digana
In reply to this post by Enrico Olivelli
To lookup easy or fast fixes, and +1 to perform a release then.
T

On Wed, Jan 16, 2019 at 1:56 PM Enrico Olivelli <[hidden email]> wrote:

> An user is asking for a release of the enforcer plugin
>
> https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
>
> I can prepare the release
>
> Thoughts?
> Enrico
> --
>
>
> -- Enrico Olivelli
>
Reply | Threaded
Open this post in threaded view
|

Re: Migrating code from m-dependency-tree to m-artifact-transfer (was: Releasing Maven enforcer plugin)

rfscholte
Can you add an exclusion of maven-dependency-tree to the  
extra-enforcer-rules dependency?

thanks,
Robert

On Tue, 22 Jan 2019 18:40:36 +0100, Gabriel Belingueres  
<[hidden email]> wrote:

> Moving the collecting code from m-dependency-tree to m-artifact-transfer
> found a problem:
> I added m-dependency-tree 3.0.1 as a dependency of m-artifact-transfer
> because it has a lot of funcionality useful when using Aether's collect
> (DependencyNode, DefaultDependencyNode, visitors and filters).
> When executing the requireUpperBoundDeps rule on the m-artifact-transfer
> lib, it throws an exception related some classloading issue:
>
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal  
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-SNAPSHOT:enforce
> (enforce-requireUpperBoundDeps) on project maven-artifact-transfer:
> Execution enforce-requireUpperBoundDeps of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-SNAPSHOT:enforce
> failed: An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-SNAPSHOT:enforce:
> java.lang.NoSuchMethodError:
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyNode.<init>(Lorg/apache/maven/shared/dependency/graph/DependencyNode;Lorg/apache/maven/artifact/Artifact;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Boolean;)V
> -----------------------------------------------------
> realm =
> plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-SNAPSHOT
> strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> urls[0] =
> file:/win/productos/repo/org/apache/maven/plugins/maven-enforcer-plugin/3.0.0-SNAPSHOT/maven-enforcer-plugin-3.0.0-SNAPSHOT.jar
> urls[1] =
> file:/win/productos/repo/org/codehaus/mojo/extra-enforcer-rules/1.0-beta-9/extra-enforcer-rules-1.0-beta-9.jar
> urls[2] =
> file:/win/productos/repo/org/apache/maven/shared/maven-dependency-tree/2.1/maven-dependency-tree-2.1.jar
> urls[3] =
> file:/win/productos/repo/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> urls[4] =
> file:/win/productos/repo/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> urls[5] = file:/win/productos/repo/junit/junit/4.11/junit-4.11.jar
> urls[6] =
> file:/win/productos/repo/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
> urls[7] =
> file:/win/productos/repo/commons-codec/commons-codec/1.6/commons-codec-1.6.jar
> urls[8] =
> file:/win/productos/repo/org/apache/maven/shared/maven-common-artifact-filters/3.0.1/maven-common-artifact-filters-3.0.1.jar
> urls[9] =
> file:/win/productos/repo/org/apache/maven/shared/maven-shared-utils/3.1.0/maven-shared-utils-3.1.0.jar
> urls[10] =
> file:/win/productos/repo/commons-io/commons-io/2.5/commons-io-2.5.jar
> urls[11] = file:/win/productos/repo/com/ibm/icu/icu4j/56.1/icu4j-56.1.jar
> urls[12] =
> file:/win/productos/repo/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> urls[13] =
> file:/win/productos/repo/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> urls[14] =
> file:/win/productos/repo/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> urls[15] =
> file:/win/productos/repo/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> urls[16] =
> file:/win/productos/repo/org/codehaus/plexus/plexus-component-annotations/1.7.1/plexus-component-annotations-1.7.1.jar
> urls[17] =
> file:/win/productos/repo/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> urls[18] =
> file:/win/productos/repo/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> urls[19] =
> file:/win/productos/repo/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.jar
> urls[20] =
> file:/win/productos/repo/org/apache/maven/enforcer/enforcer-api/3.0.0-SNAPSHOT/enforcer-api-3.0.0-SNAPSHOT.jar
> urls[21] =
> file:/win/productos/repo/org/apache/maven/enforcer/enforcer-rules/3.0.0-SNAPSHOT/enforcer-rules-3.0.0-SNAPSHOT.jar
> urls[22] =
> file:/win/productos/repo/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar
> urls[23] = file:/win/productos/repo/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> urls[24] =
> file:/win/productos/repo/org/apache/maven/shared/maven-artifact-transfer/0.11.0-SNAPSHOT/maven-artifact-transfer-0.11.0-SNAPSHOT.jar
> Number of foreign imports: 1
> import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
>
> -----------------------------------------------------
>
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
>     at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>     at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native  
> Method)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke (Method.java:564)
>     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: org.apache.maven.plugin.PluginExecutionException: Execution
> enforce-requireUpperBoundDeps of goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-SNAPSHOT:enforce
> failed: An API incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-SNAPSHOT:enforce:
> java.lang.NoSuchMethodError:
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyNode.<init>(Lorg/apache/maven/shared/dependency/graph/DependencyNode;Lorg/apache/maven/artifact/Artifact;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Boolean;)V
>
>
> -----------------------------------------------------
>
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:186)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
>     at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>     at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native  
> Method)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke (Method.java:564)
>     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: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-SNAPSHOT:enforce:
> java.lang.NoSuchMethodError:
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyNode.<init>(Lorg/apache/maven/shared/dependency/graph/DependencyNode;Lorg/apache/maven/artifact/Artifact;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Boolean;)V
> -----------------------------------------------------
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:184)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
>     at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>     at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native  
> Method)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke (Method.java:564)
>     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.NoSuchMethodError:
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyNode.<init>(Lorg/apache/maven/shared/dependency/graph/DependencyNode;Lorg/apache/maven/artifact/Artifact;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/Boolean;)V
>     at
> org.apache.maven.shared.transfer.dependencies.collect.internal.Maven31CollectorResult.buildDependencyNode
> (Maven31CollectorResult.java:121)
>     at
> org.apache.maven.shared.transfer.dependencies.collect.internal.Maven31CollectorResult.getDependencyGraphRoot
> (Maven31CollectorResult.java:100)
>     at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.getNode
> (RequireUpperBoundDeps.java:123)
>     at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.execute
> (RequireUpperBoundDeps.java:149)
>     at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:205)
>     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
>     at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
>     at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
>     at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
>     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>     at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>     at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>     at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>     at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>     at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native  
> Method)
>     at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
>     at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke (Method.java:564)
>     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)
>
>
> Testing in other projects, I found the offending issue is the dependeny  
> to
> m-dependency-tree 2.1 coming from the extra-enforcer-rules additional
> dependency (declared in org.apache.maven:maven-parent:33 parent pom)
>
> Note: when implemented the same functionality in m-dependency-tree
> 3.0.2-SNAPSHOT this problem didn't show (I suppose because
> m-dependency-tree 3.0.2-SNAPSHOT was a direct dependency for enforcer
> plugin?)
>
> Is there some classloading trick I could add so that execution does not
> interfere with m-dependency-tree 2.1?
>
> TIA,
> Gabriel
>
> El jue., 17 de ene. de 2019 a la(s) 14:43, Robert Scholte (
> [hidden email]) escribió:
>
>> Hi Gabriel,
>>
>> I think you missed the message that this code doesn't belong to
>> m-dependency-tree, but to m-artifact-transfer.
>> Would be great if you could move the code.
>>
>> thanks,
>> Robert
>>
>> On Thu, 17 Jan 2019 16:13:15 +0100, Gabriel Belingueres
>> <[hidden email]> wrote:
>>
>> > I've made progress with the m-dependency-tree [1] shared library which
>> > should help unblock some issues in enforcer. It needs review though
>> (and
>> > a
>> > release)
>> >
>> > [1] https://issues.apache.org/jira/browse/MSHARED-788
>> >
>> > El jue., 17 de ene. de 2019 06:25, Tibor Digana  
>> <[hidden email]>
>> > escribió:
>> >
>> >> To lookup easy or fast fixes, and +1 to perform a release then.
>> >> T
>> >>
>> >> On Wed, Jan 16, 2019 at 1:56 PM Enrico Olivelli <[hidden email]>
>> >> wrote:
>> >>
>> >> > An user is asking for a release of the enforcer plugin
>> >> >
>> >> >
>> >>  
>> https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
>> >> >
>> >> > I can prepare the release
>> >> >
>> >> > Thoughts?
>> >> > Enrico
>> >> > --
>> >> >
>> >> >
>> >> > -- Enrico Olivelli
>> >> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]