[jira] [Updated] (MSHARED-952) PrettyPrintXmlWriter output is platform dependent
[ https://issues.apache.org/jira/browse/MSHARED-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MSHARED-952: Fix Version/s: (was: maven-shared-utils-3.4.0) maven-shared-utils-3.3.4 > PrettyPrintXmlWriter output is platform dependent > - > > Key: MSHARED-952 > URL: https://issues.apache.org/jira/browse/MSHARED-952 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Critical > Fix For: maven-shared-utils-3.3.4 > > > This makes the test platform dependent. All this code can be ripped out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-969) Environment variable with null value
[
https://issues.apache.org/jira/browse/MSHARED-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MSHARED-969:
Fix Version/s: (was: maven-shared-utils-3.4.0)
maven-shared-utils-3.3.4
> Environment variable with null value
>
>
> Key: MSHARED-969
> URL: https://issues.apache.org/jira/browse/MSHARED-969
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.3
>Reporter: Slawomir Jaranowski
>Assignee: Martin Kanters
>Priority: Major
> Fix For: maven-shared-utils-3.3.4
>
>
> When we add environment variable with {{null}} value then to executed process
> is pass variable with {{"null"}} as string.
> Variable with {{null}} value should not be set, when executed process will
> try to get this variable will receive {{null}} as we expect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-962) Upgrade Jansi to 2.0.1
[ https://issues.apache.org/jira/browse/MSHARED-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MSHARED-962: Fix Version/s: (was: maven-shared-utils-3.4.0) maven-shared-utils-3.3.4 > Upgrade Jansi to 2.0.1 > -- > > Key: MSHARED-962 > URL: https://issues.apache.org/jira/browse/MSHARED-962 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: maven-shared-utils-3.3.4 > > > Changelog: [https://github.com/fusesource/jansi/blob/master/changelog.md] > Performance optimizations, particularly for Windows > Utilize VIRTUAL_TERMINAL native feature in recent Windows versions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-973) Upgrade Jansi to 2.2.0
[ https://issues.apache.org/jira/browse/MSHARED-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MSHARED-973: Fix Version/s: (was: maven-shared-utils-3.4.0) maven-shared-utils-3.3.4 > Upgrade Jansi to 2.2.0 > -- > > Key: MSHARED-973 > URL: https://issues.apache.org/jira/browse/MSHARED-973 > Project: Maven Shared Components > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Robert Scholte >Priority: Major > Fix For: maven-shared-utils-3.3.4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-954) Deprecate StringUtils.unifyLineSeparator
[ https://issues.apache.org/jira/browse/MSHARED-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MSHARED-954: Fix Version/s: (was: maven-shared-utils-3.4.0) maven-shared-utils-3.3.4 > Deprecate StringUtils.unifyLineSeparator > > > Key: MSHARED-954 > URL: https://issues.apache.org/jira/browse/MSHARED-954 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Major > Fix For: maven-shared-utils-3.3.4 > > > This method produces platform dependent code and contributes to > non-reproducible builds. In the context of Maven this is almost never what's > needed. Use an explicit line separator such as "\n" or "\r\n" instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-951) Checked exception converted to raw runtime exception
[
https://issues.apache.org/jira/browse/MSHARED-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MSHARED-951:
Fix Version/s: (was: maven-shared-utils-3.4.0)
maven-shared-utils-3.3.4
> Checked exception converted to raw runtime exception
>
>
> Key: MSHARED-951
> URL: https://issues.apache.org/jira/browse/MSHARED-951
> Project: Maven Shared Components
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: maven-shared-utils-3.3.4
>
>
> In Xpp3DOMBuilder
> ```
> public static Xpp3Dom build( @WillClose InputStream is, @Nonnull String
> encoding, boolean trim )
> throws XmlPullParserException
> {
> try
> {
> Reader reader = new InputStreamReader( is, encoding );
> return build( reader, trim );
> }
> catch ( UnsupportedEncodingException e )
> {
> throw new RuntimeException( e );
> }
> }
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-350) Split @Parameter into @Input and @Output
[
https://issues.apache.org/jira/browse/MPLUGIN-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305429#comment-17305429
]
Arnaud Heritier commented on MPLUGIN-350:
-
I agree that the granularity of the description is important and more granular
infos we have better we can control the behavior.
But let's be honest, we don't necessarily have to target something ideal from
the beginning (it's often the problem we have in maven ecosystem to try to do
things perfects from the beginning - it's good because we rarely have to
update/break our features but it's bad because the project moves very slowly).
On this topic we have also the advantage to not be precursors on this topic and
we can look at what others are doing like Gradle:
https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks
> Split @Parameter into @Input and @Output
>
>
> Key: MPLUGIN-350
> URL: https://issues.apache.org/jira/browse/MPLUGIN-350
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> By knowing if parameters are input or output parameters, it is possible to
> improve our builds. It will be possible to create DAGs and chain the
> execution blocks much smarter.
> The Maven Extension created by Gradle heavily relies on this kind of
> information.
> It is probably easier to use new annotations instead of adding a (required)
> status-field to @Parameter
> Looking at the {{plugin.xml}} it looks quite easy to solve this and stay
> backwards compatible: the file looks now like:
> {code:xml}
>
>
> ...
>
>
> {code}
> With plexus-magic the following should still work:
> {code:xml}
>
>
> ...
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1048) Unrecognized option: --no-transfer-progress
[ https://issues.apache.org/jira/browse/MRELEASE-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143634#comment-17143634 ] Arnaud Heritier commented on MRELEASE-1048: --- I had a quick look at it. This option is effectively not declared in [https://github.com/apache/maven-release/blob/master/maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/InvokerMavenExecutor.java] but the real problem is that we cannot pass to the InvocationRequest a TransfertListerner like we do in a MavenExecutionRequest [https://github.com/apache/maven/blob/658ad90b3850131e4a73fd6cca2ead30f6e5f213/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1469-L1484] We could probably have a workaround by just defining the system property -[Dorg.slf4j.simpleLogger.log.org|http://dorg.slf4j.simplelogger.log.org/].apache.maven.cli.transfer.Slf4jMavenTransferListener=warn like in pre 3.6.1 but it's not really clean ... WDYT [~rfscholte] ? > Unrecognized option: --no-transfer-progress > --- > > Key: MRELEASE-1048 > URL: https://issues.apache.org/jira/browse/MRELEASE-1048 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.5.3 >Reporter: Olivier Vernin >Priority: Major > > ``` > usr/share/maven/bin/mvn B -s settings-release.xml > -Darguments='-no-transfer-progress' release:prepare > > Failed to execute goal > org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on > project remoting: Failed to re-parse additional arguments for Maven > invocation. Unrecognized option: --no-transfer-progress -> [Help 1] > ``` > > maven version > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /usr/share/maven > Java version: 1.8.0_252, vendor: Oracle Corporation, runtime: > /usr/local/openjdk-8/jre > Default locale: en, platform encoding: UTF-8 > OS name: "linux", version: "4.15.0-1082-azure", arch: "amd64", family: "unix" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081315#comment-17081315
]
Arnaud Heritier commented on MRELEASE-1042:
---
I created this projects which is reproducing the issue as soon as you have some
activeProfiles in your user settings
[https://github.com/aheritier/MRELEASE-1042]
Running the build in debug, you will see that the release:perform do not add
the foo and bar profiles
I think I start to understand where the problem is but I am not an expert
enough in this plugin to have a strong opinion.
With the new architecture the RunPerformGoalsPhase
[https://github.com/apache/maven-release/blob/master/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/RunPerformGoalsPhase.java#L55]
is taking the arguments to pass to the build from
AbstractRunGoalsPhase#getAdditionalArguments
[https://github.com/apache/maven-release/blob/master/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRunGoalsPhase.java#L100]
but this one is taking its profiles only from the
releaseDescriptor.getActivateProfiles() and completely ignores the mojo
configuration and its releaseProfiles
In the release descriptor (exec.activateProfiles) I have effectively only my
settings profiles because the "release:prepare" mojo do not see the
"releaseProfiles" config entry AFAIK
Thus when the release.properties is generated we are supposed to add the
"releaseProfiles" but "getAdditionalProfiles()" returns null in the prepare
Mojo (it's only implemented in perform) thus we completely lost the info
[https://github.com/apache/maven-release/blob/master/maven-release-plugin/src/main/java/org/apache/maven/plugins/release/AbstractReleaseMojo.java#L191-L208]
One solution could be to let the perform mojo see (implement) the
releaseProfiles config argument to allow it to store it in the
release.properties which is used by perform.
Or the perform mojo has to be reworked to append its releaseProfiles config to
the getActivateProfiles()
Not sure, if it makes sense for you.
[~rfscholte], [~olamy], [~hboutemy] I am removing myself as assignee as I am
not sure to be able to fix it properly with my limited knowledge, at least
without some guidance
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Assignee: Arnaud Heritier
>Priority: Major
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier reassigned MRELEASE-1042:
-
Assignee: (was: Arnaud Heritier)
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Priority: Major
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17081287#comment-17081287
]
Arnaud Heritier commented on MRELEASE-1042:
---
I have no idea for now
I did a quick code review and found nothing weird in the chain to compute the
list of profiles.
We correctly add in the "activateProfiles" the ones which are coming from the
maven session and the ones configured in releaseProfiles
I tried to add a test in the PerformReleaseMojoTest to reproduce the issue and
I cannot :(
I will try to create a test project ..
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Assignee: Arnaud Heritier
>Priority: Major
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier reassigned MRELEASE-1042:
-
Assignee: Arnaud Heritier
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Assignee: Arnaud Heritier
>Priority: Major
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080631#comment-17080631
]
Arnaud Heritier commented on MRELEASE-1042:
---
Rolling back to 2.x to finish my release I confirm that the profiles are all set
{noformat}
[INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
/Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
/var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings629775235847682.xml
-f pom.xml deploy --no-plugin-updates -P
cloudbees-internal-deploy,cloudbees-snapshots,apache-staging,cloudbees-internal-release
-f pom.xml{noformat}
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Priority: Major
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
[
https://issues.apache.org/jira/browse/MRELEASE-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080629#comment-17080629
]
Arnaud Heritier commented on MRELEASE-1042:
---
With debug logs I confirm that the settings from the parent are correctly
injected
{noformat}
[DEBUG] Goal:
org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform (default-cli)
[DEBUG] Style: Aggregating
[DEBUG] Configuration:
${arguments}
${connectionUrl}
${dryRun}
${goals}
${localCheckout}
forked-path
${password}
${pomFileName}
cloudbees-internal-release
${releaseStrategyId}
false
${username}
${workingDirectory}
...
[DEBUG] (f) releaseProfiles = cloudbees-internal-release{noformat}
I can share privately with a developer the full debug logs.
I will see if I can try t have a look at the code this week-end
> releaseProfiles get overriden by activeProfiles
> ---
>
> Key: MRELEASE-1042
> URL: https://issues.apache.org/jira/browse/MRELEASE-1042
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M2
>Reporter: Arnaud Heritier
>Priority: Major
>
> I tried to release a project with 3.0.0-M2 and potentially it is another
> problem related to MRELEASE-1038 [~rfscholte] [~olamy]
>
> In our corporate POM we have a pluginManagement entry:
> {code:java}
>
> maven-release-plugin
> 2.5.3
>
> forked-path
> false
> cloudbees-internal-release
>
>
> {code}
> My project extends it and has no settings related to the release plugin
> In my user settings I have
> {code:java}
>
> cloudbees-internal-deploy
> cloudbees-snapshots
> apache-staging
>
> {code}
> Then I release my project using 3.0.0-M2 with
> {code:java}
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
> org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
> {code}
> The perform step is taking my user profiles but not the ones from
> "releaseProfiles"
> {noformat}
> [INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
> /Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
> /var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
> -f pom.xml deploy -P
> cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
> pom.xml{noformat}
> Not sure if it could be because I call the release plugin with the full GAV
> but it is strange ...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MRELEASE-1042) releaseProfiles get overriden by activeProfiles
Arnaud Heritier created MRELEASE-1042:
-
Summary: releaseProfiles get overriden by activeProfiles
Key: MRELEASE-1042
URL: https://issues.apache.org/jira/browse/MRELEASE-1042
Project: Maven Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 3.0.0-M2
Reporter: Arnaud Heritier
I tried to release a project with 3.0.0-M2 and potentially it is another
problem related to MRELEASE-1038 [~rfscholte] [~olamy]
In our corporate POM we have a pluginManagement entry:
{code:java}
maven-release-plugin
2.5.3
forked-path
false
cloudbees-internal-release
{code}
My project extends it and has no settings related to the release plugin
In my user settings I have
{code:java}
cloudbees-internal-deploy
cloudbees-snapshots
apache-staging
{code}
Then I release my project using 3.0.0-M2 with
{code:java}
mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:prepare
org.apache.maven.plugins:maven-release-plugin:3.0.0-M2:perform
{code}
The perform step is taking my user profiles but not the ones from
"releaseProfiles"
{noformat}
[INFO] Executing: /bin/sh -c cd /Users/arnaud/some/path/target/checkout &&
/Users/arnaud/.asdf/installs/maven/3.6.3/bin/mvn -s
/var/folders/bw/j0tmy8p52szfms6c7qb0tx2rgn/T/release-settings4094445863857985100.xml
-f pom.xml deploy -P
cloudbees-internal-deploy,cloudbees-snapshots,apache-staging -f
pom.xml{noformat}
Not sure if it could be because I call the release plugin with the full GAV but
it is strange ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1038) releaseProfiles get overriden by exec.pomFileName
[
https://issues.apache.org/jira/browse/MRELEASE-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077081#comment-17077081
]
Arnaud Heritier commented on MRELEASE-1038:
---
[~olamy] I think we should have considered this bug as a higher priority and do
another release.
I agree that there is a workaround but the time lost to fail a release, to
identify that the problems comes from this bug may give a lot of stress to some
people.
Yes it's a M1, not a final release but in our ecosystem we have sadly often a
lot of releases in non-final versions for a long time and our users are using
them with no fear in general
> releaseProfiles get overriden by exec.pomFileName
> -
>
> Key: MRELEASE-1038
> URL: https://issues.apache.org/jira/browse/MRELEASE-1038
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 3.0.0-M1
>Reporter: Benoit MESSAGER
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiles specified in . are overrided by the
> pom file name.
> This come from : org.apache.maven.shared.release.config.ReleaseUtils line 130
> :
> {code:java}
> if ( properties.containsKey( "exec.activateProfiles" ) )
> {
> builder.setActivateProfiles( Arrays.asList( properties.getProperty(
> "exec.pomFileName" ).split( "," ) ) );
> }
> {code}
> this look like a failed copy/paste
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1019) mvn release perform fails when the tag has the same name than a branch
[ https://issues.apache.org/jira/browse/MRELEASE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783357#comment-16783357 ] Arnaud HERITIER commented on MRELEASE-1019: --- [~elecharny] could you share you logs to show the issue to the team. They'll better understand the clash between the 2.1.0 branch you have and the 2.1.0 tag you wanted to create and thus why the checkout was getting the branch content in release:perform instead of the tag Thx > mvn release perform fails when the tag has the same name than a branch > -- > > Key: MRELEASE-1019 > URL: https://issues.apache.org/jira/browse/MRELEASE-1019 > Project: Maven Release Plugin > Issue Type: Bug >Reporter: Emmanuel Lecharny >Priority: Major > > I tried to cut a release of Apache MINA 2.1.0 for a week, with no success. > Actually, the release was fine, but the packages weren't pushed in the Nexus > staging repo. > > After investigation with Arnaud Héritier, it appeared that the tag we wanted > to create collided with an existing branch, thus the release plugin was > fetching the code from the branch, not from the tag, resulting in the > target/checkout directory containing 2.1.1-SNAPSHOT versions of the code. > > Renaming the branch to 2.1 solved the issue. > > We do think that the release plugin should checkout the code from the created > tag, and not from the branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6393) Broken link in "Project maven is retired. See maven's attic page."
[ https://issues.apache.org/jira/browse/MNG-6393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435323#comment-16435323 ] Arnaud HERITIER commented on MNG-6393: -- I don't see this banner [~meri] I imagine it's a but, it's not retired :) Could you take a screenshot ? > Broken link in "Project maven is retired. See maven's attic page." > -- > > Key: MNG-6393 > URL: https://issues.apache.org/jira/browse/MNG-6393 > Project: Maven > Issue Type: Task >Reporter: Maria Jurcovicova >Priority: Major > > The [https://maven.apache.org/] page currently shows red banner on top. The > banner says: "Project _maven_ is retired. See maven's [attic page > |https://attic.apache.org/projects/maven.html]." > If maven was really retired, then the link in "attic page" is broken. There > does not seem to be any mention of maven in apache attic. If the project is > not retired, the banner should not be there. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6282) Console output has no colors (regression in Maven 3.5.1)
[ https://issues.apache.org/jira/browse/MNG-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161157#comment-16161157 ] Arnaud HERITIER commented on MNG-6282: -- Hi [~dejan2609] can you verify if colors are backs with `-Dstyle.color=always` I imagine the regression could come from MNG-6220 cc [~rfscholte] but strangely I don't succeed to use `-Dstyle.color` on my side. I need to investigate > Console output has no colors (regression in Maven 3.5.1) > > > Key: MNG-6282 > URL: https://issues.apache.org/jira/browse/MNG-6282 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.5.1 >Reporter: Dejan Stojadinović > Labels: regression > Attachments: screenshot-1.png > > > See > [screenshot|https://issues.apache.org/jira/secure/attachment/12886398/screenshot-1.png] > for more details. > _*Environment:*_ > * Windows 10, 64 bit > * Oracle Java, version: *1.8.0_144* -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980410#comment-15980410
]
Arnaud HERITIER commented on MNG-5883:
--
>From my POV the legacy mode should be deprecated one day and removed thus the
>info / warning / notice ?
{quote}The new repository behaviour causes local snapshot builds to be ignored
and breaks remote repository migrations.{quote}
There are issues open about these problems ? (I agree, I don't really like it
also myself and have various behaviors which were "borderline")
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975482#comment-15975482
]
Arnaud HERITIER commented on MNG-6220:
--
I'm interested to have the batch mode with color but a system property could be
enough
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15973380#comment-15973380
]
Arnaud HERITIER commented on MNG-6220:
--
Hi [~rfscholte], [~mryan]
I agree that it might be interesting to have the ability to programatically
activate / deactivate the color output but from my POV a command line option is
too much. It might be an extension point like proposed by Robert or a system
property but not more. End users (developers) won't really need it. This is
only useful for IDE, CI, .. and others integrations like mentioned here.
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6217) Creating a WARNING by using executions in pluginManagement
[
https://issues.apache.org/jira/browse/MNG-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964947#comment-15964947
]
Arnaud HERITIER commented on MNG-6217:
--
I think it works (I don't say it is a good thing / idea)
{code:xml}
...
exec1
...
exec2
...
...
exec1
...
exec2
...
{code}
> Creating a WARNING by using executions in pluginManagement
> --
>
> Key: MNG-6217
> URL: https://issues.apache.org/jira/browse/MNG-6217
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.1
>
>
> I can often observe that defining something like this in pluginManagement:
> {code:xml}
>
>
> ...
>
>
>
>
>
>
> {code}
> which is superfluous and shut not being done.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MSHARED-627) Enhance the ArtifactResolver with a method to resolve versions of an Artifact
[
https://issues.apache.org/jira/browse/MSHARED-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15884891#comment-15884891
]
Arnaud HERITIER commented on MSHARED-627:
-
AFAIR C = Classifier and T = Type (Packaging)
> Enhance the ArtifactResolver with a method to resolve versions of an Artifact
> -
>
> Key: MSHARED-627
> URL: https://issues.apache.org/jira/browse/MSHARED-627
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-artifact-transfer
>Affects Versions: maven-artifact-transfer-0.9.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-artifact-transfer-1.0.0
>
>
> The maven-artifact-transfer should be enhanced having a method to resolve
> versions of artifacts like this:
> {code:java}
> public interface ArtifactResolver {
> ..
> List resolveArtifactVersions( ProjectBuildingRequest buildingRequest,
> Artifact mavenArtifact )
> throws ArtifactResolverException;
> ..
> }
> {code}
> I have a [working implementation|https://svn.apache.org/r1784464] but I'm not
> sure if it should return a list of versions as plain String ?
> This will help to use maven-artifact-transfer also in other plugin for
> example in versions-maven-plugin.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER resolved MNG-5961.
--
Resolution: Fixed
Fixed in 3.5.0
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848169#comment-15848169
]
Arnaud HERITIER commented on MNG-5961:
--
no it's good [~michael-o] it was just to explain why I replaced the entry and I
didn't add a new one (I had the question, thus I prefer to keep a public trace
of it)
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15848117#comment-15848117
]
Arnaud HERITIER commented on MNG-5961:
--
About the fact to replace {{org.slf4j.helpers.Log4jLoggerFactory}} by
{{org.apache.logging.slf4j.Log4jLoggerFactory}} and not the addition of a new
entry it is because the old one was wrong.
{{org.slf4j.helpers.Log4jLoggerFactory}} is for LOG4J 1.x not 2.x
https://www.slf4j.org/xref/org/slf4j/impl/Log4jLoggerFactory.html
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER updated MNG-5961:
-
Fix Version/s: (was: needing-scrub-3.4.0-fallout)
3.5.0
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.5.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (MNG-6037) add gossip slf4j provider support
[ https://issues.apache.org/jira/browse/MNG-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847550#comment-15847550 ] Arnaud HERITIER commented on MNG-6037: -- what does it mean [~hboutemy]? Still no colorised console for Maven ?!? It's a running gag ... ??? > add gossip slf4j provider support > - > > Key: MNG-6037 > URL: https://issues.apache.org/jira/browse/MNG-6037 > Project: Maven > Issue Type: New Feature > Components: Logging >Affects Versions: 3.3.9 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: needing-scrub-3.4.0-fallout > > > Gossip slf4j provider: https://github.com/jdillon/gossip > Jason Dillon provided a pull request https://github.com/apache/maven/pull/81 > this implementation adds color to level rendering and error rendering > I removed the message colorization support (that added color by recognizing > patterns in messages) from the logging implementation and implemented it > directly in messages in MNG-3507 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15811577#comment-15811577
]
Arnaud HERITIER commented on MNG-5961:
--
This fix is trivial [~stephenc] we could re-apply it with no risk
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: needing-scrub-3.4.0-fallout
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MDEP-548) maven-dependency-plugin:get is broken in 3.0.0
Arnaud HERITIER created MDEP-548:
Summary: maven-dependency-plugin:get is broken in 3.0.0
Key: MDEP-548
URL: https://issues.apache.org/jira/browse/MDEP-548
Project: Maven Dependency Plugin
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Arnaud HERITIER
Using a command line call with no POM
With 3.0.0
{code}
mvn -X -B -U org.apache.maven.plugins:maven-dependency-plugin:3.0.0:get
-Dartifact=com.cloudbees.jenkins.main:jenkins-enterprise-war:2.7.21.1:war
-Dtransitive=false
[INFO] Scanning for projects...
[INFO] Downloading:
https://nexus-internal.cloudbees.com/content/groups/mirror/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml
[INFO] Downloaded:
https://nexus-internal.cloudbees.com/content/groups/mirror/org/apache/maven/plugins/maven-dependency-plugin/maven-metadata.xml
(921 B at 198 B/s)
[INFO]
[INFO]
[INFO] Building Maven Stub Project (No POM) 1
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:3.0.0:get (default-cli) @ standalone-pom ---
[INFO] Resolving com.cloudbees.jenkins.main:jenkins-enterprise-war:war:2.7.21.1
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 5.835 s
[INFO] Finished at: 2016-12-16T21:58:22+01:00
[INFO] Final Memory: 15M/172M
[INFO]
{code}
With 2.10
{code}
mvn -X -B -U org.apache.maven.plugins:maven-dependency-plugin:3.0.0:get
-Dartifact=com.cloudbees.jenkins.main:jenkins-enterprise-war:2.7.21.1:war
-Dtransitive=false
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Maven Stub Project (No POM) 1
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.10:get (default-cli) @ standalone-pom ---
[INFO] Resolving com.cloudbees.jenkins.main:jenkins-enterprise-war:war:2.7.21.1
[INFO] Downloading:
https://nexus-internal.cloudbees.com/content/groups/mirror/com/cloudbees/jenkins/main/jenkins-enterprise-war/2.7.21.1/jenkins-enterprise-war-2.7.21.1.war
...
{code}
cc [~rfscholte]
I'm on Apache Maven 3.4.0-SNAPSHOT but my coworkers has the issue with 3.3.9
and others releases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152381#comment-15152381
]
Arnaud HERITIER commented on MNG-5971:
--
I agree that the import scope which add depMgt entries which cannot be
redefined was always a nightmare especially nowdays where BOMs are often used
and thus you can override a part of the depMgt with a BOM if the entries were
already defined in another one.
Changing the behavior is difficult, but I'm not sure if it isn't better than an
new scope which will be difficult to explain: import vs include
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Wish
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118996#comment-15118996
]
Arnaud HERITIER commented on MNG-5607:
--
Have a look at this : https://github.com/search?q=M2_HOME=Code=✓
You'll just see how it is widely used.
Thus yes we can add MVN_HOME ( = M2_HOME) which isn't difficult to do and
backward compatible but I'm not in favor to just rename M2_HOME to MVN_HOME or
to remove M2_HOME
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5607) Don't use M2_HOME anymore in mvn shell/batch file anymore
[
https://issues.apache.org/jira/browse/MNG-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15118961#comment-15118961
]
Arnaud HERITIER commented on MNG-5607:
--
Yes I have a big doubt to change this for 3.4.x
We can introduce it with MVN_HOME value that takes M2_HOME as value if it
exists but Otherwise I think it is dangerous. I'm sure that in various
integrations of Maven M2_HOME is used ...
> Don't use M2_HOME anymore in mvn shell/batch file anymore
> -
>
> Key: MNG-5607
> URL: https://issues.apache.org/jira/browse/MNG-5607
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.1
> Environment: all
>Reporter: Karl Heinz Marbaise
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
>
> Currently the {{mvn}} shell script and the {{mvn.bat}} using {{M2_HOME}}.
> This should be changed either to {{MAVEN_HOME}} or {{M3_HOME}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116976#comment-15116976 ] Arnaud HERITIER commented on MNG-5966: -- Ahh we replaced or .bat by .cmd scripts ? ok it is a little bit more powerful :-) > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15116921#comment-15116921 ] Arnaud HERITIER commented on MNG-5966: -- Great [~juven] !!! I didn't see it was yours. Happy to see you always involved in our community. Thanks a lot [~hboutemy] For windows with a classical DOS session I think it's not possible. But within Cygwin or powershell yes .. > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114574#comment-15114574 ] Arnaud HERITIER commented on MNG-5966: -- +1000 > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: 3.4.0 >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER resolved MNG-5961.
--
Resolution: Fixed
Yes it is exactly what I just fixed in master (thus for 3.3.10) with the commit
mentionned by [~sgfan]
This bug was a subtask to complete MNG-3507 with LOG4J (Issue which may not be
solved soon)
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.3.10
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER updated MNG-5961:
-
Fix Version/s: 3.3.10
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
> Fix For: 3.3.10
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER reassigned MNG-5961:
Assignee: Arnaud HERITIER
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.3.10
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5961) Maven possibly not aware of log4j2
[
https://issues.apache.org/jira/browse/MNG-5961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098236#comment-15098236
]
Arnaud HERITIER commented on MNG-5961:
--
ok thanks [~michael-o] I didn't notice it
> Maven possibly not aware of log4j2
> --
>
> Key: MNG-5961
> URL: https://issues.apache.org/jira/browse/MNG-5961
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.9
>Reporter: Mike Drob
>Assignee: Arnaud HERITIER
> Fix For: 3.4.0
>
>
> Using a fresh install of maven 3.3.9 I followed the steps at
> https://garygregory.wordpress.com/2015/03/23/watch-maven-in-color to add
> color highlighting to my output. Everything works as expected, however on all
> usages I would get the warning:
> {noformat}
> [WARN] The SLF4J binding actually used is not supported by Maven:
> org.apache.logging.slf4j.Log4jLoggerFactory
> [WARN] Maven supported bindings are:
> [WARN] (from
> jar:file:/opt/apache-maven-3.3.9/lib/maven-embedder-3.3.9.jar!/META-INF/maven/slf4j-configuration.properties)
> - ch.qos.logback.classic.LoggerContext
> - org.slf4j.helpers.Log4jLoggerFactory
> - org.slf4j.impl.SimpleLoggerFactory
> {noformat}
> This looks pretty harmless, and I was able to suppress it by manually adding
> the line
> {code}
> org.apache.logging.slf4j.Log4jLoggerFactory
> org.apache.maven.cli.logging.impl.Log4j2Configuration
> {code}
> to {{/META-INF/maven/slf4j-configuration.properties}} in
> {{maven-embedder-3.3.9.jar}}.
> I'm not sure that this is a "correct" solution, and I'm not even confident I
> could explain what effect it has, hence not posting a patch, but somebody
> with more knowledge might be able to triage this better. Or offer an
> "official" way to do colorized output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5904) Remove the whole Ant Build
[
https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14946985#comment-14946985
]
Arnaud HERITIER commented on MNG-5904:
--
The advantage of the ant build was to define a system property {{M2_HOME}}
(existing path or not) and then ant took care to bootstrap maven and install
the distribution into {{M2_HOME}}.
With another shell using this maven deployed in {{M2_HOME}} I was able to test
it on various projects without having to manually extract and potentially move
the archive produce by {{mvn package}}
> Remove the whole Ant Build
> --
>
> Key: MNG-5904
> URL: https://issues.apache.org/jira/browse/MNG-5904
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.4.0
> Environment: We should remove the whole Ant build cause we have a
> large number of Maven versions which could be used to start building Maven
> itself.
> So i don't see any useful in it anymore.
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.4.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5904) Remove the whole Ant Build
[ https://issues.apache.org/jira/browse/MNG-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14946962#comment-14946962 ] Arnaud HERITIER commented on MNG-5904: -- Not sure Myself I'm using it to build and deploy in one step a new maven core distro locally. Maybe there is another way to build/install/test dev versions of maven core ? (At the end, based on my limited/inexistent contributions, I won't veto this if you judge it useful but verify if others dev aren't using it) > Remove the whole Ant Build > -- > > Key: MNG-5904 > URL: https://issues.apache.org/jira/browse/MNG-5904 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.4.0 > Environment: We should remove the whole Ant build cause we have a > large number of Maven versions which could be used to start building Maven > itself. > So i don't see any useful in it anymore. >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5902) URL contains illegal character ("[") for google guava artifact from central repo (goal: dependency:go-offline)
[
https://issues.apache.org/jira/browse/MNG-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943162#comment-14943162
]
Arnaud HERITIER commented on MNG-5902:
--
I'm not sure if it is a plain Maven issue or a Tycho issue
> URL contains illegal character ("[") for google guava artifact from central
> repo (goal: dependency:go-offline)
> --
>
> Key: MNG-5902
> URL: https://issues.apache.org/jira/browse/MNG-5902
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.2.3
> Environment: CentOS 6.7; Tycho 0.23.0
>Reporter: Mark Leone
>
> While running the Maven goal dependency:go-offline, the build fails while
> trying to download google guava artifacts from the central repository. The
> error message indicates an illegal character in the URL, specifically a "["
> character, which comes from the version specifier.
> First I run
> mvn -Dmaven.repo.local=/some/path/ -DgeneratePom=true clean install
> to create the artifacts, and that build succeeds. Then when I run
> mvn -Dmaven.repo.local=/some/path/ -o clean install
> it fails because it's running in offline mode and there is no local cache
> available for http://download.eclipse.org/tools/cdt/releases/8.6
> So then I run
> mvn -Dmaven.repo.local=/some/path/ dependency:go-offline
> to make it download all the artifacts it needs for the build, but it fails
> with this message:
> ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.8:resolve-plugins
> (resolve-plugins) on project : Nested: Could not transfer artifact
> com.google.guava:guava:jar:[10.0.1,14.0.1] from/to central
> (https://repo.maven.apache.org/maven2): Illegal character in path at index
> 60:
> https://repo.maven.apache.org/maven2/com/google/guava/guava/[10.0.1,14.0.1]/guava-[10.0.1,14.0.1].jar
> The product being built is an Eclipse RCP product, using the
> org.eclipse.tycho:target-platform-configuration plug-in to load the
> dependencies from an RCP target file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MNG-5842) java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty plugin
[
https://issues.apache.org/jira/browse/MNG-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER resolved MNG-5842.
--
Resolution: Duplicate
Fix Version/s: 3.3.7
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty
> plugin
>
>
> Key: MNG-5842
> URL: https://issues.apache.org/jira/browse/MNG-5842
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Jean-Christophe Gay
>Assignee: Arnaud HERITIER
> Fix For: 3.3.7
>
>
> When Maven is used with a different SLF4J implementation than slf4j-simple
> (in my case logback to have colored logs), running jetty-maven-plugin fails.
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T13:57:37+02:00)
> Maven home: /usr/local/Cellar/maven/3.3.3/libexec
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.3", arch: "x86_64", family: "mac"
> {code}
> {code}
> [WARNING] FAILED org.mortbay.jetty.plugin.JettyServer@66c4005:
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> java.lang.ClassNotFoundException: org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ~[plexus-classworlds-2.5.2.jar:na]
> ... 21 common frames omitted
> Wrapped by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:619)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.info(JettyAwareLogger.java:314)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.util.log.Slf4jLog.info(Slf4jLog.java:74)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.server.Server.doStart(Server.java:271)
> ~[jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
> ~[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:520)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:365)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:521)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [maven-core-3.3.1.jar:3.3.1]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:275)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:101)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
>
[jira] [Resolved] (MNG-5845) when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
[
https://issues.apache.org/jira/browse/MNG-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER resolved MNG-5845.
--
Resolution: Duplicate
Fix Version/s: 3.3.7
> when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
> -
>
> Key: MNG-5845
> URL: https://issues.apache.org/jira/browse/MNG-5845
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.3
> Environment: window7;
> maven 3.3.3;
> my custom maven plugin dependencies
>
>
>
> org.apache.maven
> maven-core
> 3.3.3
>
>
> org.apache.maven
> maven-plugin-api
> 3.3.3
>
>
>
> org.apache.maven.plugin-tools
> maven-plugin-annotations
> 3.4
> provided
>
>
>
> org.codehaus.plexus
> plexus-component-annotations
> 1.6
> provided
>
>
> org.codehaus.plexus
> plexus-container-default
> 1.6
>
>
> org.codehaus.plexus
> plexus-interactivity-api
> 1.0-alpha-6
>
>
> plexus
> plexus-utils
>
>
>
>
> org.codehaus.plexus
> plexus-utils
> 3.0.22
>
>
> org.apache.maven.plugin-testing
> maven-plugin-testing-harness
> 3.3.0
> test
>
>
> org.slf4j
> slf4j-api
> 1.7.12
>
>
> org.slf4j
> slf4j-log4j12
> 1.7.12
>
>
>Reporter: feilong
>Assignee: Arnaud HERITIER
> Labels: maven
> Fix For: 3.3.7
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> *my code is*
> {code}
> @Mojo(name = "hello",requiresProject = false)
> public class HelloWorldMojo extends AbstractMojo{
> @Override
> public void execute() throws MojoExecutionException,MojoFailureException{
> String[] argStrings = { "Hello world" };
> FormattingTuple formattingTuple = MessageFormatter.arrayFormat("{}",
> argStrings);
> getLog().info(formattingTuple.getMessage());
> }
> }
> {code}
> *when i run my plugins , show me result:*
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at com.feilong.core.log.Slf4jUtil.formatMessage(Slf4jUtil.java:77)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.getFolderPath(BaseFlowMojo.java:72)
> at
> com.feilong.project.train.mojo.InvitationMojo.handleExecute(InvitationMojo.java:89)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.execute(BaseFlowMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.lang.ClassNotFoundException:
> org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 26 more
> {code}
> *And from the log (run with -X), i see that :*
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T19:57:37+08:00)
> Maven home: D:\FeiLong Soft\Essential\Development\apache-maven-3.3.3\bin\..
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: D:\Program Files\Java\jdk1.8.0_11\jre
> Default locale: zh_CN, platform encoding: GBK
> OS name: "windows 7", version: "6.1", arch: "x86", family: "dos"
> [DEBUG] Created new class realm maven.api
> [DEBUG] Importing foreign packages into class realm maven.api
> [DEBUG] Imported: javax.enterprise.inject.* < plexus.core
> [DEBUG] Imported: javax.enterprise.util.* < plexus.core
> [DEBUG] Imported: javax.inject.* < plexus.core
> [DEBUG]
[jira] [Commented] (MNG-5842) java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty plugin
[
https://issues.apache.org/jira/browse/MNG-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941190#comment-14941190
]
Arnaud HERITIER commented on MNG-5842:
--
Reported as MNG-5845, and MNG-5787. The problem comes from the fact that we are
exporting the slf4j-api artefact, thus plugins cannot use their own version but
we forgot to export the content of the package org/slf4j/helpers. Thus the
`java.lang.ClassNotFoundException: org.slf4j.helpers.MessageFormatter`
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty
> plugin
>
>
> Key: MNG-5842
> URL: https://issues.apache.org/jira/browse/MNG-5842
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Jean-Christophe Gay
>
> When Maven is used with a different SLF4J implementation than slf4j-simple
> (in my case logback to have colored logs), running jetty-maven-plugin fails.
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T13:57:37+02:00)
> Maven home: /usr/local/Cellar/maven/3.3.3/libexec
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.3", arch: "x86_64", family: "mac"
> {code}
> {code}
> [WARNING] FAILED org.mortbay.jetty.plugin.JettyServer@66c4005:
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> java.lang.ClassNotFoundException: org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ~[plexus-classworlds-2.5.2.jar:na]
> ... 21 common frames omitted
> Wrapped by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:619)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.info(JettyAwareLogger.java:314)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.util.log.Slf4jLog.info(Slf4jLog.java:74)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.server.Server.doStart(Server.java:271)
> ~[jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
> ~[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:520)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:365)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:521)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [maven-core-3.3.1.jar:3.3.1]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:275)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:101)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_40]
> at
>
[jira] [Commented] (MNG-5845) when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
[
https://issues.apache.org/jira/browse/MNG-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941189#comment-14941189
]
Arnaud HERITIER commented on MNG-5845:
--
Reported as MNG-5842, and MNG-5787. The problem comes from the fact that we are
exporting the slf4j-api artefact, thus plugins cannot use their own version but
we forgot to export the content of the package org/slf4j/helpers. Thus the
`java.lang.ClassNotFoundException: org.slf4j.helpers.MessageFormatter`
> when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
> -
>
> Key: MNG-5845
> URL: https://issues.apache.org/jira/browse/MNG-5845
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.3
> Environment: window7;
> maven 3.3.3;
> my custom maven plugin dependencies
>
>
>
> org.apache.maven
> maven-core
> 3.3.3
>
>
> org.apache.maven
> maven-plugin-api
> 3.3.3
>
>
>
> org.apache.maven.plugin-tools
> maven-plugin-annotations
> 3.4
> provided
>
>
>
> org.codehaus.plexus
> plexus-component-annotations
> 1.6
> provided
>
>
> org.codehaus.plexus
> plexus-container-default
> 1.6
>
>
> org.codehaus.plexus
> plexus-interactivity-api
> 1.0-alpha-6
>
>
> plexus
> plexus-utils
>
>
>
>
> org.codehaus.plexus
> plexus-utils
> 3.0.22
>
>
> org.apache.maven.plugin-testing
> maven-plugin-testing-harness
> 3.3.0
> test
>
>
> org.slf4j
> slf4j-api
> 1.7.12
>
>
> org.slf4j
> slf4j-log4j12
> 1.7.12
>
>
>Reporter: feilong
> Labels: maven
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> *my code is*
> {code}
> @Mojo(name = "hello",requiresProject = false)
> public class HelloWorldMojo extends AbstractMojo{
> @Override
> public void execute() throws MojoExecutionException,MojoFailureException{
> String[] argStrings = { "Hello world" };
> FormattingTuple formattingTuple = MessageFormatter.arrayFormat("{}",
> argStrings);
> getLog().info(formattingTuple.getMessage());
> }
> }
> {code}
> *when i run my plugins , show me result:*
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at com.feilong.core.log.Slf4jUtil.formatMessage(Slf4jUtil.java:77)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.getFolderPath(BaseFlowMojo.java:72)
> at
> com.feilong.project.train.mojo.InvitationMojo.handleExecute(InvitationMojo.java:89)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.execute(BaseFlowMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.lang.ClassNotFoundException:
> org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 26 more
> {code}
> *And from the log (run with -X), i see that :*
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T19:57:37+08:00)
> Maven home: D:\FeiLong Soft\Essential\Development\apache-maven-3.3.3\bin\..
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: D:\Program Files\Java\jdk1.8.0_11\jre
> Default locale: zh_CN, platform encoding: GBK
> OS name: "windows 7", version: "6.1", arch: "x86", family: "dos"
> [DEBUG] Created new class realm maven.api
> [DEBUG] Importing
[jira] [Assigned] (MNG-5845) when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
[
https://issues.apache.org/jira/browse/MNG-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER reassigned MNG-5845:
Assignee: Arnaud HERITIER
> when in maven mojo, ClassNotFoundException slf4j-api `MessageFormatter` class
> -
>
> Key: MNG-5845
> URL: https://issues.apache.org/jira/browse/MNG-5845
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.3
> Environment: window7;
> maven 3.3.3;
> my custom maven plugin dependencies
>
>
>
> org.apache.maven
> maven-core
> 3.3.3
>
>
> org.apache.maven
> maven-plugin-api
> 3.3.3
>
>
>
> org.apache.maven.plugin-tools
> maven-plugin-annotations
> 3.4
> provided
>
>
>
> org.codehaus.plexus
> plexus-component-annotations
> 1.6
> provided
>
>
> org.codehaus.plexus
> plexus-container-default
> 1.6
>
>
> org.codehaus.plexus
> plexus-interactivity-api
> 1.0-alpha-6
>
>
> plexus
> plexus-utils
>
>
>
>
> org.codehaus.plexus
> plexus-utils
> 3.0.22
>
>
> org.apache.maven.plugin-testing
> maven-plugin-testing-harness
> 3.3.0
> test
>
>
> org.slf4j
> slf4j-api
> 1.7.12
>
>
> org.slf4j
> slf4j-log4j12
> 1.7.12
>
>
>Reporter: feilong
>Assignee: Arnaud HERITIER
> Labels: maven
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> *my code is*
> {code}
> @Mojo(name = "hello",requiresProject = false)
> public class HelloWorldMojo extends AbstractMojo{
> @Override
> public void execute() throws MojoExecutionException,MojoFailureException{
> String[] argStrings = { "Hello world" };
> FormattingTuple formattingTuple = MessageFormatter.arrayFormat("{}",
> argStrings);
> getLog().info(formattingTuple.getMessage());
> }
> }
> {code}
> *when i run my plugins , show me result:*
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at com.feilong.core.log.Slf4jUtil.formatMessage(Slf4jUtil.java:77)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.getFolderPath(BaseFlowMojo.java:72)
> at
> com.feilong.project.train.mojo.InvitationMojo.handleExecute(InvitationMojo.java:89)
> at
> com.feilong.project.train.mojo.BaseFlowMojo.execute(BaseFlowMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> ... 21 more
> Caused by: java.lang.ClassNotFoundException:
> org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 26 more
> {code}
> *And from the log (run with -X), i see that :*
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T19:57:37+08:00)
> Maven home: D:\FeiLong Soft\Essential\Development\apache-maven-3.3.3\bin\..
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: D:\Program Files\Java\jdk1.8.0_11\jre
> Default locale: zh_CN, platform encoding: GBK
> OS name: "windows 7", version: "6.1", arch: "x86", family: "dos"
> [DEBUG] Created new class realm maven.api
> [DEBUG] Importing foreign packages into class realm maven.api
> [DEBUG] Imported: javax.enterprise.inject.* < plexus.core
> [DEBUG] Imported: javax.enterprise.util.* < plexus.core
> [DEBUG] Imported: javax.inject.* < plexus.core
> [DEBUG] Imported: org.apache.maven.* < plexus.core
>
[jira] [Assigned] (MNG-5842) java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty plugin
[
https://issues.apache.org/jira/browse/MNG-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER reassigned MNG-5842:
Assignee: Arnaud HERITIER
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty
> plugin
>
>
> Key: MNG-5842
> URL: https://issues.apache.org/jira/browse/MNG-5842
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Jean-Christophe Gay
>Assignee: Arnaud HERITIER
>
> When Maven is used with a different SLF4J implementation than slf4j-simple
> (in my case logback to have colored logs), running jetty-maven-plugin fails.
> {code}
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T13:57:37+02:00)
> Maven home: /usr/local/Cellar/maven/3.3.3/libexec
> Java version: 1.8.0_40, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
> Default locale: fr_FR, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.3", arch: "x86_64", family: "mac"
> {code}
> {code}
> [WARNING] FAILED org.mortbay.jetty.plugin.JettyServer@66c4005:
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> java.lang.ClassNotFoundException: org.slf4j.helpers.MessageFormatter
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> ~[plexus-classworlds-2.5.2.jar:na]
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ~[plexus-classworlds-2.5.2.jar:na]
> ... 21 common frames omitted
> Wrapped by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:619)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.log.JettyAwareLogger.info(JettyAwareLogger.java:314)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.util.log.Slf4jLog.info(Slf4jLog.java:74)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.eclipse.jetty.server.Server.doStart(Server.java:271)
> ~[jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
> ~[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
> ~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:520)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:365)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:521)
> [jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [maven-core-3.3.1.jar:3.3.1]
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [maven-core-3.3.1.jar:3.3.1]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:275)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:101)
> [takari-smart-builder-0.4.0.jar:0.4.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_40]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
> java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
>
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747150#comment-14747150
]
Arnaud HERITIER commented on MNG-5889:
--
Hi Daniel,
It is clearly a bug/limitation of the current implementation and it is really
annoying for exemple on CI servers where you can checkout the project in a
subdirectory and launch the build with the path to the pom parameter.
I was aware of this bug for few months but I forgot to report it. I described
it to the team on IRC few days ago but I had sadly no feedback.
Technically I don't yet know how to fix it. The problem is that it enforces
at the .sh/.cmd script level to parte the command line options to find if the
-f/--file option is defined. If it is the case we need to extract its value and
compute the path of the module directory (AFAIR we can either pass to the
option the module directory or the POM file). When the module directory is
found we need to find the .mvn directory from this path and not from the local
directory. For the shell .sh version I think I may succeed to propose a fix,
but for the windows .cmd I'm less confident and I'm clearly against to have a
different behaviour based on the OS
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747310#comment-14747310
]
Arnaud HERITIER commented on MNG-5889:
--
[~daniel.spil...@hamburg.de] Yes I discovered the issue within Jenkins too
where it is a common need to define the path and to not checkout the project in
the root directory of the workspace. Having an option to setup the base
directory may be a workaround but I don't find any other usage of it and like
you I would prefer to see the problem fixed on Maven side
[~khmarbaise] yes because of JVM options which have to be discovered before
launching Maven :(
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3
>Reporter: Daniel Spilker
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694903#comment-14694903
]
Arnaud HERITIER commented on MNG-5869:
--
[~krosenvold] [~olamy] Do you think that in 3.2/3.3 we may have an isolation
issue which may explain that this plugin breaks our download of dependencies ?
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
(2 KB at 62.8 KB/sec)
06:28:08 [INFO]
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695015#comment-14695015
]
Arnaud HERITIER commented on MNG-5869:
--
I was waiting for such behaviour (connection timeout) but it wasn't the case :(
I killed it after an hour
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
(2 KB at 62.8 KB/sec)
06:28:08 [INFO] Downloading:
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693116#comment-14693116
]
Arnaud HERITIER commented on MNG-5869:
--
Thanks for your investigation [~krosenvold]
Strange side effect of this mock server stuffs
Thus the problem is solved in most recent versions of this library.
Do you think there is an interest to keep this issue opened to understand the
change between 3.1 vs 3.2/3.3 ?
Or we just close it has the problem is already solved by the plugin maintainer
?
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO]
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693375#comment-14693375
]
Arnaud HERITIER commented on MNG-5869:
--
I identified the fix as done in the version 3.9.6 of the plugin. I will look at
commits/changelogs ..
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
(2 KB at 62.8 KB/sec)
06:28:08 [INFO] Downloading:
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693416#comment-14693416
]
Arnaud HERITIER commented on MNG-5869:
--
yes but AFAIU the source of the issue is that the mock server shouldn't be used
by maven for downloads ?
this plugin was (is always?) interfering with wagon and our downloads and thus
this problem of incorrect content-length broken the downloads which had nothing
more to download but were waiting for more ...
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693388#comment-14693388
]
Arnaud HERITIER commented on MNG-5869:
--
https://github.com/jamesdbloom/mockserver/compare/mockserver-3.9.5...mockserver-3.9.6
There is nothing obvious/documented about such fix.
I will have look more deeply to the changes.
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
(2 KB at 62.8 KB/sec)
[jira] [Updated] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER updated MNG-5869:
-
Attachment: threaddumps.log
Here is the thread dump [~krosenvold]
I reproduced it on my laptop, I will give you the process to reproduce it
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
(2 KB at 62.8 KB/sec)
06:28:08 [INFO] Downloading:
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14692396#comment-14692396
]
Arnaud HERITIER commented on MNG-5869:
--
With a classical output (and not the batch mode) we clearly see that all
downloads are supposed to be ended
{code}
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.1/commons-lang3-3.1.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.3/maven-common-artifact-filters-1.3.jar
34/34 KB 31/31 KB 309/309 KB 257/257 KB 115/115 KB
{code}
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
[jira] [Updated] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud HERITIER updated MNG-5869:
-
Attachment: settings.xml
settings used to download from central with URL http://repo1.maven.org/maven2
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
(2 KB at 62.8 KB/sec)
06:28:08 [INFO] Downloading:
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14692410#comment-14692410
]
Arnaud HERITIER commented on MNG-5869:
--
To reproduce it, on my environment I have:
* Oracle JDK 1.8.0_51
* Apache Maven 3.3.3
I clone the repository
{code}
git clone https://github.com/kenzanmedia/bowtie.git
{code}
I add in it the settings.xml attached to this ticket
Then I launch a build with an empty local repo
{code}
mvn -s settings.xml clean test -Dmaven.repo.local=$(mktemp -d -t
maven-local-repo)
{code}
Your build should freeze after few minutes while downloading surefire
dependencies
Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
Attachments: settings.xml, threaddumps.log
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in
recent versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have
some guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup
some mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
[jira] [Created] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
Arnaud HERITIER created MNG-5869:
Summary: Frozen downloads with HTTP repositories and Maven 3.2 or
3.3
Key: MNG-5869
URL: https://issues.apache.org/jira/browse/MNG-5869
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.3.3, 3.2.5
Reporter: Arnaud HERITIER
We recently discovered a strange bug of frozen dependencies downloads
I didn't yet studied a lot the issue but I guess it may be something in recent
versions of Wagon.
I created few jobs to demonstrate the Maven issue and I would like to have some
guidance to deeply analyse it.
The project used is https://github.com/kenzanmedia/bowtie/ which has a really
simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
We are using some custom global and user maven settings but only to setup some
mirrors, some credentials and to (re)define some repositories
Here are my results jobs on https://aheritier.ci.cloudbees.com
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
* (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
* (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
* (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and
3.3.3 it works only if we use the https access to maven central
For Maven 3.2 and 3.3 with http repositories the build is frozen and killed
after the timeout I defined (5 minutes - I did also a test with 1h)
All builds are frozen at the same point in the download process to grab
surefire artefacts
DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
{code}
06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie
---
06:28:06 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
06:28:06 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
(3 KB at 3.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
(3 KB at 42.7 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
(6 KB at 52.9 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
(2 KB at 2.2 KB/sec)
06:28:07 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
06:28:07 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
(16 KB at 154.9 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
06:28:08 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
(2 KB at 62.8 KB/sec)
06:28:08 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting/2.0.9/maven-reporting-2.0.9.pom
06:28:09 [INFO] Downloaded:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting/2.0.9/maven-reporting-2.0.9.pom
(2 KB at 41.2 KB/sec)
06:28:09 [INFO] Downloading:
http://repo.cloudbees.com/content/repositories/central/org/apache/maven/maven-toolchain/2.0.9/maven-toolchain-2.0.9.pom
06:28:09 [INFO]
[jira] [Commented] (MNG-5846) Maven 3.3.3 ignores repository definition for central
[
https://issues.apache.org/jira/browse/MNG-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599848#comment-14599848
]
Arnaud HERITIER commented on MNG-5846:
--
[~joehni] Even if doing this is a bad idea, AFAIK it isn't officialy deprecated
and if there is such regression it is annoying because it was used a lot by
people in the past because it avoided to enforce users to setup a mirror in
your local settings to build a project once.
Thus from my POV, yes having repositories in POMs is very bad, using it to
overwrite central is bad but having a regression (if confirmed) in Maven
behaviour is worst.
Maven 3.3.3 ignores repository definition for central
---
Key: MNG-5846
URL: https://issues.apache.org/jira/browse/MNG-5846
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.3.1
Environment: n/a
Reporter: Torsten Liermann
Hi,
The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
using maven 3.3.3.
It's starts correctly and downloads a set of dependencies from the specified
and overriden central repositories. The, suddenly, during a running build it
starts downloading dependencies from the default central repository (which
is actually overridden). This behaviour is problematic for us.
In these log-statements you can see that initial downloads are done from the
overridden definition and that later the default central repository is used.
{quote}
?xml version=1.0 encoding=UTF-8?
project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdxxx/groupId
artifactIdyyy/artifactId
version5.0-SNAPSHOT/version
dependencies
dependency
groupIdorg.glassfish.main.appclient.client/groupId
artifactIdgf-client/artifactId
version3.1.2.2/version
/dependency
/dependencies
repositories
repository
idcentral/id
urlhttp://www.liermann.ws/maven//url
releases
enabledtrue/enabled
/releases
snapshots
enabledtrue/enabled
updatePolicyalways/updatePolicy
/snapshots
/repository
/repositories
pluginRepositories
pluginRepository
idcentral/id
urlhttp://www.liermann.ws/maven//url
releases
enabledtrue/enabled
/releases
snapshots
enabledtrue/enabled
updatePolicyalways/updatePolicy
/snapshots
/pluginRepository
/pluginRepositories
/project
{quote}
Log file snippet
{quote}
Downloading:
http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
Downloaded:
http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
(31 KB at 532.0 KB/sec)
Downloading:
http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
Downloaded:
http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
(6 KB at 101.3 KB/sec)
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MSHADE-185) systemPath content is interpolated for system dependencies
Arnaud Heritier created MSHADE-185:
--
Summary: systemPath content is interpolated for system dependencies
Key: MSHADE-185
URL: https://jira.codehaus.org/browse/MSHADE-185
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 2.3, 2.2
Reporter: Arnaud Heritier
For example with such a POM :
{code}
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/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdtest.shade/groupId
artifactIdsystem-dep/artifactId
packagingjar/packaging
version1.0.0-SNAPSHOT/version
dependencies
dependency
groupIdjline/groupId
artifactIdjline/artifactId
version2.12/version
/dependency
dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version1.6/version
scopesystem/scope
systemPath${tools.jar}/systemPath
optionaltrue/optional
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-shade-plugin/artifactId
version2.3/version
executions
execution
phasepackage/phase
goals
goalshade/goal
/goals
configuration
shadedArtifactAttachedfalse/shadedArtifactAttached
createDependencyReducedPomtrue/createDependencyReducedPom
createSourcesJartrue/createSourcesJar
artifactSet
includes
includejline:jline/include
/includes
/artifactSet
relocations
relocation
patternjline/pattern
shadedPatternorg.crsh.console.jline/shadedPattern
/relocation
/relocations
/configuration
/execution
/executions
/plugin
/plugins
/build
profiles
!-- required by byteman --
profile
iddefault-profile/id
activation
file
exists${java.home}/../lib/tools.jar/exists
/file
/activation
properties
tools.jar${java.home}/../lib/tools.jar/tools.jar
/properties
/profile
profile
idmac-jdk6-profile/id
activation
file
exists${java.home}/../Classes/classes.jar/exists
/file
/activation
properties
tools.jar${java.home}/../Classes/classes.jar/tools.jar
/properties
/profile
/profiles
/project
{code}
I'll have in the dependency-reduced-pom.xml
{code}
dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version1.6/version
scopesystem/scope
systemPath/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/jre/../lib/tools.jar/systemPath
optionaltrue/optional
/dependency
{code}
While a classical jar/install/deploy won't replace such value
Because of this we can deploy crappy things on central. See :
https://jira.exoplatform.org/browse/CRASH-225
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-235) duplicate classes due to MCOMPILER-157 when compiler is called twice or more
Arnaud Heritier created MCOMPILER-235:
-
Summary: duplicate classes due to MCOMPILER-157 when compiler is
called twice or more
Key: MCOMPILER-235
URL: https://jira.codehaus.org/browse/MCOMPILER-235
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.2
Environment: Maven 3.2.3
Reporter: Arnaud Heritier
I tried to upgrade our projects to use the compiler 3.2 and instead of 3.1
Classical builds are ok but site builds are KO because for various reasons
(reports) the lifecycle is forked and thus the compiler is called twice (or
more) and fails because it finds duplicated classes
Example :
{code}
[INFO]
[INFO] Building eXo Commons - Common Services 4.1.x-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @
commons-component-common ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @
commons-component-common ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.3:create (default) @
commons-component-common ---
[INFO]
[INFO] --- jacoco-maven-plugin:0.7.2.201409121644:prepare-agent
(prepare-ut-agent) @ commons-component-common ---
[INFO] argLine set to
-javaagent:/srv/ciagent/workspace/commons-master-site/.repository/org/jacoco/org.jacoco.agent/0.7.2.201409121644/org.jacoco.agent-0.7.2.201409121644-runtime.jar=destfile=/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/target/jacoco.exec,append=true
[INFO]
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
commons-component-common ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 5 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @
commons-component-common ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 97 source files to
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/target/classes
[WARNING] Supported source version 'RELEASE_5' from annotation processor
'org.chromattic.apt.ChromatticProcessor' less than -source '1.7'
[INFO] About to process the type
org.exoplatform.settings.chromattic.SettingsRoot
[INFO] About to process the type
org.exoplatform.settings.chromattic.SubContextEntity
[INFO] About to process the type
org.exoplatform.settings.chromattic.SimpleContextEntity
[INFO] About to process the type org.exoplatform.settings.chromattic.ScopeEntity
[INFO] About to process the type
org.exoplatform.settings.chromattic.ContextEntity
[INFO] Processing node type package org.exoplatform.settings.chromattic
[INFO]
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/main/java/org/exoplatform/services/user/UserStateService.java:
Some input files use unchecked or unsafe operations.
[INFO]
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/main/java/org/exoplatform/services/user/UserStateService.java:
Recompile with -Xlint:unchecked for details.
[INFO]
[INFO] --- maven-resources-plugin:2.7:testResources (default-testResources) @
commons-component-common ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 19 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
commons-component-common ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 32 source files to
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/target/test-classes
[WARNING]
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/test/java/org/exoplatform/commons/event/TestEventManager.java:[29,23]
junit.framework.Assert in junit.framework has been deprecated
[WARNING] Supported source version 'RELEASE_5' from annotation processor
'org.chromattic.apt.ChromatticProcessor' less than -source '1.7'
[WARNING] Supported source version 'RELEASE_5' from annotation processor
'org.chromattic.testgenerator.CheckTestProcessor' less than -source '1.7'
[WARNING]
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/test/java/org/exoplatform/commons/event/TestEventManager.java:[29,23]
junit.framework.Assert in junit.framework has been deprecated
[WARNING]
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/test/java/org/exoplatform/commons/event/TestEventManager.java:[29,23]
junit.framework.Assert in junit.framework has been deprecated
[WARNING]
/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/test/java/org/exoplatform/commons/event/TestEventManager.java:[88,9]
junit.framework.Assert in junit.framework has been deprecated
[WARNING]
[jira] (MASSEMBLY-554) DependencySet unpackOptions 'filtered' causes unpack not to work
[ https://jira.codehaus.org/browse/MASSEMBLY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346921#comment-346921 ] Arnaud Heritier commented on MASSEMBLY-554: --- the unpackOptions lineEnding has the same bad effect DependencySet unpackOptions 'filtered' causes unpack not to work Key: MASSEMBLY-554 URL: https://jira.codehaus.org/browse/MASSEMBLY-554 Project: Maven Assembly Plugin Issue Type: Bug Components: filtering Affects Versions: 2.2 Environment: Ubuntu 10.10 Linux, x86-64. Reporter: Dave Combs Attachments: example.zip In 2.2-beta-4, the dependencySet option 'filtered' does not appear to work. Files from a dependency end up in the right place (under / in the fragment below), but the filters are not applied. In 2.2 it is worse--the files are correctly filtered, but a directory of the same name as the archive from which they came (com.kaazing.gateway.assembly.core.tar.gz below) is included in the output under /, rather than just the contents of the archive, and the filtered files appear there. It's as though the archive is exploded in place under its own name. dependencySet outputDirectory//outputDirectory unpacktrue/unpack unpackOptions filteredtrue/filtered /unpackOptions includes includecom.kaazing.gateway.core:com.kaazing.gateway.assembly.core:tar.gz:bin/include /includes /dependencySet This makes the filtering option essentially unusable, since I can't find a way to eliminate this top-level directory creation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1911) Building plugins with extensions in a reactor fails
[
https://jira.codehaus.org/browse/MNG-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344133#comment-344133
]
Arnaud Heritier commented on MNG-1911:
--
The only existing workaround is to extract your extension (or the plugin
defining it) in another independent project (which I agree, is often overkill).
I don't know if [~jason] and others who worked on the core recently have an
idea how to fix it but the root cause of the problem is that an extension can
extend an existing lifecycle or add a new one and thus Maven may require it to
read poms).
Building plugins with extensions in a reactor fails
---
Key: MNG-1911
URL: https://jira.codehaus.org/browse/MNG-1911
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.1
Reporter: Guillaume Nodet
Assignee: Jason van Zyl
Priority: Critical
Attachments: MNG-1911.zip
I have the following in my main pom
{code:xml}
build
pluginManagement
plugins
plugin
groupIdorg.apache.servicemix.plugins/groupId
artifactIdmaven2-jbi-plugin/artifactId
version1.0-SNAPSHOT/version
extensionstrue/extensions
/plugin
/plugins
/pluginManagement
/build
{code}
If i try to add it to the modules, the first time, maven complains that it
can not download the plugin.
If i remove the {{extensions}} tag, all works, but i need it :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-351) Javadoc:fix fixTags parameter doesn't support 'return' value
[
https://jira.codehaus.org/browse/MJAVADOC-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier reassigned MJAVADOC-351:
Assignee: Arnaud Heritier
Javadoc:fix fixTags parameter doesn't support 'return' value
Key: MJAVADOC-351
URL: https://jira.codehaus.org/browse/MJAVADOC-351
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.7, 2.8, 2.8.1
Reporter: Lars van der Vliet
Assignee: Arnaud Heritier
Fix For: 2.9.2
Attachments: fixTags.patch
Javadoc:fix fixTags parameter doesn't support 'return' value
According to the docs
(http://maven.apache.org/plugins/maven-javadoc-plugin/fix-mojo.html#fixTags)
the fixTags parameter should be able to handle the following values:
# all (fix all Javadoc tags)
# author (fix only @author tag)
# version (fix only @version tag)
# since (fix only @since tag)
# param (fix only @param tag)
# return (fix only @return tag)
# throws (fix only @throws tag)
# link (fix only @link tag)
When Calling javadoc:fix version 2.8 or 2.7 with -DfixTags=return gives the
following error:
{code}
Unrecognized 'return' for fixTags parameter. Ignored it!
{code}
Using 2.6 this works just fine. When looking at the following diff:
{code}
---
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
2011/04/25 13:38:09 1096478
+++
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
2011/04/30 18:59:02 1098139
@@ -491,10 +491,8 @@
for ( int j = 0; j split.length; j++ )
{
String s = split[j].trim();
-if ( FIX_TAGS_ALL.equalsIgnoreCase( s.trim() ) ||
AUTHOR_TAG.equalsIgnoreCase( s.trim() )
-|| VERSION_TAG.equalsIgnoreCase( s.trim() ) ||
SINCE_TAG.equalsIgnoreCase( s.trim() )
-|| PARAM_TAG.equalsIgnoreCase( s.trim() ) ||
RETURN_TAG.equalsIgnoreCase( s.trim() )
-|| THROWS_TAG.equalsIgnoreCase( s.trim() ) )
+if ( JavadocUtil.equalsIgnoreCase( s, FIX_TAGS_ALL,
AUTHOR_TAG, VERSION_TAG, SINCE_TAG, PARAM_TAG,
+ THROWS_TAG ) )
{
filtered.add( s );
}
{code}
the functionality seems to be broken since revision 1098139. I added a patch
which restores the functionality.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-351) Javadoc:fix fixTags parameter doesn't support 'return' value
[
https://jira.codehaus.org/browse/MJAVADOC-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MJAVADOC-351.
Resolution: Fixed
Fix Version/s: 2.9.2
Sorry for the delay to have this simple fix. I just encountered it and applied
your patch. thx
Javadoc:fix fixTags parameter doesn't support 'return' value
Key: MJAVADOC-351
URL: https://jira.codehaus.org/browse/MJAVADOC-351
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.7, 2.8, 2.8.1
Reporter: Lars van der Vliet
Assignee: Arnaud Heritier
Fix For: 2.9.2
Attachments: fixTags.patch
Javadoc:fix fixTags parameter doesn't support 'return' value
According to the docs
(http://maven.apache.org/plugins/maven-javadoc-plugin/fix-mojo.html#fixTags)
the fixTags parameter should be able to handle the following values:
# all (fix all Javadoc tags)
# author (fix only @author tag)
# version (fix only @version tag)
# since (fix only @since tag)
# param (fix only @param tag)
# return (fix only @return tag)
# throws (fix only @throws tag)
# link (fix only @link tag)
When Calling javadoc:fix version 2.8 or 2.7 with -DfixTags=return gives the
following error:
{code}
Unrecognized 'return' for fixTags parameter. Ignored it!
{code}
Using 2.6 this works just fine. When looking at the following diff:
{code}
---
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
2011/04/25 13:38:09 1096478
+++
maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractFixJavadocMojo.java
2011/04/30 18:59:02 1098139
@@ -491,10 +491,8 @@
for ( int j = 0; j split.length; j++ )
{
String s = split[j].trim();
-if ( FIX_TAGS_ALL.equalsIgnoreCase( s.trim() ) ||
AUTHOR_TAG.equalsIgnoreCase( s.trim() )
-|| VERSION_TAG.equalsIgnoreCase( s.trim() ) ||
SINCE_TAG.equalsIgnoreCase( s.trim() )
-|| PARAM_TAG.equalsIgnoreCase( s.trim() ) ||
RETURN_TAG.equalsIgnoreCase( s.trim() )
-|| THROWS_TAG.equalsIgnoreCase( s.trim() ) )
+if ( JavadocUtil.equalsIgnoreCase( s, FIX_TAGS_ALL,
AUTHOR_TAG, VERSION_TAG, SINCE_TAG, PARAM_TAG,
+ THROWS_TAG ) )
{
filtered.add( s );
}
{code}
the functionality seems to be broken since revision 1098139. I added a patch
which restores the functionality.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5097) @parameter using 'property' to allow custom naming convention, throws a NPE if the parameter is defined, but empty.
[
https://jira.codehaus.org/browse/MNG-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MNG-5097.
Resolution: Fixed
Fix Version/s: 3.1.0
Was fixed in 3.1.0 (see @mcculls comment)
@parameter using 'property' to allow custom naming convention, throws a NPE
if the parameter is defined, but empty.
---
Key: MNG-5097
URL: https://jira.codehaus.org/browse/MNG-5097
Project: Maven 2 3
Issue Type: Bug
Components: Plugin API
Affects Versions: 3.0.3
Environment: Gentoo Linux, amd64, multicore.
Reporter: rydnr
Priority: Minor
Fix For: 3.1.0
Attachments: build.log, empty-string-npe.zip
The test case (not JUnit) is attached.
If a Maven plugin runs within Maven 3.0.3, and defines
/**
* @parameter property=abc
*/
private String somethingDifferentThanAbc;
public void setAbc(String value) {
somethingDifferentThanAbc = value;
}
Works for non-empty values:
abcabc-value/abc
But throws a NPE in
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter:331
(fieldTypeConverter is null) with empty values:
abc/abc
It works in Maven 2.x. It works if you declare the
property with no naming conventions:
private String abc;
As a side note, the plexus classes being used are not the ones declared in
the pom, but the ones bundled within
$MAVEN_HOME/lib/sisu-inject-plexus-2.1.1.jar.
I couldn't find sisu-inject-plexus-2.1.1-sources.jar anywhere, but the
repository itself is fortunately available at
https://github.com/sonatype/sisu.git
And then within
/sisu-inject/containers/guice-plexus/guice-plexus-shim/src/main/java/
I could have try to post a patch, but I'm not really sure about why this
corner case is producing plexus-container's misbehavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-581) Git relative pathing broken with release plugin
[
https://jira.codehaus.org/browse/MRELEASE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=328736#comment-328736
]
Arnaud Heritier commented on MRELEASE-581:
--
How was organized your project ?
You add some relative path between the reactor/parent and its modules with some
.. (to have the parent as the same level than modules ?)
Git relative pathing broken with release plugin
---
Key: MRELEASE-581
URL: https://jira.codehaus.org/browse/MRELEASE-581
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare
Affects Versions: 2.0
Environment: windows xp, service pack 2
Reporter: Matthew Sandoz
Assignee: Mark Struberg
Attachments: gitexe.zip, MRELEASE-581.patch
i have a multimodule project, and when i try to do a release, i get
everything working fine until the end. It seems to think for some reason that
I am at the root of my scm tree. The repo i have to work in has several
projects, and mine is in a subdirectory - domains/redemption. the plugin
appears to try to check in my submodules at my current location instead of my
scm root.
COMMAND:
{{mvn release:prepare -DpreparationGoals=clean install -DskipTests
-DautoVersionSubmodules=true}}
{noformat}
END OF OUTPUT:
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] Redemption Parent POM . SUCCESS
[2.595s]
[INFO] [INFO] Redemption Runtime Confguration ... SUCCESS
[3.531s]
[INFO] [INFO] Redemption Service Metadata ... SUCCESS
[18.816s]
[INFO] [INFO] Redemption Model .. SUCCESS
[35.693s]
[INFO] [INFO] Redemption DAO SUCCESS
[41.770s]
[INFO] [INFO] Redemption Service Implementation . SUCCESS
[17.517s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Parent POM ... SUCCESS
[0.016s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: XSLT . SUCCESS
[5.469s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: EIP .. SUCCESS
[0.343s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Version Router ... SUCCESS
[3.157s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Binding Component ::
Service Unit SUCCESS [3.656s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Service Assembly . SUCCESS
[3.516s]
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO]
[INFO] [INFO] Total time: 2 minutes 26 seconds
[INFO] [INFO] Finished at: Tue Jul 27 17:18:02 EDT 2010
[INFO] [INFO] Final Memory: 116M/254M
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C git add pom.xml redemption-conf\pom.xml
redemption-metadata\pom.xml redemption-model\pom.xml rede
mption-dao\pom.xml redemption-impl\pom.xml redemption-esb\pom.xml
redemption-esb\redemption-xslt\pom.xml redemption-esb\redemption
-eip\pom.xml redemption-esb\redemption-router\pom.xml
redemption-esb\redemption-bc-su\pom.xml redemption-esb\redemption-sa\pom.xml
[INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
[INFO] Executing: cmd.exe /X /C git status
[INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
[INFO] Executing: cmd.exe /X /C git commit --verbose -F
D:\DOCUME~1\sandozm\LOCALS~1\Temp\maven-scm-1862033505.commit pom.xml red
emption-conf\pom.xml redemption-metadata\pom.xml redemption-model\pom.xml
redemption-dao\pom.xml redemption-impl\pom.xml redemptio
n-esb\pom.xml redemption-esb\redemption-xslt\pom.xml
redemption-esb\redemption-eip\pom.xml redemption-esb\redemption-router\pom.xm
l redemption-esb\redemption-bc-su\pom.xml
redemption-esb\redemption-sa\pom.xml
[INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The git-commit command failed.
Command output:
error: pathspec 'redemption-conf\pom.xml' did not match any file(s) known to
git.
error: pathspec 'redemption-metadata\pom.xml' did not match any file(s) known
to git.
error: pathspec 'redemption-model\pom.xml' did not match any file(s) known to
git.
error: pathspec
[jira] (MRELEASE-581) Git relative pathing broken with release plugin
[
https://jira.codehaus.org/browse/MRELEASE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=328757#comment-328757
]
Arnaud Heritier commented on MRELEASE-581:
--
ok thus it is another problem to solve than the one I saw today (similar to
this one, the release plugin is dying with such errors if it's not a classical
inheritance)
[~velo] were you able to test the patch proposed by [~struberg] ?
Git relative pathing broken with release plugin
---
Key: MRELEASE-581
URL: https://jira.codehaus.org/browse/MRELEASE-581
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare
Affects Versions: 2.0
Environment: windows xp, service pack 2
Reporter: Matthew Sandoz
Assignee: Mark Struberg
Attachments: gitexe.zip, MRELEASE-581.patch
i have a multimodule project, and when i try to do a release, i get
everything working fine until the end. It seems to think for some reason that
I am at the root of my scm tree. The repo i have to work in has several
projects, and mine is in a subdirectory - domains/redemption. the plugin
appears to try to check in my submodules at my current location instead of my
scm root.
COMMAND:
{{mvn release:prepare -DpreparationGoals=clean install -DskipTests
-DautoVersionSubmodules=true}}
{noformat}
END OF OUTPUT:
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] Redemption Parent POM . SUCCESS
[2.595s]
[INFO] [INFO] Redemption Runtime Confguration ... SUCCESS
[3.531s]
[INFO] [INFO] Redemption Service Metadata ... SUCCESS
[18.816s]
[INFO] [INFO] Redemption Model .. SUCCESS
[35.693s]
[INFO] [INFO] Redemption DAO SUCCESS
[41.770s]
[INFO] [INFO] Redemption Service Implementation . SUCCESS
[17.517s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Parent POM ... SUCCESS
[0.016s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: XSLT . SUCCESS
[5.469s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: EIP .. SUCCESS
[0.343s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Version Router ... SUCCESS
[3.157s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Binding Component ::
Service Unit SUCCESS [3.656s]
[INFO] [INFO] crm :: guest :: redemption :: ESB :: Service Assembly . SUCCESS
[3.516s]
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] BUILD SUCCESSFUL
[INFO] [INFO]
[INFO] [INFO] Total time: 2 minutes 26 seconds
[INFO] [INFO] Finished at: Tue Jul 27 17:18:02 EDT 2010
[INFO] [INFO] Final Memory: 116M/254M
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C git add pom.xml redemption-conf\pom.xml
redemption-metadata\pom.xml redemption-model\pom.xml rede
mption-dao\pom.xml redemption-impl\pom.xml redemption-esb\pom.xml
redemption-esb\redemption-xslt\pom.xml redemption-esb\redemption
-eip\pom.xml redemption-esb\redemption-router\pom.xml
redemption-esb\redemption-bc-su\pom.xml redemption-esb\redemption-sa\pom.xml
[INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
[INFO] Executing: cmd.exe /X /C git status
[INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
[INFO] Executing: cmd.exe /X /C git commit --verbose -F
D:\DOCUME~1\sandozm\LOCALS~1\Temp\maven-scm-1862033505.commit pom.xml red
emption-conf\pom.xml redemption-metadata\pom.xml redemption-model\pom.xml
redemption-dao\pom.xml redemption-impl\pom.xml redemptio
n-esb\pom.xml redemption-esb\redemption-xslt\pom.xml
redemption-esb\redemption-eip\pom.xml redemption-esb\redemption-router\pom.xm
l redemption-esb\redemption-bc-su\pom.xml
redemption-esb\redemption-sa\pom.xml
[INFO] Working directory: D:\workspaces\crm-dev\domains\redemption
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The git-commit command failed.
Command output:
error: pathspec 'redemption-conf\pom.xml' did not match any file(s) known to
git.
error: pathspec 'redemption-metadata\pom.xml' did not match any file(s) known
to git.
error: pathspec 'redemption-model\pom.xml' did not match
[jira] (ARCHETYPE-432) Update distributionManagement in POM
[
https://jira.codehaus.org/browse/ARCHETYPE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier reassigned ARCHETYPE-432:
-
Assignee: Olivier Lamy
Update distributionManagement in POM
Key: ARCHETYPE-432
URL: https://jira.codehaus.org/browse/ARCHETYPE-432
Project: Maven Archetype
Issue Type: Task
Affects Versions: 2.2
Environment: n/a
Reporter: Anders Hammar
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
The current distributionManagement says:
{noformat}
site
idapache.website/id
urlscp://people.apache.org/www/maven.apache.org/archetype//url
/site
{noformat}
I think this needs to be changed according to the new Site deployment process?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-432) Update distributionManagement in POM
[
https://jira.codehaus.org/browse/ARCHETYPE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed ARCHETYPE-432.
-
Resolution: Fixed
Fixed by [~olamy]. See :
http://svn.apache.org/viewvc?view=revisionrevision=r1500011
http://svn.apache.org/viewvc?view=revisionrevision=r1500012
http://svn.apache.org/viewvc?view=revisionrevision=r1500013
Update distributionManagement in POM
Key: ARCHETYPE-432
URL: https://jira.codehaus.org/browse/ARCHETYPE-432
Project: Maven Archetype
Issue Type: Task
Affects Versions: 2.2
Environment: n/a
Reporter: Anders Hammar
Assignee: Olivier Lamy
Priority: Critical
Fix For: 2.3
The current distributionManagement says:
{noformat}
site
idapache.website/id
urlscp://people.apache.org/www/maven.apache.org/archetype//url
/site
{noformat}
I think this needs to be changed according to the new Site deployment process?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-431) Only include Apache Maven archetypes in internal archetype catalog
[ https://jira.codehaus.org/browse/ARCHETYPE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=328142#comment-328142 ] Arnaud Heritier commented on ARCHETYPE-431: --- [~afloom] I'm interested to release the archetype 2.3 soon but this issue is always opened, what can we do ? About the internal catalog when do we use it (I didn't review the code for now)? Aren't we using the one from central by default ? (http://search.maven.org/remotecontent?filepath=archetype-catalog.xml) The internal is used only if the one from central cannot be downloaded ? (I that case we may suppose that the user will have difficulties to download the plugin itself) Only include Apache Maven archetypes in internal archetype catalog -- Key: ARCHETYPE-431 URL: https://jira.codehaus.org/browse/ARCHETYPE-431 Project: Maven Archetype Issue Type: Task Components: Generator Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Assignee: Anders Hammar Priority: Minor Fix For: 2.3 Currently the internal archetype catalog includes archetypes from different projects. However, there are new archetypes added to the Maven echo-system daily and deciding which to include (and keep it up-to-date) will be impossible. The best solution would the be to just include the official archetypes from the Maven team. We should also update the versions here and not use RELEASE as version as it is deprecated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-692) The maven-site-plugin v3.3 does not render snippets as in v3.2 (Syntax highlighting and line numbers)
[
https://jira.codehaus.org/browse/MSITE-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MSITE-692:
--
Description:
Hi,
you will find in attachment a maven project that shows the issue.
When you run the command {{mvn site}} you get:
!3.2.png!
When you run the command {{mvn site -Dmaven.site.plugin.version=3.3}} you get
!3.3.png!
By comparing html produce by maven-site-plugin:
* With 3.2, all snippets are in tag pre class=prettyprint linenumssome
code/pre
* With 3.3, all snippets are in tag presome code/pre
This is why the fluido skin .js don't activate color syntax nor line numbering.
was:
Hi,
you will find in attachment a maven project that shows the issue.
When you run the command {{mvn site}} you get:
!3.2.png
When you run the command {{mvn site -Dmaven.site.plugin.version=3.3}} you get
!3.3.png!
By comparing html produce by maven-site-plugin:
* With 3.2, all snippets are in tag pre class=prettyprint linenumssome
code/pre
* With 3.3, all snippets are in tag presome code/pre
This is why the fluido skin .js don't activate color syntax nor line numbering.
The maven-site-plugin v3.3 does not render snippets as in v3.2 (Syntax
highlighting and line numbers)
-
Key: MSITE-692
URL: https://jira.codehaus.org/browse/MSITE-692
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: doxia integration
Affects Versions: 3.3
Environment: Maven v3.0.5
Reporter: Rautureau
Attachments: 3.2.png, 3.3.png, maven-site-example.zip
Hi,
you will find in attachment a maven project that shows the issue.
When you run the command {{mvn site}} you get:
!3.2.png!
When you run the command {{mvn site -Dmaven.site.plugin.version=3.3}} you get
!3.3.png!
By comparing html produce by maven-site-plugin:
* With 3.2, all snippets are in tag pre class=prettyprint linenumssome
code/pre
* With 3.3, all snippets are in tag presome code/pre
This is why the fluido skin .js don't activate color syntax nor line
numbering.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5484) Changing the Maven distribution name breaks ITs
Arnaud Heritier created MNG-5484:
Summary: Changing the Maven distribution name breaks ITs
Key: MNG-5484
URL: https://jira.codehaus.org/browse/MNG-5484
Project: Maven 2 3
Issue Type: Bug
Components: Integration Tests
Affects Versions: 3.1.0-alpha-1
Environment: 3.1-SNAPSHOT but probably existing for a long time
Reporter: Arnaud Heritier
We have a feature branch like slf4j-log4j2 where we temporarily changed the
distribution name :
{code}
arnaud@mbp-arnaud:~/Code/Maven/maven-integration-testing (git:master)$ mvn
--version
Apache Maven (Log4J2) 3.1-SNAPSHOT (e8de237706061aff5e6924f0d553ae23d7321f16;
2013-06-11 23:02:46+0200)
Maven home: /Users/arnaud/Applications/apache-maven-3.1-SNAPSHOT-log4j2
Java version: 1.7.0_21, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: mac os x, version: 10.8.4, arch: x86_64, family: mac
{code}
All ITs are skipped with :
{code}
Running integration tests for Maven 4J2)
using Maven executable:
/Users/arnaud/Applications/apache-maven-3.1-SNAPSHOT-log4j2/bin/mvn
Bootstrap(Bootstrap)SKIPPED - Maven
version 4J2) not in range [2.0,)
mng5482AetherNotFound(PluginDependency).SKIPPED - Maven
version 4J2) not in range [3.1-A,)
mng5482AetherNotFound(PluginSite)...SKIPPED - Maven
version 4J2) not in range [3.1-A,)
mng5445LegacyStringSearchModelInterpolator(it)..SKIPPED - Maven
version 4J2) not in range [3.1,)
mng5387ArtifactReplacementPlugin(ArtifactReplacementExecution)SKIPPED - Maven
version 4J2) not in range [3.1,)
mng5382Jsr330Plugin(Jsr330PluginExecution)..SKIPPED - Maven
version 4J2) not in range [3.1-alpha,)
mng5338FileOptionToDirectory(FileOptionToADirectory)SKIPPED - Maven
version 4J2) not in range [3.1-A,)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-345) archetype:create-from-project do not process jarModule and ejbModule sections into EAR's pom.xml
[
https://jira.codehaus.org/browse/ARCHETYPE-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed ARCHETYPE-345.
-
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Arnaud Heritier
Thanks a lot for these complete and valuable patch.
Sorry for the long delay to apply it.
It did few refactoring to avoid code duplications
It will be in release 2.3
archetype:create-from-project do not process jarModule and ejbModule
sections into EAR's pom.xml
Key: ARCHETYPE-345
URL: https://jira.codehaus.org/browse/ARCHETYPE-345
Project: Maven Archetype
Issue Type: Bug
Components: Plugin
Affects Versions: 2.0-alpha-5, 2.0
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_20
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows 2003 version: 5.2 arch: x86 Family: windows
Reporter: amber
Assignee: Arnaud Heritier
Fix For: 2.3
Attachments: ARCHETYPE-345.patch
During the archetype:create-from-project phase, the plugin ignore the
jarModule and EjbModule maven's sections in the EAR pom.xml (multi modules):
Into modules section, com.mycompany.myApp should be ${groupId}, and
myApp-x should be ${rootArtifactId}-x
EAR pom.xml founded into
target\generated-sources\archetype\src\main\resources\archetype-resources\__rootArtifactId__-ear
:
?xml version=1.0 encoding=UTF-8?
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/maven-v4_0_0.xsd;
parent
groupId${groupId}/groupId
artifactId${rootArtifactId}/artifactId
version${version}/version
/parent
modelVersion4.0.0/modelVersion
artifactId${artifactId}/artifactId
packagingear/packaging
name${project.artifactId}-${project.version}/name
dependencies
dependency
groupId${groupId}/groupId
artifactId${rootArtifactId}-services/artifactId
version${version}/version
typeejb/type
/dependency
dependency
groupId${groupId}/groupId
artifactId${rootArtifactId}-model/artifactId
version${version}/version
typejar/type
/dependency
dependency
groupId${groupId}/groupId
artifactId${rootArtifactId}-webmodule/artifactId
version${version}/version
typewar/type
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.4.2/version
configuration
defaultLibBundleDirlib/defaultLibBundleDir
archive
manifest
addClasspathtrue/addClasspath
/manifest
/archive
modules
jarModule
== groupIdcom.mycompany.myApp/groupId
== artifactIdmyApp-model/artifactId
/jarModule
ejbModule
== groupIdcom.mycompany.myApp/groupId
== artifactIdmyApp-services/artifactId
/ejbModule
webModule
== groupIdcom.mycompany.myApp/groupId
== artifactIdmyApp-webmodule/artifactId
== contextRoot/myApp-webModule/contextRoot
unpacktrue/unpack
/webModule
/modules
/configuration
/plugin
/plugins
/build
[...]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-413) on linux adding parent element to generate pom.xml changes line endings to /r/n
[ https://jira.codehaus.org/browse/ARCHETYPE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed ARCHETYPE-413. - Resolution: Fixed Fix Version/s: 2.3 Assignee: Arnaud Heritier patch applied. Thx a lot on linux adding parent element to generate pom.xml changes line endings to /r/n - Key: ARCHETYPE-413 URL: https://jira.codehaus.org/browse/ARCHETYPE-413 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.2 Reporter: Milos Kleint Assignee: Arnaud Heritier Priority: Critical Fix For: 2.3 Attachments: ARCHETYPE-413.patch originally reported as http://netbeans.org/bugzilla/show_bug.cgi?id=197505 the newly created pom.xml from any archetype is modified by the archetype plugin in case the current working directory contains a pom.xml file and a parent section is inserted to the newly created pom. on linux this appears to be changing newlines from \n to \r\n (windows style newlines) which becomes a problem with scm systems for example. included is a patch that fixes the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5482) Catch NoClassDefFoundError org/sonatype/aether
Arnaud Heritier created MNG-5482:
Summary: Catch NoClassDefFoundError org/sonatype/aether
Key: MNG-5482
URL: https://jira.codehaus.org/browse/MNG-5482
Project: Maven 2 3
Issue Type: Improvement
Components: Plugins and Lifecycle
Affects Versions: 3.1.0-alpha-1
Reporter: Arnaud Heritier
In Maven 3.1 Sonatype Aether was replaced by Eclipse Aether where the root
package was changed org.sonatype.aether - org.eclipse.aether
Due to this all plugins which are using directly aether have to be updated to
support both packages.
For now with old plugins the user receive such ugly error :
{code}
[INFO] Dependency-reduced POM written at:
/Users/arnaud/Code/eXo/platform-public-distributions/plf-tomcat-extensions-manager/dependency-reduced-pom.xml
[WARNING] Error injecting:
org.apache.maven.shared.dependency.graph.internal.Maven3DependencyGraphBuilder
java.lang.NoClassDefFoundError: org/sonatype/aether/graph/Dependency
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
at java.lang.Class.getDeclaredMethods(Class.java:1793)
at
com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:674)
at
com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPoint.java:366)
at
com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(ConstructorBindingImpl.java:165)
at
com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl.java:609)
at
com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:565)
at
com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:551)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:865)
at
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:790)
at
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:278)
at
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:210)
at
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:986)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1019)
at
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:982)
at
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1032)
at
org.eclipse.sisu.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:44)
at
com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
at
com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
at
org.eclipse.sisu.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:134)
at
com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
at
com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
at
com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at
com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1054)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:59)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
at
org.eclipse.sisu.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
at
org.eclipse.sisu.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:52)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:259)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:239)
at
[jira] (MNG-5483) Non-resolvable import POM when building offline
Arnaud Heritier created MNG-5483:
Summary: Non-resolvable import POM when building offline
Key: MNG-5483
URL: https://jira.codehaus.org/browse/MNG-5483
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.1.0-alpha-1
Reporter: Arnaud Heritier
Priority: Critical
In our projects we are massively using import of dependencies management to
avoid to redefine the versions of all our components.
Example : https://github.com/exoplatform/platform-public-distributions/
This project is using right now some dependencies coming from a JBoss staging
repository. To build it I activate a profile declared in my settings.
With Maven 3.0.5 due to MNG-5185 I need to declare the profile for every build
to don't let maven reject dependencies in staging which are already in my local
repository (that's a shame but this is another issue already discussed in the
dev list).
But with Maven 3.0.5 if I put Maven in offline mode, there is no problem to
build the project (it will use my local copy of artifacts in staging)
With Maven 3.1.0-alpha-1 I have the same behavior due to MNG-5185 BUT I cannot
use anymore the offline mode too. Local artifacts coming from staging aren't
used by Maven :( :
{code}
arnaud@imac-arnaud:~/Code/eXo/platform-public-distributions (git:master $%)$
mvn clean install -o
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project - [Help 1]
[ERROR]
[ERROR] The project
org.exoplatform.platform.distributions:plf-public-distributions:4.0.x-SNAPSHOT
(/Users/arnaud/Code/eXo/platform-public-distributions/pom.xml) has 143 errors
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.jcr:jcr-parent:pom:1.15.4-GA has not been downloaded from it
before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 263, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.ws:ws-parent:pom:2.3.4-GA has not been downloaded from it
before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 271, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.core:core-parent:pom:2.5.4-GA has not been downloaded from it
before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 279, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.kernel:kernel-parent:pom:2.4.4-GA has not been downloaded from
it before. @ org.exoplatform.commons:commons:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/commons/commons/4.0.x-SNAPSHOT/commons-4.0.x-SNAPSHOT.pom,
line 287, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.jcr:jcr-parent:pom:1.15.4-GA has not been downloaded from it
before. @ org.exoplatform.social:social:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/social/social/4.0.x-SNAPSHOT/social-4.0.x-SNAPSHOT.pom,
line 345, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.ws:ws-parent:pom:2.3.4-GA has not been downloaded from it
before. @ org.exoplatform.social:social:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/social/social/4.0.x-SNAPSHOT/social-4.0.x-SNAPSHOT.pom,
line 353, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.core:core-parent:pom:2.5.4-GA has not been downloaded from it
before. @ org.exoplatform.social:social:4.0.x-SNAPSHOT,
/Users/arnaud/.m2/repository/org/exoplatform/social/social/4.0.x-SNAPSHOT/social-4.0.x-SNAPSHOT.pom,
line 361, column 19 - [Help 2]
[ERROR] Non-resolvable import POM: Cannot access exo-mirror
(https://repository.exoplatform.org/public) in offline mode and the artifact
org.exoplatform.kernel:kernel-parent:pom:2.4.4-GA has not been downloaded from
it before. @ org.exoplatform.social:social:4.0.x-SNAPSHOT,
[jira] (MASSEMBLY-554) DependencySet unpackOptions 'filtered' causes unpack not to work
[ https://jira.codehaus.org/browse/MASSEMBLY-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=325296#comment-325296 ] Arnaud Heritier commented on MASSEMBLY-554: --- I met also this inconsistent behavior. DependencySet unpackOptions 'filtered' causes unpack not to work Key: MASSEMBLY-554 URL: https://jira.codehaus.org/browse/MASSEMBLY-554 Project: Maven 2.x Assembly Plugin Issue Type: Bug Components: filtering Affects Versions: 2.2 Environment: Ubuntu 10.10 Linux, x86-64. Reporter: Dave Combs Attachments: example.zip In 2.2-beta-4, the dependencySet option 'filtered' does not appear to work. Files from a dependency end up in the right place (under / in the fragment below), but the filters are not applied. In 2.2 it is worse--the files are correctly filtered, but a directory of the same name as the archive from which they came (com.kaazing.gateway.assembly.core.tar.gz below) is included in the output under /, rather than just the contents of the archive, and the filtered files appear there. It's as though the archive is exploded in place under its own name. dependencySet outputDirectory//outputDirectory unpacktrue/unpack unpackOptions filteredtrue/filtered /unpackOptions includes includecom.kaazing.gateway.core:com.kaazing.gateway.assembly.core:tar.gz:bin/include /includes /dependencySet This makes the filtering option essentially unusable, since I can't find a way to eliminate this top-level directory creation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve missing dependency error message when _maven.repositories conflict
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier reopened MNG-5185:
--
Reopen as there is a discussion in progress about the proposed fix :
http://maven.40175.n5.nabble.com/Pain-with-MNG-5181-maven-repositories-td5743021.html
Improve missing dependency error message when _maven.repositories conflict
Key: MNG-5185
URL: https://jira.codehaus.org/browse/MNG-5185
Project: Maven 2 3
Issue Type: Improvement
Affects Versions: 3.0.2, 3.0.3, 3.0.4
Reporter: Mark Derricutt
Assignee: Olivier Lamy
Fix For: 3.1.0
Attachments:
0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
Based on a discussion on the users list [1], Maven 3 has changed how it
resolves artifacts from custom repositories. Unfortunately, when conflicts
arise ( GAV is in local repo, but POM has no matching repository id declared
) Maven just tells the user that the artifact could not be resolved.
This leads to confusion from users who find the .jar files in their local
repository, and they just get frustrated and complain that maven sucks.
It would be good if Maven was updated with some improved error messages along
the lines of:
The {GAV} artifact was found in your local repository, but came from the
undeclared repository xxx, either configure this in your pom with {insert
sample XML block in error message}, or in your yyy mirror.
The mirror section of the error message should be included -if- the current
~/.m2/settings.xml declares a mirror. By improving the messages here we can
help the users move on to building software, rather than pulling out their
hair :)
[1]
http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-643) descriptorSourceDirectory: parameter isn't used
Arnaud Heritier created MASSEMBLY-643:
-
Summary: descriptorSourceDirectory: parameter isn't used
Key: MASSEMBLY-643
URL: https://jira.codehaus.org/browse/MASSEMBLY-643
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.4
Reporter: Arnaud Heritier
I configure the plugin with something like this :
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorplf-standalone-enterprise-tomcat-distribution-content.xml/descriptor
/descriptors
descriptorSourceDirectorysrc/main/assemblies/descriptorSourceDirectory
/configuration
/plugin
{code}
But it doesn't find the descriptor (using its filename or its ID)
{code}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-assembly-plugin:2.4:single' with basic
configurator --
[DEBUG] (s) descriptorSourceDirectory =
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/src/main/assemblies
[DEBUG] (s) descriptors =
[plf-standalone-enterprise-tomcat-distribution-content.xml]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single
(plf-standalone-tomcat-distribution-content) on project
plf-enterprise-tomcat-standalone: Error reading assemblies: Error locating
assembly descriptor: plf-standalone-enterprise-tomcat-distribution-content.xml
[ERROR]
[ERROR] [1] [INFO] Searching for file location:
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
[ERROR]
[ERROR] [2] [INFO] File:
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
does not exist.
[ERROR]
[ERROR] [3] [INFO] File:
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
does not exist.
{code}
I simplified the config (I'll need to create an it) in my case i was using a
2nd assembly coming from the classpath
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-643) descriptorSourceDirectory: parameter isn't used
[
https://jira.codehaus.org/browse/MASSEMBLY-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318374#comment-318374
]
Arnaud Heritier commented on MASSEMBLY-643:
---
A workaround is to use this config
{code}
descriptors
descriptorsrc/main/assemblies/plf-standalone-enterprise-tomcat-distribution-content.xml/descriptor
/descriptors
{code}
descriptorSourceDirectory: parameter isn't used
---
Key: MASSEMBLY-643
URL: https://jira.codehaus.org/browse/MASSEMBLY-643
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.4
Reporter: Arnaud Heritier
I configure the plugin with something like this :
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorplf-standalone-enterprise-tomcat-distribution-content.xml/descriptor
/descriptors
descriptorSourceDirectorysrc/main/assemblies/descriptorSourceDirectory
/configuration
/plugin
{code}
But it doesn't find the descriptor (using its filename or its ID)
{code}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-assembly-plugin:2.4:single' with basic
configurator --
[DEBUG] (s) descriptorSourceDirectory =
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/src/main/assemblies
[DEBUG] (s) descriptors =
[plf-standalone-enterprise-tomcat-distribution-content.xml]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.4:single
(plf-standalone-tomcat-distribution-content) on project
plf-enterprise-tomcat-standalone: Error reading assemblies: Error locating
assembly descriptor: plf-standalone-enterprise-tomcat-distribution-content.xml
[ERROR]
[ERROR] [1] [INFO] Searching for file location:
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
[ERROR]
[ERROR] [2] [INFO] File:
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
does not exist.
[ERROR]
[ERROR] [3] [INFO] File:
/Users/arnaud/Code/eXo/platform-distributions/plf-enterprise-tomcat-standalone/plf-standalone-enterprise-tomcat-distribution-content.xml
does not exist.
{code}
I simplified the config (I'll need to create an it) in my case i was using a
2nd assembly coming from the classpath
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-392) dependency:tree is erroneous with Maven 3 (3.0.4 or 3.1-SNAPSHOT)
Arnaud Heritier created MDEP-392: Summary: dependency:tree is erroneous with Maven 3 (3.0.4 or 3.1-SNAPSHOT) Key: MDEP-392 URL: https://jira.codehaus.org/browse/MDEP-392 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: tree Affects Versions: 2.6 Environment: Java 6 Reporter: Arnaud Heritier Priority: Critical Attachments: dependency-tree-mvn-2.2.1.txt, dependency-tree-mvn-3.1-SNAPSHOT.txt I have a complex project with many deps, many depsMgt import ... https://github.com/exoplatform/platform-tomcat-standalone I discovered the issue on rev fb36980 I was trying to blacklist all servlet/jsp dependencies coming projects dependencies (searching them with dependency:tree -Dverbose -Dincludes=*:*servlet*:*). The plugin reported that there was no such dep in my graph after all my exclusions and cleanup in low level projects. But it was false because the assembly plugin continued to find such deps and copied them in my distribution. Downgrading to Maven 2.2.1 allowed me to find some of these dependencies that I didn't found with 3.1 (see commit https://github.com/exoplatform/platform-tomcat-standalone/commit/67eb23a8b6e033cecbd1d1726ff75afebdd0fdfd) Note : this bug is probably something low level because the enforcer plugin has it too. It didn't discover/reported the dependency I wanted to blacklist -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-392) dependency:tree is erroneous with Maven 3 (3.0.4 or 3.1-SNAPSHOT)
[
https://jira.codehaus.org/browse/MDEP-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=315012#comment-315012
]
Arnaud Heritier commented on MDEP-392:
--
Ipushed a branch MDEP-392 in this project to help to reproduce it :
https://github.com/exoplatform/platform-tomcat-standalone/tree/MDEP-392
You may need this repository http://repository.exoplatform.org/public/
Then with Maven 3.x:
{code}
mvn dependency:tree -Dverbose -Dincludes=javax.servlet:servlet-api:*
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building eXo Platform Tomcat Standalone Package
4.0.0.Alpha1-kill-exobuild-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.6:tree (default-cli) @
platform-tomcat-standalone ---
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 24.901s
[INFO] Finished at: Tue Dec 04 23:25:22 CET 2012
[INFO] Final Memory: 34M/125M
[INFO]
{code}
With Maven 2.2.1:
{code}
mvn dependency:tree -Dverbose -Dincludes=javax.servlet:servlet-api:*
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO]
[INFO] Building eXo Platform Tomcat Standalone Package
[INFO]task-segment: [dependency:tree]
[INFO]
[INFO] [dependency:tree {execution: default-cli}]
[INFO]
org.exoplatform.platform.pkg:platform-tomcat-standalone:pom:4.0.0.Alpha1-kill-exobuild-SNAPSHOT
[INFO] \-
org.exoplatform.portal:exo.portal.component.management:jar:3.4.0.Final:compile
[INFO]\- org.exoplatform.ws:exo.ws.rest.core:jar:2.2.10-GA-SNAPSHOT:compile
[INFO] \- javax.servlet:servlet-api:jar:2.5:compile
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 15 seconds
[INFO] Finished at: Tue Dec 04 23:28:17 CET 2012
[INFO] Final Memory: 127M/239M
[INFO]
{code}
I hope that SNAPSHOTs deps will be always available to allow you to reproduce it
For now I didn't find how to easily debug this problem
dependency:tree is erroneous with Maven 3 (3.0.4 or 3.1-SNAPSHOT)
-
Key: MDEP-392
URL: https://jira.codehaus.org/browse/MDEP-392
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: tree
Affects Versions: 2.6
Environment: Java 6
Reporter: Arnaud Heritier
Priority: Critical
Attachments: dependency-tree-mvn-2.2.1.txt,
dependency-tree-mvn-3.1-SNAPSHOT.txt
I have a complex project with many deps, many depsMgt import ...
https://github.com/exoplatform/platform-tomcat-standalone
I discovered the issue on rev fb36980
I was trying to blacklist all servlet/jsp dependencies coming projects
dependencies (searching them with dependency:tree -Dverbose
-Dincludes=*:*servlet*:*).
The plugin reported that there was no such dep in my graph after all my
exclusions and cleanup in low level projects.
But it was false because the assembly plugin continued to find such deps and
copied them in my distribution.
Downgrading to Maven 2.2.1 allowed me to find some of these dependencies that
I didn't found with 3.1 (see commit
https://github.com/exoplatform/platform-tomcat-standalone/commit/67eb23a8b6e033cecbd1d1726ff75afebdd0fdfd)
Note : this bug is probably something low level because the enforcer plugin
has it too. It didn't discover/reported the dependency I wanted to blacklist
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-388) NPE in analyze-report
[
https://jira.codehaus.org/browse/MDEP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MDEP-388:
-
Issue Type: Bug (was: New Feature)
NPE in analyze-report
-
Key: MDEP-388
URL: https://jira.codehaus.org/browse/MDEP-388
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Affects Versions: 2.5.1
Reporter: Benson Margulies
Fix For: 2.6
Using Maven 3.0.4, and site plugin 3.2, and an execution of the
analyze-report goal, I get the following NPE. I'm going to go try to make
some sense and add notes here.
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-289) Incorrect warning with javax.xml
[ https://jira.codehaus.org/browse/MDEP-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=314043#comment-314043 ] Arnaud Heritier commented on MDEP-289: -- I agree with your anlyze and he fact that classes included in the JDK shouldn't be reported as missing deps (but I don't know how to fix that for now - without a dirty hack) Incorrect warning with javax.xml Key: MDEP-289 URL: https://jira.codehaus.org/browse/MDEP-289 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.1 Environment: OS : Windows XP Maven 2.2.1 Java 1.5 Reporter: zaccret Attachments: sandbox.zip When you use some javax.xml classes in a project and that you have transitive dependencies containing these classes, you will get a warning if you analyze your dependencies (Used undeclared dependencies found), even if the classes you use are contained in your JDK. I attach a project using javax.xml.parsers.DocumentBuilder which is included in Java Class Library (rt.jar) but also in a transitive dependency (xml-apis). I think we should not get a warning because the Java Class Library should be the first library found in the classpath, doesn't it ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-388) NPE in analyze-report
[
https://jira.codehaus.org/browse/MDEP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MDEP-388.
Resolution: Duplicate
Fix Version/s: 2.6
This is fixed in the incoming 2.6 release
NPE in analyze-report
-
Key: MDEP-388
URL: https://jira.codehaus.org/browse/MDEP-388
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: analyze
Affects Versions: 2.5.1
Reporter: Benson Margulies
Fix For: 2.6
Using Maven 3.0.4, and site plugin 3.2, and an execution of the
analyze-report goal, I get the following NPE. I'm going to go try to make
some sense and add notes here.
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-366) NPE when running site
[
https://jira.codehaus.org/browse/MDEP-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MDEP-366.
Resolution: Fixed
Fix Version/s: 2.6
Assignee: Arnaud Heritier
Thx a lot for this patch
Wil be solved in the next release
NPE when running site
-
Key: MDEP-366
URL: https://jira.codehaus.org/browse/MDEP-366
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Paul Nyheim
Assignee: Arnaud Heritier
Priority: Blocker
Fix For: 2.6
Attachments: mdep-366-it.patch, mdep-366.patch
I have configured the {{analyze-report}} report in my reporting section of
pom.xml
{code:xml}
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.5/version
reportSets
reportSet
reports
reportanalyze-report/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
And when I try to run {{mvn site}}, I get this NPE:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on project
: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.1:site failed.
NullPointerException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
project : Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.1:site failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-site of goal org.apache.maven.plugins:maven-site-plugin:3.1:site
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugin.dependency.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:100)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:135)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{noformat}
--
This message is automatically generated by JIRA.
If you
[jira] (MRELEASE-724) Release plugin doesn't honor profiles defined in user settings
Arnaud Heritier created MRELEASE-724:
Summary: Release plugin doesn't honor profiles defined in user
settings
Key: MRELEASE-724
URL: https://jira.codehaus.org/browse/MRELEASE-724
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Arnaud Heritier
Priority: Critical
We tried to upgrade the release plugin from 2.2.1 to 2.2.2 and it broke our
release.
We don't define repositories (especially private ones) in our pom but in our
developers settings (activated from command line or more often in
activeProfiles)
Releasing this project fails with :
{code}
arnaud@mbp-arnaud:~/Code/eXo/cloud-management (git:develop %)$ mvn
release:prepare -DdryRun=true
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
...
[INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
cloud-management-parent ---
[INFO] Resuming release from phase 'run-preparation-goals'
[INFO] Executing preparation goals - since this is simulation mode it is
running against the original project, not the rewritten ones
[INFO] Executing goals 'clean verify'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [INFO]
[INFO] [INFO] Reactor Build Order:
...
[INFO] [INFO]
[INFO] [INFO] Building eXo Cloud Management :: Parent 1.1-M4-SNAPSHOT
[INFO] [INFO]
...
[INFO] [INFO] --- maven-license-plugin:1.9.0:check (check-headers) @
cloud-management-parent ---
[INFO] [WARNING] The POM for
org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 is missing, no
dependency information available
[INFO] [INFO]
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] eXo Cloud Management :: Parent FAILURE
[1.257s]
...
[INFO] [INFO]
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO]
...
[INFO] [INFO]
[INFO] [WARNING] The requested profile exo-central could not be activated
because it does not exist.
[INFO] [WARNING] The requested profile local-properties could not be
activated because it does not exist.
[INFO] [WARNING] The requested profile exo-private could not be activated
because it does not exist.
[INFO] [WARNING] The requested profile exo-staging could not be activated
because it does not exist.
[INFO] [ERROR] Failed to execute goal
com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
(check-headers) on project cloud-management-parent: Execution check-headers of
goal com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check failed:
Plugin com.mycila.maven-license-plugin:maven-license-plugin:1.9.0 or one of its
dependencies could not be resolved: Failure to find
org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 in
http://repository.exoplatform.org/public was cached in the local repository,
resolution will not be reattempted until the update interval of exo-fr-mirror
has elapsed or updates are forced - [Help 1]
[INFO] [ERROR]
[INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
[INFO] [ERROR]
[INFO] [ERROR] For more information about the errors and possible solutions,
please read the following articles:
[INFO] [ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] eXo Cloud Management :: Parent FAILURE [5.210s]
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
...
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2.2:prepare (default-cli) on
project cloud-management-parent: Maven execution failed, exit code: '1' -
[Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the
[jira] (MRELEASE-724) Release plugin doesn't honor profiles defined in user settings
[
https://jira.codehaus.org/browse/MRELEASE-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MRELEASE-724:
-
Attachment: MRELEASE-724.log
debug logs
Release plugin doesn't honor profiles defined in user settings
--
Key: MRELEASE-724
URL: https://jira.codehaus.org/browse/MRELEASE-724
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.2.2
Reporter: Arnaud Heritier
Priority: Critical
Attachments: MRELEASE-724.log
We tried to upgrade the release plugin from 2.2.1 to 2.2.2 and it broke our
release.
We don't define repositories (especially private ones) in our pom but in our
developers settings (activated from command line or more often in
activeProfiles)
Releasing this project fails with :
{code}
arnaud@mbp-arnaud:~/Code/eXo/cloud-management (git:develop %)$ mvn
release:prepare -DdryRun=true
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
...
[INFO] --- maven-release-plugin:2.2.2:prepare (default-cli) @
cloud-management-parent ---
[INFO] Resuming release from phase 'run-preparation-goals'
[INFO] Executing preparation goals - since this is simulation mode it is
running against the original project, not the rewritten ones
[INFO] Executing goals 'clean verify'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] [INFO] Scanning for projects...
[INFO] [INFO]
[INFO] [INFO] Reactor Build Order:
...
[INFO] [INFO]
[INFO] [INFO] Building eXo Cloud Management :: Parent 1.1-M4-SNAPSHOT
[INFO] [INFO]
...
[INFO] [INFO] --- maven-license-plugin:1.9.0:check (check-headers) @
cloud-management-parent ---
[INFO] [WARNING] The POM for
org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 is missing, no
dependency information available
[INFO] [INFO]
[INFO] [INFO] Reactor Summary:
[INFO] [INFO]
[INFO] [INFO] eXo Cloud Management :: Parent FAILURE
[1.257s]
...
[INFO] [INFO]
[INFO] [INFO] BUILD FAILURE
[INFO] [INFO]
...
[INFO] [INFO]
[INFO] [WARNING] The requested profile exo-central could not be activated
because it does not exist.
[INFO] [WARNING] The requested profile local-properties could not be
activated because it does not exist.
[INFO] [WARNING] The requested profile exo-private could not be activated
because it does not exist.
[INFO] [WARNING] The requested profile exo-staging could not be activated
because it does not exist.
[INFO] [ERROR] Failed to execute goal
com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
(check-headers) on project cloud-management-parent: Execution check-headers
of goal com.mycila.maven-license-plugin:maven-license-plugin:1.9.0:check
failed: Plugin com.mycila.maven-license-plugin:maven-license-plugin:1.9.0 or
one of its dependencies could not be resolved: Failure to find
org.exoplatform.cloud-management:cloud-build-tools:jar:0.1-M1 in
http://repository.exoplatform.org/public was cached in the local repository,
resolution will not be reattempted until the update interval of exo-fr-mirror
has elapsed or updates are forced - [Help 1]
[INFO] [ERROR]
[INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
[INFO] [ERROR]
[INFO] [ERROR] For more information about the errors and possible solutions,
please read the following articles:
[INFO] [ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] eXo Cloud Management :: Parent FAILURE [5.210s]
...
[INFO]
[INFO] BUILD FAILURE
[INFO]
...
[INFO]
[ERROR] Failed to execute goal
[jira] (WAGON-367) Very large number of temporary files http-wagon.*.tmp if wagon is used in a long time running JVM (like a CI server)
[
https://jira.codehaus.org/browse/WAGON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=286094#comment-286094
]
Arnaud Heritier commented on WAGON-367:
---
What is your point of view ? Should we block the 2.2 release to include this
fix in webdav (and perhaps others) connectors ?
Very large number of temporary files http-wagon.*.tmp if wagon is used in a
long time running JVM (like a CI server)
--
Key: WAGON-367
URL: https://jira.codehaus.org/browse/WAGON-367
Project: Maven Wagon
Issue Type: Bug
Components: wagon-webdav
Affects Versions: 2.1
Reporter: Arnaud Heritier
See
http://maven.apache.org/wagon/wagon-providers/wagon-http-shared/xref/index.html
I discovered the issue in Jenkins after having it running for days. My
temporary directory had so many files http-wagon.*.tmp that a {{rm *}} was
refused (too many params).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-601) The Maven 2 release plugin modifies CDATA elements in pom.xml files.
[ https://jira.codehaus.org/browse/MRELEASE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=286111#comment-286111 ] Arnaud Heritier commented on MRELEASE-601: -- Reproduced with 2.2.1 The Maven 2 release plugin modifies CDATA elements in pom.xml files. Key: MRELEASE-601 URL: https://jira.codehaus.org/browse/MRELEASE-601 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-7 Reporter: Brandon Enochs Priority: Blocker Attachments: pom.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-367) Unlimited number of temporary http-wagon.*.tmp files if wagon is used in a long time running JVM
Arnaud Heritier created WAGON-367:
-
Summary: Unlimited number of temporary http-wagon.*.tmp files if
wagon is used in a long time running JVM
Key: WAGON-367
URL: https://jira.codehaus.org/browse/WAGON-367
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.1
Reporter: Arnaud Heritier
See
http://maven.apache.org/wagon/wagon-providers/wagon-http-shared/xref/index.html
I discovered the issue in Jenkins after having it running for days. My
temporary directory had so many files http-wagon.*.tmp that a {{rm *}} was
refused (too many params).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-367) Very large number of temporary files http-wagon.*.tmp if wagon is used in a long time running JVM (like a CI server)
[
https://jira.codehaus.org/browse/WAGON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated WAGON-367:
--
Summary: Very large number of temporary files http-wagon.*.tmp if wagon
is used in a long time running JVM (like a CI server) (was: Very large number
of temporary http-wagon.*.tmp files if wagon is used in a long time running
JVM (like a CI server))
Very large number of temporary files http-wagon.*.tmp if wagon is used in a
long time running JVM (like a CI server)
--
Key: WAGON-367
URL: https://jira.codehaus.org/browse/WAGON-367
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.1
Reporter: Arnaud Heritier
See
http://maven.apache.org/wagon/wagon-providers/wagon-http-shared/xref/index.html
I discovered the issue in Jenkins after having it running for days. My
temporary directory had so many files http-wagon.*.tmp that a {{rm *}} was
refused (too many params).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-367) Very large number of temporary http-wagon.*.tmp files if wagon is used in a long time running JVM (like a CI server)
[
https://jira.codehaus.org/browse/WAGON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated WAGON-367:
--
Summary: Very large number of temporary http-wagon.*.tmp files if wagon
is used in a long time running JVM (like a CI server) (was: Unlimited number
of temporary http-wagon.*.tmp files if wagon is used in a long time running
JVM)
Very large number of temporary http-wagon.*.tmp files if wagon is used in a
long time running JVM (like a CI server)
--
Key: WAGON-367
URL: https://jira.codehaus.org/browse/WAGON-367
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.1
Reporter: Arnaud Heritier
See
http://maven.apache.org/wagon/wagon-providers/wagon-http-shared/xref/index.html
I discovered the issue in Jenkins after having it running for days. My
temporary directory had so many files http-wagon.*.tmp that a {{rm *}} was
refused (too many params).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MWAR-240) archiveClasses and attachClasses in 2.1
[
https://jira.codehaus.org/browse/MWAR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MWAR-240.
Resolution: Fixed
Fix Version/s: 2.1.2
Will be fixed in the next version (applied patch + added an integration test)
archiveClasses and attachClasses in 2.1
---
Key: MWAR-240
URL: https://jira.codehaus.org/browse/MWAR-240
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_18
Default locale: de_DE, platform encoding: Cp1252
OS name: windows 7 version: 6.1 arch: amd64 Family: windows
Reporter: Sergiy Shyrkov
Assignee: Arnaud Heritier
Fix For: 2.1.2
Attachments: effective-pom.out, mwar-240.patch, mwar-240-test-case.zip
There seems to be a regression between 2.1-beta-1 and 2.1 with regard to
archiveClasses and attachClasses options.
My use case:
I have a WAR project with Java classes and I am setting both archiveClasses
and attachClasses to true.
With 2.1-beta-1 it was working correctly (mvn clean install) -- I got
classes packaged into a JAR and placed into WEB-INF/lib and I got that JAR
artifact deployed to my Maven repository.
Just upgraded to 2.1 and I got the following with the same use case: I got
classes packaged into a JAR and placed into WEB-INF/lib (correct) and I got
an empty JAR artifact (only META-INF/ present) deployed to my Maven
repository (incorrect).
Looking at the code in 2.1 of WarMojo (line 230) I am seeing that the classes
folder (for classes to be included into attached artifact) is empty, because
it was cleared before due to archiveClasses=true
Trying to debug both code branches I am seeing a difference between
2.1-beta-1 and 2.1 in that the
getJarArchiver().getDirs() before the call to packager.packageClasses()
method (line 233/234)
is empty in the 2.1:
(java.util.HashMapK,V) {}
whereas it is not in 2.1-beta-1. It contains a list of all my classes,
perhaps because the same archiver instance was used to package them into JAR
for WEB-INF/lib.
That is why I am getting all my classes in the attached artifact with
2.1-beta-1
I would really need your help in understanding the correct behaviour.
Is this a regression bug for 2.1 or I am completely wrong in my expectations
about archiveClasses and attachClasses used together?
Kind regards
Sergiy Shyrkov
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
