[jira] [Updated] (MASSEMBLY-864) Dependencies specified in activeByDefault profile not picked up.
[ https://issues.apache.org/jira/browse/MASSEMBLY-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Axel Fontaine updated MASSEMBLY-864: Attachment: massembly-864.zip > Dependencies specified in activeByDefault profile not picked up. > > > Key: MASSEMBLY-864 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-864 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Axel Fontaine >Priority: Major > Attachments: massembly-864.zip > > > I have the following dependencySet in my assembly XML: > > jre > > com.oracle:server-jre > > true > > > jdk8.74/jre/**/* > > > > And the following dependency in my pom.xml: > > com.oracle > server-jre > linux-x64 > 8.74 > tar.gz > provided > > The dependency gets correctly picked up when it is declared within the main > dependencies section of the POM. However when it is only present within a > profile: > > > CommercialDBTest > > true > > > > com.oracle > server-jre > linux-x64 > tar.gz > provided > > I then get > [WARNING] The following patterns were never triggered in this artifact > exclusion filter: > o 'com.oracle:server-jre' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-227) Use build extensions defined in pom.xml for deploy-file
[ https://issues.apache.org/jira/browse/MDEPLOY-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289141#comment-16289141 ] Axel Fontaine commented on MDEPLOY-227: --- After investigating further I discovered that this seems to work when using "mvn -f pom.xml" instead of just "mvn". Not obvious. > Use build extensions defined in pom.xml for deploy-file > --- > > Key: MDEPLOY-227 > URL: https://issues.apache.org/jira/browse/MDEPLOY-227 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 2.8.2 >Reporter: Axel Fontaine > > It is currently not possible to use deploy-file to deploy to S3 as that > requires a build extension for a custom wagon and deploy-file ignores those. > This works fine with deploy, but that rebuilds the artifacts, which isn't > what I want either. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MDEPLOY-227) Use build extensions defined in pom.xml for deploy-file
Axel Fontaine created MDEPLOY-227: - Summary: Use build extensions defined in pom.xml for deploy-file Key: MDEPLOY-227 URL: https://issues.apache.org/jira/browse/MDEPLOY-227 Project: Maven Deploy Plugin Issue Type: Bug Components: deploy:deploy-file Affects Versions: 2.8.2 Reporter: Axel Fontaine It is currently not possible to use deploy-file to deploy to S3 as that requires a build extension for a custom wagon and deploy-file ignores those. This works fine with deploy, but that rebuilds the artifacts, which isn't what I want either. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MENFORCER-280) Enforcer dependency convergence stumbles on selenium-java
Axel Fontaine created MENFORCER-280:
---
Summary: Enforcer dependency convergence stumbles on selenium-java
Key: MENFORCER-280
URL: https://issues.apache.org/jira/browse/MENFORCER-280
Project: Maven Enforcer Plugin
Issue Type: Bug
Affects Versions: 3.0.0-M1
Reporter: Axel Fontaine
When running the dependency convergence check, we get this impossible result:
{{Dependency convergence error for org.seleniumhq.selenium:selenium-java:3.3.1
paths to dependency are:
+-com.mywebapp:0-SNAPSHOT
+-org.seleniumhq.selenium:selenium-java:3.3.1
and
+-com.mywebapp:0-SNAPSHOT
+-org.seleniumhq.selenium:selenium-java:3.3.1
+-org.seleniumhq.selenium:selenium-java:3.1.0}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MASSEMBLY-864) Dependencies specified in activeByDefault profile not picked up.
[ https://issues.apache.org/jira/browse/MASSEMBLY-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088181#comment-16088181 ] Axel Fontaine edited comment on MASSEMBLY-864 at 7/15/17 3:06 AM: -- Thanks for investigating! What do you think? Should this be raised as a bug with Maven Core? P.S.: Thank you very much for the workaround!! For the first time in months Flyway's TravisCI build is now green! was (Author: axel.fontaine): Thanks for investigating! What do you think? Should this be raised as a bug with Maven Core? > Dependencies specified in activeByDefault profile not picked up. > > > Key: MASSEMBLY-864 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-864 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Axel Fontaine > > I have the following dependencySet in my assembly XML: > > jre > > com.oracle:server-jre > > true > > > jdk8.74/jre/**/* > > > > And the following dependency in my pom.xml: > > com.oracle > server-jre > linux-x64 > 8.74 > tar.gz > provided > > The dependency gets correctly picked up when it is declared within the main > dependencies section of the POM. However when it is only present within a > profile: > > > CommercialDBTest > > true > > > > com.oracle > server-jre > linux-x64 > tar.gz > provided > > I then get > [WARNING] The following patterns were never triggered in this artifact > exclusion filter: > o 'com.oracle:server-jre' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MASSEMBLY-864) Dependencies specified in activeByDefault profile not picked up.
[ https://issues.apache.org/jira/browse/MASSEMBLY-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088181#comment-16088181 ] Axel Fontaine edited comment on MASSEMBLY-864 at 7/14/17 10:05 PM: --- Thanks for investigating! What do you think? Should this be raised as a bug with Maven Core? was (Author: axel.fontaine): Should this be raised as a bug with Maven Core? > Dependencies specified in activeByDefault profile not picked up. > > > Key: MASSEMBLY-864 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-864 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Axel Fontaine > > I have the following dependencySet in my assembly XML: > > jre > > com.oracle:server-jre > > true > > > jdk8.74/jre/**/* > > > > And the following dependency in my pom.xml: > > com.oracle > server-jre > linux-x64 > 8.74 > tar.gz > provided > > The dependency gets correctly picked up when it is declared within the main > dependencies section of the POM. However when it is only present within a > profile: > > > CommercialDBTest > > true > > > > com.oracle > server-jre > linux-x64 > tar.gz > provided > > I then get > [WARNING] The following patterns were never triggered in this artifact > exclusion filter: > o 'com.oracle:server-jre' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-864) Dependencies specified in activeByDefault profile not picked up.
[ https://issues.apache.org/jira/browse/MASSEMBLY-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16088181#comment-16088181 ] Axel Fontaine commented on MASSEMBLY-864: - Should this be raised as a bug with Maven Core? > Dependencies specified in activeByDefault profile not picked up. > > > Key: MASSEMBLY-864 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-864 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Axel Fontaine > > I have the following dependencySet in my assembly XML: > > jre > > com.oracle:server-jre > > true > > > jdk8.74/jre/**/* > > > > And the following dependency in my pom.xml: > > com.oracle > server-jre > linux-x64 > 8.74 > tar.gz > provided > > The dependency gets correctly picked up when it is declared within the main > dependencies section of the POM. However when it is only present within a > profile: > > > CommercialDBTest > > true > > > > com.oracle > server-jre > linux-x64 > tar.gz > provided > > I then get > [WARNING] The following patterns were never triggered in this artifact > exclusion filter: > o 'com.oracle:server-jre' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-864) Dependencies specified in activeByDefault profile not picked up.
[ https://issues.apache.org/jira/browse/MASSEMBLY-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087315#comment-16087315 ] Axel Fontaine commented on MASSEMBLY-864: - Sorry about the delay and thanks for your patience. I've finally come around to creating a small project to reproduce this: https://github.com/axelfontaine/massembly-864 While it doesn't fully reproduce this issue, it certainly exhibits other problematic behavior in the Maven Assembly plugin which is biting us with the Flyway build and may help us uncover the root cause for the behavior I originally reported here. The issue uncovered by the repro repo is that the assembly plugin attempts to download dependencies from only defined in disabled Maven profiles. If you clone that repo and run "./mvnw install -P-fat" it should succeed, yet fails. I hope this helps in tracking this down. P.S.: Yes I know the S3 wagon probably should warn instead of fail, but my point still stands: the assembly plugin should not attempt to download dependencies only defined in disabled Maven profiles. > Dependencies specified in activeByDefault profile not picked up. > > > Key: MASSEMBLY-864 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-864 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Axel Fontaine > > I have the following dependencySet in my assembly XML: > > jre > > com.oracle:server-jre > > true > > > jdk8.74/jre/**/* > > > > And the following dependency in my pom.xml: > > com.oracle > server-jre > linux-x64 > 8.74 > tar.gz > provided > > The dependency gets correctly picked up when it is declared within the main > dependencies section of the POM. However when it is only present within a > profile: > > > CommercialDBTest > > true > > > > com.oracle > server-jre > linux-x64 > tar.gz > provided > > I then get > [WARNING] The following patterns were never triggered in this artifact > exclusion filter: > o 'com.oracle:server-jre' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-863) Add ability to set outputDirectory in unpackOptions
[ https://issues.apache.org/jira/browse/MASSEMBLY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079600#comment-16079600 ] Axel Fontaine commented on MASSEMBLY-863: - Yep. Definitely a dupe. Sorry about that. Feel free to close this one. > Add ability to set outputDirectory in unpackOptions > --- > > Key: MASSEMBLY-863 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-863 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 3.0.0 >Reporter: Axel Fontaine > > I have a tar.gz dependency containing the following structure: jdk8.74/jre/... > I would like to include that jre folder as /jre within an assembly. This is > my current dependencySet: > > jre > > com.oracle:server-jre > > true > > > jdk8.74/jre/**/* > > > > This always results in the contents of the jre folder ending up under > /jre/jdk8.74/jre in the assembly instead of simply under /jre . There > currently is no setting in > http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions > that allows me to do that. > (Apologies for the layout, the "preformatted" style seems to have no effect) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MASSEMBLY-863) Add ability to set outputDirectory in unpackOptions
[ https://issues.apache.org/jira/browse/MASSEMBLY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Axel Fontaine resolved MASSEMBLY-863. - Resolution: Duplicate > Add ability to set outputDirectory in unpackOptions > --- > > Key: MASSEMBLY-863 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-863 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 3.0.0 >Reporter: Axel Fontaine > > I have a tar.gz dependency containing the following structure: jdk8.74/jre/... > I would like to include that jre folder as /jre within an assembly. This is > my current dependencySet: > > jre > > com.oracle:server-jre > > true > > > jdk8.74/jre/**/* > > > > This always results in the contents of the jre folder ending up under > /jre/jdk8.74/jre in the assembly instead of simply under /jre . There > currently is no setting in > http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions > that allows me to do that. > (Apologies for the layout, the "preformatted" style seems to have no effect) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MASSEMBLY-862) Assembly creation fails on Windows when extracting a tar.gz containing a symbolic link
[ https://issues.apache.org/jira/browse/MASSEMBLY-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16079572#comment-16079572 ] Axel Fontaine commented on MASSEMBLY-862: - Hi Plamen, Thank you very much for the detailed explanation. I went back over my config and noticed that I was indeed extracting the dependency using the dependency plugin first. Now why was this the case? It turns out that I simply could not get the assembly plugin to work properly. I have now filed the first two issues describing some of the problems I had that led to this situation: * https://issues.apache.org/jira/browse/MASSEMBLY-863 * https://issues.apache.org/jira/browse/MASSEMBLY-864 > Assembly creation fails on Windows when extracting a tar.gz containing a > symbolic link > -- > > Key: MASSEMBLY-862 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-862 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 > Environment: Windows >Reporter: Axel Fontaine > > Related issue: https://github.com/codehaus-plexus/plexus-archiver/issues/66 > Workaround: open console with admin rights > Suggested solution: > The platform the build runs on should not influence the ability to build the > assembly. The issue with the Maven Assembly Plugin (which uses the Plexus > Archiver) is actually that it depends on the filesystem (and its capabilities > on the current platform) to build the archive, whereas it could also build it > fully in-memory and be truly platform independent. This should be the > default, with maybe an optional flag to revert to disk buffering for extra > large payloads. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MASSEMBLY-864) Dependencies specified in activeByDefault profile not picked up.
Axel Fontaine created MASSEMBLY-864: --- Summary: Dependencies specified in activeByDefault profile not picked up. Key: MASSEMBLY-864 URL: https://issues.apache.org/jira/browse/MASSEMBLY-864 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 3.0.0 Reporter: Axel Fontaine I have the following dependencySet in my assembly XML: jre com.oracle:server-jre true jdk8.74/jre/**/* And the following dependency in my pom.xml: com.oracle server-jre linux-x64 8.74 tar.gz provided The dependency gets correctly picked up when it is declared within the main dependencies section of the POM. However when it is only present within a profile: CommercialDBTest true com.oracle server-jre linux-x64 tar.gz provided I then get [WARNING] The following patterns were never triggered in this artifact exclusion filter: o 'com.oracle:server-jre' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MASSEMBLY-863) Add ability to set outputDirectory in unpackOptions
[
https://issues.apache.org/jira/browse/MASSEMBLY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Axel Fontaine updated MASSEMBLY-863:
Description:
I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
I would like to include that jre folder as /jre within an assembly. This is my
current dependencySet:
jre
com.oracle:server-jre
true
jdk8.74/jre/**/*
This always results in the contents of the jre folder ending up under
/jre/jdk8.74/jre in the assembly instead of simply under /jre . There currently
is no setting in
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
that allows me to do that.
(Apologies for the layout, the "preformatted" style seems to have no effect)
was:
I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
I would like to include that jre folder as /jre within an assembly. This is my
current dependencySet:
{{
jre
com.oracle:server-jre
true
jdk8.74/jre/**/*
}}
This always results in the contents of the jre folder ending up under
/jre/jdk8.74/jre in the assembly instead of simply under /jre . There currently
is no setting in
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
that allows me to do that.
> Add ability to set outputDirectory in unpackOptions
> ---
>
> Key: MASSEMBLY-863
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-863
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Axel Fontaine
>
> I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
> I would like to include that jre folder as /jre within an assembly. This is
> my current dependencySet:
>
> jre
>
> com.oracle:server-jre
>
> true
>
>
> jdk8.74/jre/**/*
>
>
>
> This always results in the contents of the jre folder ending up under
> /jre/jdk8.74/jre in the assembly instead of simply under /jre . There
> currently is no setting in
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
> that allows me to do that.
> (Apologies for the layout, the "preformatted" style seems to have no effect)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MASSEMBLY-863) Add ability to set outputDirectory in unpackOptions
[
https://issues.apache.org/jira/browse/MASSEMBLY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Axel Fontaine updated MASSEMBLY-863:
Description:
I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
I would like to include that jre folder as /jre within an assembly. This is my
current dependencySet:
{{
jre
com.oracle:server-jre
true
jdk8.74/jre/**/*
}}
This always results in the contents of the jre folder ending up under
/jre/jdk8.74/jre in the assembly instead of simply under /jre . There currently
is no setting in
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
that allows me to do that.
was:
I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
I would like to include that jre folder as /jre within an assembly. This is my
current dependencySet:
{{
jre
com.oracle:server-jre
true
jdk8.74/jre/**/*
}}
This always results in the contents of the jre folder ending up under
/jre/jdk8.74/jre in the assembly instead of simply under /jre . There currently
is no setting in
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
that allows me to do that.
> Add ability to set outputDirectory in unpackOptions
> ---
>
> Key: MASSEMBLY-863
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-863
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Axel Fontaine
>
> I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
> I would like to include that jre folder as /jre within an assembly. This is
> my current dependencySet:
> {{
>
> jre
>
> com.oracle:server-jre
>
> true
>
>
> jdk8.74/jre/**/*
>
>
>
> }}
> This always results in the contents of the jre folder ending up under
> /jre/jdk8.74/jre in the assembly instead of simply under /jre . There
> currently is no setting in
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
> that allows me to do that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MASSEMBLY-863) Add ability to set outputDirectory in unpackOptions
[
https://issues.apache.org/jira/browse/MASSEMBLY-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Axel Fontaine updated MASSEMBLY-863:
Description:
I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
I would like to include that jre folder as /jre within an assembly. This is my
current dependencySet:
{{
jre
com.oracle:server-jre
true
jdk8.74/jre/**/*
}}
This always results in the contents of the jre folder ending up under
/jre/jdk8.74/jre in the assembly instead of simply under /jre . There currently
is no setting in
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
that allows me to do that.
was:
I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
I would like to include that jre folder as /jre within an assembly. This is my
current dependencySet:
jre
com.oracle:server-jre
true
jdk8.74/jre/**/*
This always results in the contents of the jre folder ending up under
/jre/jdk8.74/jre in the assembly instead of simply under /jre
> Add ability to set outputDirectory in unpackOptions
> ---
>
> Key: MASSEMBLY-863
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-863
> Project: Maven Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Axel Fontaine
>
> I have a tar.gz dependency containing the following structure: jdk8.74/jre/...
> I would like to include that jre folder as /jre within an assembly. This is
> my current dependencySet:
> {{
> jre
>
> com.oracle:server-jre
>
> true
>
>
> jdk8.74/jre/**/*
>
>
>
> }}
> This always results in the contents of the jre folder ending up under
> /jre/jdk8.74/jre in the assembly instead of simply under /jre . There
> currently is no setting in
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
> that allows me to do that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MASSEMBLY-863) Add ability to set outputDirectory in unpackOptions
Axel Fontaine created MASSEMBLY-863: --- Summary: Add ability to set outputDirectory in unpackOptions Key: MASSEMBLY-863 URL: https://issues.apache.org/jira/browse/MASSEMBLY-863 Project: Maven Assembly Plugin Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Axel Fontaine I have a tar.gz dependency containing the following structure: jdk8.74/jre/... I would like to include that jre folder as /jre within an assembly. This is my current dependencySet: jre com.oracle:server-jre true jdk8.74/jre/**/* This always results in the contents of the jre folder ending up under /jre/jdk8.74/jre in the assembly instead of simply under /jre -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MASSEMBLY-862) Assembly creation fails on Windows when extracting a tar.gz containing a symbolic link
Axel Fontaine created MASSEMBLY-862: --- Summary: Assembly creation fails on Windows when extracting a tar.gz containing a symbolic link Key: MASSEMBLY-862 URL: https://issues.apache.org/jira/browse/MASSEMBLY-862 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 3.0.0 Environment: Windows Reporter: Axel Fontaine Related issue: https://github.com/codehaus-plexus/plexus-archiver/issues/66 Workaround: open console with admin rights Suggested solution: The platform the build runs on should not influence the ability to build the assembly. The issue with the Maven Assembly Plugin (which uses the Plexus Archiver) is actually that it depends on the filesystem (and its capabilities on the current platform) to build the archive, whereas it could also build it fully in-memory and be truly platform independent. This should be the default, with maybe an optional flag to revert to disk buffering for extra large payloads. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MNG-6028) When a reactor build fails maven should include current goals in resume suggestion
Axel Fontaine created MNG-6028: -- Summary: When a reactor build fails maven should include current goals in resume suggestion Key: MNG-6028 URL: https://issues.apache.org/jira/browse/MNG-6028 Project: Maven Issue Type: Improvement Affects Versions: 3.3.9 Reporter: Axel Fontaine Start multiproject build at root with mvn clean install if module-a fails you currently get [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :module-a to be able to easily copy-paste this it would be much nicer if the goals were already filled in: [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn clean install -rf :module-a -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5949) NPE when running with -T2 under Jenkins
[ https://issues.apache.org/jira/browse/MNG-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065829#comment-15065829 ] Axel Fontaine commented on MNG-5949: I finally had the chance to upgrade Jenkins to the latest version (1.642) with all Jenkins plugins updated. Same issue. > NPE when running with -T2 under Jenkins > --- > > Key: MNG-5949 > URL: https://issues.apache.org/jira/browse/MNG-5949 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.1, 3.3.3, 3.3.9 > Environment: Linux x64, JDK 8, Jenkins >Reporter: Axel Fontaine > > When running single threaded everything works fine. When I enable -T2 the > resource plugin fails to create the output directory of the second module due > to this NPE: > java.lang.NullPointerException > at > org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:195) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:561) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > 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:116) > at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185) > at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5949) NPE when running with -T2 under Jenkins
[ https://issues.apache.org/jira/browse/MNG-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060755#comment-15060755 ] Axel Fontaine commented on MNG-5949: I tried both 2.6 and 2.7, same behavior. This is the complete stack trace if it helps: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:2.6:resources (default-resources) on project proj-base: Cannot create resource output directory: /var/lib/jenkins/workspace/proj/proj-base/target/classes -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:2.6:resources (default-resources) on project proj-base: Cannot create resource output directory: /var/lib/jenkins/workspace/proj/proj-base/target/classes at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798) 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:116) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.UserRequest.deserialize(UserRequest.java:185) at java.lang.Thread.run(Thread.java:745) at hudson.remoting.UserRequest.perform(UserRequest.java:99) Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot create resource output directory: /var/lib/jenkins/workspace/proj/proj-base/target/classes at org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:307) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) ... 11 more Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Cannot create resource output directory: /var/lib/jenkins/workspace/proj/proj-base/target/classes at org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:215) at org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301) ... 13 more [ERROR] NullPointerException java.lang.NullPointerException at org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:195) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:561) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) 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:116) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) > NPE when running with -T2 under Jenkins > --- > > Key: MNG-5949 > URL: https://issues.apache.org/jira/browse/MNG-5949 > Project:
[jira] [Commented] (MNG-5949) NPE when running with -T2 under Jenkins
[ https://issues.apache.org/jira/browse/MNG-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060790#comment-15060790 ] Axel Fontaine commented on MNG-5949: Maven Build Type on Jenkins Master > NPE when running with -T2 under Jenkins > --- > > Key: MNG-5949 > URL: https://issues.apache.org/jira/browse/MNG-5949 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.1, 3.3.3, 3.3.9 > Environment: Linux x64, JDK 8, Jenkins >Reporter: Axel Fontaine > > When running single threaded everything works fine. When I enable -T2 the > resource plugin fails to create the output directory of the second module due > to this NPE: > java.lang.NullPointerException > at > org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:195) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:561) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > 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:116) > at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185) > at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5949) NPE when running with -T2 under Jenkins
[ https://issues.apache.org/jira/browse/MNG-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060824#comment-15060824 ] Axel Fontaine commented on MNG-5949: Well that can't be a permission issue as it works every time without -T2 > NPE when running with -T2 under Jenkins > --- > > Key: MNG-5949 > URL: https://issues.apache.org/jira/browse/MNG-5949 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.1, 3.3.3, 3.3.9 > Environment: Linux x64, JDK 8, Jenkins >Reporter: Axel Fontaine > > When running single threaded everything works fine. When I enable -T2 the > resource plugin fails to create the output directory of the second module due > to this NPE: > java.lang.NullPointerException > at > org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:195) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:561) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) > 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:116) > at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185) > at > org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5949) NPE when running with -T2 under Jenkins
Axel Fontaine created MNG-5949: -- Summary: NPE when running with -T2 under Jenkins Key: MNG-5949 URL: https://issues.apache.org/jira/browse/MNG-5949 Project: Maven Issue Type: Bug Components: core Affects Versions: 3.3.9, 3.3.3, 3.3.1 Environment: Linux x64, JDK 8, Jenkins Reporter: Axel Fontaine When running single threaded everything works fine. When I enable -T2 the resource plugin fails to create the output directory of the second module due to this NPE: java.lang.NullPointerException at org.apache.maven.execution.MavenSession.getPluginContext(MavenSession.java:195) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:561) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) 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:116) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5916) Regression from 3.0: Allow filtering out certain loggers from within a plugin
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976431#comment-14976431 ] Axel Fontaine commented on MNG-5916: Can this issue be reopened until a fix/solution exists? I believe the description of the problem should be complete by now. > Regression from 3.0: Allow filtering out certain loggers from within a plugin > - > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MNG-5916) Regression from 3.0: Allow filtering out certain loggers from within a plugin
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Axel Fontaine updated MNG-5916: --- Comment: was deleted (was: Can this issue be reopened until a fix/solution exists? I believe the description of the problem should be complete by now.) > Regression from 3.0: Allow filtering out certain loggers from within a plugin > - > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (MNG-5916) Regression from 3.0: Allow filtering out certain loggers from within a plugin
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Axel Fontaine reopened MNG-5916: Reopening as I believe the description of the problem should be complete now. > Regression from 3.0: Allow filtering out certain loggers from within a plugin > - > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5916) Replace slf4j-simple with logback or allow filtering out certain loggers
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973156#comment-14973156 ] Axel Fontaine commented on MNG-5916: I believe you didn't read my description properly. This is not a request for help. It is a bug/regression compared to Maven 3.0.x where I could influence this by filtering logging output via a custom log4j/logback appender to the Maven log. This is not possible anymore and a real issue for us. I HAVE read the Maven guide guide thoroughly and it does NOT provide a solution, since filtering out certain loggers requires modifying the Maven installation (something we cannot do on our users' machines as I mentioned in the original description) and CANNOT be done from WITHIN a plugin. This also has nothing to do with HTTPCLIENT-1664 as commons logging output can already be easily be redirected to slf4j. My apologies if I wasn't clear enough in my initial description. > Replace slf4j-simple with logback or allow filtering out certain loggers > > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5916) Replace slf4j-simple with logback or allow filtering out certain loggers
[
https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973340#comment-14973340
]
Axel Fontaine commented on MNG-5916:
[~afloom] Up until 3.0 we were using a log4j appender like this:
import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.LoggingEvent;
import org.apache.maven.plugin.logging.Log;
/**
* Log4J appender that writes to the Maven log.
*/
public class MavenLogAppender extends AppenderSkeleton {
private static Log log;
public static void init(Log mavenLog) {
log = mavenLog;
if (log.isDebugEnabled()) {
Logger.getRootLogger().setLevel(Level.DEBUG);
}
}
@Override
protected void append(LoggingEvent event) {
Level level = event.getLevel();
String message = event.getRenderedMessage();
@SuppressWarnings("ThrowableResultOfMethodCallIgnored") Throwable
throwable =
event.getThrowableInformation() == null ? null :
event.getThrowableInformation().getThrowable();
if (event.getLogger().getEffectiveLevel().isGreaterOrEqual(level)) {
if (level == Level.DEBUG) {
if (throwable == null) {
log.debug(message);
} else {
log.debug(message, throwable);
}
} else if (level == Level.INFO) {
if (throwable == null) {
log.info(message);
} else {
log.info(message, throwable);
}
} else if (level == Level.WARN) {
if (throwable == null) {
log.warn(message);
} else {
log.warn(message, throwable);
}
} else if ((level == Level.ERROR) || (level == Level.FATAL)) {
if (throwable == null) {
log.error(message);
} else {
log.error(message, throwable);
}
}
}
}
@Override
public void close() {
}
@Override
public boolean requiresLayout() {
return false;
}
}
This allowed us to ship a log4j.xml file as part of our plugin jar that
suppressed the output of the HTTP Client wire log:
We then binded everything together in the mojo with a non-static initializer:
public class MyMojo extends AbstractMojo {
{
MavenLogAppender.init(getLog());
}
...
}
This is not possible anymore since 3.1 due to the logging changes.
[~michael-o] This is not intuitive compared to -X and having everything work as
expected. We cannot expect all our users to have to manually copy a logback.xml
file and invoke maven with special arguments whenever they want to see debug
output.
> Replace slf4j-simple with logback or allow filtering out certain loggers
>
>
> Key: MNG-5916
> URL: https://issues.apache.org/jira/browse/MNG-5916
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.3
>Reporter: Axel Fontaine
>
> We are developing a Maven plugin that uses Apache HTTP client. When switching
> Maven to debug mode with -X Apache HTTP client produces gazillions of output
> messages as all wire traffic is being logged. It is not only annoying, it
> also makes this unusable in systems like Travis CI that limit output to some
> sane amount..
> We need some way of disabling the output of the org.apache.http.wire log from
> our within our plugin jar. (Patching existing Maven installations is not an
> option as we do not have this kind of control over our user's machines).
> Any help/suggestions/solutions welcome.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5916) Replace slf4j-simple with logback or allow filtering out certain loggers
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973396#comment-14973396 ] Axel Fontaine commented on MNG-5916: Well it is a functional regression compared to 3.0. For me that qualifies as a bug. Maybe just the second part of the title would capture the issue better and be less prescriptive of a possible solution: Allow filtering out certain loggers from within a plugin > Replace slf4j-simple with logback or allow filtering out certain loggers > > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-5916) Replace slf4j-simple with logback or allow filtering out certain loggers
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973390#comment-14973390 ] Axel Fontaine edited comment on MNG-5916 at 10/25/15 7:14 PM: -- While you may be correct in theory, in practice this is couldn't be further from the truth. As a plugin writer, the output of the plugin is a very important part of the UI. To ensure an optimal user experience it is important to think carefully about what should be output at which logging level by the plugin. The exact set of libraries a plugin uses should not be of concern to users of the plugin. And they certainly shouldn't all have to perform some manual configuration to ensure proper output. As THAT would be a fundamental misconception of UX and a very leaky abstraction. I don't have code for this for 3.1+ as filtering logging output is not possible anymore. was (Author: axel.fontaine): While you may be correct in theory, in practice this is couldn't be further from the truth. As a plugin writer, the output of the plugin is a very important part of the UI. To ensure an optimal user experience it is important to think carefully about what should be output at which logging level by the plugin. The exact set of libraries a plugin uses should not be of concern to users of the plugin. And they certainly shouldn't all have to perform some manual configuration to ensure proper output. As THAT would be a fundamental misconception of UX and a very leaky abstraction. > Replace slf4j-simple with logback or allow filtering out certain loggers > > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5916) Replace slf4j-simple with logback or allow filtering out certain loggers
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973390#comment-14973390 ] Axel Fontaine commented on MNG-5916: While you may be correct in theory, in practice this is couldn't be further from the truth. As a plugin writer, the output of the plugin is a very important part of the UI. To ensure an optimal user experience it is important to think carefully about what should be output at which logging level by the plugin. The exact set of libraries a plugin uses should not be of concern to users of the plugin. And they certainly shouldn't all have to perform some manual configuration to ensure proper output. As THAT would be a fundamental misconception of UX and a very leaky abstraction. > Replace slf4j-simple with logback or allow filtering out certain loggers > > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNG-5916) Regression from 3.0: Allow filtering out certain loggers from within a plugin
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Axel Fontaine updated MNG-5916: --- Summary: Regression from 3.0: Allow filtering out certain loggers from within a plugin (was: Replace slf4j-simple with logback or allow filtering out certain loggers) > Regression from 3.0: Allow filtering out certain loggers from within a plugin > - > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5916) Regression from 3.0: Allow filtering out certain loggers from within a plugin
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973399#comment-14973399 ] Axel Fontaine commented on MNG-5916: The main thing I want have turned off here is the wire logger of the HTTP client. My point isn't that this should affect the entire build, but that there should be a mechanism of doing this on a plugin by plugin base if necessary. This was possible before and this should probably be doable as each plugin already has some level of isolation by having its own classloader. I would be happy with any solution that re-enables what was available with 3.0. P.S.: The wire logger makes very little sense and Gradle for example has it set to off by default. Would shipping Maven with it off by default be possible? > Regression from 3.0: Allow filtering out certain loggers from within a plugin > - > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5916) Regression from 3.0: Allow filtering out certain loggers from within a plugin
[ https://issues.apache.org/jira/browse/MNG-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14973400#comment-14973400 ] Axel Fontaine commented on MNG-5916: You can define regression how you want, but fact is it was working (and very useful) with Maven 3.0 and it isn't anymore now. I am open for any alternative solutions to this problem, including shipping better defaults for the http client wire logger (always off) as suggested above and implemented by Gradle. > Regression from 3.0: Allow filtering out certain loggers from within a plugin > - > > Key: MNG-5916 > URL: https://issues.apache.org/jira/browse/MNG-5916 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.3.3 >Reporter: Axel Fontaine > > We are developing a Maven plugin that uses Apache HTTP client. When switching > Maven to debug mode with -X Apache HTTP client produces gazillions of output > messages as all wire traffic is being logged. It is not only annoying, it > also makes this unusable in systems like Travis CI that limit output to some > sane amount.. > We need some way of disabling the output of the org.apache.http.wire log from > our within our plugin jar. (Patching existing Maven installations is not an > option as we do not have this kind of control over our user's machines). > Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5916) Replace slf4j-simple with logback or allow filtering out certain loggers
Axel Fontaine created MNG-5916: -- Summary: Replace slf4j-simple with logback or allow filtering out certain loggers Key: MNG-5916 URL: https://issues.apache.org/jira/browse/MNG-5916 Project: Maven Issue Type: Bug Components: Logging Affects Versions: 3.3.3 Reporter: Axel Fontaine We are developing a Maven plugin that uses Apache HTTP client. When switching Maven to debug mode with -X Apache HTTP client produces gazillions of output messages as all wire traffic is being logged. It is not only annoying, it also makes this unusable in systems like Travis CI that limit output to some sane amount.. We need some way of disabling the output of the org.apache.http.wire log from our within our plugin jar. (Patching existing Maven installations is not an option as we do not have this kind of control over our user's machines). Any help/suggestions/solutions welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MDEP-489) Regression: unpack-dependencies fails on Windows for tar.gz containing executable file
Axel Fontaine created MDEP-489: -- Summary: Regression: unpack-dependencies fails on Windows for tar.gz containing executable file Key: MDEP-489 URL: https://issues.apache.org/jira/browse/MDEP-489 Project: Maven Dependency Plugin Issue Type: Bug Components: unpack-dependencies Affects Versions: 2.10 Reporter: Axel Fontaine unpack-dependencies fails on Windows for a tar.gz dependency containing an executable file with the following message: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack-dependencies (unpa ck-jres) on project boxfuse-commandline: Error unpacking file: C:\Users\Axel\.m2\repository\com\oracle\server- jre\8.45\server-jre-8.45-linux-x64.tar.gz to: C:\Workspaces\boxfuse-client\boxfuse-commandline\target\dependen cy\server-jre-linux-x64-tar.gz [ERROR] org.codehaus.plexus.archiver.ArchiverException: Error while expanding C:\Users\Axel\.m2\repository\com \oracle\server-jre\8.45\server-jre-8.45-linux-x64.tar.gz: C:\Workspaces\boxfuse-client\boxfuse-commandline\tar get\dependency\server-jre-linux-x64-tar.gz\jdk1.8.0_45\jre\lib\amd64\server\libjsig.so: A required privilege i s not held by the client. This was working fine in all previous versions including 2.8 and 2.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578351#comment-14578351
]
Axel Fontaine commented on MASSEMBLY-771:
-
Here is the descriptor:
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd;
idlinux-x64/id
formats
formattar.gz/format
/formats
baseDirectorybase/baseDirectory
componentDescriptors
componentDescriptorsrc/main/assembly/component.xml/componentDescriptor
/componentDescriptors
fileSets
fileSet
directorytarget/dependency/server-jre-linux-x64-tar.gz/jdk1.${jre.version.major}.0_${jre.version.minor}/jre/directory
outputDirectory/jre/outputDirectory
fileMode755/fileMode
/fileSet
/fileSets
/assembly
Since this build has to run both on Windows Linux, I wouldn't know how to fix
it. Suggestions?
Regression: Unable to create tar.gz in cross-platform build without error
messages on Windows
-
Key: MASSEMBLY-771
URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5.5
Environment: Windows
Reporter: Axel Fontaine
Recent versions of the assembly plugin started outputting a harmless, but
annoying error message when creating tar.gz files from Windows:
[ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
root-relative-reference (starting with slash) /mypath
This used to work fine with older versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578351#comment-14578351
]
Axel Fontaine edited comment on MASSEMBLY-771 at 6/9/15 5:38 AM:
-
Here is the descriptor:
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd;
idlinux-x64/id
formats
formattar.gz/format
/formats
baseDirectorybase/baseDirectory
componentDescriptors
componentDescriptorsrc/main/assembly/component.xml/componentDescriptor
/componentDescriptors
fileSets
fileSet
directorytarget/dependency/server-jre-linux-x64-tar.gz/jdk1.8.0_45/jre/directory
outputDirectory/jre/outputDirectory
fileMode755/fileMode
/fileSet
/fileSets
/assembly
Since this build has to run both on Windows Linux, I wouldn't know how to fix
it. Suggestions?
was (Author: axel.fontaine):
Here is the descriptor:
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
http://maven.apache.org/xsd/assembly-1.1.0.xsd;
idlinux-x64/id
formats
formattar.gz/format
/formats
baseDirectorybase/baseDirectory
componentDescriptors
componentDescriptorsrc/main/assembly/component.xml/componentDescriptor
/componentDescriptors
fileSets
fileSet
directorytarget/dependency/server-jre-linux-x64-tar.gz/jdk1.${jre.version.major}.0_${jre.version.minor}/jre/directory
outputDirectory/jre/outputDirectory
fileMode755/fileMode
/fileSet
/fileSets
/assembly
Since this build has to run both on Windows Linux, I wouldn't know how to fix
it. Suggestions?
Regression: Unable to create tar.gz in cross-platform build without error
messages on Windows
-
Key: MASSEMBLY-771
URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5.5
Environment: Windows
Reporter: Axel Fontaine
Recent versions of the assembly plugin started outputting a harmless, but
annoying error message when creating tar.gz files from Windows:
[ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
root-relative-reference (starting with slash) /mypath
This used to work fine with older versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[ https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578351#comment-14578351 ] Axel Fontaine edited comment on MASSEMBLY-771 at 6/9/15 5:42 AM: - Here is the descriptor: assembly xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd; idlinux-x64/id formats formattar.gz/format /formats baseDirectorybase/baseDirectory componentDescriptors componentDescriptorsrc/main/assembly/component.xml/componentDescriptor /componentDescriptors files file sourcesrc/main/assembly/LICENSE_DE.txt/source outputDirectory//outputDirectory fileMode644/fileMode lineEndinglf/lineEnding filteredtrue/filtered /file file sourcesrc/main/assembly/LICENSES-THIRD-PARTY.txt/source outputDirectory//outputDirectory fileMode644/fileMode lineEndinglf/lineEnding filteredtrue/filtered /file /files fileSets fileSet directorytarget/dependency/server-jre-linux-x64-tar.gz/jdk1.8.0_45/jre/directory outputDirectory/jre/outputDirectory fileMode755/fileMode /fileSet /fileSets /assembly Since this build has to run both on Windows Linux, I wouldn't know how to fix it. Suggestions? was (Author: axel.fontaine): Here is the descriptor: assembly xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd; idlinux-x64/id formats formattar.gz/format /formats baseDirectorybase/baseDirectory componentDescriptors componentDescriptorsrc/main/assembly/component.xml/componentDescriptor /componentDescriptors fileSets fileSet directorytarget/dependency/server-jre-linux-x64-tar.gz/jdk1.8.0_45/jre/directory outputDirectory/jre/outputDirectory fileMode755/fileMode /fileSet /fileSets /assembly Since this build has to run both on Windows Linux, I wouldn't know how to fix it. Suggestions? Regression: Unable to create tar.gz in cross-platform build without error messages on Windows - Key: MASSEMBLY-771 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.5 Environment: Windows Reporter: Axel Fontaine Recent versions of the assembly plugin started outputting a harmless, but annoying error message when creating tar.gz files from Windows: [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific root-relative-reference (starting with slash) /mypath This used to work fine with older versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[ https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578360#comment-14578360 ] Axel Fontaine commented on MASSEMBLY-771: - Thanks. I edited my original post while you answered. How do you also deal with files that have to be put in the root of the tar file? (like LICENSE_DE.txt in this example) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows - Key: MASSEMBLY-771 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.5 Environment: Windows Reporter: Axel Fontaine Recent versions of the assembly plugin started outputting a harmless, but annoying error message when creating tar.gz files from Windows: [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific root-relative-reference (starting with slash) /mypath This used to work fine with older versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[ https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578367#comment-14578367 ] Axel Fontaine commented on MASSEMBLY-771: - Nevermind. Removing outputDirectory//outputDirectory did the trick. Thanks for your help and sorry for the inconvenience. Regression: Unable to create tar.gz in cross-platform build without error messages on Windows - Key: MASSEMBLY-771 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.5.5 Environment: Windows Reporter: Axel Fontaine Recent versions of the assembly plugin started outputting a harmless, but annoying error message when creating tar.gz files from Windows: [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific root-relative-reference (starting with slash) /mypath This used to work fine with older versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MASSEMBLY-772) tar.gz contents owned by user who ran build
Axel Fontaine created MASSEMBLY-772: --- Summary: tar.gz contents owned by user who ran build Key: MASSEMBLY-772 URL: https://issues.apache.org/jira/browse/MASSEMBLY-772 Project: Maven Assembly Plugin Issue Type: Bug Components: maven-archiver Affects Versions: 2.5.5 Environment: Windows, Maven 3.3.3 Reporter: Axel Fontaine When creating a tar.gz, the files it contains have no group (OK), but do have a user (not OK). More specifically it is the user who ran the build. This should really be empty to avoid any surprises. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MNG-5635) No info generated for nested classes in mojo config
[ https://jira.codehaus.org/browse/MNG-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348050#comment-348050 ] Axel Fontaine commented on MNG-5635: Maybe nested parameter elements like this: parameters parameter namemyparam/name typecom.company.MyClass/type requiredfalse/required editabletrue/editable description.../description parameters parameter namemynestedparam/name typejava.lang.String[]/type requiredfalse/required editabletrue/editable description.../description /parameter parameter ... No info generated for nested classes in mojo config --- Key: MNG-5635 URL: https://jira.codehaus.org/browse/MNG-5635 Project: Maven 2 3 Issue Type: Bug Components: IDEs, Plugin API, Plugins and Lifecycle Affects Versions: 3.2.1 Reporter: Axel Fontaine For more advanced plugins, it is nice to have nested objects in order to group settings (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Other_Object_Classes) Currently the metadata for these does not get generated nor included in plugin.xml (even though it is present in the original class). This in turn leads to IDEs not being able to offer completion, documentation, validation, ... for these attributes, hindering reliability and discoverability, two of Maven's primary strengths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5635) No info generated for nested classes in mojo config
[ https://jira.codehaus.org/browse/MNG-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Axel Fontaine updated MNG-5635: --- Description: For more advanced plugins, it is nice to have nested objects in order to group settings (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Other_Object_Classes) Currently the metadata for these does not get generated nor included in plugin.xml (even though it is present in the original class). This in turn leads to IDEs not being able to offer completion, documentation, validation, ... for these attributes, hindering reliability and discoverability, two of Maven's primary strengths. was: For more advanced plugins, it is nice to have nested objects in order to group settings (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Other_Object_Classes) Currently the metadata for these does not get generated and included in plugin.xml (even though it is present). This in turn leads to IDEs not being able to offer completion, documentation, validation, ... for these attributes, hindering reliability and discoverability, two of Maven's primary strengths. No info generated for nested classes in mojo config --- Key: MNG-5635 URL: https://jira.codehaus.org/browse/MNG-5635 Project: Maven 2 3 Issue Type: Bug Components: IDEs, Plugin API, Plugins and Lifecycle Affects Versions: 3.2.1 Reporter: Axel Fontaine For more advanced plugins, it is nice to have nested objects in order to group settings (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Other_Object_Classes) Currently the metadata for these does not get generated nor included in plugin.xml (even though it is present in the original class). This in turn leads to IDEs not being able to offer completion, documentation, validation, ... for these attributes, hindering reliability and discoverability, two of Maven's primary strengths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5635) No info generated for nested classes in mojo config
Axel Fontaine created MNG-5635: -- Summary: No info generated for nested classes in mojo config Key: MNG-5635 URL: https://jira.codehaus.org/browse/MNG-5635 Project: Maven 2 3 Issue Type: Bug Components: IDEs, Plugin API, Plugins and Lifecycle Affects Versions: 3.2.1 Reporter: Axel Fontaine For more advanced plugins, it is nice to have nested objects in order to group settings (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html#Other_Object_Classes) Currently the metadata for these does not get generated and included in plugin.xml (even though it is present). This in turn leads to IDEs not being able to offer completion, documentation, validation, ... for these attributes, hindering reliability and discoverability, two of Maven's primary strengths. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5614) Continuous Delivery Friendly Versions not present in installed artifacts
Axel Fontaine created MNG-5614:
--
Summary: Continuous Delivery Friendly Versions not present in
installed artifacts
Key: MNG-5614
URL: https://jira.codehaus.org/browse/MNG-5614
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Axel Fontaine
Consider a parent pom with these tags:
...
version${revision}/version
...
properties
revision0-SNAPSHOT/revision
/properties
...
If I start the build with:
mvn install -Drevision=666
The revision gets replaced correctly at runtime (correct), but the placeholder
remains in the installed artifact in the local repository (wrong).
To make matters worse, if you have a Maven Plugin child module with these tags
in the pom:
...
parent
groupIdcom.boxfuse.client/groupId
artifactIdboxfuse-client/artifactId
version${revision}/version
/parent
...
packagingmaven-plugin/packaging
...
dependencies
dependency
groupId${project.groupId}/groupId
artifactIdother-artifact/artifactId
version${project.version}/version
/dependency
/dependencies
Once the plugin gets used in yet another module, the resolution of
other-artifact will fail at runtime with:
Plugin ...:666 or one of its dependencies could not be resolved: Could not
find artifact ...:other-artifact:jar:0-SNAPSHOT
Until this is fixed the functionality provided by MNG-5576 is virtually useless.
By speaking about the fix, why bother with replacing variables? Why bother with
parent POMs? How about simply installing and deploying the effective POM? This
would solve a whole range of problems at once. And at the end of the day, this
will simplify many things, at the cost of slightly larger installed POMs.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5614) Continuous Delivery Friendly Versions not present in installed artifacts
[
https://jira.codehaus.org/browse/MNG-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Axel Fontaine updated MNG-5614:
---
Description:
Consider a parent pom with these tags:
...
version${revision}/version
...
properties
revision0-SNAPSHOT/revision
/properties
...
If I start the build with:
mvn install -Drevision=666
The revision gets replaced correctly at runtime (correct), but the placeholder
remains in the installed artifact in the local repository (wrong).
To make matters worse, if you have a Maven Plugin child module with these tags
in the pom:
...
parent
...
version${revision}/version
/parent
...
packagingmaven-plugin/packaging
...
dependencies
dependency
groupId${project.groupId}/groupId
artifactIdother-artifact/artifactId
version${project.version}/version
/dependency
/dependencies
Once the plugin gets used in yet another module, the resolution of
other-artifact will fail at runtime with:
Plugin ...:666 or one of its dependencies could not be resolved: Could not
find artifact ...:other-artifact:jar:0-SNAPSHOT
Until this is fixed the functionality provided by MNG-5576 is virtually useless.
By speaking about the fix, why bother with replacing variables? Why bother with
parent POMs? How about simply installing and deploying the effective POM? This
would solve a whole range of problems at once. And at the end of the day, this
will simplify many things, at the cost of slightly larger installed POMs.
was:
Consider a parent pom with these tags:
...
version${revision}/version
...
properties
revision0-SNAPSHOT/revision
/properties
...
If I start the build with:
mvn install -Drevision=666
The revision gets replaced correctly at runtime (correct), but the placeholder
remains in the installed artifact in the local repository (wrong).
To make matters worse, if you have a Maven Plugin child module with these tags
in the pom:
...
parent
groupIdcom.boxfuse.client/groupId
artifactIdboxfuse-client/artifactId
version${revision}/version
/parent
...
packagingmaven-plugin/packaging
...
dependencies
dependency
groupId${project.groupId}/groupId
artifactIdother-artifact/artifactId
version${project.version}/version
/dependency
/dependencies
Once the plugin gets used in yet another module, the resolution of
other-artifact will fail at runtime with:
Plugin ...:666 or one of its dependencies could not be resolved: Could not
find artifact ...:other-artifact:jar:0-SNAPSHOT
Until this is fixed the functionality provided by MNG-5576 is virtually useless.
By speaking about the fix, why bother with replacing variables? Why bother with
parent POMs? How about simply installing and deploying the effective POM? This
would solve a whole range of problems at once. And at the end of the day, this
will simplify many things, at the cost of slightly larger installed POMs.
Continuous Delivery Friendly Versions not present in installed artifacts
Key: MNG-5614
URL: https://jira.codehaus.org/browse/MNG-5614
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Axel Fontaine
Consider a parent pom with these tags:
...
version${revision}/version
...
properties
revision0-SNAPSHOT/revision
/properties
...
If I start the build with:
mvn install -Drevision=666
The revision gets replaced correctly at runtime (correct), but the
placeholder remains in the installed artifact in the local repository (wrong).
To make matters worse, if you have a Maven Plugin child module with these
tags in the pom:
...
parent
...
version${revision}/version
/parent
...
packagingmaven-plugin/packaging
...
dependencies
dependency
groupId${project.groupId}/groupId
artifactIdother-artifact/artifactId
version${project.version}/version
/dependency
/dependencies
Once the plugin gets used in yet another module, the resolution of
other-artifact will fail at runtime with:
Plugin ...:666 or one of its dependencies could not be resolved: Could not
find artifact ...:other-artifact:jar:0-SNAPSHOT
Until this is fixed the functionality provided by MNG-5576 is virtually
useless.
By speaking about the fix, why bother with replacing variables? Why bother
with parent POMs? How about simply installing and deploying the effective
POM? This would solve a whole range of problems at once. And at the end of
the day, this will simplify many things, at the cost of slightly larger
installed POMs.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-130) External plugins list is not up to date
[ https://jira.codehaus.org/browse/MNGSITE-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=303231#comment-303231 ] Axel Fontaine commented on MNGSITE-130: --- +1 for updating the list or making the list easier to update. Flyway now has a large number of users integrating it through its Maven plugin. It would be nice to see it listed on the Maven site too. External plugins list is not up to date --- Key: MNGSITE-130 URL: https://jira.codehaus.org/browse/MNGSITE-130 Project: Maven Project Web Site Issue Type: Improvement Reporter: Brett Porter See also MNGSITE-129. Regarding plugins list at http://maven.apache.org/plugins/, there's several good plugins missing, and I'm not sure how popular the ones there are. We might want to consider some alternatives here: - better edit the list for popular plugins - refer to something generated from the repository index that is more comprehensive -- 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-751) Mercurial: release:rollback does not remove newly created tag
Axel Fontaine created MRELEASE-751: -- Summary: Mercurial: release:rollback does not remove newly created tag Key: MRELEASE-751 URL: https://jira.codehaus.org/browse/MRELEASE-751 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Axel Fontaine release:rollback does not remove newly created tag for Mercurial attempting to release again causes the build to fail because the tag the release plugin attempts to create already exists. -- 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] Commented: (MNG-4715) version expression constant
[
http://jira.codehaus.org/browse/MNG-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262679#action_262679
]
Axel Fontaine commented on MNG-4715:
I also believe expressions should be allowed.
This enables you to decouple updating your version number from checking in to
version control, which is one of the big problems with the traditional Maven
release process.
This way, the only change actually commited for a new release is the code. No
need to additionally modify the POM.
I've described this in detail here:
http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html
version expression constant
---
Key: MNG-4715
URL: http://jira.codehaus.org/browse/MNG-4715
Project: Maven 2 3
Issue Type: Improvement
Components: Dependencies, POM
Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
Environment: eclipse linux xp
Reporter: Faruk
Priority: Critical
Fix For: Issues to be reviewed for 3.x
Attachments: untitled.JPG
early versions, we define modules versions with expressions, and set them to
the parent pom,
simply;
properties
ibb-core-cache.version1.0.1/ibb-core-cache.version
ibb-core-util.version1.0.1/ibb-core-util.version
/properties
and then, we give this property to modules pom as expression ,
nameik-plug/name
packagingjar/packaging
version${ibb-core-util.versionn}/version
but know , it gives an error you know like this,
[WARNING] Some problems were encountered while building the effective model
for ibb-parent:ibb-modules-parent:pom:1.0.0
[WARNING] 'version' contains an expression but should be a constant. @
ibb-parent:ibb-modules-parent:${ibb-core-jars.version},
C:\dev\ibb\workspace\core\ibb-modules-parent\pom.xml
but I think that, this enhancement is causes wrong result,
think that , if we have i project already developing about 3 years, this
project has a lot of modules, and this modules have sub modules , and this
sub modules already bound to some other modules not define in your pom, but
your updates must be affect them, at this situation, developer want to write
the existing version numbers with properties to parent pom, and want to
manage them like this. at the attach file below , the close projects are
belongs to open projects, but they are the different team developing this. I
cant force the other developers to cache their versions, I must use this
versions as initial step
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-657) Surefire silently fails when argLine contains tabs or newlines
Surefire silently fails when argLine contains tabs or newlines -- Key: SUREFIRE-657 URL: http://jira.codehaus.org/browse/SUREFIRE-657 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.6 Reporter: Axel Fontaine Surefire will silently fail without executing any tests if the argLine for the forked process contains tabs \t or newlines \n. This commonly occurs when the argLine is long, and an IDE feels the need to break up the line while reformating the xml. A solution could be to replace \t and \n with a space. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-121) Encoding not passed on to Eclipse compiler
Encoding not passed on to Eclipse compiler -- Key: MCOMPILER-121 URL: http://jira.codehaus.org/browse/MCOMPILER-121 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Axel Fontaine encoding works fine with javac, but does not get passed/does not work with the eclipse compiler. Example: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.1/version configuration source1.6/source target1.6/target encodingUTF-8/encoding /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVEN-1834) Java sources in War file not build unless at least 1 unit test is present
Java sources in War file not build unless at least 1 unit test is present - Key: MAVEN-1834 URL: http://jira.codehaus.org/browse/MAVEN-1834 Project: Maven 1.x Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Win2000 Reporter: Axel Fontaine Within a multiproject (have not tested standalone), when a war subproject contains java code and/or resources, but no test cases, the java code does not get compiled/the resources do not get copied and therefore not packaged. Works fine in maven 1.0.2 Workaround: Adding a dummy unit test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVEN-1795) Property containing underscore not picked up
Property containing underscore not picked up
Key: MAVEN-1795
URL: http://jira.codehaus.org/browse/MAVEN-1795
Project: Maven 1.x
Issue Type: Bug
Components: core
Affects Versions: 1.0.2
Environment: Win 2000
Reporter: Axel Fontaine
project.properties
==
my_property.value=1.2.3
project.xml
=
dependency
groupIdx/groupId
artifactIdx/artifactId
version${my_property.value}/version
typejar/type
/dependency
And it cannot find the dependency. Removing the underscore (myproperty.value)
fixes it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
