[jira] (MJARSIGNER-35) verbose mode shows keystore password in clear text
[ https://jira.codehaus.org/browse/MJARSIGNER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=341973#comment-341973 ] S van Sabben commented on MJARSIGNER-35: Where is the deployment location? So I can use also the 1.3.2-SNAPSHOT version. I have a problem with MJARSIGNER-34 and encrypted passwords. Hopefully it is also solved with the fix for MJARSIGNER-34. verbose mode shows keystore password in clear text -- Key: MJARSIGNER-35 URL: https://jira.codehaus.org/browse/MJARSIGNER-35 Project: Maven Jar Signer Plugin Issue Type: Bug Affects Versions: 1.3.1 Reporter: Marco Speranza Assignee: Tony Chemit Fix For: 1.3.2 If is enabled verbose output, is printed out to the command line the keystore password in clear text. here is an example: [INFO] cmd.exe /X /C C:\Program Files\Java\jdk1.7.0_51\jre\..\bin\jarsigner.exe -verbose -keystore mc-keystore -storepass mypassword -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJARSIGNER-35) verbose mode shows keystore password in clear text
[ https://jira.codehaus.org/browse/MJARSIGNER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=341975#comment-341975 ] Tony Chemit commented on MJARSIGNER-35: --- You can use the snapshot repository http://repository.apache.org/content/groups/snapshots verbose mode shows keystore password in clear text -- Key: MJARSIGNER-35 URL: https://jira.codehaus.org/browse/MJARSIGNER-35 Project: Maven Jar Signer Plugin Issue Type: Bug Affects Versions: 1.3.1 Reporter: Marco Speranza Assignee: Tony Chemit Fix For: 1.3.2 If is enabled verbose output, is printed out to the command line the keystore password in clear text. here is an example: [INFO] cmd.exe /X /C C:\Program Files\Java\jdk1.7.0_51\jre\..\bin\jarsigner.exe -verbose -keystore mc-keystore -storepass mypassword -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJARSIGNER-35) verbose mode shows keystore password in clear text
[ https://jira.codehaus.org/browse/MJARSIGNER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=341991#comment-341991 ] S van Sabben commented on MJARSIGNER-35: Thanks! I see that storepass and keypass value now displays with * in the logging. Great. I also use the verify goal with maven password encryption. The verify goal didn't include -storepass, -keypass -storetype and -providerName. Did the 1.3.2-snapshot not contains the changes that are made for MJARSIGNER-34? verbose mode shows keystore password in clear text -- Key: MJARSIGNER-35 URL: https://jira.codehaus.org/browse/MJARSIGNER-35 Project: Maven Jar Signer Plugin Issue Type: Bug Affects Versions: 1.3.1 Reporter: Marco Speranza Assignee: Tony Chemit Fix For: 1.3.2 If is enabled verbose output, is printed out to the command line the keystore password in clear text. here is an example: [INFO] cmd.exe /X /C C:\Program Files\Java\jdk1.7.0_51\jre\..\bin\jarsigner.exe -verbose -keystore mc-keystore -storepass mypassword -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-628) Bogus warning when assembling to a directory
[ https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=341993#comment-341993 ] Laurent TOURREAU commented on MASSEMBLY-628: This issue is still present in version 2.4 when using Maven 3.1.1 Can you please reopen it? Bogus warning when assembling to a directory Key: MASSEMBLY-628 URL: https://jira.codehaus.org/browse/MASSEMBLY-628 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3 Java version: 1.6.0_32, vendor: Sun Microsystems Inc. Java home: c:\Program Files\Java\jdk1.6.0_32\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows maven-assembly-plugin:2.3 Reporter: Vinicius Isola Attachments: test.zip When adding a dir format to the assembly file, it will output a bogus warning like the following: [WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a regular file (it may be a directory). It cannot be attached to the project build for installation or deployment. I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289 Attached is an example project that can reproduce the problem just running mvn clean install -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-183) Multiple programming language support
Andrey Utis created MPMD-183: Summary: Multiple programming language support Key: MPMD-183 URL: https://jira.codehaus.org/browse/MPMD-183 Project: Maven PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 3.0.1 Reporter: Andrey Utis Currently PMD supports multiple languages (with 5.1.0 it supports even more). But the only way to run the PMD plugin for multiple languages is to run multiple executions. It would be great to be able to configure multiple languages within one execution. Example: a project that contains Java, JavaScript, Velocity templates, and PL/SQL code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-184) Excludes file for non-Java languages
Andrey Utis created MPMD-184: Summary: Excludes file for non-Java languages Key: MPMD-184 URL: https://jira.codehaus.org/browse/MPMD-184 Project: Maven PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 3.0.1 Reporter: Andrey Utis Currently there's an exclude file mechanism for Java language violations (if we have pre-existing code that violates some rules, but still want to enforce the rule going forward). This mechanism doesn't work for other languages. It should be generalized to work for any programming language supported by PMD. I know I originally implemented the excludes mechanism, so if I find some time, I will try to work on this. But if anyone else is able to fix this, that would be great :) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5591) Installing workspace reader triggers MNG-5503
[
https://jira.codehaus.org/browse/MNG-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342003#comment-342003
]
Jason van Zyl commented on MNG-5591:
Sure, I'm aware how Sisu works and I'll look at the workspace reader as this is
working fine in m2e where we have a workspace reader installed and nothing
showed up in the tests. I'll take a look later this week.
Installing workspace reader triggers MNG-5503
-
Key: MNG-5591
URL: https://jira.codehaus.org/browse/MNG-5591
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.2.1
Reporter: Mikolaj Izdebski
Attachments:
0001-MNG-5591-Set-role-hint-for-ReactorReader-to-default.patch,
dummy-extension.tar.gz
It looks like Maven 3.2.1 introduced a regression. Installing
extension which provides workspace reader triggers MNG-5503.
Maven resolves artifacts from reactor, workspace, repositories (in
that order). In standard Maven distribution there is no workspace,
but Maven provides an extension point which allows extensions to
install workspace reader by providing a component with role
{{org.eclipse.aether.repository.WorkspaceReader}} and role hint {{ide}}.
Installing workspace reader extension in Maven 3.2.1 triggers a
regression - Maven fails to resolve artifacts produced by reactor
build (MNG-5503). Even though artifact is present in reactor Maven
queries workspace about it and if artifact is not found there it
continues with repositories. Expected behaviour is resolving artifact
from reactor.
Steps to reproduce this:
1) download and extract {{apache-maven-3.2.1-bin.tar.gz}}
2) download dummy-extension.tar.gz and build it with {{mvn package}}
3) download reproducer for MNG-5503 from:
https://bugzilla.redhat.com/attachment.cgi?id=784786
4) try to build reproducer project, it succeeds
5) copy {{dummy-extension-1.0.0.jar}} to Maven {{lib/ext}}
6) try to build reproducer project, it fails
When repeating the same steps for Maven 3.1.1 failure is not reproducible.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342004#comment-342004 ] Jason van Zyl commented on MNG-5207: This looks relatively easy to fix, Stephen seems to have a handle on it but the question is whether this is something that we actually want. While I'd admit what you're doing is ingenious I've never seen people use reactor different versions for the projects that are in the reactor and this is what is implicitly enforced. Not saying it's right or wrong right now, but that it works in 2.x where be basically have no formal specification is not in and of itself a compelling reason to restore. But it should either work or fail and tell you why. [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers - Key: MNG-5207 URL: https://jira.codehaus.org/browse/MNG-5207 Project: Maven 2 3 Issue Type: Bug Components: Reactor and workspace Affects Versions: 3.0.3 Reporter: Jörg Schaible Assignee: Jason van Zyl Priority: Critical Fix For: Issues to be reviewed for 4.x Attachments: mng5207-it.tgz, mng-5207-minimal.tar.gz, MNG-5207.tgz Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in proper order, if a transitive dependency (that is part of the reactor build) is overruled in the dependencyManagement section with the current SNAPSHOT version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5207) [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342007#comment-342007 ] Jörg Schaible commented on MNG-5207: For me it is a simple consequence using dependencyManagement for transitive deps. If you're allowed to overwrite/manage a transitive dep with a SNAPSHOT version, then Maven should also recognize that it is part of the current reactor build and adjust the build sequence accordingly, because it *requires* the SNAPSHOT at some point. If you have cleaned your local repo before, the build simply breaks if the build order does not respect this dependency. Currently Maven is simply not aware at all stages what it tries to build. [Regression] Maven 3 fails to calculate proper build order with dependencies with classifiers - Key: MNG-5207 URL: https://jira.codehaus.org/browse/MNG-5207 Project: Maven 2 3 Issue Type: Bug Components: Reactor and workspace Affects Versions: 3.0.3 Reporter: Jörg Schaible Assignee: Jason van Zyl Priority: Critical Fix For: Issues to be reviewed for 4.x Attachments: mng5207-it.tgz, mng-5207-minimal.tar.gz, MNG-5207.tgz Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in proper order, if a transitive dependency (that is part of the reactor build) is overruled in the dependencyManagement section with the current SNAPSHOT version. Build order is perfectly calculated with Maven 2.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5592) Maven Dependency Resolution Locks up
Mark Derricutt created MNG-5592:
---
Summary: Maven Dependency Resolution Locks up
Key: MNG-5592
URL: https://jira.codehaus.org/browse/MNG-5592
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.1.1, 3.2.1
Environment: OS/X, Java 7 and Java 8
Reporter: Mark Derricutt
One one of my larger integration projects that involves A LOT of version ranges
across a broad range of dependencies I'm seeing that Maven locks up resolving
dependencies.
I've recently seen this in 3.1.1 but it's happening more and more often under
3.2.1.
It appears that Eclipse Aether is falling into a circular loop somewhere and
locking up.
{code}
main #1 prio=5 os_prio=31 tid=0x7f966b001000 nid=0x1903 runnable
[0x000103559000]
java.lang.Thread.State: RUNNABLE
at
org.eclipse.aether.util.graph.transformer.ConflictResolver$ConflictContext.isIncluded(ConflictResolver.java:1062)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector$1.accept(NearestVersionSelector.java:145)
at
org.eclipse.aether.util.graph.visitor.PathRecordingDependencyVisitor.visitEnter(PathRecordingDependencyVisitor.java:88)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:324)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure(NearestVersionSelector.java:149)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector.backtrack(NearestVersionSelector.java:111)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector.selectVersion(NearestVersionSelector.java:84)
at
org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:187)
at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:275)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317)
at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at
[jira] (MNG-5592) Maven Dependency Resolution Locks up
[
https://jira.codehaus.org/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Derricutt updated MNG-5592:
Description:
One one of my larger integration projects that involves A LOT of version ranges
across a broad range of dependencies I'm seeing that Maven locks up resolving
dependencies.
I've recently seen this in 3.1.1 but it's happening more and more often under
3.2.1.
It appears that Eclipse Aether is falling into a circular loop somewhere and
locking up.
{code}
main #1 prio=5 os_prio=31 tid=0x7f966b001000 nid=0x1903 runnable
[0x000103559000]
java.lang.Thread.State: RUNNABLE
at
org.eclipse.aether.util.graph.transformer.ConflictResolver$ConflictContext.isIncluded(ConflictResolver.java:1062)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector$1.accept(NearestVersionSelector.java:145)
at
org.eclipse.aether.util.graph.visitor.PathRecordingDependencyVisitor.visitEnter(PathRecordingDependencyVisitor.java:88)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:324)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure(NearestVersionSelector.java:149)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector.backtrack(NearestVersionSelector.java:111)
at
org.eclipse.aether.util.graph.transformer.NearestVersionSelector.selectVersion(NearestVersionSelector.java:84)
at
org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:187)
at
org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:275)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317)
at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
{code}
Running with {{-X -U}} I can see that Maven/Aether seems to be
[jira] (MNG-5592) Maven Dependency Resolution Locks up
[
https://jira.codehaus.org/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=342029#comment-342029
]
Mark Derricutt commented on MNG-5592:
-
Interesting, I left my build running a {{depenency:tree}} run whilst out for
lunch and just over an hour later I got the following on my console:
{code}
[ERROR] Failed to execute goal on project bundles: Could not resolve
dependencies for project smx3.integration:bundles:pom:3.0.1-SNAPSHOT: Failed to
collect dependencies for
[smx3.lib:com.springsource.org.apache.commons.codec:jar:1.3.0 (compile?),
smx3.lib:com.springsource.org.apache.commons.lang:jar:2.4.0 (compile?),
smx3.lib:spring:jar:2.5.5 (compile?), smx3.lib:javamail:jar:1.4 (compile?),
org.apache.commons:commons-lang3:jar:3.1 (compile),
com.google.guava:guava:jar:16.0.1 (compile),
com.smxemail:com.smxemail.api:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.cachesupport:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.validation:jar:[2.0.0,) (compile),
com.smxemail:com.smxemail.util:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.ldap:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.pdf:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.translation:jar:[13.2.10,) (compile),
com.smxemail:com.smxemail.template:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.rest:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.email:jar:[16.0.0,) (compile),
com.smxemail:com.smxemail.mustache:jar:[1.0.2-SNAPSHOT,) (compile),
smx3:smx3.spi:jar:[1.2.1,) (compile), smx3:smx3.api:jar:[12.1.0,) (compile),
smx3:smx3.defaultconfiguration:jar:[4.0.0,) (compile),
com.smxemail:com.smxemail.hibernate:jar:[16.0.2,) (compile),
smx3:smx3.entity:jar:[9.3.32,) (compile), smx3:smx3.entitysearch:jar:[9.3.32,)
(compile), smx3:smx3.schema:jar:[13.0.0,) (compile),
smx3:smx3.schemalookups:jar:[1.0.0,) (compile),
smx3:smx3.mounting:jar:[9.3.32,) (compile), smx3:smx3.email:jar:[9.3.32,)
(compile), smx3:smx3.resources.email:jar:[9.3.32,) (compile),
smx3:smx3.partyresource:jar:[9.3.32,) (compile),
smx3:smx3.validation:jar:[9.3.32,) (compile), smx3:smx3.agreement:jar:[9.3.32,)
(compile), smx3:smx3.servicecontext:jar:[9.3.32,) (compile),
smx3:smx3.smartrules:jar:[9.3.26,) (compile),
smx3:smx3.smartrules.dsl:jar:[9.3.33,) (compile),
smx3:smx3.smartrules.library:jar:[9.3.42,) (compile),
smx3:smx3.templates:jar:[9.3.32,) (compile), smx3:smx3.injection:jar:[9.3.32,)
(compile), smx3:smx3.monitoring:jar:[7.0.8,) (compile),
smx3:smx3.reporting:jar:[9.3.27,) (compile), smx3:smx3.statistics:jar:[9.3.27,)
(compile), smx3:smx3.invoicing:jar:[9.3.26,) (compile),
smx3:smx3.standardreports:jar:[3.0.80,) (compile),
smx3:smx3.standardtranslations:jar:[3.0.142,) (compile),
smx3:smx3.applicationmanager.api:jar:[10.0.4,) (compile),
smx3:smx3.applicationmanager:jar:[9.1.10-SNAPSHOT,) (compile),
smx3:smx3.products.newzealand:jar:[1.0.13,) (compile),
org.apache.felix:org.apache.felix.webconsole:jar:2.0.6 (compile?),
org.apache.felix:org.apache.felix.bundlerepository:jar:1.2.1 (compile?),
org.apache.felix:org.apache.felix.eventadmin:jar:1.2.14 (compile?),
org.apache.felix:org.apache.felix.scr:jar:1.4.0 (compile?),
org.apache.felix:org.apache.felix.configadmin:jar:1.2.4 (compile?),
org.apache.felix:org.apache.felix.metatype:jar:1.0.4 (compile?),
org.apache.felix:org.apache.felix.http.jetty:jar:2.2.0 (compile?),
org.apache.sling:org.apache.sling.commons.log:jar:2.0.2-incubator (compile?),
org.apache.sling:org.apache.sling.api:jar:2.0.8 (compile?),
commons-io:commons-io:jar:1.4 (compile?),
commons-collections:commons-collections:jar:3.2.1 (compile?)]: Could not
resolve version conflict among [smx3:smx3.agreement:jar:[9.3.32,),
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.agreement:jar:[9.0.0,10.0.0),
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.1 - smx3:smx3.agreement:jar:9.0.1,
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.2 - smx3:smx3.agreement:jar:9.0.2,
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.3 - smx3:smx3.agreement:jar:9.0.3,
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.4 - smx3:smx3.agreement:jar:9.0.4,
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.5 - smx3:smx3.agreement:jar:9.0.5,
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.6 - smx3:smx3.agreement:jar:9.0.6,
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.7 - smx3:smx3.agreement:jar:9.0.7,
smx3:smx3.smartrules:jar:[9.3.26,) - smx3:smx3.templates:jar:[9.0.0,10.0.0) -
smx3:smx3.smartrules:jar:9.0.8 -
