[ANN] Apache Maven Enforcer Plugin 3.4.1 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Enforcer Plugin, version 3.4.1

This plugin provides goals to control certain environmental constraints
such as Maven version,
JDK version and OS family along with many more built-in rules and user
created rules.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  3.4.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.html


Release Notes - Maven Enforcer Plugin - Version 3.4.1

** Bug
* [MENFORCER-491] - ENFORCER: plugin-info and mojo pages not found

** Improvement
* [MENFORCER-490] - Properly declare dependencies

Enjoy,

-The Apache Maven team

[ANN] Apache Maven Enforcer Plugin 3.4.0 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Enforcer Plugin, version 3.4.0

This plugin provides goals to control certain environmental constraints
such as Maven version, JDK version and OS family
along with many more built-in rules and user created rules.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


 org.apache.maven.plugins
 maven-enforcer-plugin
 3.4.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.html

Release Notes - Maven Enforcer Plugin - Version 3.4.0

** Bug
* [MENFORCER-393] - Upgrading to 3.0.0 causes `Could not build
dependency tree` with repositories some unknown protocol
* [MENFORCER-426] - DependencyConvergence in 3.1.0 fails when using
version ranges
* [MENFORCER-480] - Semantics of `ignores` parameter of
`banDynamicVersions` is inverted
* [MENFORCER-481] - Omission of `excludedScopes` parameter of
`banDynamicVersions` causes NPE

** Improvement
* [MENFORCER-488] - EnforcerLogger: Provide isDebugEnabled(),
isErrorEnabled(), isWarnEnabled() and isInfoEnabled()

** Dependency upgrade
* [MENFORCER-485] - Upgrade Parent to 40
* [MENFORCER-486] - Bump commons-codec from 1.15 to 1.16.0
* [MENFORCER-487] - Bump commons-io from 2.11.0 to 2.13.0
* [MENFORCER-489] - Bump commons-lang3 from 3.12.0 to 3.13.0

Enjoy,

-The Apache Maven team

[ANN] Apache Maven Enforcer Plugin 3.3.0 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Enforcer Plugin, version 3.3.0

This plugin provides goals to control certain environmental constraints
such as Maven version, JDK version and OS family
along with many more built-in rules and user created rules.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  3.3.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.html

Release Notes - Maven Enforcer Plugin - Version 3.3.0

** Bug
* [MENFORCER-466] - RequireUpperBoundDeps fails on provided
dependencies since 3.2.1
* [MENFORCER-467] - Problematic dependency resolution by new
`banDynamicVersions` rule
* [MENFORCER-469] - banTransitiveDependencies: failing if a transitive
dependencies has another version than the resolved one
* [MENFORCER-474] - Filtering dependency tree by scope

** New Feature
* [MENFORCER-276] - Allow ignoring dependency scopes in
RequireUpperBoundDeps
* [MENFORCER-365] - DependencyConvergence rule should support ignoring
some scopes
* [MENFORCER-470] - Configurable scopes for DependencyConvergence rule

** Task
* [MENFORCER-465] - Superfluous blanks in
BanDuplicatePomDependencyVersions
* [MENFORCER-476] - Rename ResolveUtil to ResolverUtil

** Dependency upgrade
* [MENFORCER-471] - Bump plexus-utils from 3.5.0 to 3.5.1
* [MENFORCER-472] - Bump maven-invoker-plugin from 3.4.0 to 3.5.1


Enjoy,

-The Apache Maven team

[ANN] Apache Maven Enforcer Plugin 3.2.1 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Enforcer Plugin, version 3.2.1

This plugin provides goals to control certain environmental constraints
such as Maven version, JDK version and OS family
along with many more built-in rules and user created rules.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  3.2.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.html

Release Notes - Maven Enforcer Plugin - Version 3.2.1

** Bug
* [MENFORCER-378] - requireReleaseDeps does not support optional
dependencies or runtime scope
* [MENFORCER-407] - Enforcer 3.0.0 breaks with Maven 3.8.4
* [MENFORCER-434] - Version 3.1.0 is not enforcing bannedDependencies
rules
* [MENFORCER-437] - DependencyConvergence treats provided dependencies
are runtime dependencies
* [MENFORCER-459] - Plugin shouldn't use NullPointerException for
non-exceptional code flow
* [MENFORCER-461] - NPE in RequirePluginVersions
* [MENFORCER-462] - ReactorModuleConvergence not cached in reactor

** New Feature
* [MENFORCER-397] - allow no rules
* [MENFORCER-398] - show rules processed
* [MENFORCER-411] - DependencyConvergence should support
including/excluding certain dependencies
* [MENFORCER-422] - Support declaring external banned dependencies in
an external file/URL
* [MENFORCER-423] - Maven enforcer rule which checks that all
dependencies have an explicit scope set
* [MENFORCER-424] - Maven enforcer rule which checks that all
dependencies in dependencyManagement don't have an explicit scope set
* [MENFORCER-427] - Rule for no version ranges, version placeholders or
SNAPSHOT versions
* [MENFORCER-430] - Allow one of many files in RequireFiles rules to
pass
* [MENFORCER-431] - Skip specific rules
* [MENFORCER-455] - New Enforcer API
* [MENFORCER-456] - New Enforcer API - RuleConfigProvider
* [MENFORCER-458] - Move Built-In Rules to new API

** Improvement
* [MENFORCER-415] - Violation messages can be really hard to find in a
multi module project
* [MENFORCER-425] - Clarify class loading for custom Enforcer rules
* [MENFORCER-428] - Using junit jupiter bom instead of single artifacts.
* [MENFORCER-435] - Get rid of maven-dependency-tree dependency
* [MENFORCER-440] - Allow 8 as JDK version for requireJavaVersion
* [MENFORCER-444] - Improve error message for rule "requireJavaVersion"
* [MENFORCER-445] - Include Java Home in Message for Java Rule Failures
* [MENFORCER-452] - Manage all Maven Core dependencies as provided
* [MENFORCER-453] - Mange rules configuration by plugin
* [MENFORCER-454] - Deprecate 'rules' property and introduce
'enforcer.rules' as a replacement
* [MENFORCER-463] - Change success message from executed to passed

** Task
* [MENFORCER-447] - Verify working with Maven 4
* [MENFORCER-450] - Code cleanup
* [MENFORCER-451] - Refresh download page
* [MENFORCER-460] - Deprecate display-info mojo
* [MENFORCER-464] - Refresh site descriptors

** Dependency upgrade
* [MENFORCER-429] - Upgrade maven-plugin parent to 37
* [MENFORCER-438] - Upgrade maven-plugin parent to 38
* [MENFORCER-441] - Bump maven-common-artifact-filters from 3.2.0 to
3.3.2
* [MENFORCER-442] - Bump Mockito from 4.6.1 to 4.11.0
* [MENFORCER-443] - Bump junit-bom from 5.9.0 to 5.9.1
* [MENFORCER-446] - Bump plexus-utils from 3.4.2 to 3.5.0
* [MENFORCER-448] - Upgrade parent to version 39
* [MENFORCER-449] - Bump mrm-maven-plugin from 1.3.0 to 1.5.0
* [MENFORCER-457] - Bump assertj-core from 3.23.1 to 3.24.2

Enjoy,

-The Apache Maven team

[ANN] Apache Maven Enforcer Plugin 3.1.0 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Enforcer Plugin, version 3.1.0

This plugin provides goals to control certain environmental constraints
such as Maven version, JDK version and OS family
along with many more built-in rules and user created rules.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  3.1.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.cgi

Release Notes - Maven Enforcer Plugin - Version 3.1.0

** Bug
* [MENFORCER-389] - Exclusions are not considered when looking at
parent for requireReleaseDeps
* [MENFORCER-391] - requireUpperBoundDeps does not fail when packaging
is 'war'
* [MENFORCER-394] - DependencyConvergence in 3.0.0 fails on provided
scoped dependencies
* [MENFORCER-395] - NPE on requireReleaseDeps with non-matching includes
* [MENFORCER-402] - RequireUpperBoundDeps now follow scope provided
transitive dependencies
* [MENFORCER-421] - Use currently build artifacts in IT tests

** Improvement
* [MENFORCER-404] - Shared GitHub Actions
* [MENFORCER-409] - Log at ERROR level when  is set
* [MENFORCER-420] - Reuse getDependenciesToCheck results across rules

** Dependency upgrade
* [MENFORCER-372] - Switch to JUnit5
* [MENFORCER-403] - Upgrade aether-util > maven-core > enforcer
* [MENFORCER-418] - Upgrade Parent to 36
* [MENFORCER-419] - Upgrade Maven to 3.2.5

Enjoy,

-The Apache Maven team

[Enforcer plugin] Snapshot update of currently analyzed module

[Alexis Manin]

Hello,

I've got a question regarding the Maven Enforcer Plugin.

There is a behaviour I do not fully understand with the dependency
convergence rule.

When the enforcer plugin launches, it tries to download the
maven-metadata.xml of the module it tries to enforce. I would expect
it to download snapshot updates for dependencies, but not for the
current module.

I have created a minimal reproducible example here :

https://github.com/alexismanin/enforcer-test

The project uses a single repository with snapshot update policy set
to always, and we can see that enforcer always tries to download the
maven-metadata of the currently analyzed project, as shown in the
sample output of my build below:

```output

[INFO] --< com.geomatys.debug:enforcer-test >--
[INFO] Building Enforcer test 1.0-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce) @ enforcer-test ---
Downloading from spring.releases:
https://nexus.geomatys.com/repository/maven-public/com/geomatys/debug/enforcer-test/1.0-SNAPSHOT/maven-metadata.xml

```

Is there a configuration available at the Enforcer level, to force it
to ignore snapshot update of current module ?
If not, could it be added in the future ?
Last question : is it wanted to download the maven-metadata of the
current module ? If yes, why is it ? What purpose does it serve ?

Thanks for your time,

P.S: Do you want me to create a JIRA issue for this ?

-- 
Alexis Manin,
Développeur JAVA/JEE.
Geomatys.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven enforcer plugin regarding child module's groupId

[Matt Benson]

At that rate, they can also disable the execution of said enforcer rule.

Matt

On Tue, Aug 31, 2021, 10:31 AM David Hoffer  wrote:

> They can delete/change/not do that.   I'd like to put the rule in a parent
> POM that enforces in a way that can't easily be removed.
>
> -Dave
>
> On Tue, Aug 31, 2021 at 8:41 AM Delany  wrote:
>
> > Instead of policing deviations with a rule, why not make this possible at
> > the outset?
> >
> > ${project.parent.groupId}.${project.parent.artifactId}
> >
> > Delany
> >
> >
> > On Tue, 31 Aug 2021 at 16:29, David Hoffer  wrote:
> >
> > > I'd love to see that added to the included rules in the enforcer
> plugin.
> > >
> > > -Dave
> > >
> > > On Tue, Aug 31, 2021 at 6:53 AM Matt Benson 
> wrote:
> > >
> > > > On Tue, Aug 31, 2021, 3:28 AM Delany 
> > wrote:
> > > >
> > > > > Good question. There seems no way to do this dynamically in Maven
> 3.x
> > > > > Delany
> > > > >
> > > > > On Mon, 30 Aug 2021 at 20:45, David Hoffer 
> > wrote:
> > > > >
> > > > > > How to enforce that child modules append to the parent groupId
> per
> > > the
> > > > > > Maven
> > > > > > Guide to Naming Conventions
> > > > > > <
> http://maven.apache.org/guides/mini/guide-naming-conventions.html
> > >
> > > ?
> > > > > >
> > > > >
> > > >
> > > > It would seem that writing a custom enforcer rule to do this would be
> > > > trivial.
> > > >
> > > > Matt
> > > >
> > > >
> > > > > -Dave
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Maven enforcer plugin regarding child module's groupId

[David Hoffer]

They can delete/change/not do that.   I'd like to put the rule in a parent
POM that enforces in a way that can't easily be removed.

-Dave

On Tue, Aug 31, 2021 at 8:41 AM Delany  wrote:

> Instead of policing deviations with a rule, why not make this possible at
> the outset?
>
> ${project.parent.groupId}.${project.parent.artifactId}
>
> Delany
>
>
> On Tue, 31 Aug 2021 at 16:29, David Hoffer  wrote:
>
> > I'd love to see that added to the included rules in the enforcer plugin.
> >
> > -Dave
> >
> > On Tue, Aug 31, 2021 at 6:53 AM Matt Benson  wrote:
> >
> > > On Tue, Aug 31, 2021, 3:28 AM Delany 
> wrote:
> > >
> > > > Good question. There seems no way to do this dynamically in Maven 3.x
> > > > Delany
> > > >
> > > > On Mon, 30 Aug 2021 at 20:45, David Hoffer 
> wrote:
> > > >
> > > > > How to enforce that child modules append to the parent groupId per
> > the
> > > > > Maven
> > > > > Guide to Naming Conventions
> > > > > <http://maven.apache.org/guides/mini/guide-naming-conventions.html
> >
> > ?
> > > > >
> > > >
> > >
> > > It would seem that writing a custom enforcer rule to do this would be
> > > trivial.
> > >
> > > Matt
> > >
> > >
> > > > -Dave
> > > > >
> > > >
> > >
> >
>

Re: Maven enforcer plugin regarding child module's groupId

[Delany]

Instead of policing deviations with a rule, why not make this possible at
the outset?

${project.parent.groupId}.${project.parent.artifactId}

Delany


On Tue, 31 Aug 2021 at 16:29, David Hoffer  wrote:

> I'd love to see that added to the included rules in the enforcer plugin.
>
> -Dave
>
> On Tue, Aug 31, 2021 at 6:53 AM Matt Benson  wrote:
>
> > On Tue, Aug 31, 2021, 3:28 AM Delany  wrote:
> >
> > > Good question. There seems no way to do this dynamically in Maven 3.x
> > > Delany
> > >
> > > On Mon, 30 Aug 2021 at 20:45, David Hoffer  wrote:
> > >
> > > > How to enforce that child modules append to the parent groupId per
> the
> > > > Maven
> > > > Guide to Naming Conventions
> > > > <http://maven.apache.org/guides/mini/guide-naming-conventions.html>
> ?
> > > >
> > >
> >
> > It would seem that writing a custom enforcer rule to do this would be
> > trivial.
> >
> > Matt
> >
> >
> > > -Dave
> > > >
> > >
> >
>

Re: Maven enforcer plugin regarding child module's groupId

[David Hoffer]

I'd love to see that added to the included rules in the enforcer plugin.

-Dave

On Tue, Aug 31, 2021 at 6:53 AM Matt Benson  wrote:

> On Tue, Aug 31, 2021, 3:28 AM Delany  wrote:
>
> > Good question. There seems no way to do this dynamically in Maven 3.x
> > Delany
> >
> > On Mon, 30 Aug 2021 at 20:45, David Hoffer  wrote:
> >
> > > How to enforce that child modules append to the parent groupId per the
> > > Maven
> > > Guide to Naming Conventions
> > > <http://maven.apache.org/guides/mini/guide-naming-conventions.html>  ?
> > >
> >
>
> It would seem that writing a custom enforcer rule to do this would be
> trivial.
>
> Matt
>
>
> > -Dave
> > >
> >
>

Re: Maven enforcer plugin regarding child module's groupId

[Matt Benson]

On Tue, Aug 31, 2021, 3:28 AM Delany  wrote:

> Good question. There seems no way to do this dynamically in Maven 3.x
> Delany
>
> On Mon, 30 Aug 2021 at 20:45, David Hoffer  wrote:
>
> > How to enforce that child modules append to the parent groupId per the
> > Maven
> > Guide to Naming Conventions
> >   ?
> >
>

It would seem that writing a custom enforcer rule to do this would be
trivial.

Matt


> -Dave
> >
>

Re: Maven enforcer plugin regarding child module's groupId

[Delany]

Good question. There seems no way to do this dynamically in Maven 3.x
Delany

On Mon, 30 Aug 2021 at 20:45, David Hoffer  wrote:

> How to enforce that child modules append to the parent groupId per the
> Maven
> Guide to Naming Conventions
>   ?
>
> -Dave
>

Maven enforcer plugin regarding child module's groupId

[David Hoffer]

How to enforce that child modules append to the parent groupId per the Maven
Guide to Naming Conventions
  ?

-Dave

[Enforcer Plugin] DependencyConvergence of a "provided" deendency?

[Niels Basjes]

Hi,

I ran into a significant difference between maven-enforcer-plugin
versions 3.0.0-M3 and 3.0.0 in the way "provided" dependencies are handled.
I'm wondering if this is intended (and I would like to understand why) or a
regression which should be reported.

I have several projects (reusable libraries) where I have optional support
for Kryo ( https://github.com/EsotericSoftware/kryo ) which is a
serialization system that is sometimes needed.

In my library (LIB-1) I have Kyro code that is only reached IFF kryo is
present (via Annotations) and something like this in my pom.xml file.


  com.esotericsoftware
  kryo
  5.0.0
  provided


In a second library (LIB-2) I have two dependencies: LIB-1 and a different
version of Kryo in essentially the same way.


  com.esotericsoftware
  kryo
  5.1.1/version>
  provided



In the pom.xml of the LIB-2 I have this

  
 

  org.apache.maven.plugins
      maven-enforcer-plugin

  3.0.0
  

  dependency-convergence
  validate
  
enforce
  
  

  

  

  

  
  



If I run this plugin with version 3.0.0-M3 it all passes and finds these
dependencies correct.
With version 3.0.0 my build now fails with:

[WARNING]
Dependency convergence error for
com.esotericsoftware:kryo:jar:5.0.0:provided paths to dependency are:
+-com.example.application:myapp:jar:1.0-SNAPSHOT
  +-nl.example.library:mylib:jar:1.0-SNAPSHOT:compile
+-com.esotericsoftware:kryo:jar:5.0.0:provided
and
+-com.example.application:myapp:jar:1.0-SNAPSHOT
  +-com.esotericsoftware:kryo:jar:5.1.1:provided


I would love to understand.
Thanks.

-- 
Best regards / Met vriendelijke groeten,

Niels Basjes

Re: [ANN] Apache Maven Enforcer Plugin + Extension 3.0.0 Released

[Delany]

See
https://github.com/mojohaus/extra-enforcer-rules/issues/131#issuecomment-890329715

On Sun, 1 Aug 2021, 05:34 Alexander Kriegisch, 
wrote:

> It looks like class EnforceBytecodeVersion is part of
> org.codehaus.mojo:extra-enforcer-rules:1.3 which is a dependency in my
> Enforcer plugin configuration. Is that extension no longer compatible
> with Enforcer? Or has it been replaced by something else, which I am
> unaware of? Like I said, in M3 it was still working.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Alexander Kriegisch schrieb am 01.08.2021 10:16 (GMT +07:00):
>
> > In a GitHub project, Dependabot suggested an update from 3.0.0-M3 to
> > 3.0.0, but all CI builds fail with this error message:
> >
> > Failed to execute goal
> > org.apache.maven.plugins:maven-enforcer-plugin:3.0.0:enforce
> > (enforce-bytecode-version) on project x:
> >   Unable to parse configuration of mojo (...)
> >   for parameter enforceBytecodeVersion:
> > Cannot create instance of class
> > org.apache.maven.plugins.enforcer.EnforceBytecodeVersion:
> >
>  org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException:
> > (...)
> >
> > In the release notes, I do not see any reference to that rule having
> > been removed between M3 and final release. Is there some other dependent
> > component which needs to be upgraded? Maybe I need to override some
> > dependency-managed component from a parent POM.
> >
> > Thanks in advance for your insights.
> >
> >
> > Robert Scholte schrieb am 30.07.2021 16:46 (GMT +07:00):
> >
> >> The Apache Maven team is pleased to announce the release of the Apache
> Maven
> >> Enforcer Plugin and Extension, version 3.0.0
> >>
> >> The Enforcer plugin is the Loving Iron Fist of Maven and provides goals
> to
> >> control certain environmental constraints such as Maven version, JDK
> version
> >> and OS family along with many more built-in rules and user created
> rules.
> >>
> >> https://maven.apache.org/enforcer/maven-enforcer-plugin/
> >>
> >> You should specify the version in your project's plugin configuration:
> >>
> >> 
> >> org.apache.maven.plugins
> >> maven-enforcer-plugin
> >> 3.0.0
> >> 
> >>
> >> You can download the appropriate sources etc. from the download page:
> >>
> >> https://maven.apache.org/enforcer/download.html
> >>
> >>
> >> Release Notes - Maven Enforcer Plugin - Version 3.0.0
> >>
> >> ** Bug
> >>
> >> * [MENFORCER-168] - In a multi module project "bannedDependencies"
> rule
> >> tries to resolve project artifacts from external repository
> >> * [MENFORCER-185] - Require Release Dependencies ignorant about
> >> aggregator build
> >> * [MENFORCER-301] - banDuplicatePomDependencyVersions does not check
> >> managementDependencies
> >> * [MENFORCER-336] - Beanshell rule is not thread-safe
> >> * [MENFORCER-346] - RequireSnapshotVersion not compatible with CI
> >> Friendly Versions (${revision})
> >> * [MENFORCER-351] - NPE when using new  syntax with
> >> maven-enforcer-plugin
> >> * [MENFORCER-352] - Broken links on Maven Enforcer Plugin site
> >> * [MENFORCER-357] - RequirePluginVersions not recognizing
> >> versions-from-properties
> >> * [MENFORCER-359] - [REGRESSION] RequirePluginVersions fails when
> >> versions are inherited
> >> * [MENFORCER-364] - requireFilesExist rule should be case sensitive
> >> * [MENFORCER-366] - Broken Links on Project Home Page
> >> * [MENFORCER-373] - TestRequireOS uses hamcrest via transitive
> >> dependency
> >> * [MENFORCER-374] - plexus-container-default in enforcer-api is very
> >> outdated
> >> * [MENFORCER-381] - classifier not included in output of failed
> >> RequireUpperBoundDeps test
> >>
> >> ** New Feature
> >> * [MENFORCER-358] - requireUpperBounds deps should have includes
> >> * [MENFORCER-361] - Introduce RequireTextFileChecksum with line
> >> separator
> >> normalization
> >>
> >> ** Improvement
> >> * [MENFORCER-211] - wildcard ignore in requireReleaseDeps
> >> * [MENFORCER-245] - Improve documentation about writing own Enforcer
> >> Rule
> >> * [MENFORCER-257] - RequireActiveProfile should respect inherited
> >> activated profiles
> >> 

Re: [ANN] Apache Maven Enforcer Plugin + Extension 3.0.0 Released

[Alexander Kriegisch]

It looks like class EnforceBytecodeVersion is part of
org.codehaus.mojo:extra-enforcer-rules:1.3 which is a dependency in my
Enforcer plugin configuration. Is that extension no longer compatible
with Enforcer? Or has it been replaced by something else, which I am
unaware of? Like I said, in M3 it was still working.

-- 
Alexander Kriegisch
https://scrum-master.de


Alexander Kriegisch schrieb am 01.08.2021 10:16 (GMT +07:00):

> In a GitHub project, Dependabot suggested an update from 3.0.0-M3 to
> 3.0.0, but all CI builds fail with this error message:
> 
> Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0:enforce
> (enforce-bytecode-version) on project x:
>   Unable to parse configuration of mojo (...)
>   for parameter enforceBytecodeVersion:
> Cannot create instance of class
> org.apache.maven.plugins.enforcer.EnforceBytecodeVersion:
> org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException:
> (...)
> 
> In the release notes, I do not see any reference to that rule having
> been removed between M3 and final release. Is there some other dependent
> component which needs to be upgraded? Maybe I need to override some
> dependency-managed component from a parent POM.
> 
> Thanks in advance for your insights.
> 
> 
> Robert Scholte schrieb am 30.07.2021 16:46 (GMT +07:00):
> 
>> The Apache Maven team is pleased to announce the release of the Apache Maven
>> Enforcer Plugin and Extension, version 3.0.0
>> 
>> The Enforcer plugin is the Loving Iron Fist of Maven and provides goals to
>> control certain environmental constraints such as Maven version, JDK version
>> and OS family along with many more built-in rules and user created rules.
>> 
>> https://maven.apache.org/enforcer/maven-enforcer-plugin/
>> 
>> You should specify the version in your project's plugin configuration:
>> 
>> 
>> org.apache.maven.plugins
>> maven-enforcer-plugin
>> 3.0.0
>> 
>> 
>> You can download the appropriate sources etc. from the download page:
>> 
>> https://maven.apache.org/enforcer/download.html
>> 
>> 
>> Release Notes - Maven Enforcer Plugin - Version 3.0.0
>> 
>> ** Bug
>> 
>>     * [MENFORCER-168] - In a multi module project "bannedDependencies" rule
>> tries to resolve project artifacts from external repository
>>     * [MENFORCER-185] - Require Release Dependencies ignorant about
>> aggregator build
>>     * [MENFORCER-301] - banDuplicatePomDependencyVersions does not check
>> managementDependencies
>>     * [MENFORCER-336] - Beanshell rule is not thread-safe
>>     * [MENFORCER-346] - RequireSnapshotVersion not compatible with CI
>> Friendly Versions (${revision})
>>     * [MENFORCER-351] - NPE when using new  syntax with
>> maven-enforcer-plugin
>>     * [MENFORCER-352] - Broken links on Maven Enforcer Plugin site
>>     * [MENFORCER-357] - RequirePluginVersions not recognizing
>> versions-from-properties
>>     * [MENFORCER-359] - [REGRESSION] RequirePluginVersions fails when
>> versions are inherited
>>     * [MENFORCER-364] - requireFilesExist rule should be case sensitive
>>     * [MENFORCER-366] - Broken Links on Project Home Page
>>     * [MENFORCER-373] - TestRequireOS uses hamcrest via transitive
>> dependency
>>     * [MENFORCER-374] - plexus-container-default in enforcer-api is very
>> outdated
>>     * [MENFORCER-381] - classifier not included in output of failed
>> RequireUpperBoundDeps test
>> 
>> ** New Feature
>>     * [MENFORCER-358] - requireUpperBounds deps should have includes
>>     * [MENFORCER-361] - Introduce RequireTextFileChecksum with line
>> separator
>> normalization
>> 
>> ** Improvement
>>     * [MENFORCER-211] - wildcard ignore in requireReleaseDeps
>>     * [MENFORCER-245] - Improve documentation about writing own Enforcer
>> Rule
>>     * [MENFORCER-257] - RequireActiveProfile should respect inherited
>> activated profiles
>>     * [MENFORCER-277] - Upgrade maven-dependency-tree to 3.x
>>     * [MENFORCER-304] - Improve dependency resolving in multiple modules
>> project
>>     * [MENFORCER-313] - requireUpperBoundDeps: add [] and colors to
>> the output
>>     * [MENFORCER-329] - Example for writing a custom rule should be upgraded
>>     * [MENFORCER-338] - Along with JavaVersion, allow enforcement of the
>> JavaVendor
>>     * [MENFORCER-349] - Include Java vendor in display-info output
>>     * [MENFORCER-350] - requireMavenVersion x.y.z is processed as (,x.y.z]
>> instead of [x.y.z,)
>>     * [MENFOR

Re: [ANN] Apache Maven Enforcer Plugin + Extension 3.0.0 Released

[Alexander Kriegisch]

In a GitHub project, Dependabot suggested an update from 3.0.0-M3 to
3.0.0, but all CI builds fail with this error message:

Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0:enforce
(enforce-bytecode-version) on project x:
  Unable to parse configuration of mojo (...)
  for parameter enforceBytecodeVersion:
Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion:
org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException:
(...)

In the release notes, I do not see any reference to that rule having
been removed between M3 and final release. Is there some other dependent
component which needs to be upgraded? Maybe I need to override some
dependency-managed component from a parent POM.

Thanks in advance for your insights.

-- 
Alexander Kriegisch
https://scrum-master.de


Robert Scholte schrieb am 30.07.2021 16:46 (GMT +07:00):

> The Apache Maven team is pleased to announce the release of the Apache Maven
> Enforcer Plugin and Extension, version 3.0.0
> 
> The Enforcer plugin is the Loving Iron Fist of Maven and provides goals to
> control certain environmental constraints such as Maven version, JDK version
> and OS family along with many more built-in rules and user created rules.
> 
> https://maven.apache.org/enforcer/maven-enforcer-plugin/
> 
> You should specify the version in your project's plugin configuration:
> 
> 
> org.apache.maven.plugins
> maven-enforcer-plugin
> 3.0.0
> 
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/enforcer/download.html
> 
> 
> Release Notes - Maven Enforcer Plugin - Version 3.0.0
> 
> ** Bug
> 
>     * [MENFORCER-168] - In a multi module project "bannedDependencies" rule
> tries to resolve project artifacts from external repository
>     * [MENFORCER-185] - Require Release Dependencies ignorant about
> aggregator build
>     * [MENFORCER-301] - banDuplicatePomDependencyVersions does not check
> managementDependencies
>     * [MENFORCER-336] - Beanshell rule is not thread-safe
>     * [MENFORCER-346] - RequireSnapshotVersion not compatible with CI
> Friendly Versions (${revision})
>     * [MENFORCER-351] - NPE when using new  syntax with
> maven-enforcer-plugin
>     * [MENFORCER-352] - Broken links on Maven Enforcer Plugin site
>     * [MENFORCER-357] - RequirePluginVersions not recognizing
> versions-from-properties
>     * [MENFORCER-359] - [REGRESSION] RequirePluginVersions fails when
> versions are inherited
>     * [MENFORCER-364] - requireFilesExist rule should be case sensitive
>     * [MENFORCER-366] - Broken Links on Project Home Page
>     * [MENFORCER-373] - TestRequireOS uses hamcrest via transitive dependency
>     * [MENFORCER-374] - plexus-container-default in enforcer-api is very
> outdated
>     * [MENFORCER-381] - classifier not included in output of failed
> RequireUpperBoundDeps test
> 
> ** New Feature
>     * [MENFORCER-358] - requireUpperBounds deps should have includes
>     * [MENFORCER-361] - Introduce RequireTextFileChecksum with line separator
> normalization
> 
> ** Improvement
>     * [MENFORCER-211] - wildcard ignore in requireReleaseDeps
>     * [MENFORCER-245] - Improve documentation about writing own Enforcer Rule
>     * [MENFORCER-257] - RequireActiveProfile should respect inherited
> activated profiles
>     * [MENFORCER-277] - Upgrade maven-dependency-tree to 3.x
>     * [MENFORCER-304] - Improve dependency resolving in multiple modules
> project
>     * [MENFORCER-313] - requireUpperBoundDeps: add [] and colors to
> the output
>     * [MENFORCER-329] - Example for writing a custom rule should be upgraded
>     * [MENFORCER-338] - Along with JavaVersion, allow enforcement of the
> JavaVendor
>     * [MENFORCER-349] - Include Java vendor in display-info output
>     * [MENFORCER-350] - requireMavenVersion x.y.z is processed as (,x.y.z]
> instead of [x.y.z,)
>     * [MENFORCER-353] - Consistently format artifacts same as dependency:tree
>     * [MENFORCER-355] - make build Reproducible
>     * [MENFORCER-376] - Add support for excludes/includes in
> requireJavaVendor rule
>     * [MENFORCER-384] - Introduce Maven Enforcer Extension
>     * [MENFORCER-388] - Extends RequirePluginVersions with banMavenDefaults
> 
> ** Task
>     * [MENFORCER-377] - Remove reference to travis or switch to travis.com
>     * [MENFORCER-380] - Fix maven assembly links
>     * [MENFORCER-387] - Require Java 8
> 
> ** Dependency upgrade
>     * [MENFORCER-267] - Upgrade to make Maven 3.1+
>     * [MENFORCER-371] - Require Maven 3.1.1
>     * [MENFORCER-379] - Update maven-common-artifact-filters to 3.2.0
> 
> Note: Thanks to all t

[ANN] Apache Maven Enforcer Plugin + Extension 3.0.0 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Enforcer Plugin and Extension, version 3.0.0

The Enforcer plugin is the Loving Iron Fist of Maven and provides goals to 
control certain environmental constraints such as Maven version, JDK version 
and OS family along with many more built-in rules and user created rules.

https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-enforcer-plugin
3.0.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.html


Release Notes - Maven Enforcer Plugin - Version 3.0.0

** Bug

    * [MENFORCER-168] - In a multi module project "bannedDependencies" rule 
tries to resolve project artifacts from external repository
    * [MENFORCER-185] - Require Release Dependencies ignorant about aggregator 
build
    * [MENFORCER-301] - banDuplicatePomDependencyVersions does not check 
managementDependencies
    * [MENFORCER-336] - Beanshell rule is not thread-safe
    * [MENFORCER-346] - RequireSnapshotVersion not compatible with CI Friendly 
Versions (${revision})
    * [MENFORCER-351] - NPE when using new  syntax with 
maven-enforcer-plugin
    * [MENFORCER-352] - Broken links on Maven Enforcer Plugin site
    * [MENFORCER-357] - RequirePluginVersions not recognizing 
versions-from-properties
    * [MENFORCER-359] - [REGRESSION] RequirePluginVersions fails when versions 
are inherited
    * [MENFORCER-364] - requireFilesExist rule should be case sensitive
    * [MENFORCER-366] - Broken Links on Project Home Page
    * [MENFORCER-373] - TestRequireOS uses hamcrest via transitive dependency
    * [MENFORCER-374] - plexus-container-default in enforcer-api is very 
outdated
    * [MENFORCER-381] - classifier not included in output of failed 
RequireUpperBoundDeps test

** New Feature
    * [MENFORCER-358] - requireUpperBounds deps should have includes
    * [MENFORCER-361] - Introduce RequireTextFileChecksum with line separator 
normalization

** Improvement
    * [MENFORCER-211] - wildcard ignore in requireReleaseDeps
    * [MENFORCER-245] - Improve documentation about writing own Enforcer Rule
    * [MENFORCER-257] - RequireActiveProfile should respect inherited activated 
profiles
    * [MENFORCER-277] - Upgrade maven-dependency-tree to 3.x
    * [MENFORCER-304] - Improve dependency resolving in multiple modules project
    * [MENFORCER-313] - requireUpperBoundDeps: add [] and colors to the 
output
    * [MENFORCER-329] - Example for writing a custom rule should be upgraded
    * [MENFORCER-338] - Along with JavaVersion, allow enforcement of the 
JavaVendor
    * [MENFORCER-349] - Include Java vendor in display-info output
    * [MENFORCER-350] - requireMavenVersion x.y.z is processed as (,x.y.z] 
instead of [x.y.z,)
    * [MENFORCER-353] - Consistently format artifacts same as dependency:tree
    * [MENFORCER-355] - make build Reproducible
    * [MENFORCER-376] - Add support for excludes/includes in requireJavaVendor 
rule
    * [MENFORCER-384] - Introduce Maven Enforcer Extension
    * [MENFORCER-388] - Extends RequirePluginVersions with banMavenDefaults

** Task
    * [MENFORCER-377] - Remove reference to travis or switch to travis.com
    * [MENFORCER-380] - Fix maven assembly links
    * [MENFORCER-387] - Require Java 8

** Dependency upgrade
    * [MENFORCER-267] - Upgrade to make Maven 3.1+
    * [MENFORCER-371] - Require Maven 3.1.1
    * [MENFORCER-379] - Update maven-common-artifact-filters to 3.2.0

Note: Thanks to all the individual contributors and OpenValue: they've provided 
several PR during an Open Source Contribution Training Day. 

Enjoy,

-The Apache Maven team

Re: maven enforcer plugin questions

[Tomo Suzuki]

>  though the changes were innocuous

In such case, usually run “mvn help:effective-pom“ to figure out the
difference.

In my experience, enforcer rules (requireUpperBounds,
dependencyConvergence) are deterministic and reliable. Would you be willing
to share a minimum reproducible project as a Github repository? I‘m
interested in 2 enforcer rule invocations show different results.

Regards,
Tomo

On Sat, Dec 5, 2020 at 13:43 Andrew Marlow  wrote:

> hi,
>
> Thank you Bernd for answering my question. I didn't know about the
> dedicated mailing list. However, when I go to
> https://maven.apache.org/enforcer/maven-enforcer-plugin/ and see the link
> to https://maven.apache.org/enforcer/maven-enforcer-plugin/mail-lists.html
> I find that link is broken, so I will ask the question here.
>
> I have introduced the enforcer to the project I am working on and have
> found it very useful. However I have just been compelled to abandon it
> which I do with great reluctance.   Upon the merging in of some pom changes
> the enforcer started to change what it had been reporting even though the
> changes were innocuous. There were no dependency changes. Furthermore, it
> started to not report on convergence errors that it previously did report.
> I run the enforcer via a python script that runs the enforcer, capturing
> the output into a logfile. It then analyses the logfile to find where the
> convergence errors are and reports on those which are not in an exemption
> list that the script has. When this started happening in some of our
> jenkins jobs I ran the same commands that the jobs uses and I got different
> results. I was also able to get a third result that was different to the
> other two by running the same command but with specifying my own maven
> local repo cache via the -Dmaven.local.repo option. So I was forced to come
> to the conclusion that the enforcer is unreliable. I would be interested to
> hear what use other developers make of the enforcer and what their
> experiences are.
>
> On Sat, 5 Dec 2020 at 17:18, Bernd Eckenfels 
> wrote:
>
> > Hello,
> >
> > Yes. this list can be used to reach users of maven, including maven
> > plugins like the enforcer plugin (a official plugin has the name
> > maven-something-plugin and is hosted on the Maven web site like
> > https://maven.apache.org/enforcer/maven-enforcer-plugin/).
> >
> > But even if it where a third party plugin, it is fine to discuss them
> here
> > with other users.
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Andrew Marlow 
> > Gesendet: Saturday, December 5, 2020 1:01:35 PM
> > An: users@maven.apache.org 
> > Betreff: maven enforcer plugin questions
> >
> > Hello everyone,
> >
> > excuse me, is this the right place to discuss questions about the maven
> > enforcer plugin please?
> >
> > --
> > Regards,
> >
> > Andrew Marlow
> > http://www.andrewpetermarlow.co.uk
> >
>
>
> --
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>
-- 
Regards,
Tomo

Re: maven enforcer plugin questions

[Andrew Marlow]

hi,

Thank you Bernd for answering my question. I didn't know about the
dedicated mailing list. However, when I go to
https://maven.apache.org/enforcer/maven-enforcer-plugin/ and see the link
to https://maven.apache.org/enforcer/maven-enforcer-plugin/mail-lists.html
I find that link is broken, so I will ask the question here.

I have introduced the enforcer to the project I am working on and have
found it very useful. However I have just been compelled to abandon it
which I do with great reluctance.   Upon the merging in of some pom changes
the enforcer started to change what it had been reporting even though the
changes were innocuous. There were no dependency changes. Furthermore, it
started to not report on convergence errors that it previously did report.
I run the enforcer via a python script that runs the enforcer, capturing
the output into a logfile. It then analyses the logfile to find where the
convergence errors are and reports on those which are not in an exemption
list that the script has. When this started happening in some of our
jenkins jobs I ran the same commands that the jobs uses and I got different
results. I was also able to get a third result that was different to the
other two by running the same command but with specifying my own maven
local repo cache via the -Dmaven.local.repo option. So I was forced to come
to the conclusion that the enforcer is unreliable. I would be interested to
hear what use other developers make of the enforcer and what their
experiences are.

On Sat, 5 Dec 2020 at 17:18, Bernd Eckenfels  wrote:

> Hello,
>
> Yes. this list can be used to reach users of maven, including maven
> plugins like the enforcer plugin (a official plugin has the name
> maven-something-plugin and is hosted on the Maven web site like
> https://maven.apache.org/enforcer/maven-enforcer-plugin/).
>
> But even if it where a third party plugin, it is fine to discuss them here
> with other users.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Andrew Marlow 
> Gesendet: Saturday, December 5, 2020 1:01:35 PM
> An: users@maven.apache.org 
> Betreff: maven enforcer plugin questions
>
> Hello everyone,
>
> excuse me, is this the right place to discuss questions about the maven
> enforcer plugin please?
>
> --
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>


-- 
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

Re: maven enforcer plugin questions

[Bernd Eckenfels]

Hello,

Yes. this list can be used to reach users of maven, including maven plugins 
like the enforcer plugin (a official plugin has the name maven-something-plugin 
and is hosted on the Maven web site like 
https://maven.apache.org/enforcer/maven-enforcer-plugin/).

But even if it where a third party plugin, it is fine to discuss them here with 
other users.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Andrew Marlow 
Gesendet: Saturday, December 5, 2020 1:01:35 PM
An: users@maven.apache.org 
Betreff: maven enforcer plugin questions

Hello everyone,

excuse me, is this the right place to discuss questions about the maven
enforcer plugin please?

--
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

maven enforcer plugin questions

[Andrew Marlow]

Hello everyone,

excuse me, is this the right place to discuss questions about the maven
enforcer plugin please?

-- 
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

Re: Maven enforcer plugin failing with maven 3.6.1 but passing with maven 3.6.3

[Debraj Manna]

This has been answered in stackoverflow
<https://stackoverflow.com/questions/63644201/why-is-maven-enforcer-plugin-failing-with-maven-version-3-6-1-but-passing-with-3>


https://stackoverflow.com/questions/63644201/why-is-maven-enforcer-plugin-failing-with-maven-version-3-6-1-but-passing-with-3

On Sat, Aug 29, 2020 at 6:37 PM Debraj Manna 
wrote:

> I am observing the same behavior with maven docker also. It is passing
> with 3.6.3 but failing with 3.6.1.
>
> Used the below commands
>
> Debrajs-MacBook-Air:es-plugins debrajmanna$ docker run -it --rm --name
> es-plugins -v "$(pwd)":/Users/debrajmanna/code/vnera/es-plugins -w
> /Users/debrajmanna/code/vnera/es-plugins maven:3.6.1 mvn validate
>
> Debrajs-MacBook-Air:es-plugins debrajmanna$ docker run -it --rm --name
> es-plugins -v "$(pwd)":/Users/debrajmanna/code/vnera/es-plugins -w
> /Users/debrajmanna/code/vnera/es-plugins maven:3.6.3 mvn validate
>
> On Sat, Aug 29, 2020 at 5:32 PM Debraj Manna 
> wrote:
>
>> It is failing consistently in our environment. Can you let me know what
>> can cause this difference in behavior?
>>
>> Any other log I can provide that may help in debugging this issue further?
>>
>> On Sat, Aug 29, 2020 at 4:45 PM Karl Heinz Marbaise 
>> wrote:
>>
>>> Hi,
>>>
>>> as already mentioned on SO the behaviour can't be reproduced with the
>>> example project.
>>>
>>> Tested with Maven 3.6.0, 3.6.1, 3.6.2 and 3.6.3...
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>> On 29.08.20 08:34, Debraj Manna wrote:
>>> > Hi
>>> >
>>> > In one of my project I am trying to use DependencyConvergence rule with
>>> > maven enforcer plugin. I am observing that if I use maven 3.6.1 then
>>> the
>>> > enforcer is failing with the below error but the same has been working
>>> fine
>>> > with maven 3.6.3. Can someone let me know if this expected? If yes can
>>> > someone point me to the relevant jira under which this issue is fixed
>>> in
>>> > maven 3.6.3.
>>> >
>>> > I have placed a sample project in
>>> https://github.com/debraj-manna/es-plugins
>>> > where this issue can be reproduced.
>>> >
>>> > maven-enforcer-plugin - 3.0.0-M2
>>> >
>>> > Debrajs-MacBook-Air:es-plugins debrajmanna$
>>> > ~/Downloads/apache-maven-3.6.1/bin/mvn validate
>>> > [INFO] Scanning for projects...
>>> > [INFO]
>>> >
>>> --------
>>> > [INFO] Reactor Build Order:
>>> > [INFO]
>>> > [INFO] es-plugins
>>> > [pom]
>>> > [INFO] dedup
>>> >   [jar]
>>> > [INFO]
>>> > [INFO] ---< org.example:es-plugins
>>> >> ---
>>> > [INFO] Building es-plugins 1.0-SNAPSHOT
>>> > [1/2]
>>> > [INFO] [ pom
>>> > ]-
>>> > [INFO]
>>> > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
>>> > (javaversion-dependencyconvergence) @ es-plugins ---
>>> > [INFO]
>>> > [INFO] -< org.example:dedup
>>> >> --
>>> > [INFO] Building dedup 1.0-SNAPSHOT
>>> >   [2/2]
>>> > [INFO] [ jar
>>> > ]-
>>> > [INFO]
>>> > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
>>> > (javaversion-dependencyconvergence) @ dedup ---
>>> > [WARNING]
>>> > Dependency convergence error for
>>> > com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1
>>> paths to
>>> > dependency are:
>>> > +-org.example:dedup:1.0-SNAPSHOT
>>> >+-org.elasticsearch.test:framework:7.7.1
>>> >
>>> +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1
>>> > and
>>> > +-org.example:dedup:1.0-SNAPSHOT
>>> >+-org.elasticsearch.test:framework:7.7.1
>>> >  +-org.apache.lucene:lucene-test-framework:8.5.1
>>> >
>>> +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.2
>>> >
>>> > [WARNING]
>>> > Dependency convergence error for commons-logging:commons-logging:1.2
>>> paths
>>> > to dependency are:
>>> > +

Re: Maven enforcer plugin failing with maven 3.6.1 but passing with maven 3.6.3

[Debraj Manna]

I am observing the same behavior with maven docker also. It is passing with
3.6.3 but failing with 3.6.1.

Used the below commands

Debrajs-MacBook-Air:es-plugins debrajmanna$ docker run -it --rm --name
es-plugins -v "$(pwd)":/Users/debrajmanna/code/vnera/es-plugins -w
/Users/debrajmanna/code/vnera/es-plugins maven:3.6.1 mvn validate

Debrajs-MacBook-Air:es-plugins debrajmanna$ docker run -it --rm --name
es-plugins -v "$(pwd)":/Users/debrajmanna/code/vnera/es-plugins -w
/Users/debrajmanna/code/vnera/es-plugins maven:3.6.3 mvn validate

On Sat, Aug 29, 2020 at 5:32 PM Debraj Manna 
wrote:

> It is failing consistently in our environment. Can you let me know what
> can cause this difference in behavior?
>
> Any other log I can provide that may help in debugging this issue further?
>
> On Sat, Aug 29, 2020 at 4:45 PM Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> as already mentioned on SO the behaviour can't be reproduced with the
>> example project.
>>
>> Tested with Maven 3.6.0, 3.6.1, 3.6.2 and 3.6.3...
>>
>> Kind regards
>> Karl Heinz Marbaise
>> On 29.08.20 08:34, Debraj Manna wrote:
>> > Hi
>> >
>> > In one of my project I am trying to use DependencyConvergence rule with
>> > maven enforcer plugin. I am observing that if I use maven 3.6.1 then the
>> > enforcer is failing with the below error but the same has been working
>> fine
>> > with maven 3.6.3. Can someone let me know if this expected? If yes can
>> > someone point me to the relevant jira under which this issue is fixed in
>> > maven 3.6.3.
>> >
>> > I have placed a sample project in
>> https://github.com/debraj-manna/es-plugins
>> > where this issue can be reproduced.
>> >
>> > maven-enforcer-plugin - 3.0.0-M2
>> >
>> > Debrajs-MacBook-Air:es-plugins debrajmanna$
>> > ~/Downloads/apache-maven-3.6.1/bin/mvn validate
>> > [INFO] Scanning for projects...
>> > [INFO]
>> > 
>> > [INFO] Reactor Build Order:
>> > [INFO]
>> > [INFO] es-plugins
>> > [pom]
>> > [INFO] dedup
>> >   [jar]
>> > [INFO]
>> > [INFO] ---< org.example:es-plugins
>> >> ---
>> > [INFO] Building es-plugins 1.0-SNAPSHOT
>> > [1/2]
>> > [INFO] [ pom
>> > ]-
>> > [INFO]
>> > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
>> > (javaversion-dependencyconvergence) @ es-plugins ---
>> > [INFO]
>> > [INFO] -< org.example:dedup
>> >> --
>> > [INFO] Building dedup 1.0-SNAPSHOT
>> >   [2/2]
>> > [INFO] [ jar
>> > ]-
>> > [INFO]
>> > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
>> > (javaversion-dependencyconvergence) @ dedup ---
>> > [WARNING]
>> > Dependency convergence error for
>> > com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1 paths
>> to
>> > dependency are:
>> > +-org.example:dedup:1.0-SNAPSHOT
>> >+-org.elasticsearch.test:framework:7.7.1
>> >  +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1
>> > and
>> > +-org.example:dedup:1.0-SNAPSHOT
>> >+-org.elasticsearch.test:framework:7.7.1
>> >  +-org.apache.lucene:lucene-test-framework:8.5.1
>> >
>> +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.2
>> >
>> > [WARNING]
>> > Dependency convergence error for commons-logging:commons-logging:1.2
>> paths
>> > to dependency are:
>> > +-org.example:dedup:1.0-SNAPSHOT
>> >+-org.elasticsearch.test:framework:7.7.1
>> >  +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>> >+-org.apache.httpcomponents:httpclient:4.5.10
>> >  +-commons-logging:commons-logging:1.2
>> > and
>> > +-org.example:dedup:1.0-SNAPSHOT
>> >+-org.elasticsearch.test:framework:7.7.1
>> >  +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>> >+-org.apache.httpcomponents:httpasyncclient:4.1.4
>> >  +-commons-logging:commons-logging:1.2
>> > and
>> > +-org.example:dedup:1.0-SNAPSHOT
>> >+-org.elasticsearch.test:framework:7.7.1
>> >  +-org.elasticsearch.client:elasticsearch-rest-client:7.7

Re: Maven enforcer plugin failing with maven 3.6.1 but passing with maven 3.6.3

[Debraj Manna]

It is failing consistently in our environment. Can you let me know what can
cause this difference in behavior?

Any other log I can provide that may help in debugging this issue further?

On Sat, Aug 29, 2020 at 4:45 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> as already mentioned on SO the behaviour can't be reproduced with the
> example project.
>
> Tested with Maven 3.6.0, 3.6.1, 3.6.2 and 3.6.3...
>
> Kind regards
> Karl Heinz Marbaise
> On 29.08.20 08:34, Debraj Manna wrote:
> > Hi
> >
> > In one of my project I am trying to use DependencyConvergence rule with
> > maven enforcer plugin. I am observing that if I use maven 3.6.1 then the
> > enforcer is failing with the below error but the same has been working
> fine
> > with maven 3.6.3. Can someone let me know if this expected? If yes can
> > someone point me to the relevant jira under which this issue is fixed in
> > maven 3.6.3.
> >
> > I have placed a sample project in
> https://github.com/debraj-manna/es-plugins
> > where this issue can be reproduced.
> >
> > maven-enforcer-plugin - 3.0.0-M2
> >
> > Debrajs-MacBook-Air:es-plugins debrajmanna$
> > ~/Downloads/apache-maven-3.6.1/bin/mvn validate
> > [INFO] Scanning for projects...
> > [INFO]
> > 
> > [INFO] Reactor Build Order:
> > [INFO]
> > [INFO] es-plugins
> > [pom]
> > [INFO] dedup
> >   [jar]
> > [INFO]
> > [INFO] ---< org.example:es-plugins
> >> ---
> > [INFO] Building es-plugins 1.0-SNAPSHOT
> > [1/2]
> > [INFO] [ pom
> > ]-
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
> > (javaversion-dependencyconvergence) @ es-plugins ---
> > [INFO]
> > [INFO] -< org.example:dedup
> >> --
> > [INFO] Building dedup 1.0-SNAPSHOT
> >   [2/2]
> > [INFO] [ jar
> > ]-
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
> > (javaversion-dependencyconvergence) @ dedup ---
> > [WARNING]
> > Dependency convergence error for
> > com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1 paths
> to
> > dependency are:
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1
> > and
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-org.apache.lucene:lucene-test-framework:8.5.1
> >
> +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.2
> >
> > [WARNING]
> > Dependency convergence error for commons-logging:commons-logging:1.2
> paths
> > to dependency are:
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
> >+-org.apache.httpcomponents:httpclient:4.5.10
> >  +-commons-logging:commons-logging:1.2
> > and
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
> >+-org.apache.httpcomponents:httpasyncclient:4.1.4
> >  +-commons-logging:commons-logging:1.2
> > and
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
> >+-commons-logging:commons-logging:1.1.3
> > and
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
> >+-commons-logging:commons-logging:1.1.3
> > and
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-commons-logging:commons-logging:1.1.3
> >
> > [WARNING]
> > Dependency convergence error for
> org.apache.httpcomponents:httpcore:4.4.12
> > paths to dependency are:
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearch.test:framework:7.7.1
> >  +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
> >+-org.apache.httpcomponents:httpclient:4.5.10
> >  +-org.apache.httpcomponents:httpcore:4.4.12
> > and
> > +-org.example:dedup:1.0-SNAPSHOT
> >+-org.elasticsearc

Re: Maven enforcer plugin failing with maven 3.6.1 but passing with maven 3.6.3

[Karl Heinz Marbaise]

Hi,

as already mentioned on SO the behaviour can't be reproduced with the
example project.

Tested with Maven 3.6.0, 3.6.1, 3.6.2 and 3.6.3...

Kind regards
Karl Heinz Marbaise
On 29.08.20 08:34, Debraj Manna wrote:

Hi

In one of my project I am trying to use DependencyConvergence rule with
maven enforcer plugin. I am observing that if I use maven 3.6.1 then the
enforcer is failing with the below error but the same has been working fine
with maven 3.6.3. Can someone let me know if this expected? If yes can
someone point me to the relevant jira under which this issue is fixed in
maven 3.6.3.

I have placed a sample project in https://github.com/debraj-manna/es-plugins
where this issue can be reproduced.

maven-enforcer-plugin - 3.0.0-M2

Debrajs-MacBook-Air:es-plugins debrajmanna$
~/Downloads/apache-maven-3.6.1/bin/mvn validate
[INFO] Scanning for projects...
[INFO]

[INFO] Reactor Build Order:
[INFO]
[INFO] es-plugins
[pom]
[INFO] dedup
  [jar]
[INFO]
[INFO] ---< org.example:es-plugins

---

[INFO] Building es-plugins 1.0-SNAPSHOT
[1/2]
[INFO] [ pom
]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
(javaversion-dependencyconvergence) @ es-plugins ---
[INFO]
[INFO] -< org.example:dedup

--

[INFO] Building dedup 1.0-SNAPSHOT
  [2/2]
[INFO] [ jar
]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
(javaversion-dependencyconvergence) @ dedup ---
[WARNING]
Dependency convergence error for
com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1 paths to
dependency are:
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.apache.lucene:lucene-test-framework:8.5.1
   +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.2

[WARNING]
Dependency convergence error for commons-logging:commons-logging:1.2 paths
to dependency are:
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-org.apache.httpcomponents:httpclient:4.5.10
 +-commons-logging:commons-logging:1.2
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-org.apache.httpcomponents:httpasyncclient:4.1.4
 +-commons-logging:commons-logging:1.2
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-commons-logging:commons-logging:1.1.3
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
   +-commons-logging:commons-logging:1.1.3
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-commons-logging:commons-logging:1.1.3

[WARNING]
Dependency convergence error for org.apache.httpcomponents:httpcore:4.4.12
paths to dependency are:
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-org.apache.httpcomponents:httpclient:4.5.10
 +-org.apache.httpcomponents:httpcore:4.4.12
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-org.apache.httpcomponents:httpcore:4.4.12
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-org.apache.httpcomponents:httpasyncclient:4.1.4
 +-org.apache.httpcomponents:httpcore:4.4.10
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
   +-org.apache.httpcomponents:httpcore:4.4.12

[WARNING]
Dependency convergence error for
org.apache.httpcomponents:httpclient:4.5.10 paths to dependency are:
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-org.apache.httpcomponents:httpclient:4.5.10
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
   +-org.apache.httpcomponents:httpasyncclient:4.1.4
 +-org.apache.httpcomponents:httpclient:4.5.6
and
+-org.example:dedup:1.0-SNAPSHOT
   +-org.elasticsearch.test:framework:7.7.1
 +-org.elasticsearch.client:elasticsearch-rest-

Re: Maven enforcer plugin failing with maven 3.6.1 but passing with maven 3.6.3

[Debraj Manna]

Just to be more explicit with maven versions. I tried with maven version
3.6.1, 3.6.3 and 3.5.3. It worked fine only with 3.6.3.

On Sat, Aug 29, 2020 at 12:04 PM Debraj Manna 
wrote:

> Hi
>
> In one of my project I am trying to use DependencyConvergence rule with
> maven enforcer plugin. I am observing that if I use maven 3.6.1 then the
> enforcer is failing with the below error but the same has been working fine
> with maven 3.6.3. Can someone let me know if this expected? If yes can
> someone point me to the relevant jira under which this issue is fixed in
> maven 3.6.3.
>
> I have placed a sample project in
> https://github.com/debraj-manna/es-plugins where this issue can be
> reproduced.
>
> maven-enforcer-plugin - 3.0.0-M2
>
> Debrajs-MacBook-Air:es-plugins debrajmanna$
> ~/Downloads/apache-maven-3.6.1/bin/mvn validate
> [INFO] Scanning for projects...
> [INFO]
> 
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] es-plugins
> [pom]
> [INFO] dedup
>  [jar]
> [INFO]
> [INFO] ---< org.example:es-plugins
> >---
> [INFO] Building es-plugins 1.0-SNAPSHOT
> [1/2]
> [INFO] ----[ pom
> ]-
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
> (javaversion-dependencyconvergence) @ es-plugins ---
> [INFO]
> [INFO] -< org.example:dedup
> >--
> [INFO] Building dedup 1.0-SNAPSHOT
>  [2/2]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
> (javaversion-dependencyconvergence) @ dedup ---
> [WARNING]
> Dependency convergence error for
> com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1 paths to
> dependency are:
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.apache.lucene:lucene-test-framework:8.5.1
>   +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.2
>
> [WARNING]
> Dependency convergence error for commons-logging:commons-logging:1.2 paths
> to dependency are:
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>   +-org.apache.httpcomponents:httpclient:4.5.10
> +-commons-logging:commons-logging:1.2
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>   +-org.apache.httpcomponents:httpasyncclient:4.1.4
> +-commons-logging:commons-logging:1.2
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>   +-commons-logging:commons-logging:1.1.3
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
>   +-commons-logging:commons-logging:1.1.3
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-commons-logging:commons-logging:1.1.3
>
> [WARNING]
> Dependency convergence error for org.apache.httpcomponents:httpcore:4.4.12
> paths to dependency are:
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>   +-org.apache.httpcomponents:httpclient:4.5.10
> +-org.apache.httpcomponents:httpcore:4.4.12
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>   +-org.apache.httpcomponents:httpcore:4.4.12
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
>   +-org.apache.httpcomponents:httpasyncclient:4.1.4
> +-org.apache.httpcomponents:httpcore:4.4.10
> and
> +-org.example:dedup:1.0-SNAPSHOT
>   +-org.elasticsearch.test:framework:7.7.1
> +-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
>   +-org.apache.httpcomponents:httpcore:4.4.12
>
> [WARNING]
> Dependency convergence error for
> org.apache.httpcomponents:httpclient:4.5.10 paths to dependency are:
> +-org.example:dedup:1.0-SNAPSHOT
>   +-

Maven enforcer plugin failing with maven 3.6.1 but passing with maven 3.6.3

[Debraj Manna]

Hi

In one of my project I am trying to use DependencyConvergence rule with
maven enforcer plugin. I am observing that if I use maven 3.6.1 then the
enforcer is failing with the below error but the same has been working fine
with maven 3.6.3. Can someone let me know if this expected? If yes can
someone point me to the relevant jira under which this issue is fixed in
maven 3.6.3.

I have placed a sample project in https://github.com/debraj-manna/es-plugins
where this issue can be reproduced.

maven-enforcer-plugin - 3.0.0-M2

Debrajs-MacBook-Air:es-plugins debrajmanna$
~/Downloads/apache-maven-3.6.1/bin/mvn validate
[INFO] Scanning for projects...
[INFO]

[INFO] Reactor Build Order:
[INFO]
[INFO] es-plugins
[pom]
[INFO] dedup
 [jar]
[INFO]
[INFO] ---< org.example:es-plugins
>---
[INFO] Building es-plugins 1.0-SNAPSHOT
[1/2]
[INFO] [ pom
]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
(javaversion-dependencyconvergence) @ es-plugins ---
[INFO]
[INFO] -< org.example:dedup
>--
[INFO] Building dedup 1.0-SNAPSHOT
 [2/2]
[INFO] [ jar
]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.0.0-M2:enforce
(javaversion-dependencyconvergence) @ dedup ---
[WARNING]
Dependency convergence error for
com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1 paths to
dependency are:
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.1
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.apache.lucene:lucene-test-framework:8.5.1
  +-com.carrotsearch.randomizedtesting:randomizedtesting-runner:2.7.2

[WARNING]
Dependency convergence error for commons-logging:commons-logging:1.2 paths
to dependency are:
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-org.apache.httpcomponents:httpclient:4.5.10
+-commons-logging:commons-logging:1.2
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-org.apache.httpcomponents:httpasyncclient:4.1.4
+-commons-logging:commons-logging:1.2
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-commons-logging:commons-logging:1.1.3
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
  +-commons-logging:commons-logging:1.1.3
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-commons-logging:commons-logging:1.1.3

[WARNING]
Dependency convergence error for org.apache.httpcomponents:httpcore:4.4.12
paths to dependency are:
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-org.apache.httpcomponents:httpclient:4.5.10
+-org.apache.httpcomponents:httpcore:4.4.12
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-org.apache.httpcomponents:httpcore:4.4.12
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-org.apache.httpcomponents:httpasyncclient:4.1.4
+-org.apache.httpcomponents:httpcore:4.4.10
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
  +-org.apache.httpcomponents:httpcore:4.4.12

[WARNING]
Dependency convergence error for
org.apache.httpcomponents:httpclient:4.5.10 paths to dependency are:
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-org.apache.httpcomponents:httpclient:4.5.10
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client:7.7.1
  +-org.apache.httpcomponents:httpasyncclient:4.1.4
+-org.apache.httpcomponents:httpclient:4.5.6
and
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:framework:7.7.1
+-org.elasticsearch.client:elasticsearch-rest-client-sniffer:7.7.1
  +-org.apache.httpcomponents:httpclient:4.5.10

[WARNING]
Dependency convergence error for
org.apache.httpcomponents:httpcore-nio:4.4.10 paths to dependency are:
+-org.example:dedup:1.0-SNAPSHOT
  +-org.elasticsearch.test:fra

Re: Problem with use of enforcer-plugin after upgrading the Apache parent POM (18->21)

[Julian Reschke]

On 24.06.2019 14:49, Thomas Broyer wrote:

One of the POMs might need to use `combine.children="append"` on the
 element: https://maven.apache.org/pom.html#Plugins
No idea why that would only manifest during releases thoguh… have you
compared "mvn help:effective-pom" vs "mvn help:effective-pom
-Papache-release,release"?


I don't see any differences with respect to the enforcer, but show:



  
maven-enforcer-plugin
3.0.0-M2

  
enforce-maven-version

  enforce


  

  3.0.5

  

  
  
enforce-file-size
package

  enforce


  

  5100
  

C:\tmp\jackrabbit-oak\oak-run\target/oak-run-1.16-SNAPSHOT.jar
  

  

  

  


Best regards, Julian

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Problem with use of enforcer-plugin after upgrading the Apache parent POM (18->21)

[Thomas Broyer]

One of the POMs might need to use `combine.children="append"` on the
 element: https://maven.apache.org/pom.html#Plugins
No idea why that would only manifest during releases thoguh… have you
compared "mvn help:effective-pom" vs "mvn help:effective-pom
-Papache-release,release"?

On Mon, Jun 24, 2019 at 12:23 PM Julian Reschke 
wrote:

> Hi there,
>
> I've found a strange issue (well, strange to me) when I tried to upgrade
> Oak's parent POM from 18 to 21 (details at
> <https://issues.apache.org/jira/browse/OAK-8255>).
>
> The actual change that triggers the issue for us was between version 18
> and 19, which introduces the use of the enforcer plugin to check the
> Maven version
> (<
> https://github.com/apache/maven-apache-parent/commit/35c824cfef4d8ae3ec7234365635e43f57b8e05a#diff-600376dffeb79835ede4a0b285078036
> >,
> <https://issues.apache.org/jira/browse/MPOM-164>).
>
> In Oak, we use the enforcer plugin to check the size of a generated JAR
> file. After updating the parent POM, this check fails (or does not
> happen?) - if and only if when done using "release:prepare".
>
> To reproduce:
>
> - clone https://github.com/apache/jackrabbit-oak
> - update oak-parent/pom.xml to use version 21 instead of 18 of parent pom
> - run mvn:release-prepare -DdryRun=true -Darguments="-DskipTests"
>
> <https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run/pom.xml#L157>
> is the place in oak-run's POM where we use the enforcer plugin.
>
> Are we doing something stupid here that conflicts with the use of the
> enforcer plugin in the Apache parent POM?
>
> Best regards, Julian
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

Problem with use of enforcer-plugin after upgrading the Apache parent POM (18->21)

[Julian Reschke]

Hi there,

I've found a strange issue (well, strange to me) when I tried to upgrade
Oak's parent POM from 18 to 21 (details at
<https://issues.apache.org/jira/browse/OAK-8255>).

The actual change that triggers the issue for us was between version 18
and 19, which introduces the use of the enforcer plugin to check the
Maven version
(<https://github.com/apache/maven-apache-parent/commit/35c824cfef4d8ae3ec7234365635e43f57b8e05a#diff-600376dffeb79835ede4a0b285078036>,
<https://issues.apache.org/jira/browse/MPOM-164>).

In Oak, we use the enforcer plugin to check the size of a generated JAR
file. After updating the parent POM, this check fails (or does not
happen?) - if and only if when done using "release:prepare".

To reproduce:

- clone https://github.com/apache/jackrabbit-oak
- update oak-parent/pom.xml to use version 21 instead of 18 of parent pom
- run mvn:release-prepare -DdryRun=true -Darguments="-DskipTests"

<https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run/pom.xml#L157>
is the place in oak-run's POM where we use the enforcer plugin.

Are we doing something stupid here that conflicts with the use of the
enforcer plugin in the Apache parent POM?

Best regards, Julian

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: New release of the maven-enforcer-plugin?

[Böhme , Christoph]

Hi,


Thank you for the quick response.


That time frame would work well for us.


Kind Regards,

Christoph



Von: Karl Heinz Marbaise 
Gesendet: Donnerstag, 27. September 2018 10:45:32
An: Maven Users List; Böhme, Christoph
Betreff: Re: New release of the maven-enforcer-plugin?

Hi,


I'm currently occupied with Maven Core Release / Install / Deploy
plugin...but the next on my TODO list is Maven Enforcer plugin...


I would say about 2-3 Weeks time frame...?

would that help?

Kind regards
Karl Heinz Marbaise
On 27/09/18 10:36, Böhme, Christoph wrote:
> Hi all,
>
> Are there any plans of building another milestone release of the 
> maven-enforcer-plugin in the near future?
> I am asking because I'd like to use the recently added feature to specify 
> rules on the command line in our CI-pipeline. I'd rather avoid having to 
> create a custom in-house release of the enforcer-plugin just to have a stable 
> version.
>
> Thank you
>
> Kind regards
> Christoph
>

Re: New release of the maven-enforcer-plugin?

[Karl Heinz Marbaise]

Hi,


I'm currently occupied with Maven Core Release / Install / Deploy 
plugin...but the next on my TODO list is Maven Enforcer plugin...



I would say about 2-3 Weeks time frame...?

would that help?

Kind regards
Karl Heinz Marbaise
On 27/09/18 10:36, Böhme, Christoph wrote:

Hi all,

Are there any plans of building another milestone release of the 
maven-enforcer-plugin in the near future?
I am asking because I'd like to use the recently added feature to specify rules 
on the command line in our CI-pipeline. I'd rather avoid having to create a 
custom in-house release of the enforcer-plugin just to have a stable version.

Thank you

Kind regards
Christoph



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

New release of the maven-enforcer-plugin?

[Böhme , Christoph]

Hi all,

Are there any plans of building another milestone release of the 
maven-enforcer-plugin in the near future?
I am asking because I'd like to use the recently added feature to specify rules 
on the command line in our CI-pipeline. I'd rather avoid having to create a 
custom in-house release of the enforcer-plugin just to have a stable version.

Thank you

Kind regards
Christoph

-- 

***Lesen. Hören. Wissen. Deutsche Nationalbibliothek***

Christoph Böhme
Deutsche Nationalbibliothek
Informationstechnik
Adickesallee 1
60322 Frankfurt am Main
Telefon: +49 69 1525-1721
Telefax: +49 69 1525-1799
mailto:c.boe...@dnb.de
http://www.dnb.de

Re: Programmatic access to enforcer plugin

[Laird Nelson]

On Sat, Jul 21, 2018 at 9:27 AM Elliotte Rusty Harold 
wrote:

> If anyone has sample code
> that queries repos for dependencies without M2E, that would also be
> helpful.


I've put together a project that runs Maven/Aether dependency resolution
internals in a CDI 2.0 SE container:
https://microbean.github.io/microbean-maven-cdi/.  Put this jar and its
dependencies on your classpath, start a CDI 2.0 SE container, and off you
go (
https://github.com/microbean/microbean-maven-cdi/blob/c5abd2e3c321020c419442c44ef726e48952d983/src/test/java/org/microbean/maven/cdi/TestMavenExtension.java#L91-L111
).

For those who are curious, Aether has a long history and is now known as
maven-resolver:
https://lairdnelson.wordpress.com/2017/03/06/maven-and-the-project-formerly-known-as-aether/

You can find examples of various kinds here:
https://github.com/apache/maven-resolver/tree/master/maven-resolver-demos/maven-resolver-demo-snippets/src/main/java/org/apache/maven/resolver/examples

Hope that helps,
Best,
Laird

Re: Programmatic access to enforcer plugin

[Elliotte Rusty Harold]

There exists a very large group of open source libraries, some my
organization owns and a few we don't. It is not currently possible to
find a convergent set of versions for these libraries, and it's hard
to collect a set of versions that doesn't hit no such method errors
and other serious incompatibilities.

I want to generate a list of the version conflicts across all these
libraries, and then create an ordered list of the dependency upgrades
that need to be patched in and shipped so we can publish a BOM of
versions that at least work together, even if they're not necessarily
all the latest version. Then I want to keep publish newer versions of
the BOM as new versions of the dependencies ship.

We can't afford to simply fail the build of all the components on the
first convergence error. We tried that and it became quickly obvious
that none of them would or could build if we did. This is going to be
a multistep fix.

I'm considering whether it may be necessary to drop deeper down the
stack and write my own code to check for dependency convergence. I
actually have some existing Aether code that queries the repos for a
complete dependency graph. Unfortunately parts of it depend on M2E
which I don't want to use for this project. So I would need to rewrite
those lines to use org.apache.maven instead. If anyone has sample code
that queries repos for dependencies without M2E, that would also be
helpful.


On Thu, Jul 19, 2018 at 4:08 PM, Karl Heinz Marbaise  wrote:
> Hi,
>
> can explain more in detail what you like to achieve? Best would be based on
> an example...
>
> Apart from that maven-enforcer is intended to check for rules which if
> someone violates the defined rules...not really intended to make a report
> ?...
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 19/07/18 20:13, Elliotte Rusty Harold wrote:
>>
>> Short of forking the project, is any sort of programmatic API for the
>> Maven enforcer plugin available? E.g. I'd like to point a rule at a
>> dependency coordinates and get a report back in a somewhat more
>> structured form than System.out.println.
>>
>> Has anyone done something like this? Are there any docs better than
>> reading the source code? Thanks.
>>
>



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Programmatic access to enforcer plugin

[Karl Heinz Marbaise]

Hi,

can explain more in detail what you like to achieve? Best would be based 
on an example...


Apart from that maven-enforcer is intended to check for rules which if 
someone violates the defined rules...not really intended to make a 
report ?...



Kind regards
Karl Heinz Marbaise

On 19/07/18 20:13, Elliotte Rusty Harold wrote:

Short of forking the project, is any sort of programmatic API for the
Maven enforcer plugin available? E.g. I'd like to point a rule at a
dependency coordinates and get a report back in a somewhat more
structured form than System.out.println.

Has anyone done something like this? Are there any docs better than
reading the source code? Thanks.




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Programmatic access to enforcer plugin

[Elliotte Rusty Harold]

Short of forking the project, is any sort of programmatic API for the
Maven enforcer plugin available? E.g. I'd like to point a rule at a
dependency coordinates and get a report back in a somewhat more
structured form than System.out.println.

Has anyone done something like this? Are there any docs better than
reading the source code? Thanks.

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Enforcer Plugin 3.0.0-M2 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Apache  
Maven Enforcer Plugin, version 3.0.0-M2


The Enforcer plugin provides goals to control certain environmental  
constraints such as Maven version, JDK version and OS family along with  
many more built-in rules and user created rules.


https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  3.0.0-M2


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.cgi


Release Notes - Maven Enforcer Plugin - Version 3.0.0-M2 (including  
3.0.0-M1)


** Bug
* [MENFORCER-234] - Link to plugin's web site is reported as  
redirected by maven linkcheck plugin.
* [MENFORCER-239] - Fix link in navigation  
(enforcer/maven-enforcer-plugin/index.html) RESOURCES

* [MENFORCER-240] - Link to page does not work
* [MENFORCER-265] - Get site generation working
* [MENFORCER-268] - Usage of CI friendly version placeholders does not  
work
* [MENFORCER-274] - Use of RequireJavaVersion with Java-9 breaking  
starting at b175
* [MENFORCER-281] - RequirePluginVersions broken with "CI Friendly  
versions"


** New Feature
* [MENFORCER-204] - Add new rule: should be able to make sure that  
project artifact is a Snapshot

* [MENFORCER-247] - Add a "require file checksum" rule
* [MENFORCER-273] - RequireUpperBoundDeps.excludes
* [MENFORCER-282] - Add RequireProfileIdsExist to ensure al mentioned  
cmdline profiles exist


** Improvement
* [MENFORCER-228] - DependencyConvergence: Simplify logging errors
* [MENFORCER-253] - Upgrade maven-shared-components parent to version  
30
* [MENFORCER-259] - The rule BanDuplicatePomDependencyVersions is not  
documented

* [MENFORCER-263] - Upgrade mrm-maven-plugin to 1.0.0
* [MENFORCER-266] - Remove usage of prerequisites in parent pom
* [MENFORCER-291] - Cleanup ReactorModuleConvergence implementation
* [MENFORCER-292] - Remove getModelsRecursively from EnforcerRuleUtils
* [MENFORCER-293] - Remove deprecated marked ignoreParent from  
BanDistributionManagement


** Task
* [MENFORCER-221] - Removed deprecated marked constructor from  
EnforcerExpressionEvaluator

* [MENFORCER-272] - Allow site generation to work
* [MENFORCER-284] - switch to Git
* [MENFORCER-296] - Update URL for CI System

** Dependency upgrade
* [MENFORCER-278] - Upgrade mockito to 2.X to prevent JDK 9 WARNINGs
* [MENFORCER-289] - Upgrade maven-plugin-plugin to 3.5
* [MENFORCER-290] - Upgrade plexus-utils 3.1.0
* [MENFORCER-297] - Upgrade parent to 31
* [MENFORCER-303] - Upgrade mave-surefire/failsafe-plugin 2.21.0


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Enforcer Plugin 3.0.0-M1 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Apache  
Maven Enforcer Plugin, version 3.0.0-M1


The Enforcer plugin provides goals to control certain environmental  
constraints such as Maven version, JDK version and OS family along with  
many more standard rules and user created rules.


https://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  3.0.0-M1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/enforcer/download.cgi

NOTE: this is a milestone release, because there are still some open  
issues which need to be fixed before the official 3.0.0.
This release is mainly there to provide a Java9 compatible plugin  
(previous versions of some rules fail the build).



Release Notes - Maven Enforcer Plugin - Version 3.0.0-M1

** Bug
* [MENFORCER-234] - Link to plugin's web site is reported as  
redirected by maven linkcheck plugin.
* [MENFORCER-239] - Fix link in navigation  
(enforcer/maven-enforcer-plugin/index.html) RESOURCES

* [MENFORCER-240] - Link to page does not work
* [MENFORCER-265] - Get site generation working
* [MENFORCER-274] - Use of RequireJavaVersion with Java-9 breaking  
starting at b175


** Improvement
* [MENFORCER-228] - DependencyConvergence: Simplify logging errors
* [MENFORCER-253] - Upgrade maven-shared-components parent to version  
30
* [MENFORCER-259] - The rule BanDuplicatePomDependencyVersions is not  
documented

* [MENFORCER-263] - Upgrade mrm-maven-plugin to 1.0.0
* [MENFORCER-266] - Remove usage of prerequisites in parent pom
* [MENFORCER-267] - Upgrade to make Maven 3+

** New Feature
* [MENFORCER-204] - Add new rule: should be able to make sure that  
project artifact is a Snapshot

* [MENFORCER-247] - Add a "require file checksum" rule
* [MENFORCER-273] - RequireUpperBoundDeps.excludes

** Task
* [MENFORCER-272] - Allow site generation to work


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-enforcer-plugin rules question

[Martin Gainty]

i found plugin that appears to address class-cycle issues found in class files


http://classycle.sourceforge.net/

Classycle<http://classycle.sourceforge.net/>
classycle.sourceforge.net
Home; Examples; Download; User Guide; API documentation; SourceForge project 
page. powered by : Classycle: Analysing Tools for Java Class and Package 
Dependencies


Using this exmaple:


public class ClassA
{
 public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect this 
class cycle
}

public class ClassB extends ClassA
{
 public ClassA classA=null; //this is OK as it is Base Class
}



produces this xml output:



  
 
  
  



  
  



I'll need to factor in some xslt magic to find cycle but I think we have a 
delta detected by this plugin


thanks all,

Martin
__




From: Martin Gainty <mgai...@hotmail.com>
Sent: Tuesday, January 10, 2017 12:05 PM
To: Maven Users List
Subject: Re: maven-enforcer-plugin rules question


i couldnt get it this cycle failure:

Test set: de.andrena.tools.nopackagecycles.PackageCycleCollectorPerformanceTest
---
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec - in 
de.andrena.tools.nopackagecycles.PackageCycleCollectorPerformanceTest



package de.andrena.tools.nopackagecycles;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.empty;
import static org.hamcrest.Matchers.is;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import jdepend.framework.JavaPackage;
import org.junit.Before;
import org.junit.Test;
import de.andrena.tools.nopackagecycles.ClassB;

public class ClassB extends ClassA
{
 public ClassA classA=null; //OK
}



public class PackageCycleCollectorPerformanceTest {


//add one obvious cycle


public void findRealPackageCycle() throws Exception {
JavaPackage javaPackage =new JavaPackage("de.andrena.tools.nopackagecycles");
JavaClass javaClassA=new JavaClass("ClassA");
javaPackage.addClass(javaClassA);
JavaClass javaClassB=new JavaClass("ClassB");
javaPackage.addClass(javaClassB);
allPackages.add(javaPackage);
   List<Set> cycles = new 
PackageCycleCollector().collectCycles(allPackages);
assertThat(cycles, is(empty()));
}
...
}


package de.andrena.tools.nopackagecycles;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.empty;
import static org.hamcrest.Matchers.is;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import jdepend.framework.JavaPackage;
import org.junit.Before;
import org.junit.Test;
import de.andrena.tools.nopackagecycles.ClassB;
public class ClassA
{
 public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect this 
cycle!
}


what am i doing wrong?


Thanks Curtis

Martin
__



From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of Curtis 
Rueden <ctrue...@wisc.edu>
Sent: Tuesday, January 10, 2017 11:02 AM
To: Maven Users List
Subject: Re: maven-enforcer-plugin rules question

Hi Martin,

A quick Google search revealed this:
https://github.com/andrena/no-package-cycles-enforcer-rule
[https://avatars2.githubusercontent.com/u/1824230?v=3=400]<https://github.com/andrena/no-package-cycles-enforcer-rule>

GitHub - andrena/no-package-cycles-enforcer-rule 
...<https://github.com/andrena/no-package-cycles-enforcer-rule>
github.com
no-package-cycles-enforcer-rule - Shamelessly copied and improved from 
http://stackoverflow.com/questions/3416547/maven-jdepend-fail-build-with-cycles




I haven't tried it personally. Though now that I know about it, I'm sorely
tempted-it would certainly improve the API design.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
[https://gravatar.com/avatar/63df759e2779af56fd050a968ff98d09]<http://imagej.net/User:Rueden>

User:Rueden - ImageJ<http://imagej.net/User:Rueden>
imagej.net
What is Curtis working on? Primary projects. Here is a summary of my current 
projects, in priority order. I try to keep this list up to date. The ImageJ2 
paper.





On Tue, Jan 10, 2017 at 9:34 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> I need to detect package cycles such as what is seen here:
>
> class ClassA
>
> {
>
>  ClassB classB; //detect this package cycle!
>
> }
> class ClassB extends ClassA
>
> {
>
> }
>
>
> which maven-enforcer-plugin rule will allow me to detect package cycle?
>
>
> http://maven.

Re: maven-enforcer-plugin rules question

[Curtis Rueden]

Hi Martin,

Detecting cycles at the class level seems like a less common use case, and
thus harder to achieve out of the box.

I played a bit with jdeps -- from the docs, it seems like it should be able
to emit output along the lines you are looking for -- but I could not get
it to behave within 10 minutes. Maybe someone else here has more experience
with it.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Wed, Jan 11, 2017 at 6:10 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> all:
>  I need to catch a class cycle for example:
>
> package fubar;
>
> class classA
>
> {
>
>  classB classb; //i need to detect this cycle
>
> }
>
>
> package fubar;
>
> class classB extends classA
> {
>  classA classa; //ok since child class can reach to base class
>
> }
>
>
> does maven-enforcer-plugin have a rule which will detect class cycle
> illustrated above?
>
> Thanks!
>
> Martin
> __
>
>
>
> 
> From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of
> Curtis Rueden <ctrue...@wisc.edu>
> Sent: Tuesday, January 10, 2017 12:13 PM
> To: Maven Users List
> Subject: Re: maven-enforcer-plugin rules question
>
> Hi Martin,
>
> I do not see how your example constitutes a "package cycle"? Both ClassA
> and ClassB belong to the same package.
>
> Put ClassA or ClassB into a different package, and see if the rule
> complains.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
>
>
> On Tue, Jan 10, 2017 at 11:05 AM, Martin Gainty <mgai...@hotmail.com>
> wrote:
>
> > i couldnt get it this cycle failure:
> >
> > Test set: de.andrena.tools.nopackagecycles.PackageCycleCollectorPerfor
> man
> > ceTest
> > 
> > ---
> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
> > - in de.andrena.tools.nopackagecycles.PackageCycleCollectorPerfor
> manceTest
> >
> >
> >
> > package de.andrena.tools.nopackagecycles;
> > import static org.hamcrest.MatcherAssert.assertThat;
> > import static org.hamcrest.Matchers.empty;
> > import static org.hamcrest.Matchers.is;
> > import java.util.ArrayList;
> > import java.util.Collections;
> > import java.util.HashSet;
> > import java.util.List;
> > import java.util.Set;
> > import jdepend.framework.JavaPackage;
> > import org.junit.Before;
> > import org.junit.Test;
> > import de.andrena.tools.nopackagecycles.ClassB;
> >
> > public class ClassB extends ClassA
> > {
> >  public ClassA classA=null; //OK
> > }
> >
> >
> >
> > public class PackageCycleCollectorPerformanceTest {
> >
> >
> > //add one obvious cycle
> >
> >
> > public void findRealPackageCycle() throws Exception {
> > JavaPackage javaPackage =new JavaPackage("de.andrena.tools.
> > nopackagecycles");
> > JavaClass javaClassA=new JavaClass("ClassA");
> > javaPackage.addClass(javaClassA);
> > JavaClass javaClassB=new JavaClass("ClassB");
> > javaPackage.addClass(javaClassB);
> > allPackages.add(javaPackage);
> >List<Set> cycles = new PackageCycleCollector().
> > collectCycles(allPackages);
> > assertThat(cycles, is(empty()));
> > }
> > ...
> > }
> >
> >
> > package de.andrena.tools.nopackagecycles;
> > import static org.hamcrest.MatcherAssert.assertThat;
> > import static org.hamcrest.Matchers.empty;
> > import static org.hamcrest.Matchers.is;
> > import java.util.ArrayList;
> > import java.util.Collections;
> > import java.util.HashSet;
> > import java.util.List;
> > import java.util.Set;
> > import jdepend.framework.JavaPackage;
> > import org.junit.Before;
> > import org.junit.Test;
> > import de.andrena.tools.nopackagecycles.ClassB;
> > public class ClassA
> > {
> >  public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect
> > this cycle!
> > }
> >
> >
> > what am i doing wrong?
> >
> >
> > Thanks Curtis
> >
> > Martin
> > __
> >
> >
> > 
> > From: ctrueden.w...@gmail.com <ctrueden.w..

Re: maven-enforcer-plugin rules question

[Martin Gainty]

all:
 I need to catch a class cycle for example:

package fubar;

class classA

{

 classB classb; //i need to detect this cycle

}


package fubar;

class classB extends classA
{
 classA classa; //ok since child class can reach to base class

}


does maven-enforcer-plugin have a rule which will detect class cycle 
illustrated above?

Thanks!

Martin
__




From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of Curtis 
Rueden <ctrue...@wisc.edu>
Sent: Tuesday, January 10, 2017 12:13 PM
To: Maven Users List
Subject: Re: maven-enforcer-plugin rules question

Hi Martin,

I do not see how your example constitutes a "package cycle"? Both ClassA
and ClassB belong to the same package.

Put ClassA or ClassB into a different package, and see if the rule
complains.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Tue, Jan 10, 2017 at 11:05 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> i couldnt get it this cycle failure:
>
> Test set: de.andrena.tools.nopackagecycles.PackageCycleCollectorPerforman
> ceTest
> 
> ---
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
> - in de.andrena.tools.nopackagecycles.PackageCycleCollectorPerformanceTest
>
>
>
> package de.andrena.tools.nopackagecycles;
> import static org.hamcrest.MatcherAssert.assertThat;
> import static org.hamcrest.Matchers.empty;
> import static org.hamcrest.Matchers.is;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import jdepend.framework.JavaPackage;
> import org.junit.Before;
> import org.junit.Test;
> import de.andrena.tools.nopackagecycles.ClassB;
>
> public class ClassB extends ClassA
> {
>  public ClassA classA=null; //OK
> }
>
>
>
> public class PackageCycleCollectorPerformanceTest {
>
>
> //add one obvious cycle
>
>
> public void findRealPackageCycle() throws Exception {
> JavaPackage javaPackage =new JavaPackage("de.andrena.tools.
> nopackagecycles");
> JavaClass javaClassA=new JavaClass("ClassA");
> javaPackage.addClass(javaClassA);
> JavaClass javaClassB=new JavaClass("ClassB");
> javaPackage.addClass(javaClassB);
> allPackages.add(javaPackage);
>List<Set> cycles = new PackageCycleCollector().
> collectCycles(allPackages);
> assertThat(cycles, is(empty()));
> }
> ...
> }
>
>
> package de.andrena.tools.nopackagecycles;
> import static org.hamcrest.MatcherAssert.assertThat;
> import static org.hamcrest.Matchers.empty;
> import static org.hamcrest.Matchers.is;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import jdepend.framework.JavaPackage;
> import org.junit.Before;
> import org.junit.Test;
> import de.andrena.tools.nopackagecycles.ClassB;
> public class ClassA
> {
>  public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect
> this cycle!
> }
>
>
> what am i doing wrong?
>
>
> Thanks Curtis
>
> Martin
> __
>
>
> 
> From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of
> Curtis Rueden <ctrue...@wisc.edu>
> Sent: Tuesday, January 10, 2017 11:02 AM
> To: Maven Users List
> Subject: Re: maven-enforcer-plugin rules question
>
> Hi Martin,
>
> A quick Google search revealed this:
> https://github.com/andrena/no-package-cycles-enforcer-rule
> [https://avatars2.githubusercontent.com/u/1824230?v=3=400]<https://
> github.com/andrena/no-package-cycles-enforcer-rule>
>
> GitHub - andrena/no-package-cycles-enforcer-rule ...<https://github.com/
> andrena/no-package-cycles-enforcer-rule>
> github.com
> no-package-cycles-enforcer-rule - Shamelessly copied and improved from
> http://stackoverflow.com/questions/3416547/maven-
> jdepend-fail-build-with-cycles
>
>
>
>
> I haven't tried it personally. Though now that I know about it, I'm sorely
> tempted-it would certainly improve the API design.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> [https://gravatar.com/avatar/63df759e2779af56fd050a968ff98d09]<
> http://imagej.net/User:Rueden>
>
> User:Rueden - ImageJ<http://imagej.net/User:Rueden&g

Re: maven-enforcer-plugin rules question

[Curtis Rueden]

Hi Martin,

I do not see how your example constitutes a "package cycle"? Both ClassA
and ClassB belong to the same package.

Put ClassA or ClassB into a different package, and see if the rule
complains.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Tue, Jan 10, 2017 at 11:05 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> i couldnt get it this cycle failure:
>
> Test set: de.andrena.tools.nopackagecycles.PackageCycleCollectorPerforman
> ceTest
> 
> ---
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
> - in de.andrena.tools.nopackagecycles.PackageCycleCollectorPerformanceTest
>
>
>
> package de.andrena.tools.nopackagecycles;
> import static org.hamcrest.MatcherAssert.assertThat;
> import static org.hamcrest.Matchers.empty;
> import static org.hamcrest.Matchers.is;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import jdepend.framework.JavaPackage;
> import org.junit.Before;
> import org.junit.Test;
> import de.andrena.tools.nopackagecycles.ClassB;
>
> public class ClassB extends ClassA
> {
>  public ClassA classA=null; //OK
> }
>
>
>
> public class PackageCycleCollectorPerformanceTest {
>
>
> //add one obvious cycle
>
>
> public void findRealPackageCycle() throws Exception {
> JavaPackage javaPackage =new JavaPackage("de.andrena.tools.
> nopackagecycles");
> JavaClass javaClassA=new JavaClass("ClassA");
> javaPackage.addClass(javaClassA);
> JavaClass javaClassB=new JavaClass("ClassB");
> javaPackage.addClass(javaClassB);
> allPackages.add(javaPackage);
>List<Set> cycles = new PackageCycleCollector().
> collectCycles(allPackages);
> assertThat(cycles, is(empty()));
> }
> ...
> }
>
>
> package de.andrena.tools.nopackagecycles;
> import static org.hamcrest.MatcherAssert.assertThat;
> import static org.hamcrest.Matchers.empty;
> import static org.hamcrest.Matchers.is;
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import jdepend.framework.JavaPackage;
> import org.junit.Before;
> import org.junit.Test;
> import de.andrena.tools.nopackagecycles.ClassB;
> public class ClassA
> {
>  public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect
> this cycle!
> }
>
>
> what am i doing wrong?
>
>
> Thanks Curtis
>
> Martin
> __
>
>
> 
> From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of
> Curtis Rueden <ctrue...@wisc.edu>
> Sent: Tuesday, January 10, 2017 11:02 AM
> To: Maven Users List
> Subject: Re: maven-enforcer-plugin rules question
>
> Hi Martin,
>
> A quick Google search revealed this:
> https://github.com/andrena/no-package-cycles-enforcer-rule
> [https://avatars2.githubusercontent.com/u/1824230?v=3=400]<https://
> github.com/andrena/no-package-cycles-enforcer-rule>
>
> GitHub - andrena/no-package-cycles-enforcer-rule ...<https://github.com/
> andrena/no-package-cycles-enforcer-rule>
> github.com
> no-package-cycles-enforcer-rule - Shamelessly copied and improved from
> http://stackoverflow.com/questions/3416547/maven-
> jdepend-fail-build-with-cycles
>
>
>
>
> I haven't tried it personally. Though now that I know about it, I'm sorely
> tempted-it would certainly improve the API design.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - http://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
> [https://gravatar.com/avatar/63df759e2779af56fd050a968ff98d09]<
> http://imagej.net/User:Rueden>
>
> User:Rueden - ImageJ<http://imagej.net/User:Rueden>
> imagej.net
> What is Curtis working on? Primary projects. Here is a summary of my
> current projects, in priority order. I try to keep this list up to date.
> The ImageJ2 paper.
>
>
>
>
>
> On Tue, Jan 10, 2017 at 9:34 AM, Martin Gainty <mgai...@hotmail.com>
> wrote:
>
> > I need to detect package cycles such as what is seen here:
> >
> > class ClassA
> >
> > {
> >
> >  ClassB classB; //detect this package cycle!
> >
> > }
> > class ClassB extends ClassA
> >
> > {
> >
> > }
> >
> >
> > which maven-enforcer-plugin ru

Re: maven-enforcer-plugin rules question

[Martin Gainty]

i couldnt get it this cycle failure:

Test set: de.andrena.tools.nopackagecycles.PackageCycleCollectorPerformanceTest
---
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec - in 
de.andrena.tools.nopackagecycles.PackageCycleCollectorPerformanceTest



package de.andrena.tools.nopackagecycles;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.empty;
import static org.hamcrest.Matchers.is;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import jdepend.framework.JavaPackage;
import org.junit.Before;
import org.junit.Test;
import de.andrena.tools.nopackagecycles.ClassB;

public class ClassB extends ClassA
{
 public ClassA classA=null; //OK
}



public class PackageCycleCollectorPerformanceTest {


//add one obvious cycle


public void findRealPackageCycle() throws Exception {
JavaPackage javaPackage =new JavaPackage("de.andrena.tools.nopackagecycles");
JavaClass javaClassA=new JavaClass("ClassA");
javaPackage.addClass(javaClassA);
JavaClass javaClassB=new JavaClass("ClassB");
javaPackage.addClass(javaClassB);
allPackages.add(javaPackage);
   List<Set> cycles = new 
PackageCycleCollector().collectCycles(allPackages);
assertThat(cycles, is(empty()));
}
...
}


package de.andrena.tools.nopackagecycles;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.empty;
import static org.hamcrest.Matchers.is;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import jdepend.framework.JavaPackage;
import org.junit.Before;
import org.junit.Test;
import de.andrena.tools.nopackagecycles.ClassB;
public class ClassA
{
 public de.andrena.tools.nopackagecycles.ClassB classB=null; //detect this 
cycle!
}


what am i doing wrong?


Thanks Curtis

Martin
__



From: ctrueden.w...@gmail.com <ctrueden.w...@gmail.com> on behalf of Curtis 
Rueden <ctrue...@wisc.edu>
Sent: Tuesday, January 10, 2017 11:02 AM
To: Maven Users List
Subject: Re: maven-enforcer-plugin rules question

Hi Martin,

A quick Google search revealed this:
https://github.com/andrena/no-package-cycles-enforcer-rule
[https://avatars2.githubusercontent.com/u/1824230?v=3=400]<https://github.com/andrena/no-package-cycles-enforcer-rule>

GitHub - andrena/no-package-cycles-enforcer-rule 
...<https://github.com/andrena/no-package-cycles-enforcer-rule>
github.com
no-package-cycles-enforcer-rule - Shamelessly copied and improved from 
http://stackoverflow.com/questions/3416547/maven-jdepend-fail-build-with-cycles




I haven't tried it personally. Though now that I know about it, I'm sorely
tempted-it would certainly improve the API design.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden
[https://gravatar.com/avatar/63df759e2779af56fd050a968ff98d09]<http://imagej.net/User:Rueden>

User:Rueden - ImageJ<http://imagej.net/User:Rueden>
imagej.net
What is Curtis working on? Primary projects. Here is a summary of my current 
projects, in priority order. I try to keep this list up to date. The ImageJ2 
paper.





On Tue, Jan 10, 2017 at 9:34 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> I need to detect package cycles such as what is seen here:
>
> class ClassA
>
> {
>
>  ClassB classB; //detect this package cycle!
>
> }
> class ClassB extends ClassA
>
> {
>
> }
>
>
> which maven-enforcer-plugin rule will allow me to detect package cycle?
>
>
> http://maven.apache.org/enforcer/enforcer-rules/index.html
Apache Maven Enforcer Rules - Standard 
Rules<http://maven.apache.org/enforcer/enforcer-rules/index.html>
maven.apache.org
Standard Rules. The following standard rules ship along with the enforcer 
plugin: alwaysFail - Always fail... used to test plugin configuration. 
alwaysPass - Always ...



>
> Apache Maven Enforcer Rules - Standard Rules<http://maven.apache.org/
> enforcer/enforcer-rules/index.html>
> maven.apache.org
> Standard Rules. The following standard rules ship along with the enforcer
> plugin: alwaysFail - Always fail... used to test plugin configuration.
> alwaysPass - Always ...
>
>
>
>
> Thanks!
>
> Martin
> __
>
>

Re: maven-enforcer-plugin rules question

[Curtis Rueden]

Hi Martin,

A quick Google search revealed this:
https://github.com/andrena/no-package-cycles-enforcer-rule

I haven't tried it personally. Though now that I know about it, I'm sorely
tempted—it would certainly improve the API design.

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden


On Tue, Jan 10, 2017 at 9:34 AM, Martin Gainty <mgai...@hotmail.com> wrote:

> I need to detect package cycles such as what is seen here:
>
> class ClassA
>
> {
>
>  ClassB classB; //detect this package cycle!
>
> }
> class ClassB extends ClassA
>
> {
>
> }
>
>
> which maven-enforcer-plugin rule will allow me to detect package cycle?
>
>
> http://maven.apache.org/enforcer/enforcer-rules/index.html
>
> Apache Maven Enforcer Rules - Standard Rules<http://maven.apache.org/
> enforcer/enforcer-rules/index.html>
> maven.apache.org
> Standard Rules. The following standard rules ship along with the enforcer
> plugin: alwaysFail - Always fail... used to test plugin configuration.
> alwaysPass - Always ...
>
>
>
>
> Thanks!
>
> Martin
> __
>
>

maven-enforcer-plugin rules question

[Martin Gainty]

I need to detect package cycles such as what is seen here:

class ClassA

{

 ClassB classB; //detect this package cycle!

}
class ClassB extends ClassA

{

}


which maven-enforcer-plugin rule will allow me to detect package cycle?


http://maven.apache.org/enforcer/enforcer-rules/index.html

Apache Maven Enforcer Rules - Standard 
Rules<http://maven.apache.org/enforcer/enforcer-rules/index.html>
maven.apache.org
Standard Rules. The following standard rules ship along with the enforcer 
plugin: alwaysFail - Always fail... used to test plugin configuration. 
alwaysPass - Always ...




Thanks!

Martin
__

Re: Question about Java version range using in Maven Enforcer Plugin

[Curtis Rueden]

Hi Sandra,

 I discussed with my team how they interprets the range value
 [1.6,1.8]. They would interpret this as every Java 8 version is
 possible. Is this a misinterpretation of us?

For the most part, the RequireMavenVersion and RequireJavaVersion rules
use the standard Maven version range syntax [1].

So try writing:
[1.6, 1.9)

Where the closing paren means up to, but not including, 1.9.

Regards,
Curtis

[1] http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

On Tue, Jan 27, 2015 at 3:18 PM, Sandra Kosmalla skosma...@web.de wrote:

 Hi,

 I want to set the RequiredJavaVersion rule in Maven Enforcer Plugin with
 the requirement that using Java in versions 1.6, 1.7 and 1.8 is possible
 (independent of update version). So I set the value [1.6,1.8] in the
 property version in the RequiredJavaVersion rule. If I configure Java
 8 in my JAVA_HOME, the build failed because of the rule
 RequiredJavaVersion.

 The goal enforcer:display-info prints following information

 [INFO] --- maven-enforcer-plugin:1.3.1:display-info (default-cli) @  ---
 [INFO] Maven Version: 3.2.5
 [INFO] JDK Version: 1.8.0_31 normalized as: 1.8.0-31
 [INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
 3.13.0-37-generic

 I have to set the range value to [1.6,1.8.0.*] so that the build runs
 successfully.

 I discussed with my team how they interprets the range value [1.6,1.8].
 They would interpret this as every Java 8 version is possible. Is this a
 misinterpretation of us? What do you say about it?

 Thanks and best regards,

 Sandra Kosmalla

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Question about Java version range using in Maven Enforcer Plugin

[Sandra Kosmalla]

Hi,

I want to set the RequiredJavaVersion rule in Maven Enforcer Plugin with
the requirement that using Java in versions 1.6, 1.7 and 1.8 is possible
(independent of update version). So I set the value [1.6,1.8] in the
property version in the RequiredJavaVersion rule. If I configure Java
8 in my JAVA_HOME, the build failed because of the rule RequiredJavaVersion.

The goal enforcer:display-info prints following information

[INFO] --- maven-enforcer-plugin:1.3.1:display-info (default-cli) @  ---
[INFO] Maven Version: 3.2.5
[INFO] JDK Version: 1.8.0_31 normalized as: 1.8.0-31
[INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
3.13.0-37-generic

I have to set the range value to [1.6,1.8.0.*] so that the build runs
successfully.

I discussed with my team how they interprets the range value [1.6,1.8].
They would interpret this as every Java 8 version is possible. Is this a
misinterpretation of us? What do you say about it?

Thanks and best regards,

Sandra Kosmalla

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Question about Java version range using in Maven Enforcer Plugin

[Sandra Kosmalla]

Hi Curtis,

thanks for your explanation. Your suggestion works.

Regards,

Sandra

Am 27.01.2015 um 15:35 schrieb Curtis Rueden:
 Hi Sandra,
 
 I discussed with my team how they interprets the range value
 [1.6,1.8]. They would interpret this as every Java 8 version is
 possible. Is this a misinterpretation of us?
 
 For the most part, the RequireMavenVersion and RequireJavaVersion rules
 use the standard Maven version range syntax [1].
 
 So try writing:
 [1.6, 1.9)
 
 Where the closing paren means up to, but not including, 1.9.
 
 Regards,
 Curtis
 
 [1] http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
 
 On Tue, Jan 27, 2015 at 3:18 PM, Sandra Kosmalla skosma...@web.de wrote:
 
 Hi,

 I want to set the RequiredJavaVersion rule in Maven Enforcer Plugin with
 the requirement that using Java in versions 1.6, 1.7 and 1.8 is possible
 (independent of update version). So I set the value [1.6,1.8] in the
 property version in the RequiredJavaVersion rule. If I configure Java
 8 in my JAVA_HOME, the build failed because of the rule
 RequiredJavaVersion.

 The goal enforcer:display-info prints following information

 [INFO] --- maven-enforcer-plugin:1.3.1:display-info (default-cli) @  ---
 [INFO] Maven Version: 3.2.5
 [INFO] JDK Version: 1.8.0_31 normalized as: 1.8.0-31
 [INFO] OS Info: Arch: amd64 Family: unix Name: linux Version:
 3.13.0-37-generic

 I have to set the range value to [1.6,1.8.0.*] so that the build runs
 successfully.

 I discussed with my team how they interprets the range value [1.6,1.8].
 They would interpret this as every Java 8 version is possible. Is this a
 misinterpretation of us? What do you say about it?

 Thanks and best regards,

 Sandra Kosmalla

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

How to detect dependency convergence violations between *independent* projects using maven enforcer plugin

[Pisarev, Vitaliy]

When running dependency convergence with the maven enforcer 
pluginhttp://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html,
 we can easily detect that a certain project transitively depends on 2 
different versions of the same artifact.

But consider a large group that is writing plugins for the same system. And 
consider 2 teams in this group.

One team is developing plugin A and has the following dependency chain: A - B 
- C (v 1.1)

the other team develops plugin X and has the following dependency chain: X - Y 
- C (v 2.0)

Projects A and X are completely independent but in in production, both plugins 
are deployed and there is a collision. Although both teams share CI, the 
enforcer plugin does not detect this collision since collisions are detected 
only if they share a common ancestor.

(for example, if A also had: A - D - C (v 1.4), this would have been 
detected).

It seems that the solution is to define a 3rd 'super module' that will 
aggregate A and X and feed it to the enforcer plugin. I am having trouble with 
this:

I defined such a module. Added A and X as dependencies (of type 'pom') but when 
I execute the enforcer, it does not detect the collisions! It is as if the 
super pom fails to 'absorb' the transitive dependencies.

What am I missing here?

I am using maven 3.0.4.

Feature for Maven Enforcer Plugin Rule

[Basil James]

Hi,



I work for an Indian IT company(1,50,000+ employees) and we use Maven for
many of our projects.

Recently we used Maven Enforcer Plugin and Dependency Convergence Rule (
http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html).
We needed the convergence to be checked for only project specific module
dependencies. I wrote a custom rule modifying the existing rule to accept a
standard include/exclude list. This is working fine and I think it will be
a good feature to be included in the standard Dependency Convergence Rule.



Should I raise this in JIRA? I don’t have a JIRA access.



Thanks and Regards

Basil James

Re: Feature for Maven Enforcer Plugin Rule

[Karl Heinz Marbaise]

Hi Basil,



I work for an Indian IT company(1,50,000+ employees) and we use Maven for
many of our projects.

Recently we used Maven Enforcer Plugin and Dependency Convergence Rule (
http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html).
We needed the convergence to be checked for only project specific module
dependencies. I wrote a custom rule modifying the existing rule to accept a
standard include/exclude list. This is working fine and I think it will be
a good feature to be included in the standard Dependency Convergence Rule.



Should I raise this in JIRA? I don’t have a JIRA access.


Sure it would be great if you create a JIRA account via this:

https://xircles.codehaus.org/signup

afterwards you can create a JIRA ticket for this purpose and describe 
what you have changed and of course attach the patch...Apart of that it 
would be great if you have some tests for the behaviour of your changes...


Than i see no objections to integrate your change into maven-enforcer 
rules...


Kind regards
Karl-Heinz Marbaise

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Enforcer plugin

[Karl Heinz Marbaise]

Hi,

it would be really nice having a test case which reproduces the wrong 
behaviour ...


Kind regards
Karl-Heinz Marbaise
On 4/3/14 2:25 AM, Mark Eggers wrote:

Folks,

I've gotten my classifier artifact to build and install in our local
repository. Specifying the classifier gets the appropriate artifact, and
removing the classifier gets the [other] appropriate artifact.

Now I'm a bit paranoid that the artifact with the classifier will leak
out into other releases, so I thought I would write an enforcer rule.

I thought that the following would work:

bannedDependencies
 excludes
 excludeorg.mdeggers:*:*:*:*:DEBUG/exclude
 /excludes
/bannedDependencies

based on:

http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

While this certainly blocked the following dependency:

dependency
 groupIdorg.mdeggers/groupId
 artifactIdSampleBuild/artifactId
 version1.5/version
 typewar/type
 classifierDEBUG/classifier
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:DEBUG:1.5

It also blocked the following dependency:

dependency
 groupIdorg.mdeggers/groupId
 artifactIdSampleBuild/artifactId
 version1.5/version
 typewar/type
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:1.5

This I did not expect. The messages are also a bit suspect in that they
don't match the pattern given in the documentation.

I looked on JIRA and found the following (based on another thread):

http://jira.codehaus.org/browse/MENFORCER-74
http://jira.codehaus.org/browse/MENFORCER-75
http://jira.codehaus.org/browse/MENFORCER-72

These are all closed with a 'fixed' designation for release 1.3.

I'm using version 1.3.1

However, I briefly looked at the code here:

http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.3.1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependencies.java?revision=1502671view=markup


and classifier does not seem to have made it in.

Have I walked through this correctly? If so, is there a fix (other than
not using classifiers, or just hoping that a DEBUG classifier doesn't
make it into a release)?



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Enforcer plugin

[Baptiste Mathus]

Not sure I understand: did you use a standard rule or did you finally write
 use your own one? If the latter, seing the code somewhere may help. If
using a standard one, then creating a testcase project is definitely the
best way to get answers and then the potential fix.

Cheers


2014-04-03 4:22 GMT+02:00 Mark Eggers its_toas...@yahoo.com:


 On 4/2/2014 5:25 PM, Mark Eggers wrote:

 Folks,

 I've gotten my classifier artifact to build and install in our local
 repository. Specifying the classifier gets the appropriate artifact, and
 removing the classifier gets the [other] appropriate artifact.

 Now I'm a bit paranoid that the artifact with the classifier will leak
 out into other releases, so I thought I would write an enforcer rule.

 I thought that the following would work:

 bannedDependencies
  excludes
  excludeorg.mdeggers:*:*:*:*:DEBUG/exclude
  /excludes
 /bannedDependencies

 based on:

 http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

 While this certainly blocked the following dependency:

 dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
  classifierDEBUG/classifier
 /dependency

 with the message:
 Found Banned Dependency: org.mdeggers:SampleBuild:war:DEBUG:1.5

 It also blocked the following dependency:

 dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
 /dependency

 with the message:
 Found Banned Dependency: org.mdeggers:SampleBuild:war:1.5

 This I did not expect. The messages are also a bit suspect in that they
 don't match the pattern given in the documentation.

 I looked on JIRA and found the following (based on another thread):

 http://jira.codehaus.org/browse/MENFORCER-74
 http://jira.codehaus.org/browse/MENFORCER-75
 http://jira.codehaus.org/browse/MENFORCER-72

 These are all closed with a 'fixed' designation for release 1.3.

 I'm using version 1.3.1

 However, I briefly looked at the code here:

 http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-
 1.3.1/enforcer-rules/src/main/java/org/apache/maven/plugins/
 enforcer/BannedDependencies.java?revision=1502671view=markup


 and classifier does not seem to have made it in.

 Have I walked through this correctly? If so, is there a fix (other than
 not using classifiers, or just hoping that a DEBUG classifier doesn't
 make it into a release)?

 Thanks,
 Mark

 /mde/


 Works with 2.0-SNAPSHOT of the maven enforcer plugin.


 /mde/


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-- 
Baptiste Batmat MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Enforcer plugin

[Mark Eggers]

On 4/3/2014 1:08 PM, Baptiste Mathus wrote:

Not sure I understand: did you use a standard rule or did you finally write
 use your own one? If the latter, seing the code somewhere may help. If
using a standard one, then creating a testcase project is definitely the
best way to get answers and then the potential fix.

Cheers



I'll try to generate a sample project. Hopefully I can simulate this 
with a multi-module project.


However, the following snippets of my pom.xml may be enough . . .

Standard rule:

This does not work as expected in 1.3.1 of maven-enforcer-plugin:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version1.3.1/version
  executions
execution
  idban-debug/id
  goals
goalenforce/goal
  /goals
  configuration
rules
  bannedDependencies
excludes
  excludeorg.mdeggers:*:*:*:*:DEBUG/exclude
/excludes
  /bannedDependencies
/rules
  /configuration
/execution
  /executions
/plugin

with a dependency of:

dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
  classifierDEBUG/classifier.
/dependency

the build for the above dependency as expected.

However it also fails the build for the following dependency.

dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
/dependency

Found Banned Dependency: org.mdeggers:SampleBuild:war:1.5

Even though the tickets listed below show the issues closed.

http://jira.codehaus.org/browse/MENFORCER-74
http://jira.codehaus.org/browse/MENFORCER-75
http://jira.codehaus.org/browse/MENFORCER-72

This works in 2.0-SNAPSHOT

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version2.0-SNAPSHOT/version
  executions
execution
  idban-debug/id
  goals
goalenforce/goal
  /goals
  configuration
rules
  bannedDependencies
excludes
  excludeorg.mdeggers:*:*:*:*:DEBUG/exclude
/excludes
  /bannedDependencies
/rules
  /configuration
/execution
  /executions
/plugin

with a dependency of:

dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
  classifierDEBUG/classifier.
/dependency

This works as expected - fails the build for this dependency.

Including the following dependency allows the build to pass.

dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
/dependency

Since I want to use this in a profile that gets triggered during 
release, I can't have a SNAPSHOT dependency in pom.xml (nor would I want 
to).


I've built the plugin locally, and I'm now looking at adding it to my 
local Nexus repository under third party artifacts. I'll generate a 
versionId based on the date and update the poms when 2.0 is officially 
released.


Welcome to fragile build-land. :-(

Thanks for the response.

Mark
/mde/



2014-04-03 4:22 GMT+02:00 Mark Eggers its_toas...@yahoo.com:



On 4/2/2014 5:25 PM, Mark Eggers wrote:


Folks,

I've gotten my classifier artifact to build and install in our local
repository. Specifying the classifier gets the appropriate artifact, and
removing the classifier gets the [other] appropriate artifact.

Now I'm a bit paranoid that the artifact with the classifier will leak
out into other releases, so I thought I would write an enforcer rule.

I thought that the following would work:

bannedDependencies
  excludes
  excludeorg.mdeggers:*:*:*:*:DEBUG/exclude
  /excludes
/bannedDependencies

based on:

http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

While this certainly blocked the following dependency:

dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
  classifierDEBUG/classifier
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:DEBUG:1.5

It also blocked the following dependency:

dependency
  groupIdorg.mdeggers/groupId
  artifactIdSampleBuild/artifactId
  version1.5/version
  typewar/type
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:1.5

This I did not expect. The messages are also a bit suspect in that they
don't match the pattern given in the documentation.

I looked on JIRA and found the following (based on another thread):

http://jira.codehaus.org/browse/MENFORCER-74
http://jira.codehaus.org/browse/MENFORCER-75
http://jira.codehaus.org/browse/MENFORCER-72

These are all closed with a 'fixed' designation for release 1.3.

I'm using version 1.3.1

However, I briefly looked at the code here:

http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-
1.3.1/enforcer-rules/src/main/java/org/apache/maven/plugins

Enforcer plugin

[Mark Eggers]

Folks,

I've gotten my classifier artifact to build and install in our local 
repository. Specifying the classifier gets the appropriate artifact, and 
removing the classifier gets the [other] appropriate artifact.


Now I'm a bit paranoid that the artifact with the classifier will leak 
out into other releases, so I thought I would write an enforcer rule.


I thought that the following would work:

bannedDependencies
excludes
excludeorg.mdeggers:*:*:*:*:DEBUG/exclude
/excludes
/bannedDependencies

based on:

http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

While this certainly blocked the following dependency:

dependency
groupIdorg.mdeggers/groupId
artifactIdSampleBuild/artifactId
version1.5/version
typewar/type
classifierDEBUG/classifier
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:DEBUG:1.5

It also blocked the following dependency:

dependency
groupIdorg.mdeggers/groupId
artifactIdSampleBuild/artifactId
version1.5/version
typewar/type
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:1.5

This I did not expect. The messages are also a bit suspect in that they 
don't match the pattern given in the documentation.


I looked on JIRA and found the following (based on another thread):

http://jira.codehaus.org/browse/MENFORCER-74
http://jira.codehaus.org/browse/MENFORCER-75
http://jira.codehaus.org/browse/MENFORCER-72

These are all closed with a 'fixed' designation for release 1.3.

I'm using version 1.3.1

However, I briefly looked at the code here:

http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.3.1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependencies.java?revision=1502671view=markup

and classifier does not seem to have made it in.

Have I walked through this correctly? If so, is there a fix (other than 
not using classifiers, or just hoping that a DEBUG classifier doesn't 
make it into a release)?


Thanks,
Mark

/mde/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Enforcer plugin

[Mark Eggers]

On 4/2/2014 5:25 PM, Mark Eggers wrote:

Folks,

I've gotten my classifier artifact to build and install in our local
repository. Specifying the classifier gets the appropriate artifact, and
removing the classifier gets the [other] appropriate artifact.

Now I'm a bit paranoid that the artifact with the classifier will leak
out into other releases, so I thought I would write an enforcer rule.

I thought that the following would work:

bannedDependencies
 excludes
 excludeorg.mdeggers:*:*:*:*:DEBUG/exclude
 /excludes
/bannedDependencies

based on:

http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

While this certainly blocked the following dependency:

dependency
 groupIdorg.mdeggers/groupId
 artifactIdSampleBuild/artifactId
 version1.5/version
 typewar/type
 classifierDEBUG/classifier
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:DEBUG:1.5

It also blocked the following dependency:

dependency
 groupIdorg.mdeggers/groupId
 artifactIdSampleBuild/artifactId
 version1.5/version
 typewar/type
/dependency

with the message:
Found Banned Dependency: org.mdeggers:SampleBuild:war:1.5

This I did not expect. The messages are also a bit suspect in that they
don't match the pattern given in the documentation.

I looked on JIRA and found the following (based on another thread):

http://jira.codehaus.org/browse/MENFORCER-74
http://jira.codehaus.org/browse/MENFORCER-75
http://jira.codehaus.org/browse/MENFORCER-72

These are all closed with a 'fixed' designation for release 1.3.

I'm using version 1.3.1

However, I briefly looked at the code here:

http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.3.1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependencies.java?revision=1502671view=markup


and classifier does not seem to have made it in.

Have I walked through this correctly? If so, is there a fix (other than
not using classifiers, or just hoping that a DEBUG classifier doesn't
make it into a release)?

Thanks,
Mark

/mde/


Works with 2.0-SNAPSHOT of the maven enforcer plugin.

/mde/


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Aw: Re: maven-enforcer-plugin problems with test dependency in multi module project

[Matthias Mayer]

Without the maven enforce rule “requireReleaseDeps” and without the 
typetest-jar/type in the pom.xml of the test-child “mvn clean package” 
failed as predicted.

Without the maven enforce rule “requireReleaseDeps” and with the 
typetest-jar/type “mvn clean package” and “mvn clean compile” succeeded.

With the maven enforce rule “requireReleaseDeps” and with the 
typetest-jar/type in the pom.xml of the test-child “mvn clean package” 
succeeded but “mvn clean compile” failed because of the missing 
test:test-parent:jar:tests. But since the scope is set scopetest/scope this 
shouldn't matter, should it?

Best regards

Matthias

 Gesendet: Donnerstag, 30. Januar 2014 um 17:13 Uhr
 Von: Karl Heinz Marbaise khmarba...@gmx.de
 An: users@maven.apache.org
 Betreff: Re: maven-enforcer-plugin problems with test dependency in multi 
 module project

 Hi,
 
 based on the error message you have a dependency on your test-jar 
 project but you defined the dependency a little bit wrong:
 
 test:test-child:jar:1.0.0: Failure to find test:test-parent:jar:tests:1.0.0
 
 This shows that you have defined a dependency in the test-parent but 
 like this:
 
   dependencies
  dependency
groupIdtest/groupId
artifactIdtest-parent/artifactId
version1.0-SNAPSHOT/version
   scopetest/scope
  /dependency
   /dependencies
 
 BUT you have to give the type in this case like this:
 
   dependencies
  dependency
groupIdtest/groupId
artifactIdtest-parent/artifactId
version1.0-SNAPSHOT/version
   typetest-jar/type
   scopetest/scope
  /dependency
   /dependencies
 
 Best test is to comment out the maven-enforcer-rule and try to build 
 your project just from the parent via
 
 
 mvn clean package
 
 I assume in your case without the above fix your project will not build.
 If it will you need to clean out your local repository first and retry it...
 
 
 Kind regards
 Karl Heinz Marbaise
 
   Hi,
 
  I have a multi-module-project with one module that implements classes for 
  testing (test-parent) and another module (test-child) that uses theses 
  classes. There is a dependency in test scope from the test-child to the 
  test-parent.
  (See article 
  http://stackoverflow.com/questions/1725476/maven-test-dependency-in-multi-module-project
   and 
  http://maven.apache.org/guides/mini/guide-attached-tests.html[http://maven.apache.org/guides/mini/guide-attached-tests.html])
  The pom of the depending test-child contains the following code:
 
  dependencies
 dependency
   groupIdtest/groupId
   artifactIdtest-parent/artifactId
   version1.0-SNAPSHOT/version
   typetest-jar/type
   scopetest/scope
 /dependency
  /dependencies
 
  The test-parent module that contains the derived classes contains the 
  following code:
 
  plugins
 plugin
   artifactIdmaven-jar-plugin/artifactId
   version2.2/version
   executions
 execution
   goals
 goaltest-jar/goal
   /goals
   phasetest-compile/phase
 /execution
   /executions
 /plugin
  /plugins
 
  In a parent pom the maven-enforcer-plugin is included and the 
  RequireReleaseDeps rule is added to the list of rules. While running the 
  Maven goal “compile”  the project compilation of the test-child fails with 
  the following message:
  [ERROR] Failed to execute goal 
  org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce (default) on 
  project test-child: Execution default of goal 
  org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce failed: 
  org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: 
  Could not resolve dependencies for project test:test-child:jar:1.0.0: 
  Failure to find test:test-parent:jar:tests:1.0.0
  It seems that Maven checks the dependencies of type and scope “test” in the 
  compile phase. In the case the test-jar is build in the test-compile and is 
  not present yet. This leads to the error.
  If I remove the RequireReleaseDeps from the rules it works fine.
  Here is the simplified config of the maven-enforcer-plugin:
 
  pluginManagement
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-enforcer-plugin/artifactId
 version${maven-enforcer-plugin.version}/version
 inheritedtrue/inherited
 executions
   execution
 goalsgoalenforce/goal/goals
   /execution
 /executions
 configuration
   !-- skip/ --
   rules
 requireReleaseDeps
   onlyWhenReleasefalse/onlyWhenRelease
 /requireReleaseDeps
 requireMavenVersion
   version[3.0.4,]/version
 /requireMavenVersion
   /rules
   fail${maven-enforcer-plugin.fail}/fail
 /configuration
   /plugin
 /plugins
  /pluginManagement
 plugins
   plugin
  groupIdorg.apache.maven.plugins

maven-enforcer-plugin problems with test dependency in multi module project

[Matthias Mayer]

Hi,
 
I have a multi-module-project with one module that implements classes for 
testing (test-parent) and another module (test-child) that uses theses classes. 
There is a dependency in test scope from the test-child to the test-parent.
(See article 
http://stackoverflow.com/questions/1725476/maven-test-dependency-in-multi-module-project
 and 
http://maven.apache.org/guides/mini/guide-attached-tests.html[http://maven.apache.org/guides/mini/guide-attached-tests.html])
The pom of the depending test-child contains the following code:

dependencies
  dependency
    groupIdtest/groupId
    artifactIdtest-parent/artifactId
    version1.0-SNAPSHOT/version
    typetest-jar/type
    scopetest/scope
  /dependency
/dependencies

The test-parent module that contains the derived classes contains the following 
code:

plugins
  plugin
    artifactIdmaven-jar-plugin/artifactId
    version2.2/version
    executions
      execution
    goals
      goaltest-jar/goal
    /goals
    phasetest-compile/phase
      /execution
    /executions
  /plugin
/plugins

In a parent pom the maven-enforcer-plugin is included and the 
RequireReleaseDeps rule is added to the list of rules. While running the Maven 
goal “compile”  the project compilation of the test-child fails with the 
following message:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce (default) on 
project test-child: Execution default of goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce failed: 
org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: Could 
not resolve dependencies for project test:test-child:jar:1.0.0: Failure to find 
test:test-parent:jar:tests:1.0.0
It seems that Maven checks the dependencies of type and scope “test” in the 
compile phase. In the case the test-jar is build in the test-compile and is not 
present yet. This leads to the error.
If I remove the RequireReleaseDeps from the rules it works fine.
Here is the simplified config of the maven-enforcer-plugin:

pluginManagement
  plugins
    plugin
      groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version${maven-enforcer-plugin.version}/version
  inheritedtrue/inherited
  executions
    execution
      goalsgoalenforce/goal/goals
    /execution
  /executions
  configuration
    !-- skip/ --
    rules
  requireReleaseDeps
    onlyWhenReleasefalse/onlyWhenRelease
  /requireReleaseDeps
  requireMavenVersion
    version[3.0.4,]/version
      /requireMavenVersion
    /rules
    fail${maven-enforcer-plugin.fail}/fail
      /configuration
    /plugin
  /plugins
/pluginManagement
  plugins
    plugin
   groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
    /plugin
  /plugins
/build

Is this behavior of the maven-enforcer-plug-in correct? If so, is there a way 
to work around it?
 
Matthias

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-enforcer-plugin problems with test dependency in multi module project

[Karl Heinz Marbaise]

Hi,

based on the error message you have a dependency on your test-jar 
project but you defined the dependency a little bit wrong:


test:test-child:jar:1.0.0: Failure to find test:test-parent:jar:tests:1.0.0

This shows that you have defined a dependency in the test-parent but 
like this:


 dependencies
dependency
  groupIdtest/groupId
  artifactIdtest-parent/artifactId
  version1.0-SNAPSHOT/version
 scopetest/scope
/dependency
 /dependencies

BUT you have to give the type in this case like this:

 dependencies
dependency
  groupIdtest/groupId
  artifactIdtest-parent/artifactId
  version1.0-SNAPSHOT/version
 typetest-jar/type
 scopetest/scope
/dependency
 /dependencies

Best test is to comment out the maven-enforcer-rule and try to build 
your project just from the parent via



mvn clean package

I assume in your case without the above fix your project will not build.
If it will you need to clean out your local repository first and retry it...


Kind regards
Karl Heinz Marbaise

 Hi,


I have a multi-module-project with one module that implements classes for 
testing (test-parent) and another module (test-child) that uses theses classes. 
There is a dependency in test scope from the test-child to the test-parent.
(See article 
http://stackoverflow.com/questions/1725476/maven-test-dependency-in-multi-module-project
 and 
http://maven.apache.org/guides/mini/guide-attached-tests.html[http://maven.apache.org/guides/mini/guide-attached-tests.html])
The pom of the depending test-child contains the following code:

dependencies
   dependency
 groupIdtest/groupId
 artifactIdtest-parent/artifactId
 version1.0-SNAPSHOT/version
 typetest-jar/type
 scopetest/scope
   /dependency
/dependencies

The test-parent module that contains the derived classes contains the following 
code:

plugins
   plugin
 artifactIdmaven-jar-plugin/artifactId
 version2.2/version
 executions
   execution
 goals
   goaltest-jar/goal
 /goals
 phasetest-compile/phase
   /execution
 /executions
   /plugin
/plugins

In a parent pom the maven-enforcer-plugin is included and the 
RequireReleaseDeps rule is added to the list of rules. While running the Maven 
goal “compile”  the project compilation of the test-child fails with the 
following message:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce (default) on 
project test-child: Execution default of goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.3.1:enforce failed: 
org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: Could 
not resolve dependencies for project test:test-child:jar:1.0.0: Failure to find 
test:test-parent:jar:tests:1.0.0
It seems that Maven checks the dependencies of type and scope “test” in the 
compile phase. In the case the test-jar is build in the test-compile and is not 
present yet. This leads to the error.
If I remove the RequireReleaseDeps from the rules it works fine.
Here is the simplified config of the maven-enforcer-plugin:

pluginManagement
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-enforcer-plugin/artifactId
   version${maven-enforcer-plugin.version}/version
   inheritedtrue/inherited
   executions
 execution
   goalsgoalenforce/goal/goals
 /execution
   /executions
   configuration
 !-- skip/ --
 rules
   requireReleaseDeps
 onlyWhenReleasefalse/onlyWhenRelease
   /requireReleaseDeps
   requireMavenVersion
 version[3.0.4,]/version
   /requireMavenVersion
 /rules
 fail${maven-enforcer-plugin.fail}/fail
   /configuration
 /plugin
   /plugins
/pluginManagement
   plugins
 plugin
groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-enforcer-plugin/artifactId
 /plugin
   /plugins
/build



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Some help needed with maven-enforcer-plugin

[Markward Schubert]

Hi All!

I am struggling with the enforcer-plugin's requireSameVersions rule.
Introducing the bannedDependencies rule was successful, but somehow I seem
to not get the right configuration for requireSameVersion.

Here is my config:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
executions
execution
idenforce-banned-dependencies/id
goals
goalenforce/goal
/goals
configuration
rules
bannedDependencies

searchTransitivetrue/searchTransitive
excludes
excludecommons-logging/exclude
/excludes
/bannedDependencies
/rules
failtrue/fail
/configuration
/execution
execution
idenforce-same-versions/id
goals
goalenforce/goal
/goals
configuration
rules
requireSameVersions
dependencies
dependencyorg.slf4j:*/dependency
/dependencies
/requireSameVersions
/rules
failtrue/fail
/configuration
/execution
/executions
configuration
ignoreCachetrue/ignoreCache
/configuration
/plugin

As a matter of fact we have

org.slf4j:slf4j-api:1.7.5

as well as

org.slf4j:com.springsource.slf4j.api:1.6.1

in our dependency tree. But still the build is SUCCESSFUL.
Did I get anything wrong here? Some misconfiguration.

I would expect that the rule as configured would enforce all
org.slf4j-group dependencies to have the same version.

Thanks for your help!

Markward

Re: Some help needed with maven-enforcer-plugin

[Paul Benedict]

I looked up the ticket that introduced the feature:
http://jira.codehaus.org/browse/MENFORCER-147

It doesn't look like it enforces dependency versions; it enforces that
Maven plugin versions in build match reporting.

Paul



On Tue, Nov 5, 2013 at 10:07 AM, Markward Schubert 
markward.schub...@gmail.com wrote:

 Hi All!

 I am struggling with the enforcer-plugin's requireSameVersions rule.
 Introducing the bannedDependencies rule was successful, but somehow I seem
 to not get the right configuration for requireSameVersion.

 Here is my config:

 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-enforcer-plugin/artifactId
 version1.3.1/version
 executions
 execution
 idenforce-banned-dependencies/id
 goals
 goalenforce/goal
 /goals
 configuration
 rules
 bannedDependencies

 searchTransitivetrue/searchTransitive
 excludes
 excludecommons-logging/exclude
 /excludes
 /bannedDependencies
 /rules
 failtrue/fail
 /configuration
 /execution
 execution
 idenforce-same-versions/id
 goals
 goalenforce/goal
 /goals
 configuration
 rules
 requireSameVersions
 dependencies

 dependencyorg.slf4j:*/dependency
 /dependencies
 /requireSameVersions
 /rules
 failtrue/fail
 /configuration
 /execution
 /executions
 configuration
 ignoreCachetrue/ignoreCache
 /configuration
 /plugin

 As a matter of fact we have

 org.slf4j:slf4j-api:1.7.5

 as well as

 org.slf4j:com.springsource.slf4j.api:1.6.1

 in our dependency tree. But still the build is SUCCESSFUL.
 Did I get anything wrong here? Some misconfiguration.

 I would expect that the rule as configured would enforce all
 org.slf4j-group dependencies to have the same version.

 Thanks for your help!

 Markward




-- 
Cheers,
Paul

Re: Some help needed with maven-enforcer-plugin

[Markward Schubert]

Thanks Paul,

ahh, I think I really misunderstood the docs.
The dependencies tag refers to dependencies of plugins, instead of
depenencies of the project.

Thanks!


2013/11/5 Paul Benedict pbened...@apache.org

 I looked up the ticket that introduced the feature:
 http://jira.codehaus.org/browse/MENFORCER-147

 It doesn't look like it enforces dependency versions; it enforces that
 Maven plugin versions in build match reporting.

 Paul



 On Tue, Nov 5, 2013 at 10:07 AM, Markward Schubert 
 markward.schub...@gmail.com wrote:

  Hi All!
 
  I am struggling with the enforcer-plugin's requireSameVersions rule.
  Introducing the bannedDependencies rule was successful, but somehow I
 seem
  to not get the right configuration for requireSameVersion.
 
  Here is my config:
 
  plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version1.3.1/version
  executions
  execution
  idenforce-banned-dependencies/id
  goals
  goalenforce/goal
  /goals
  configuration
  rules
  bannedDependencies
 
  searchTransitivetrue/searchTransitive
  excludes
 
 excludecommons-logging/exclude
  /excludes
  /bannedDependencies
  /rules
  failtrue/fail
  /configuration
  /execution
  execution
  idenforce-same-versions/id
  goals
  goalenforce/goal
  /goals
  configuration
  rules
  requireSameVersions
  dependencies
 
  dependencyorg.slf4j:*/dependency
  /dependencies
  /requireSameVersions
  /rules
  failtrue/fail
  /configuration
  /execution
  /executions
  configuration
  ignoreCachetrue/ignoreCache
  /configuration
  /plugin
 
  As a matter of fact we have
 
  org.slf4j:slf4j-api:1.7.5
 
  as well as
 
  org.slf4j:com.springsource.slf4j.api:1.6.1
 
  in our dependency tree. But still the build is SUCCESSFUL.
  Did I get anything wrong here? Some misconfiguration.
 
  I would expect that the rule as configured would enforce all
  org.slf4j-group dependencies to have the same version.
 
  Thanks for your help!
 
  Markward
 



 --
 Cheers,
 Paul

Re: Some help needed with maven-enforcer-plugin

[Robert Scholte]

This is indeed the expected configuration, so you might have hit a bug.

Robert

Op Tue, 05 Nov 2013 17:07:12 +0100 schreef Markward Schubert  
markward.schub...@gmail.com:



Hi All!

I am struggling with the enforcer-plugin's requireSameVersions rule.
Introducing the bannedDependencies rule was successful, but somehow I  
seem

to not get the right configuration for requireSameVersion.

Here is my config:

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
executions
execution
idenforce-banned-dependencies/id
goals
goalenforce/goal
/goals
configuration
rules
bannedDependencies

searchTransitivetrue/searchTransitive
excludes
excludecommons-logging/exclude
/excludes
/bannedDependencies
/rules
failtrue/fail
/configuration
/execution
execution
idenforce-same-versions/id
goals
goalenforce/goal
/goals
configuration
rules
requireSameVersions
dependencies
dependencyorg.slf4j:*/dependency
/dependencies
/requireSameVersions
/rules
failtrue/fail
/configuration
/execution
/executions
configuration
ignoreCachetrue/ignoreCache
/configuration
/plugin

As a matter of fact we have

org.slf4j:slf4j-api:1.7.5

as well as

org.slf4j:com.springsource.slf4j.api:1.6.1

in our dependency tree. But still the build is SUCCESSFUL.
Did I get anything wrong here? Some misconfiguration.

I would expect that the rule as configured would enforce all
org.slf4j-group dependencies to have the same version.

Thanks for your help!

Markward


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Apache Maven Enforcer Plugin 1.3.1 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Apache  
Maven Enforcer Plugin, version 1.3.1


This plugin provides goals to control certain environmental constraints  
such as Maven version, JDK version and OS family along with many more  
standard rules and user created rules.


http://maven.apache.org/plugins/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version1.3.1/version
/plugin


Release Notes - Maven 2.x Enforcer Plugin - Version 1.3.1

** Bug
* [MENFORCER-156] - Upgrading maven-enforcer-plugin from 1.2 to 1.3  
breaks maven-assembly-plugin
* [MENFORCER-157] - NOTICE file bad indentation  references software  
which is not actually included

* [MENFORCER-158] - LICENSE file contains duplicated copy


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Maven 3.0.5 - Strange Interaction/Regression: maven-enforcer-plugin vs. maven-assembly-plugin

[Wolf Geldmacher]

Hi list.

I just got hit by a weird interaction between two plugins, namely the 
maven-enforcer-plugin and the maven-assembly-plugin:


I recently updated the versions for the plugins used in my build and 
suddenly the creation of an assembly broke with an NPE:
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-assembly-plugin:2.4:single (assemble) 
on project extjars: Execution assemble of goal 
org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. 
NullPointerException - [Help 1]
Now the strange part is, that the m-a-p version had not been updated and 
the assembly descriptor had not been changed.


Further investigation revealed the update of m-e-p to be the cause of 
the error, as reverting to 1.2 (down from 1.3) magically made the build 
work again.


I think this is a bug/regression that should be fixed, but: which of the 
plugins should I file the Jira against? Is the m-e-p destroying data 
that it should not touch or did the changed behaviour of m-e-p uncover a 
bug in m-a-p?


If nothing else here's more proof of the necessity of nailing down all 
the versions to get a reproducible build...


If you feel up to reproducing/analyzing the error here are the two 
(merged and stripped down) files required:


pom.xml:

project xmlns=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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion

properties
plugins.maven-enforcer-plugin.version1.3/plugins.maven-enforcer-plugin.version
/properties

groupIdch.pecunifex.maven/groupId
artifactIdextjars/artifactId
version2014.0.0-SNAPSHOT/version
packagingpom/packaging
name3rd-party Jars Assembly/name
description
Collect all 3rd-party dependencies and assemble them for 
redistribution.

/description

prerequisites
maven3.0/maven
/prerequisites

dependencies
dependency
groupIdasm/groupId
artifactIdasm-commons/artifactId
version3.1/version
/dependency
dependency
groupIdasm/groupId
artifactIdasm/artifactId
version3.1/version
/dependency
!-- ... --
/dependencies

build
defaultGoalpackage/defaultGoal
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clean-plugin/artifactId
version2.4.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.7/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.3.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.0/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.4/version
executions
execution
idassemble/id
phasepackage/phase
goalsgoalsingle/goal/goals
configuration
appendAssemblyIdfalse/appendAssemblyId
descriptors
descriptor
extjars.xml
/descriptor
/descriptors
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version${plugins.maven-enforcer-plugin.version}/version
executions
execution
idenforce-plugin-versions/id
goals
goalenforce/goal
/goals
configuration
rules
requirePluginVersions
 messageBest Practice is to 
always define plugin versions!/message

/requirePluginVersions
/rules
/configuration
/execution
/executions
/plugin
/plugins
/build
/project

extjars.xml:

assembly 
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd;
idextjars/id
formats
formatzip/format
/formats

Re: Maven 3.0.5 - Strange Interaction/Regression: maven-enforcer-plugin vs. maven-assembly-plugin

[Stephen Connolly]

File the bug request against enforcer and let that move it *if* necessary
as initial evidence points to enforcer's issue


On 3 July 2013 13:40, Wolf Geldmacher wolf.geldmac...@abacus.ch wrote:

 Hi list.

 I just got hit by a weird interaction between two plugins, namely the
 maven-enforcer-plugin and the maven-assembly-plugin:

 I recently updated the versions for the plugins used in my build and
 suddenly the creation of an assembly broke with an NPE:

 [ERROR] Failed to execute goal org.apache.maven.plugins:**
 maven-assembly-plugin:2.4:**single (assemble) on project extjars:
 Execution assemble of goal org.apache.maven.plugins:**
 maven-assembly-plugin:2.4:**single failed. NullPointerException - [Help
 1]

 Now the strange part is, that the m-a-p version had not been updated and
 the assembly descriptor had not been changed.

 Further investigation revealed the update of m-e-p to be the cause of the
 error, as reverting to 1.2 (down from 1.3) magically made the build work
 again.

 I think this is a bug/regression that should be fixed, but: which of the
 plugins should I file the Jira against? Is the m-e-p destroying data that
 it should not touch or did the changed behaviour of m-e-p uncover a bug in
 m-a-p?

 If nothing else here's more proof of the necessity of nailing down all the
 versions to get a reproducible build...

 If you feel up to reproducing/analyzing the error here are the two (merged
 and stripped down) files required:

 pom.xml:

 project 
 xmlns=http://maven.apache.**org/POM/4.0.0http://maven.apache.org/POM/4.0.0
 
  
 xmlns:xsi=http://www.w3.org/**2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instance
 
  
 xsi:schemaLocation=http://**maven.apache.org/POM/4.0.0http://maven.apache.org/POM/4.0.0
 http://maven.apache.org/xsd/**maven-4.0.0.xsdhttp://maven.apache.org/xsd/maven-4.0.0.xsd
 
 modelVersion4.0.0/**modelVersion

 properties
 plugins.maven-enforcer-**plugin.version1.3/plugins.**
 maven-enforcer-plugin.version
 /properties

 groupIdch.pecunifex.maven/**groupId
 artifactIdextjars/**artifactId
 version2014.0.0-SNAPSHOT/**version
 packagingpom/packaging
 name3rd-party Jars Assembly/name
 description
 Collect all 3rd-party dependencies and assemble them for
 redistribution.
 /description

 prerequisites
 maven3.0/maven
 /prerequisites

 dependencies
 dependency
 groupIdasm/groupId
 artifactIdasm-commons/**artifactId
 version3.1/version
 /dependency
 dependency
 groupIdasm/groupId
 artifactIdasm/artifactId
 version3.1/version
 /dependency
 !-- ... --
 /dependencies

 build
 defaultGoalpackage/**defaultGoal
 plugins
 plugin
 groupIdorg.apache.maven.**plugins/groupId
 artifactIdmaven-clean-**plugin/artifactId
 version2.4.1/version
 /plugin
 plugin
 groupIdorg.apache.maven.**plugins/groupId
 artifactIdmaven-deploy-**plugin/artifactId
 version2.7/version
 /plugin
 plugin
 groupIdorg.apache.maven.**plugins/groupId
 artifactIdmaven-install-**plugin/artifactId
 version2.3.1/version
 /plugin
 plugin
 groupIdorg.apache.maven.**plugins/groupId
 artifactIdmaven-site-plugin**/artifactId
 version3.0/version
 /plugin
 plugin
 groupIdorg.apache.maven.**plugins/groupId
 artifactIdmaven-assembly-**plugin/artifactId
 version2.4/version
 executions
 execution
 idassemble/id
 phasepackage/phase
 goalsgoalsingle/goal/**goals
 configuration
 appendAssemblyIdfalse/**appendAssemblyId
 descriptors
 descriptor
 extjars.xml
 /descriptor
 /descriptors
 /configuration
 /execution
 /executions
 /plugin
 plugin
 groupIdorg.apache.maven.**plugins/groupId
 artifactIdmaven-enforcer-**plugin/artifactId
 version${plugins.maven-**enforcer-plugin.version}/**version
 executions
 execution
 idenforce-plugin-versions/**id
 goals
 goalenforce/goal
 /goals
 configuration
 rules
 requirePluginVersions
  messageBest Practice is to always
 define plugin versions!/message
 /requirePluginVersions
 /rules

Re: Maven 3.0.5 - Strange Interaction/Regression: maven-enforcer-plugin vs. maven-assembly-plugin

[Wolf Geldmacher]

Done: http://jira.codehaus.org/browse/MENFORCER-156

On 03.07.2013 15:27, Stephen Connolly wrote:

File the bug request against enforcer and let that move it *if* necessary
as initial evidence points to enforcer's issue


On 3 July 2013 13:40, Wolf Geldmacher wrote:


Hi list.

I just got hit by a weird interaction between two plugins, namely the
maven-enforcer-plugin and the maven-assembly-plugin:

I recently updated the versions for the plugins used in my build and
suddenly the creation of an assembly broke with an NPE:


[ERROR] Failed to execute goal org.apache.maven.plugins:**
maven-assembly-plugin:2.4:**single (assemble) on project extjars:
Execution assemble of goal org.apache.maven.plugins:**
maven-assembly-plugin:2.4:**single failed. NullPointerException - [Help
1]


Now the strange part is, that the m-a-p version had not been updated and
the assembly descriptor had not been changed.

Further investigation revealed the update of m-e-p to be the cause of the
error, as reverting to 1.2 (down from 1.3) magically made the build work
again.

I think this is a bug/regression that should be fixed, but: which of the
plugins should I file the Jira against? Is the m-e-p destroying data that
it should not touch or did the changed behaviour of m-e-p uncover a bug in
m-a-p?

If nothing else here's more proof of the necessity of nailing down all the
versions to get a reproducible build...

If you feel up to reproducing/analyzing the error here are the two (merged
and stripped down) files required:

pom.xml:

project 
xmlns=http://maven.apache.**org/POM/4.0.0http://maven.apache.org/POM/4.0.0

  
xmlns:xsi=http://www.w3.org/**2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instance

  
xsi:schemaLocation=http://**maven.apache.org/POM/4.0.0http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/**maven-4.0.0.xsdhttp://maven.apache.org/xsd/maven-4.0.0.xsd

 modelVersion4.0.0/**modelVersion

 properties
plugins.maven-enforcer-**plugin.version1.3/plugins.**
maven-enforcer-plugin.version
 /properties

 groupIdch.pecunifex.maven/**groupId
 artifactIdextjars/**artifactId
 version2014.0.0-SNAPSHOT/**version
 packagingpom/packaging
 name3rd-party Jars Assembly/name
 description
 Collect all 3rd-party dependencies and assemble them for
redistribution.
 /description

 prerequisites
 maven3.0/maven
 /prerequisites

 dependencies
 dependency
 groupIdasm/groupId
 artifactIdasm-commons/**artifactId
 version3.1/version
 /dependency
 dependency
 groupIdasm/groupId
 artifactIdasm/artifactId
 version3.1/version
 /dependency
 !-- ... --
 /dependencies

 build
 defaultGoalpackage/**defaultGoal
 plugins
 plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-clean-**plugin/artifactId
 version2.4.1/version
 /plugin
 plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-deploy-**plugin/artifactId
 version2.7/version
 /plugin
 plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-install-**plugin/artifactId
 version2.3.1/version
 /plugin
 plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-site-plugin**/artifactId
 version3.0/version
 /plugin
 plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-assembly-**plugin/artifactId
 version2.4/version
 executions
 execution
 idassemble/id
 phasepackage/phase
goalsgoalsingle/goal/**goals
 configuration
appendAssemblyIdfalse/**appendAssemblyId
 descriptors
 descriptor
 extjars.xml
 /descriptor
 /descriptors
 /configuration
 /execution
 /executions
 /plugin
 plugin
groupIdorg.apache.maven.**plugins/groupId
artifactIdmaven-enforcer-**plugin/artifactId
version${plugins.maven-**enforcer-plugin.version}/**version
 executions
 execution
 idenforce-plugin-versions/**id
 goals
 goalenforce/goal
 /goals
 configuration
 rules
 requirePluginVersions
  messageBest Practice is to always
define plugin versions!/message
 /requirePluginVersions

[ANN] Apache Maven Enforcer Plugin 1.3 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Maven  
Enforcer Plugin, version 1.3


The Enforcer plugin provides goals to control certain environmental  
constraints such as Maven version, JDK version and OS family along with  
many more standard rules and user created rules.


http://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version1.3/version
/plugin


Release Notes - Apache Maven 2.x Enforcer Plugin - Version 1.3

** Bug
* [MENFORCER-42] - Maven-Enforcer-Plugin fails in multimodule project  
when artifacts not in repository
* [MENFORCER-123] - BannedDependencies version number not taken into  
account
* [MENFORCER-126] - requirePluginVersions misreports plugins with  
artifactIds defined through properties
* [MENFORCER-146] - requireUpperBoundDeps inneffective when  
DependencyManagement is used

* [MENFORCER-148] - Broken hyperlink on Enforcer plugin usage page
* [MENFORCER-149] - Broken links to properties of Require OS Version  
of Maven Enforcer Plugin

* [MENFORCER-155] - Add rule RequirePrerequisite

** Improvement
* [MENFORCER-83] - Banned dependencies should support regular  
expressions
* [MENFORCER-134] - Require Upper Bound Dependencies and matching  
Snapshot Dependencies


** New Feature
* [MENFORCER-74] - The bannedDependencies rule should support  
classifier
* [MENFORCER-75] - The bannedDependencies rule should support scope  
condition

* [MENFORCER-147] - Add RequireSameVersions
* [MENFORCER-152] - Add Rule: BanDuplicatePomDependencyVersion or  
RequireUniquePomDependencyVersion


** Task
* [MENFORCER-153] - Use Mock Repository Manager for ITs
* [MENFORCER-154] - Update maven-dependency-tree to 2.1 to make it  
work with Maven-3.1+



Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven-enforcer-plugin to ban a transitive provided dependency

[dsilve]

Hi,
I have the following scenario: 
my project (A) has a number of compile dependencies on other internal
projects (B0, B1, B2 ...).
I would like to break the build of A in case Bx has been built depending on
an older release of A.

So for instance:

A:2.0-SNAPSHOT depends on B3:2.3
and
B3:2.3 depends on A:1.0 and this dependency is provided.

I tried to use the maven-enforcer-plugin to break the build of A in case
there is a transitive dependency whose groupId and artifactId are the same
as A, but it doesn't work because the dependency A:1.0 is provided.

Any suggestions?



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-enforcer-plugin-to-ban-a-transitive-provided-dependency-tp5752733.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-enforcer-plugin to ban a transitive provided dependency

[Stephen Connolly]

provided scope is not transitive, so that is why the build will not fail
using the enforcer rule that scans transitive dependencies. You probably
will need to write your own rule if this is something that you need


On 5 April 2013 09:47, dsilve davide.silves...@gmail.com wrote:

 Hi,
 I have the following scenario:
 my project (A) has a number of compile dependencies on other internal
 projects (B0, B1, B2 ...).
 I would like to break the build of A in case Bx has been built depending on
 an older release of A.

 So for instance:

 A:2.0-SNAPSHOT depends on B3:2.3
 and
 B3:2.3 depends on A:1.0 and this dependency is provided.

 I tried to use the maven-enforcer-plugin to break the build of A in case
 there is a transitive dependency whose groupId and artifactId are the same
 as A, but it doesn't work because the dependency A:1.0 is provided.

 Any suggestions?



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/maven-enforcer-plugin-to-ban-a-transitive-provided-dependency-tp5752733.html
 Sent from the Maven - Users mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-enforcer-plugin to ban a transitive provided dependency

[dsilve]

Thank you Stephen!

Does anybody knows if there is already a plugin able to this?

David

PS: Guys don't publish unrelated posts on this thread.



--
View this message in context: 
http://maven.40175.n5.nabble.com/maven-enforcer-plugin-to-ban-a-transitive-provided-dependency-tp5752733p5752745.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Maven Enforcer Plugin 1.2 Released

[Paul Gier]

The Maven team is pleased to announce the release of the Maven Enforcer
Plugin, version 1.2

The enforcer plugin provides goals to control certain environmental
constraints such as Maven version, JDK version and OS family along with
many more standard rules and user created rules.

http://maven.apache.org/plugins/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version1.2/version
/plugin

Release Notes - Maven 2.x Enforcer Plugin - Version 1.2

** Bug
* [MENFORCER-135] - Remove log.info in DependencyVersionMap.getVersion
* [MENFORCER-139] - Regex rule example is incorrect; matching is not
described

** Improvement
* [MENFORCER-137] - DependencyConvergence should log only as WARNING
instead of ERROR.
* [MENFORCER-140] - DependencyConvergence: upgrade
maven-dependency-tree dependency to 2.0 for better Maven 3 support
* [MENFORCER-141] - Show correct version of the enforcer api /
plugin in example

** New Feature
* [MENFORCER-97] - Standard rule to check that no dependencies have
system scope
* [MENFORCER-136] - New enforcer for environment variables
* [MENFORCER-138] - Rule to ban all transitive dependencies

** Task
* [MENFORCER-144] - generate every enforcer plugin site in /enforcer
and redirect previous /plugins/maven-enforcer-plugin
* [MENFORCER-145] - use maven-plugin-tools' java 5 annotations


Enjoy,

-The Maven team




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven Enforcer plugin: can I make it be quiet?

[Laird Nelson]

On Thu, Jul 19, 2012 at 4:27 PM, Barrie Treloar baerr...@gmail.com wrote:

 Laird, can you try the snapshot and see if that fixes the problem?


That does the trick; I'd be grateful if you would release it.

Best,
Laird

-- 
http://about.me/lairdnelson

Maven Enforcer plugin: can I make it be quiet?

[Laird Nelson]

The Maven Enforcer plugin version 1.1.1 outputs a ton of information at the
INFO level that seems to me to be repetitive and uninteresting.  Here is an
excerpt from a normal run:

[INFO] javax.annotation:jsr250-api 1.0 1.0
[INFO] javax.inject:javax.inject 1 1
[INFO] javax.inject:javax.inject 1 1
[INFO] javax.inject:javax.inject 1 1
[INFO] javax.validation:validation-api 1.0.0.GA 1.0.0.GA
[INFO] javax.ws.rs:jsr311-api 1.1.1 1.1.1
[INFO] junit:junit 4.10 4.10
[INFO] junit:junit 4.10 4.10
[INFO] junit:junit 4.10 4.10
[INFO] junit:junit 4.10 4.10
[INFO] junit:junit 4.10 4.10
[INFO] org.hamcrest:hamcrest-core 1.1 1.1

I could find no information in the documentation (
http://maven.apache.org/plugins/maven-enforcer-plugin/usage.html) to tell
me how to silence this output (other than, of course, the -q option to mvn
itself).

I of course want to see the output when it encounters an error.

Should I file an issue, or is this a known state of affairs that was
deliberately put in place?

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Maven Enforcer plugin: can I make it be quiet?

[Brian Fox]

Which rule spits that out? This seems unusual.

On Thu, Jul 19, 2012 at 6:11 PM, Laird Nelson ljnel...@gmail.com wrote:

 The Maven Enforcer plugin version 1.1.1 outputs a ton of information at the
 INFO level that seems to me to be repetitive and uninteresting.  Here is an
 excerpt from a normal run:

 [INFO] javax.annotation:jsr250-api 1.0 1.0
 [INFO] javax.inject:javax.inject 1 1
 [INFO] javax.inject:javax.inject 1 1
 [INFO] javax.inject:javax.inject 1 1
 [INFO] javax.validation:validation-api 1.0.0.GA 1.0.0.GA
 [INFO] javax.ws.rs:jsr311-api 1.1.1 1.1.1
 [INFO] junit:junit 4.10 4.10
 [INFO] junit:junit 4.10 4.10
 [INFO] junit:junit 4.10 4.10
 [INFO] junit:junit 4.10 4.10
 [INFO] junit:junit 4.10 4.10
 [INFO] org.hamcrest:hamcrest-core 1.1 1.1

 I could find no information in the documentation (
 http://maven.apache.org/plugins/maven-enforcer-plugin/usage.html) to tell
 me how to silence this output (other than, of course, the -q option to mvn
 itself).

 I of course want to see the output when it encounters an error.

 Should I file an issue, or is this a known state of affairs that was
 deliberately put in place?

 Best,
 Laird

 --
 http://about.me/lairdnelson

Re: Maven Enforcer plugin: can I make it be quiet?

[Barrie Treloar]

On Fri, Jul 20, 2012 at 8:53 AM, Brian Fox bri...@infinity.nu wrote:
 Which rule spits that out? This seems unusual.

Its probably DependencyVersionMap.getVersion which was a bug since 1.0
See http://jira.codehaus.org/browse/MENFORCER-135

I've fixed it, but I haven't cut a new release.

Laird, can you try the snapshot and see if that fixes the problem?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Maven Enforcer plugin: can I make it be quiet?

[Laird Nelson]

On Thu, Jul 19, 2012 at 4:27 PM, Barrie Treloar baerr...@gmail.com wrote:

 Laird, can you try the snapshot and see if that fixes the problem?


Sure; which snapshot, now?  1.2-SNAPSHOT could not be found via
oss.sonatype.org or repo1.  Not sure what other repo to try?

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Maven Enforcer plugin: can I make it be quiet?

[Tamás Cservenák]

https://repository.apache.org/index.html#nexus-search;gav~org.apache.maven.plugins~maven-enforcer-plugin~~~

it is RAO not OSO ;)

On Fri, Jul 20, 2012 at 1:42 AM, Laird Nelson ljnel...@gmail.com wrote:

 On Thu, Jul 19, 2012 at 4:27 PM, Barrie Treloar baerr...@gmail.com
 wrote:

  Laird, can you try the snapshot and see if that fixes the problem?
 

 Sure; which snapshot, now?  1.2-SNAPSHOT could not be found via
 oss.sonatype.org or repo1.  Not sure what other repo to try?

 Best,
 Laird

 --
 http://about.me/lairdnelson

[ANN] Maven Enforcer Plugin 1.1.1 Released

[Barrie Treloar]

The Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.1.1

This plugin provides goals to control certain environmental
constraints such as Maven version, JDK version and OS family along
with many more standard rules and user created rules.

http://maven.apache.org/plugins/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-enforcer-plugin/artifactId
  version1.1.1/version
/plugin

Release Notes - Maven 2.x Enforcer Plugin - Version 1.1.1

** Bug
* [MENFORCER-117] - Custom Packaging with executions fails with
ArrayIndexOutOfBoundsException in RequirePluginVersions.java:702

** Task
* [MENFORCER-132] - Add missing rules to standard rules page and
reorder them

Enjoy,

-The Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

maven-enforcer-plugin: requireProperty example with wrong regex for project.version?

[Mirko Friedenhagen]

Hello,

I followed the instructions from
http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
and put the example configuration into my pom:

   requireProperty
propertyproject.version/property
messageProject version must be
specified./message
regex(\d|-SNAPSHOT)$/regex
regexMessageProject version must
end in a number or -SNAPSHOT./regexMessage
/requireProperty

My project.version does end in -SNAPSHOT, however Maven keeps complaining:
[DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireProperty
[DEBUG] Adding failure due to exception
org.apache.maven.enforcer.rule.api.EnforcerRuleException: Project
version must end in a number or -SNAPSHOT.
at 
org.apache.maven.plugins.enforcer.RequireProperty.execute(RequireProperty.java:81)

Looking at 
http://svn.apache.org/viewvc/maven/enforcer/tags/1.0.1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireProperty.java?view=markup
the rule uses String.matches in line 73.

Changing to regex.*(\d|-SNAPSHOT)$/regex does succeed, so probabyl
only the example is wrong.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Possible to limit enforcer plugin to a lifecycle phase?

[laredotornado-3]

Hi,

I'm using Maven 3.0.3.  If my Maven run includes the verify phase, I want
to check to see if certain properties were included at the command line. 
I've found the Maven enforcer plugin to be useful for this purpose
(guaranteeing things are included and conform to a certain value), but I
can't figure out how to adjust it to only check for these properties if the
Maven run includes the verify phase.

So for example, if someone runs mvn clean test, I don't care if they
forgot to include the tomcat.manager.url property.

Thanks for any help along these lines, - Dave

--
View this message in context: 
http://maven.40175.n5.nabble.com/Possible-to-limit-enforcer-plugin-to-a-lifecycle-phase-tp5056623p5056623.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Usage of Enforcer Plugin 1.1-SNAPSHOT

[Abid Hussain]

Hi,

we have problems with maven using a wrong version of enforcer plugin.

In the project's pom the enforcer plugin is specified like this:
plugins
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
executions
  execution
idenforce-versions/id
goals
  goalenforce/goal
/goals
configuration
  !-- ... --
/configuration
  /execution
/executions
  /plugin
/plugins

As you can see, no version number of the plugin is declared nor is it in any 
parent pom of this project.

Building the project fails as maven tries to use the 1.1-SNAPSHOT version of 
enforcer plugin which doesn't exisit in our repository. Most recent version in 
maven central is currently 1.0.1.

I wonder why maven uses a SNAPSHOT version of the plugin?

And furthermore, how does maven determine the version number of a 
plugin/dependency when no version number is specified?

Regards,

Abid
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Usage of Enforcer Plugin 1.1-SNAPSHOT

[Guo Du]

 I wonder why maven uses a SNAPSHOT version of the plugin?
Which maven version you use?

A build log will helps to understand your problem.

-Guo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Usage of Enforcer Plugin 1.1-SNAPSHOT

[Barrie Treloar]

On Thu, Nov 10, 2011 at 8:42 PM, Guo Du mrdu...@duguo.org wrote:
 I wonder why maven uses a SNAPSHOT version of the plugin?
 Which maven version you use?

 A build log will helps to understand your problem.

And best practice is to lock down the version numbers, which
ironically enforcer will tell you to do.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Usage of Enforcer Plugin 1.1-SNAPSHOT

[Abid Hussain]

Thanks. We fixed the problem by locking down the version number of enforcer 
plugin. We're using maven 2.2.1.

But still I wonder about the behaviour when no version number has been 
specified...
How are the version numbers determined by maven?

How can it happen that maven uses a snapshot version as it is a maven 
convention that snapshot projects are at a development stage?

Regards,

Abid

 On Thu, Nov 10, 2011 at 8:42 PM, Guo Du mrdu...@duguo.org wrote:
  I wonder why maven uses a SNAPSHOT version of the plugin?
  Which maven version you use?
 
  A build log will helps to understand your problem.
 
 And best practice is to lock down the version numbers, which
 ironically enforcer will tell you to do.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: enforcer plugin rules to prevent circular dependencies

[Phillip Hellewell]

On Mon, Mar 28, 2011 at 10:52 AM, Caoilte O'Connor caoi...@gmail.com wrote:
 Thanks for the detailed reply Philip,

 On Sat, Mar 26, 2011 at 3:43 AM, Phillip Hellewell ssh...@gmail.com wrote:

 In other words, if any of my dependencies are myself, then it throws
 an exception.

 Were you able to release this anywhere or is it something I could re-develop
 easily enough with the DependencyTreeBuilder.

It's not released anywhere but I could check with my boss to find out
if we could contribute back to the community.

But we're only talking about a few dozen lines of code, so you could
probably figure it out.  Look at the dependency plugin source to give
you a hint on how to do it.  BTW, we are also using this same plugin
to detect version clashes (same dependency appears more than once with
different versions).

 I don't think it is really possible to introduce a cycle when using
 releases, but it is definitely possible with snapshots (just follow
 the steps in the bug).

 I think we were able to introduce this bug by having

 Version 2 of Project A depending  on version 1 of Project B which depends on
 version 1 of Project A.

Oh yes, of course.  I'm not sure why I let myself be led to believe
this could not happen with releases.

Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: enforcer plugin rules to prevent circular dependencies

[Caoilte O'Connor]

Thanks for the detailed reply Philip,

Comments inline

On Sat, Mar 26, 2011 at 3:43 AM, Phillip Hellewell ssh...@gmail.com wrote:

 On Fri, Mar 25, 2011 at 8:45 AM, Wendy Smoak wsm...@gmail.com wrote:
  On Fri, Mar 25, 2011 at 5:55 AM, Caoilte O'Connor caoi...@gmail.com
 wrote:
  Hi,
  I've just discovered the enforcer plugin and would like to use it to
 reduce
  our dependency conflicts but a bigger problem for us when it does turn
 up
  are circular dependencies. The Dependency Tree plugin spots these, but
 does
  anyone have any rules for the enforcer plugin to fail the build if it
  occurs?

 I wrote a plugin to do it.  It uses
 org.apache.maven.shared.dependency.tree.DependencyTreeBuilder to get
 the list of DependencyNode.  Then it cycles through each one calling
 getArtifact() and compares it to see if it is the same as the main
 project's Artifact (same group id and artifact id).

 In other words, if any of my dependencies are myself, then it throws
 an exception.


Were you able to release this anywhere or is it something I could re-develop
easily enough with the DependencyTreeBuilder.



  In what situation does the build get far enough to use a plugin to
  detect this?  I thought Maven would just stop with an error if it
  encountered a cycle.

 I have heard that it will catch a cycle in a reactor build, but
 otherwise no, it won't catch it.  That's why I submitted this bug a
 couple months ago: http://jira.codehaus.org/browse/MNG-4999

 I don't think it is really possible to introduce a cycle when using
 releases, but it is definitely possible with snapshots (just follow
 the steps in the bug).


I think we were able to introduce this bug by having

Version 2 of Project A depending  on version 1 of Project B which depends on
version 1 of Project A.

Regards

Caoilte

enforcer plugin rules to prevent circular dependencies

[Caoilte O'Connor]

Hi,
I've just discovered the enforcer plugin and would like to use it to reduce
our dependency conflicts but a bigger problem for us when it does turn up
are circular dependencies. The Dependency Tree plugin spots these, but does
anyone have any rules for the enforcer plugin to fail the build if it
occurs?

Thanks


Caoilte

maven-enforcer-plugin and Maven 3

[Jeff MAURY]

Hello,

the rule 'Require Plugin Versions' is discarded when run in Maven 3, not in
Maven 2.
Is there any reason and how to achieve the same behaviour using Maven 3 ?

Thanks
Jeff MAURY

-- 
Legacy code often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury

Re: enforcer plugin rules to prevent circular dependencies

[Wendy Smoak]

On Fri, Mar 25, 2011 at 5:55 AM, Caoilte O'Connor caoi...@gmail.com wrote:
 Hi,
 I've just discovered the enforcer plugin and would like to use it to reduce
 our dependency conflicts but a bigger problem for us when it does turn up
 are circular dependencies. The Dependency Tree plugin spots these, but does
 anyone have any rules for the enforcer plugin to fail the build if it
 occurs?

In what situation does the build get far enough to use a plugin to
detect this?  I thought Maven would just stop with an error if it
encountered a cycle.

-- 
Wendy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-enforcer-plugin and Maven 3

[Marc Rohlfs]

There's already a bug report about this (You could vote for it):
http://jira.codehaus.org/browse/MENFORCER-98

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: enforcer plugin rules to prevent circular dependencies

[Phillip Hellewell]

On Fri, Mar 25, 2011 at 8:45 AM, Wendy Smoak wsm...@gmail.com wrote:
 On Fri, Mar 25, 2011 at 5:55 AM, Caoilte O'Connor caoi...@gmail.com wrote:
 Hi,
 I've just discovered the enforcer plugin and would like to use it to reduce
 our dependency conflicts but a bigger problem for us when it does turn up
 are circular dependencies. The Dependency Tree plugin spots these, but does
 anyone have any rules for the enforcer plugin to fail the build if it
 occurs?

I wrote a plugin to do it.  It uses
org.apache.maven.shared.dependency.tree.DependencyTreeBuilder to get
the list of DependencyNode.  Then it cycles through each one calling
getArtifact() and compares it to see if it is the same as the main
project's Artifact (same group id and artifact id).

In other words, if any of my dependencies are myself, then it throws
an exception.

 In what situation does the build get far enough to use a plugin to
 detect this?  I thought Maven would just stop with an error if it
 encountered a cycle.

I have heard that it will catch a cycle in a reactor build, but
otherwise no, it won't catch it.  That's why I submitted this bug a
couple months ago: http://jira.codehaus.org/browse/MNG-4999

I don't think it is really possible to introduce a cycle when using
releases, but it is definitely possible with snapshots (just follow
the steps in the bug).

You can read my thread about cycle detection from a couple months ago
here: 
http://maven.40175.n5.nabble.com/Why-is-Maven-allowing-cycles-td3355428.html

Phillip

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[maven enforcer plugin] maven enforcer plugin - plugin using = version #

[Josh J]

Using maven enforcer plugin, how can I ensure that all projects are using a
a plugin version = than the one I defined?

For example, I want to ensure all the projects in the company (we use a
company super pom) use maven release plugin = 2.1 version

In the company super pom we are using pluginManagement section. However,
child projects can always override this value and I need to trace which
project has overriden this value.


(crossposted from
http://stackoverflow.com/questions/5208051/maven-enforcer-plugin-plugin-using-version
)


Thanks,

Josh

Version 1.0 of maven-enforcer-plugin not deployed

[Johan Hedin]

Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the 
repo1.maven.org is empty.


[INFO] 
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
Downloading: 
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] A required plugin was not found: Plugin could not be found - check that 
the goal name is correct: Unable to download the artifact from any repository

Try downloading the file manually from the project website.

Then, install it using the command: 
mvn install:install-file -DgroupId=org.apache.maven.plugins 
-DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
-Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there: 
mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins 
-DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

from the specified remote repositories:
  mawell-repository.snapshots 
(scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
(scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

from the specified remote repositories:
  mawell-repository.snapshots 
(scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
(scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

TIA

Johan Hedin


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version 1.0 of maven-enforcer-plugin not deployed

[Vincent Latombe]

I can reach the artifact just fine.

Vincent


2010/11/9 Johan Hedin johan.he...@mawell.com

 Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the
 repo1.maven.org is empty.


 [INFO]
 
 Downloading:
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
 Downloading:
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] A required plugin was not found: Plugin could not be found - check
 that the goal name is correct: Unable to download the artifact from any
 repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
 -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file
 there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots (scpexe://
 repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases (scpexe://
 repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots (scpexe://
 repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases (scpexe://
 repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

 TIA

 Johan Hedin


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Version 1.0 of maven-enforcer-plugin not deployed

[Anders Hammar]

What goal did you specify? The plugin exists at Maven central.

/Anders

On Tue, Nov 9, 2010 at 00:09, Johan Hedin johan.he...@mawell.com wrote:

 Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the
 repo1.maven.org is empty.


 [INFO]
 
 Downloading:
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
 Downloading:
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] A required plugin was not found: Plugin could not be found - check
 that the goal name is correct: Unable to download the artifact from any
 repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
 -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file
 there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots (scpexe://
 repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases (scpexe://
 repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots (scpexe://
 repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases (scpexe://
 repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

 TIA

 Johan Hedin


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Version 1.0 of maven-enforcer-plugin not deployed

[Stephen Connolly]

It can take a few hours to fully sync if it's more than 24 hours
after the announcement, then it's time to start screaming!

On 8 November 2010 23:09, Johan Hedin johan.he...@mawell.com wrote:
 Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the 
 repo1.maven.org is empty.


 [INFO] 
 
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] A required plugin was not found: Plugin could not be found - check 
 that the goal name is correct: Unable to download the artifact from any 
 repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
    mvn install:install-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file there:
    mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

 TIA

 Johan Hedin


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Version 1.0 of maven-enforcer-plugin not deployed

[Stephen Connolly]

Oh and I can see the artifact just fine

On 9 November 2010 09:25, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 It can take a few hours to fully sync if it's more than 24 hours
 after the announcement, then it's time to start screaming!

 On 8 November 2010 23:09, Johan Hedin johan.he...@mawell.com wrote:
 Maven refuses to build. Version 1.0 of maven-enforcer-plugin in the 
 repo1.maven.org is empty.


 [INFO] 
 
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.pom
 Downloading: 
 http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-enforcer-plugin/1.0/maven-enforcer-plugin-1.0.jar
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] A required plugin was not found: Plugin could not be found - check 
 that the goal name is correct: Unable to download the artifact from any 
 repository

 Try downloading the file manually from the project website.

 Then, install it using the command:
    mvn install:install-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file

 Alternatively, if you host your own repository you can deploy the file there:
    mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins 
 -DartifactId=maven-enforcer-plugin -Dversion=1.0 -Dpackaging=maven-plugin 
 -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)


  org.apache.maven.plugins:maven-enforcer-plugin:maven-plugin:1.0

 from the specified remote repositories:
  mawell-repository.snapshots 
 (scpexe://repository.intra.mawell.com/opt/m2repository/snapshots),
  mawell-repository.releases 
 (scpexe://repository.intra.mawell.com/opt/m2repository/deploy),
  central (http://repo1.maven.org/maven2)

 TIA

 Johan Hedin


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org