[jira] [Commented] (MENFORCER-270) option to forbid plugin snapshot versions only when releasing
[ https://issues.apache.org/jira/browse/MENFORCER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16038637#comment-16038637 ] Joerg Schaible commented on MENFORCER-270: -- You already have this. The release plugin activates a profile (by default "release", but that can be configured) when it runs a release build. So simply configure this enforcer rule in that special profile. > option to forbid plugin snapshot versions only when releasing > - > > Key: MENFORCER-270 > URL: https://issues.apache.org/jira/browse/MENFORCER-270 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.4.1 >Reporter: Gruust >Priority: Minor > > Basically, it would be nice if plugin versions would be treated similar to > regular dependencies, ie. have a standard rule that only complains about > snapshot plugin versions when trying to release the project. That's > especially helpful when having maven plugin sub-modules as part of a larger > multi-module project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6267) Support resolving "~" in values given to CLI Option "-s"
[
https://issues.apache.org/jira/browse/MNG-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16111347#comment-16111347
]
Joerg Schaible commented on MNG-6267:
-
~ expansion is a functionality of bash. Adding support for it might have
unwanted side-effects. See linked issue of commons-io.
> Support resolving "~" in values given to CLI Option "-s"
>
>
> Key: MNG-6267
> URL: https://issues.apache.org/jira/browse/MNG-6267
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>
> Currently relative filenames given in CLI option "-s" are assumed to be
> relative to the base directory. It would be nice to also support referencing
> files below the user's home directory by leveraging the placeholder "~". This
> would be especially useful with {{mvn/maven.config}} (MNG-5767).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MTOOLCHAINS-18) toolchain.xml file should support environment variables
[
https://issues.apache.org/jira/browse/MTOOLCHAINS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125995#comment-16125995
]
Joerg Schaible commented on MTOOLCHAINS-18:
---
This is typical in Linux environments. See I have:
$ java-config -L
The following VMs are available for generation-2:
1) Blackdown JDK 1.4.2.03 [blackdown-jdk-1.4.2]
2) IBM JDK 1.4.2.13_p9 [ibm-jdk-bin-1.4]
3) IBM JDK 1.5.0.12_p5 [ibm-jdk-bin-1.5]
4) IBM JDK 1.6.0.9_p2 [ibm-jdk-bin-1.6]
5) IBM JDK 1.7.0.5 [ibm-jdk-bin-1.7]
6) IcedTea JDK 6.1.13.9 [icedtea-6]
7) IcedTea JDK 7.2.6.10 [icedtea-bin-7]
8) IcedTea JDK 3.5.1 [icedtea-bin-8]
9) JamVM JDK 2.0.0 [jamvm]
10) Oracle JDK 1.7.0.80 [oracle-jdk-bin-1.7]
*) Oracle JDK 1.8.0.144 [oracle-jdk-bin-1.8]
12) Oracle JDK 1.9.0.0_beta167 [oracle-jdk-bin-1.9]
13) Sun JDK 1.5.0.22 [sun-jdk-1.5] (Build Only)
14) Sun JDK 1.6.0.45 [sun-jdk-1.6]
I can request the Java home of each individual JRE/JDK:
$ java-config --select-vm=icedtea-bin-8 -O
/opt/icedtea-bin-3.5.1
Therefore I can setup individual environment variables:
$ env | grep JAVA_
JAVA_1_8_HOME_ICE=/opt/icedtea-bin-3.5.1
JAVA_1_9_HOME_ORACLE=/opt/oracle-jdk-bin-1.9.0.0_beta167
JAVA_1_4_HOME_BD=/opt/blackdown-jdk-1.4.2.03
JAVA_1_7_HOME_ICE=/opt/icedtea-bin-7.2.6.10
JAVA_1_5_HOME_IBM=/opt/ibm-jdk-bin-1.5.0.12_p5
JAVA_1_6_HOME_ORACLE=/opt/sun-jdk-1.6.0.45
JAVA_1_6_HOME_ICE=/usr/lib64/icedtea6
JAVA_1_7_HOME_ORACLE=/opt/oracle-jdk-bin-1.7.0.80
JAVA_HOME=/home/joehni/.gentoo/java-config-2/current-user-vm
JAVA_1_8_HOME_ORACLE=/opt/oracle-jdk-bin-1.8.0.144
JAVA_1_7_HOME_IBM=/opt/ibm-jdk-bin-1.7.0.5
JAVA_1_6_HOME_IBM=/opt/ibm-jdk-bin-1.6.0.9_p2
JAVA_1_5_HOME_ORACLE=/opt/sun-jdk-1.5.0.22
Now, imagine what happens if a vulnerability is found. The distribution will
update the package and it will get installed with the next update of the system
(sometimes with a long list of other packages).
All environment variables will point to the new location automatically while
for toolchains I have to recognize the update and will have to edit the
configuration file manually each time.
> toolchain.xml file should support environment variables
> ---
>
> Key: MTOOLCHAINS-18
> URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-18
> Project: Maven Toolchains Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
> Environment: Windows 7 64bit
>Reporter: Nicolas Radde
>Priority: Minor
>
> When the toolchain.xml file is configured as follow :
> {code:xml}
>
> jdk
>
> 1.8
> sun
>
>
> ${env.JDK_HOME_8}
>
>
> {code}
> The execution of a maven compile fail with the following error :
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-toolchains-plugin:
> 1.1:toolchain (default) on project monitoring-mq-web: Misconfigured
> toolchains.
> Non-existing JDK home configuration at
> L:\test-monitoring-mq\${env.JDK_HOME_8} -> [Help 1]
> {noformat}
> While the environment variable *JDK_HOME_8* exist.
> Using environment variable is a very convenient way to have the same
> toolchain.xml file for all developers or jenkins slaves and would be a nice
> addition to the plugin.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6284) inside should raise a warning
[ https://issues.apache.org/jira/browse/MNG-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16167442#comment-16167442 ] Joerg Schaible commented on MNG-6284: - It is absolutely fine to define even executions for a plugin declared in the pluginManagement section. A lack of understanding does not justify a warning for proper usage. > inside should raise a warning > - > > Key: MNG-6284 > URL: https://issues.apache.org/jira/browse/MNG-6284 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.5 > Environment: Ubuntu 14.04.3 >Reporter: Chris Hennick > > When I was setting up my project's pom.xml, I was unaware that there was a > difference between project/build/pluginManagement/plugins and > project/build/plugins. These StackOverflow questions indicate I'm not the > only one who was confused: > * > https://stackoverflow.com/questions/18557245/not-able-to-bind-plugin-goals-to-maven-lifecycle-phases > * > https://stackoverflow.com/questions/23785443/binding-to-lifecycle-in-maven-does-not-work-on-failsafe-and-integration-test > If we have to have such a confusing schema, then can we please at least raise > a warning when the confusion inevitably occurs, given how easy it is to > detect (since AFAICT there'd be no reason to put an executions tag inside > pluginManagement/plugins/plugin)? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6284) inside should raise a warning
[ https://issues.apache.org/jira/browse/MNG-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16167501#comment-16167501 ] Joerg Schaible commented on MNG-6284: - It binds to the lifecycle when I declare the plugin in builds/plugins later on. Typically you have a pluginManagement section in some shared parent where you have setup the plugins you're going to use everywhere and you can later on simply redeclare those plugins in your child projects without any further configuration (or executions). > inside should raise a warning > - > > Key: MNG-6284 > URL: https://issues.apache.org/jira/browse/MNG-6284 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0.5 > Environment: Ubuntu 14.04.3 >Reporter: Chris Hennick > > When I was setting up my project's pom.xml, I was unaware that there was a > difference between project/build/pluginManagement/plugins and > project/build/plugins. These StackOverflow questions indicate I'm not the > only one who was confused: > * > https://stackoverflow.com/questions/18557245/not-able-to-bind-plugin-goals-to-maven-lifecycle-phases > * > https://stackoverflow.com/questions/23785443/binding-to-lifecycle-in-maven-does-not-work-on-failsafe-and-integration-test > If we have to have such a confusing schema, then can we please at least raise > a warning when the confusion inevitably occurs, given how easy it is to > detect (since AFAICT there'd be no reason to put an executions tag inside > pluginManagement/plugins/plugin)? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MNG-6141:
Attachment: MNG-6141-2.zip
Extended example, where
* parent inherits maven-parent and manages junit,
* module-1 overrides plexus-component-annotations (managed by maven-parent) and
manages plexus-utils with a depMgmt section and
* a new module-3 (without a parent) using module-1.
{code:title=Module 1}
[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.1:compile (version managed from 3.8.2 by
localhost:parent:1.0-SNAPSHOT)
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.7:compile (version
managed from 2.0.4 by localhost:module-1:1.0-SNAPSHOT)
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api:
{code:title=Module 3}
[DEBUG] localhost:module-3:jar:1.0-SNAPSHOT
[DEBUG]localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG] org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.2:compile
[DEBUG] org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Generated with Maven 3.3.9.
If I understand you proposal now correctly, you would like to forbid the local
overriding of maven-plugin-api, which is ignored for module-2, but respected
for module-3. OTOH module-3 exposes different problems, since the active
depMgmt sections of a dependency itself are not considered.
One use case, where I use a local overriding also actively, is for testing a
different version of a dependency. Existing unit test may reveal a different
behaviour.
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-2.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MNG-6141:
Attachment: (was: MNG-6141-2.zip)
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MNG-6141:
Attachment: MNG-6141-3.zip
Updated example. Replaces MNG-6141-2.zip
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16216635#comment-16216635
]
Joerg Schaible edited comment on MNG-6141 at 10/24/17 10:08 AM:
Extended example, where
* parent inherits maven-parent and manages junit,
* module-1 overrides plexus-component-annotations (managed by maven-parent) and
manages plexus-utils with a depMgmt section and
* a new module-3 (without a parent) using module-1.
{code:title=Module 1}
[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.1:compile (version managed from 3.8.2 by
localhost:parent:1.0-SNAPSHOT)
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.7:compile (version
managed from 2.0.4 by localhost:module-1:1.0-SNAPSHOT)
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api and plexus-component-annotations:
{code:title=Module 3}
[DEBUG] localhost:module-3:jar:1.0-SNAPSHOT
[DEBUG]localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG] org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.2:compile
[DEBUG] org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Generated with Maven 3.3.9.
If I understand you proposal now correctly, you would like to forbid the local
overriding of maven-plugin-api, which is ignored for module-2, but respected
for module-3. OTOH module-3 exposes different problems, since the active
depMgmt sections of a dependency itself are not considered.
One use case, where I use a local overriding also actively, is for testing a
different version of a dependency. Existing unit test may reveal a different
behaviour.
was (Author: joehni):
Extended example, where
* parent inherits maven-parent and manages junit,
* module-1 overrides plexus-component-annotations (managed by maven-parent) and
manages plexus-utils with a depMgmt section and
* a new module-3 (without a parent) using module-1.
{code:title=Module 1}
[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.1:compile (version managed from 3.8.2 by
localhost:parent:1.0-SNAPSHOT)
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.7:compile (version
managed from 2.0.4 by localhost:module-1:1.0-SNAPSHOT)
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api:
{code:title=Module 3}
[DEBUG] localhost:module-3:jar:1.0-SNAPSHOT
[DEBUG]localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG] org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.2:compile
[DEBUG] org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Generated with Maven 3.3.9.
If I understand y
[jira] [Created] (MDEP-619) snapshotsOnly is not always respected
Joerg Schaible created MDEP-619:
---
Summary: snapshotsOnly is not always respected
Key: MDEP-619
URL: https://issues.apache.org/jira/browse/MDEP-619
Project: Maven Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 3.1.1
Environment: $ mvn -version
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T20:49:05+01:00)
Maven home: /usr/share/maven-bin-3.5
Java version: 1.8.0_172, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.8.0.172/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.76-gentoo-r1", arch: "amd64", family: "unix"
Reporter: Joerg Schaible
The configuration parameter snapshotsOnly is not always repected. We use a
profile that can be activated in the root of a multi-project with following
settings:
{code:xml}
purge
purge-group
org.apache.maven.plugins
maven-dependency-plugin
purge-local-repository
clean
purge-local-repository
${project.groupId}
groupId
${purge}
{code}
We'd like to handle all artifacts with the same groupId. The purge parameter
should be used to purge only the snapshots or anything. However, the
snapshotOnly parameter is not respected. The goal will wipe always all
artifacts with the same groupId.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPIR-373) upgrade from 2.9 to 3.0.0 introduce additional warning issue
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16554117#comment-16554117
]
Joerg Schaible commented on MPIR-373:
-
Please, can we reopen this issue? It does not make sense to receive a lot
warnings about 3rd party POMs in the Central repository when creating the
dependency report. The output of our Maven build is currently quite unreadable
and there's nothing *we* can do about it.
In a large multi-project with about 100 subprojects we get for the half of them
the following litany:
{quote}
[INFO] Generating "Dependencies" report ---
maven-project-info-reports-plugin:3.0.0:dependencies
[WARNING] Unable to create Maven project from repository.
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs:
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-surefire-plugin is missing. @ line 218, column 15
[ERROR] 'distributionManagement.status' must not be specified. @ line 252,
column 13
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:192)
at org.apache.maven.project.DefaultProjectBuilder.build
(DefaultProjectBuilder.java:327)
at
org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
(RepositoryUtils.java:125)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderArtifactRow
(DependenciesRenderer.java:799)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderDependenciesForScope
(DependenciesRenderer.java:749)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderDependenciesForAllScopes
(DependenciesRenderer.java:413)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectTransitiveDependencies
(DependenciesRenderer.java:438)
at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
(DependenciesRenderer.java:219)
at org.apache.maven.reporting.AbstractMavenReportRenderer.render
(AbstractMavenReportRenderer.java:80)
at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
(DependenciesReport.java:162)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:251)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:230)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:349)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:198)
at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:147)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.model.building.ModelBuildingException: 2 problems
were encountered while building the effective model for
commons-httpclient:commons-httpclient:3.1
[WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plu
[jira] [Commented] (MPIR-373) upgrade from 2.9 to 3.0.0 introduce additional warning issue
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16558059#comment-16558059
]
Joerg Schaible commented on MPIR-373:
-
Well, actually this issue is caused by Maven Core, i.e. in the
DefaultProjectBuilder. Basically it is fine, that this implementation checks
for valid POMs and throws exceptions for POMs in local projects or POMs that
should be installed or deployed to some location.
However, since those check were not in place for quite a lot of POMs that are
available in Central which will never be corrected, I expect the dependency
report generation to ignore those problems. It may print a single line as
warning, but certainly not a stacktrace. Since we don't get those stacktraces
calling the tree goal, there must be some functionally in the dependency plugin
or Maven core that reads POMs more gracefully.
> upgrade from 2.9 to 3.0.0 introduce additional warning issue
>
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: GW Rogde
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
[jira] [Commented] (MPIR-373) upgrade from 2.9 to 3.0.0 introduce additional warning issue
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559400#comment-16559400
]
Joerg Schaible commented on MPIR-373:
-
It would certainly help, if we simply add the message of the nested exception
to the warning instead of logging its stack trace. However, I am not sure that
this is all. Looking at the console output I have the impression that we see
for each problem two stack traces. One for the POM itself and one for the
project.
> upgrade from 2.9 to 3.0.0 introduce additional warning issue
>
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: GW Rogde
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.Mave
[jira] [Commented] (MNG-6450) Allow importing a POM with a classifier
[ https://issues.apache.org/jira/browse/MNG-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565150#comment-16565150 ] Joerg Schaible commented on MNG-6450: - I am not sure, if we can really overview the consequences of this enhancement. While I understand the intention and often wished myself something like this, we have to face, that currently all attached artefacts of a component share the same dependencies i.e. the ones that are declared in the POM of the project. I have no idea at how many places this fact is currently silently taken for sure. > Allow importing a POM with a classifier > --- > > Key: MNG-6450 > URL: https://issues.apache.org/jira/browse/MNG-6450 > Project: Maven > Issue Type: Improvement > Components: Dependencies, POM >Affects Versions: 3.0 >Reporter: Yegor Borovikov >Priority: Major > Labels: easy-fix, pull-request-available > > Currently, a POM-packaged artifact with a classifier cannot be imported - > there is an explicit check for that in > [DefaultModelValidator|https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L480]. > I couldn't find anything in Maven documentation that would mention/explain > this limitation. According to [~rfscholte] this [might > be|https://www.mail-archive.com/dev@maven.apache.org/msg114101.html] > "historical". > Example use case: a BOM (bill of materials) plugin could generate a BOM POM > and attach it (with a classifier) to the project. However, currently there's > no way to import the generated BOM because of the restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCHANGES-393) Default for teamlist is wrong
Joerg Schaible created MCHANGES-393: --- Summary: Default for teamlist is wrong Key: MCHANGES-393 URL: https://issues.apache.org/jira/browse/MCHANGES-393 Project: Maven Changes Plugin Issue Type: Bug Components: changes.xml Reporter: Joerg Schaible It seems at some stage the PIR changed the name for the page generated for the team list. At least with current PIR 3.0.0 generates a page _team.html_ and the current changes report has broken links for the devs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPIR-373) upgrade from 2.9 to 3.0.0 introduce additional warning issue
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16577884#comment-16577884
]
Joerg Schaible commented on MPIR-373:
-
Well, a simple line of warning is certainly a big improvement over a complete
stack trace.
OTOH, something like "distributionManagement.status" might cause an erroneous
POM, but should it really harm the dependency report? If Maven can use
xml-resolver:xml-resolver:1.2 to build the classpath, it should also be
possible to get a proper dependency report about it.
> upgrade from 2.9 to 3.0.0 introduce additional warning issue
>
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: GW Rogde
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultM
[jira] [Commented] (MPIR-373) upgrade from 2.9 to 3.0.0 introduce additional warning issue
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16587134#comment-16587134
]
Joerg Schaible commented on MPIR-373:
-
Yes, according to the code it skips the license info.
> upgrade from 2.9 to 3.0.0 introduce additional warning issue
>
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: GW Rogde
>Assignee: Michael Osipov
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodA
[jira] [Commented] (MCOMPILER-279) Passing multiple --add-exports args to the compilerArgs is not supported
[
https://issues.apache.org/jira/browse/MCOMPILER-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15534081#comment-15534081
]
Joerg Schaible commented on MCOMPILER-279:
--
Maybe it is better to keep that map and add an own configuration (list) element
for exports:
{code:xml}
FROM-MOD/package1=OTHER-MOD
FROM-MOD/package2=OTHER-MOD
{code}
This Java 9 stuff is even with this support cumbersome enough :-/
> Passing multiple --add-exports args to the compilerArgs is not supported
>
>
> Key: MCOMPILER-279
> URL: https://issues.apache.org/jira/browse/MCOMPILER-279
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: Michael Musgrove
>Assignee: Robert Scholte
> Attachments: jdk9-test.tar
>
>
> This plugin collapses multiple compiler args with the same name into a single
> one.
> An example of where this is an issue is when exporting extra packages from a
> Java SE 9 module:
> Suppose we want to export two packages (package1 and package2) from a module
> called FROM-MOD to the OTHER-MOD module. The syntax for this is:
> {code}
> javac ... --add-exports FROM-MOD/package1=OTHER-MOD --add-exports
> FROM-MOD/package2=OTHER-MOD
> {code}
> and the plugin configuration for this is:
> {code:xml}
>
> ...
>
> --add-exports
> FROM-MOD/package1=OTHER-MOD
> --add-exports
> FROM-MOD/package2=OTHER-MOD>
>
>
> {code}
> which produces:
> {code}
> javac ... --add-exports FROM-MOD/package1=OTHER-MOD
> FROM-MOD/package2=OTHER-MOD
> {code}
> Notice the missing --add-exports for the second export so the compiler
> complains with the error:
> bq. Caused by: java.lang.IllegalArgumentException: invalid flag:
> java.corba/com.sun.corba.se.spi.ior=ALL-UNNAMED
> A concrete but basic example maven project is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6000) activeProfiles in pom.xml
[
https://issues.apache.org/jira/browse/MNG-6000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765549#comment-15765549
]
Joerg Schaible commented on MNG-6000:
-
This is already possible using file exists.
> activeProfiles in pom.xml
> -
>
> Key: MNG-6000
> URL: https://issues.apache.org/jira/browse/MNG-6000
> Project: Maven
> Issue Type: Improvement
> Components: POM, Profiles
>Reporter: Fabrizio Lungo
> Labels: features, maven
>
> I would like to see the ability to define {{}} in a pom. I
> think this would be extremely useful and provide a way for a parent pom to
> provide a set of profiles that can be picked and chosen from as per the needs
> of the project.
> A simple but specific example is where I would like to have a profile from
> our corporate parent pom that is activated when a project should build an
> executable jar. This profile provides the configuration for the
> {{maven-jar-plugin}} (as well as adding some validations and checks) and we
> would like to activate this on a per project level.
> Initially I tried using properties but activation conditions only look at
> system properties (and not pom defined ones) and even using a property in the
> {{}} tag. As described in MNG-5235 this is because
> profiles need to be processed first and using properties from the pom would
> create chicken-egg problems and inconsistencies because a profile can then
> modify these properties.
> If {{}} were to be added to pom, this could be read first to
> determine if any profiles need to be activated and allow a pom to define
> which profiles will be active by default.
> Two optional features that could be implemented to supplement this would be:
> * Support for {{}} inside of a profile for profiles to be
> able to recursively enable other profiles (that they may depend on). This
> would allow reduction of duplication if two profiles require some shared
> preconditions they can then just activate the profile with this shared
> configuration and if one or both are activated, the shared configuration
> profile will be activated too. This should be fairly easy to implement using
> recursive checks and not revisiting any profiles already in an active list
> (to avoid cycles - which should be warned about - and unnecessary
> re-evaluations)
> * Support for disabling profiles (possibly by using
> {{!profile-1}} syntax. This could have advantages where a
> parent pom activates a profile by default and the child wants it disabled by
> default although I can see this may cause problems.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15786367#comment-15786367 ] Joerg Schaible commented on MNG-6141: - Sorry, but this is a perfectly legal situation! We manage a global POM with depMgmt section for some products. However, some derived projects will override the settings in the depMgmt section on purpose. Yes, it is possible to shoot yourself into the foot using a depMgmt section, but in any case, it must have been my own decision. Nobody said, the managing dependencies is easy, but I expect the build tool to respect my choices. > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15786501#comment-15786501 ] Joerg Schaible commented on MNG-6141: - No, they are not public. However, even the maven-parent sets defaults for some dependencies in a dependencyManagement section. > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[ https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15787514#comment-15787514 ] Joerg Schaible commented on MNG-6141: - I know, but if you set such defaults in a parent, you may deliberately overwrite it in a child. At least we do this in some special cases. > Dependency management overrides are not transitive and should be considered > an anti-pattern. > > > Key: MNG-6141 > URL: https://issues.apache.org/jira/browse/MNG-6141 > Project: Maven > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Critical > Attachments: MNG-6141.zip > > > Overriding the dependency management in a module, the overridden value will > not be preserved transitively. It makes no sense to be able to override the > dependency management in a module if that is only effective in that module > and nowhere else. Overriding the dependency management should be considered > an anti-pattern. Maven should provide a warning when it is used. During the > development of Maven 3.4, there have been quite a few discussions on dev@ > about build issues which were all caused by overriding the dependency > management without noticing this is not supported transitively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848143#comment-15848143
]
Joerg Schaible commented on MNG-5567:
-
Still I have major concerns to include this at all. Currently ZIPs are often
used as attached artifacts to transport some additional resources. With this
functionality these artifacts add suddenly all kind of unwanted transitive
dependencies. If you look at Central for ZIP artifacts then you'll have trouble
to find one that is usable as a JAR.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848793#comment-15848793
]
Joerg Schaible commented on MNG-5567:
-
bq. First of all, how are ZIP files going to have transitive dependencies? We
do not have a zip packaging yet.
It is quite common to create attached ZIP files with the assembly plugin. An
attached artifact shares the same transitive dependencies than the main
artifact. How often I wished that could be stopped for EJB clients ;-)
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15848811#comment-15848811
]
Joerg Schaible commented on MNG-5567:
-
For me those two issues are not related apart from the fact that both address
ZIP files. If I add a dependency of type zip it does not matter if the
dependency is a main artifact or addressed with a classifier. I am in both
cases affected if ZIP artifacts suddenly provide transitive dependencies.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5567) Zip files are not included in classpaths at all
[
https://issues.apache.org/jira/browse/MNG-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15849018#comment-15849018
]
Joerg Schaible commented on MNG-5567:
-
OK, that makes sense. However, it does not help for the attached artifacts.
IMHO it is quite common to pack stuff like additional SQL files, WSDLs and
their schema files, etc. into an attached ZIP for later use. It would be quite
surprising if Maven changes behaviour for these kind of artifacts.
> Zip files are not included in classpaths at all
> ---
>
> Key: MNG-5567
> URL: https://issues.apache.org/jira/browse/MNG-5567
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
>Reporter: Pablo La Greca
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.5.1
>
>
> when i added a dependency that was zip file
> eg
> {code:xml}
> hsqldb
> hsqldb
> 1.7.3.0
> provided
> zip
>
> {code}
> this file was not included in the test classpath and so the test would not
> pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MINSTALL-135) Copy and unpack dependency plugin not behaving when used simultaneously
[ https://issues.apache.org/jira/browse/MINSTALL-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901568#comment-15901568 ] Joerg Schaible commented on MINSTALL-135: - This issue has nothing to do with the install plugin and also not even with the dependency plugin. Your usage of Maven is simply wrong here. You have declared the same plugin twice, therefore all executions and goals are merged. Since you've configured the plugin twice for all executions, one configuration will be lost. It's undefined which one. Therefore merge the two declarations yourself and move the configuration into the execution block where it belongs if you execute two goals. > Copy and unpack dependency plugin not behaving when used simultaneously > --- > > Key: MINSTALL-135 > URL: https://issues.apache.org/jira/browse/MINSTALL-135 > Project: Maven Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.6 >Reporter: Vardaan Gupta > > I am trying to use two maven-dependency-plugin with goals > 1. unpack > 2. copy > They are working individually fine but when both are in the pom.xml > then behaviour is not as expected. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MDEPLOY-247) Version 3.0.0-M1 breaks deploy using alt*DeploymentRepository with old syntax on Windows using
Joerg Schaible created MDEPLOY-247: -- Summary: Version 3.0.0-M1 breaks deploy using alt*DeploymentRepository with old syntax on Windows using Key: MDEPLOY-247 URL: https://issues.apache.org/jira/browse/MDEPLOY-247 Project: Maven Deploy Plugin Issue Type: Bug Components: deploy:deploy Affects Versions: 3.0.0-M1 Environment: Windows Reporter: Joerg Schaible With version 3.0.0-M1 the syntax for the alt*DeploymentRepository changed from id::layout::URL to id::URL (were using a file protocol here). Additionally the plugin now writes a lock file into the local repository using the id of the repository as base name. Since the plugin seems to interpret id::layout as the id for a legacy parameter value, it tries to write with such a name. Works with Unix, but not with Windows. Here the build fails. Removing the layout part from the parameter will fix the problem. Therefore this report is more a heads-up for others running into this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEPLOY-247) Version 3.0.0-M1 breaks deploy using alt*DeploymentRepository with old syntax on Windows
[ https://issues.apache.org/jira/browse/MDEPLOY-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated MDEPLOY-247: --- Summary: Version 3.0.0-M1 breaks deploy using alt*DeploymentRepository with old syntax on Windows (was: Version 3.0.0-M1 breaks deploy using alt*DeploymentRepository with old syntax on Windows using) > Version 3.0.0-M1 breaks deploy using alt*DeploymentRepository with old syntax > on Windows > > > Key: MDEPLOY-247 > URL: https://issues.apache.org/jira/browse/MDEPLOY-247 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy >Affects Versions: 3.0.0-M1 > Environment: Windows >Reporter: Joerg Schaible >Priority: Trivial > > With version 3.0.0-M1 the syntax for the alt*DeploymentRepository changed > from id::layout::URL to id::URL (were using a file protocol here). > Additionally the plugin now writes a lock file into the local repository > using the id of the repository as base name. Since the plugin seems to > interpret id::layout as the id for a legacy parameter value, it tries to > write with such a name. Works with Unix, but not with Windows. Here the build > fails. > Removing the layout part from the parameter will fix the problem. Therefore > this report is more a heads-up for others running into this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6596) maven should not make assumptions on the location of the parent pom
[ https://issues.apache.org/jira/browse/MNG-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16773919#comment-16773919 ] Joerg Schaible commented on MNG-6596: - I simply assume that Pieter does not know, that you can manage a parent pom like any other artefact, that a pom containing the modules section to control the build does not have to be the parent of the modules' poms and that an empty parentPath forces the lookup of the parent from the repository. > maven should not make assumptions on the location of the parent pom > --- > > Key: MNG-6596 > URL: https://issues.apache.org/jira/browse/MNG-6596 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.4, 3.6.0 > Environment: linux maven 3.5.4 and 3.6.0 >Reporter: Pieter van den Hombergh >Priority: Major > Fix For: waiting-for-feedback > > > the parent pom is currently the way to go to set configurations for multiple > projects, even if these projects are not siblings. > Creating and deploying a parent pom to be shared in many projects should not > force you to copy the parent pom around. Configurations should be dealt with > in the same way: Don not repeat (as in copy and waste) yourselves. > Making NO assumption OR ignoring the (default)) parentPath when the > assumption does not match would solve this issue. > The problem is even more annoying when maven reacts differently to using the > same parent pom. > The parent pom in question can be found on github under [statewalker > sebipom|https://github.com/sebivenlo/statewalker] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6658) Maven 3.6.1 breaks build when using custom source folder
[
https://issues.apache.org/jira/browse/MNG-6658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16845199#comment-16845199
]
Joerg Schaible commented on MNG-6658:
-
The question is if it is caused by the weird layout or because the same class
is twice in the reactor. What happens if you create a copy of your sources in
both modules (don't forget to remove the definition for the
(test)sourceDirectory in the parent)?
> Maven 3.6.1 breaks build when using custom source folder
>
>
> Key: MNG-6658
> URL: https://issues.apache.org/jira/browse/MNG-6658
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.1
>Reporter: Gary McWilliams
>Priority: Major
>
> NOTE: apacher 3.5.x and 3.6.0 don't exhibit this behaviour, only 3.6.1
> For reasons too long (and painful) to discuss, I have a need to build 2 war
> files from one codebase.
> What I have:
> {{parent/}}
> {{ src/com/.../*.java}}
> {{ pom.xml}}
> {{ module1/}}
> {{ pom.xml}}
> {{ module2/}}
> {{ pom.xml}}
>
> The parent folder (pom.xml with packaging 'pom') contains all the source and
> defines the 2 modules.
> The parent pom.xml has:
> {{ }}
> {{ ../src/main/java}}
> {{ ../src/test/java}}
>
> When the 2 modules run, they find the source/test code in the parent folder
> and compile/build out the class/war locally in target folder.
> Until 3.6.1, now I get:
> {{[ERROR] COMPILATION ERROR :}}
> {{[INFO] -}}
> {{[ERROR] /D:/.../src/main/java/com/.../ClassA.java:[36,8] duplicate class:
> comClassA}}
> where the "duplcate" classname is "the same class", so ClassA complains about
> duplicate ClassA
> Using maven 3.5.2, I see:
> {{[INFO] Compiling 11 source files to ...}}
> In maven 3.6.1, I see:
> {{[INFO] Compiling 22 source filesto ...}}
> Just looking advice. I know I should not be trying to build 2 artifacts in
> one project, but it's been working until now
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-752) [PATCH] Option to ignore empty directories in fileSet directory
[
https://issues.apache.org/jira/browse/MASSEMBLY-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364791#comment-17364791
]
Joerg Schaible commented on MASSEMBLY-752:
--
Is there any reason, why this patch has been ignored simply and the issue
closed with "Won't Do"? If you exclude files by pattern from a fileset, your
result might contain unwanted empty directories and there's no possibility to
get rid of it.
> [PATCH] Option to ignore empty directories in fileSet directory
> ---
>
> Key: MASSEMBLY-752
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-752
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.3
>Reporter: Guillaume Boué
>Priority: Major
> Attachments: MASSEMBLY-ignoreEmptyDirectories.patch
>
>
> When the directory attribute of fileSets contains empty directories, it would
> be nice to have an option to ignore them.
> === Actual behaviour ===
> Considering the structure :
> {noformat}
> src/
>+-- folder1/file.txt
>+-- folder2/
> {noformat}
> with the following fileSet in {{assembly.xml}} :
> {code:xml}
>
> src
> /
>
> {code}
> the assembly-plugin produces, as of today :
> {noformat}
> /folder1/file.txt
> /folder2
> {noformat}
> Note that the empty directory folder2 is present in the assembly.
> === Proposed enhancement ===
> With this enhancement, it would be possible to have the following in
> {{assembly.xml}} :
> {code:xml}
>
> src
> /
> false
>
> {code}
> and the resulting assembly would be :
> {noformat}
> /folder1/file.txt
> {noformat}
> Note that folder2 would not be present inside the assembly because it is
> empty.
> Attached is a patch adding the attribute "includeEmptyDirectories" to the
> fileSet element in assembly.xml file. For backward compatibility, the default
> value of this attribute is true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MASSEMBLY-752) [PATCH] Option to ignore empty directories in fileSet directory
[
https://issues.apache.org/jira/browse/MASSEMBLY-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364791#comment-17364791
]
Joerg Schaible edited comment on MASSEMBLY-752 at 6/17/21, 8:41 AM:
Is there any reason, why this patch has been simply ignored and the issue was
closed with "Won't Do"? If you exclude files by pattern from a fileset, your
result might contain unwanted empty directories and there's no possibility to
get rid of it.
was (Author: joehni):
Is there any reason, why this patch has been ignored simply and the issue
closed with "Won't Do"? If you exclude files by pattern from a fileset, your
result might contain unwanted empty directories and there's no possibility to
get rid of it.
> [PATCH] Option to ignore empty directories in fileSet directory
> ---
>
> Key: MASSEMBLY-752
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-752
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.3
>Reporter: Guillaume Boué
>Priority: Major
> Attachments: MASSEMBLY-ignoreEmptyDirectories.patch
>
>
> When the directory attribute of fileSets contains empty directories, it would
> be nice to have an option to ignore them.
> === Actual behaviour ===
> Considering the structure :
> {noformat}
> src/
>+-- folder1/file.txt
>+-- folder2/
> {noformat}
> with the following fileSet in {{assembly.xml}} :
> {code:xml}
>
> src
> /
>
> {code}
> the assembly-plugin produces, as of today :
> {noformat}
> /folder1/file.txt
> /folder2
> {noformat}
> Note that the empty directory folder2 is present in the assembly.
> === Proposed enhancement ===
> With this enhancement, it would be possible to have the following in
> {{assembly.xml}} :
> {code:xml}
>
> src
> /
> false
>
> {code}
> and the resulting assembly would be :
> {noformat}
> /folder1/file.txt
> {noformat}
> Note that folder2 would not be present inside the assembly because it is
> empty.
> Attached is a patch adding the attribute "includeEmptyDirectories" to the
> fileSet element in assembly.xml file. For backward compatibility, the default
> value of this attribute is true.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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-tabpanel&focusedCommentId=14599688#comment-14599688
]
Joerg Schaible commented on MNG-5846:
-
It's not! If your settings.xml defines a mirror for central, it works. Your
example simply demontrates why it is a bad idea to define repositories in a
POM. Just look at the effective pom for metro-project and you will see, that
your repository definitions are nowhere.
{noformat}
mvn -f
~/.m2/repository/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
help:effective-pom
{noformat}
> 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}
>
> 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";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {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] [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-tabpanel&focusedCommentId=14599816#comment-14599816
]
Joerg Schaible commented on MNG-5846:
-
The example demonstrates simply, how Maven works by definition.
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/#.VYrsWUTgJiA
> 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}
>
> 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";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {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] [Comment Edited] (MNG-5862) POM XML parser needs XInclude and/or XML Entity support
[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636857#comment-14636857
]
Joerg Schaible edited comment on MNG-5862 at 7/22/15 12:42 PM:
---
Maven 1 had XInclude and entity support and it was dropped on purpose for Maven
2, because the POMs of M1 were not necessarily self-contained.
bq. It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
contain the plugin executions to run any single test suite ;
Why not? From your description it is not easy what you really try to
accomplish, but you have two options with M2/3 to deal with such problems using
a shared parent: Either use properties to isolate the differences or use
profiles. A property can be redefined in a child project, it's value is used
even it the property itself is used in the parent project. Profiles offer the
possibility to be automatically activated by the existence of a file or
directory i.e. if such a file/directory exists in the child project, the
profile inherited from the parent is activated.
If you cannot solve your problem with these possibilities, I'd like to know why.
was (Author: joehni):
Maven 1 hat XInclude and entity support and it was dropped on purpose for Maven
2, because the POMs of M1 were not necessarily self-contained.
bq. It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
contain the plugin executions to run any single test suite ;
Why not? From your description it is not easy what you really try to
accomplish, but you have two options with M2/3 to deal with such problems using
a shared parent: Either use properties to isolate the differences or use
profiles. A property can be redefined in a child project, it's value is used
even it the property itself is used in the parent project. Profiles offer the
possibility to be automatically activated by the existence of a file or
directory i.e. if such a file/directory exists in the child project, the
profile inherited from the parent is activated.
If you cannot solve your problem with these possibilities, I'd like to know why.
> POM XML parser needs XInclude and/or XML Entity support
> ---
>
> Key: MNG-5862
> URL: https://issues.apache.org/jira/browse/MNG-5862
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Jason Vas Dias
>
> POM XML files can get very large and repetitive , and not all modularizaton
> scenarios can be resolved by using a Super POM as described in MNG-1980 ,
> and would be easily resolved if only the POM parser supported XIncludes or
> XML Entities - neither are supported.
> Here is one such scenario:
> I have a large project that has several SureFire plugin based "Test Suites" -
> each test suite uses a "common-at-classes" module of common test classes,
> and is essentially identical except in its XML configuration "test resource"
> files
> - so the structure is like this :
> {quote}
> {noformat}
> Top Level project directory:
>./pom.xml
>./acceptance-tests/pom.xml
>./acceptance-tests/common-at-classes/pom.xml
>./acceptance-tests/test-suite_#1/pom.xml
>...
>./acceptance-tests/test-suite_#N/pom.xml
> {noformat}
> {quote}
> There are @ 10 ( being upgraded to @ 20) "test suites",
> which all do exactly the same thing, but with slightly
> different "test resource" configuration files,
> and depend on the 'acceptance-tests/common-at-classes" JAR .
> We can modularize all the test-suite dependencies OK in the single
> common-at-classes/pom.xml location .
> But their is no way to modularize the actual XML code that runs each
> test-suite with plugin executions - these plugin execution stanzas can
> currently ONLY
> be in each test-suite#N directory, even though they are identical.
> It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
> contain the plugin executions to run any single test suite ; nor can the
> common-at-classes/pom.xml contain the plugin execution to run any
> test suite, since a test suite run depends on the customized test resource
> files that only exist in each "test_suite#N/" sub-project .
> So the only solution currently available with Maven is to copy the XML stanzas
> that configure and run the test suite ( about 400 lines of XML ) into each of
> the 10-20 test-suite/pom.xml files ; this is all because Maven does not
> support
> XML XInclude or XML Entities; if it did, we could put all this code into one
> XML
> file provided by the common-at-classes project, and include it in each test
> suite .
> The test suite XML is then a nightmare to maintain, consistently for all test
> suites.
> This is becoming such a problem that I am considering making the root project
> POM do nothing more than transform th
[jira] [Comment Edited] (MNG-5862) POM XML parser needs XInclude and/or XML Entity support
[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636857#comment-14636857
]
Joerg Schaible edited comment on MNG-5862 at 7/22/15 12:41 PM:
---
Maven 1 hat XInclude and entity support and it was dropped on purpose for Maven
2, because the POMs of M1 were not necessarily self-contained.
bq. It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
contain the plugin executions to run any single test suite ;
Why not? From your description it is not easy what you really try to
accomplish, but you have two options with M2/3 to deal with such problems using
a shared parent: Either use properties to isolate the differences or use
profiles. A property can be redefined in a child project, it's value is used
even it the property itself is used in the parent project. Profiles offer the
possibility to be automatically activated by the existence of a file or
directory i.e. if such a file/directory exists in the child project, the
profile inherited from the parent is activated.
If you cannot solve your problem with these possibilities, I'd like to know why.
was (Author: joehni):
Maven 1 hat XInclude and entity support and it was dropped on purpose for Maven
2, because the POMs of M1 were not necessarily self-contained.
bq. It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
contain the plugin executions to run any single test suite ;
Why not? From your description it is not easy what you really try to
accomplish, but you have two options with M2/3 to deal with such problems using
a shared parent: Either use properties to isolate the differences or use
profiles. A property can be redefined in a child project, it's value is used
even it the property itself is used in the parent project. Profiles offer the
possibility to be automatically activated by the existence of a file or
directory i.e. if such a file/directory exists in the child project, the
profile inherited from the parent is activated.
If you cannot solve your problem with these possibilities, I'd like to know why.
> POM XML parser needs XInclude and/or XML Entity support
> ---
>
> Key: MNG-5862
> URL: https://issues.apache.org/jira/browse/MNG-5862
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Jason Vas Dias
>
> POM XML files can get very large and repetitive , and not all modularizaton
> scenarios can be resolved by using a Super POM as described in MNG-1980 ,
> and would be easily resolved if only the POM parser supported XIncludes or
> XML Entities - neither are supported.
> Here is one such scenario:
> I have a large project that has several SureFire plugin based "Test Suites" -
> each test suite uses a "common-at-classes" module of common test classes,
> and is essentially identical except in its XML configuration "test resource"
> files
> - so the structure is like this :
> {quote}
> {noformat}
> Top Level project directory:
>./pom.xml
>./acceptance-tests/pom.xml
>./acceptance-tests/common-at-classes/pom.xml
>./acceptance-tests/test-suite_#1/pom.xml
>...
>./acceptance-tests/test-suite_#N/pom.xml
> {noformat}
> {quote}
> There are @ 10 ( being upgraded to @ 20) "test suites",
> which all do exactly the same thing, but with slightly
> different "test resource" configuration files,
> and depend on the 'acceptance-tests/common-at-classes" JAR .
> We can modularize all the test-suite dependencies OK in the single
> common-at-classes/pom.xml location .
> But their is no way to modularize the actual XML code that runs each
> test-suite with plugin executions - these plugin execution stanzas can
> currently ONLY
> be in each test-suite#N directory, even though they are identical.
> It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
> contain the plugin executions to run any single test suite ; nor can the
> common-at-classes/pom.xml contain the plugin execution to run any
> test suite, since a test suite run depends on the customized test resource
> files that only exist in each "test_suite#N/" sub-project .
> So the only solution currently available with Maven is to copy the XML stanzas
> that configure and run the test suite ( about 400 lines of XML ) into each of
> the 10-20 test-suite/pom.xml files ; this is all because Maven does not
> support
> XML XInclude or XML Entities; if it did, we could put all this code into one
> XML
> file provided by the common-at-classes project, and include it in each test
> suite .
> The test suite XML is then a nightmare to maintain, consistently for all test
> suites.
> This is becoming such a problem that I am considering making the root project
> POM do nothing more than transform the
[jira] [Commented] (MNG-5862) POM XML parser needs XInclude and/or XML Entity support
[
https://issues.apache.org/jira/browse/MNG-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636857#comment-14636857
]
Joerg Schaible commented on MNG-5862:
-
Maven 1 hat XInclude and entity support and it was dropped on purpose for Maven
2, because the POMs of M1 were not necessarily self-contained.
bq. It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
contain the plugin executions to run any single test suite ;
Why not? From your description it is not easy what you really try to
accomplish, but you have two options with M2/3 to deal with such problems using
a shared parent: Either use properties to isolate the differences or use
profiles. A property can be redefined in a child project, it's value is used
even it the property itself is used in the parent project. Profiles offer the
possibility to be automatically activated by the existence of a file or
directory i.e. if such a file/directory exists in the child project, the
profile inherited from the parent is activated.
If you cannot solve your problem with these possibilities, I'd like to know why.
> POM XML parser needs XInclude and/or XML Entity support
> ---
>
> Key: MNG-5862
> URL: https://issues.apache.org/jira/browse/MNG-5862
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Jason Vas Dias
>
> POM XML files can get very large and repetitive , and not all modularizaton
> scenarios can be resolved by using a Super POM as described in MNG-1980 ,
> and would be easily resolved if only the POM parser supported XIncludes or
> XML Entities - neither are supported.
> Here is one such scenario:
> I have a large project that has several SureFire plugin based "Test Suites" -
> each test suite uses a "common-at-classes" module of common test classes,
> and is essentially identical except in its XML configuration "test resource"
> files
> - so the structure is like this :
> {quote}
> {noformat}
> Top Level project directory:
>./pom.xml
>./acceptance-tests/pom.xml
>./acceptance-tests/common-at-classes/pom.xml
>./acceptance-tests/test-suite_#1/pom.xml
>...
>./acceptance-tests/test-suite_#N/pom.xml
> {noformat}
> {quote}
> There are @ 10 ( being upgraded to @ 20) "test suites",
> which all do exactly the same thing, but with slightly
> different "test resource" configuration files,
> and depend on the 'acceptance-tests/common-at-classes" JAR .
> We can modularize all the test-suite dependencies OK in the single
> common-at-classes/pom.xml location .
> But their is no way to modularize the actual XML code that runs each
> test-suite with plugin executions - these plugin execution stanzas can
> currently ONLY
> be in each test-suite#N directory, even though they are identical.
> It would make no sense to have the "Super POM" : acceptance-tests/pom.xml
> contain the plugin executions to run any single test suite ; nor can the
> common-at-classes/pom.xml contain the plugin execution to run any
> test suite, since a test suite run depends on the customized test resource
> files that only exist in each "test_suite#N/" sub-project .
> So the only solution currently available with Maven is to copy the XML stanzas
> that configure and run the test suite ( about 400 lines of XML ) into each of
> the 10-20 test-suite/pom.xml files ; this is all because Maven does not
> support
> XML XInclude or XML Entities; if it did, we could put all this code into one
> XML
> file provided by the common-at-classes project, and include it in each test
> suite .
> The test suite XML is then a nightmare to maintain, consistently for all test
> suites.
> This is becoming such a problem that I am considering making the root project
> POM do nothing more than transform the test-suite poms with XML XInclude-s
> (using an external XML processor), creating a new copy of the whole project,
> and then run an exec plugin goal which runs maven with the transformed POMs.
> Please, please can we have some form of XInclude or XML Entity support , or
> support for an "" element, in the POM parser !
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSHADE-204) Multiple JDBC drivers not supported
[ https://issues.apache.org/jira/browse/MSHADE-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728133#comment-14728133 ] Joerg Schaible commented on MSHADE-204: --- You have to set the ServicesResourceTransformer. See plugin documentation. > Multiple JDBC drivers not supported > --- > > Key: MSHADE-204 > URL: https://issues.apache.org/jira/browse/MSHADE-204 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.1 >Reporter: Loren Cole > > Mysql JDBC driver not working when building a project with dependencies on > both postgres and mysql JDBC drivers. > java.sql.DriverManager uses the /META-INF/Services/java.sql.Driver to > register available JDBC drivers. When doing a shaded build this file is > overwritten with each driver, so the last one wins. Instead it should be > appended to contain all available drivers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5727) unexpected InvalidArtifactRTException from ProjectBuilder#build
[
https://issues.apache.org/jira/browse/MNG-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948609#comment-14948609
]
Joerg Schaible commented on MNG-5727:
-
Or this overriding the scope in a "later" dependenciesManagement section:
{code:xml|title=parent.xml}
4.0.0
test
parent
0.0.1-SNAPSHOT
junit
junit
4.12
{code}
{code:xml|title=project.xml}
4.0.0
test
parent
0.0.1-SNAPSHOT
versionless-managed-dependency.xml
junit
junit
junit
junit
runtime
{code}
> unexpected InvalidArtifactRTException from ProjectBuilder#build
> ---
>
> Key: MNG-5727
> URL: https://issues.apache.org/jira/browse/MNG-5727
> Project: Maven
> Issue Type: Bug
>Reporter: Igor Fedorenko
> Fix For: 3.2.5
>
>
> Calling into ProjectBuilder#build(File, ProjectBuildingRequest) results in
> InvalidArtifactRTException below if project pom.xml has managed dependency
> without . Although the pom is invalid, I expected to get
> ProjectBuildingException that includes location of problematic dependency,
> similar to what I get during command line build.
> {code}
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact
> {org.apache.maven.its:a:null:jar}: The version cannot be empty.
> at
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:148)
> at
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:123)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateArtifact(MavenRepositorySystem.java:695)
> at
> org.apache.maven.bridge.MavenRepositorySystem.XcreateDependencyArtifact(MavenRepositorySystem.java:613)
> at
> org.apache.maven.bridge.MavenRepositorySystem.createDependencyArtifact(MavenRepositorySystem.java:121)
> at
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:808)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028424#comment-15028424 ] Joerg Schaible commented on MNG-5939: - Typically this has nothing to do with Maven, but with the parent POM you are using. > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.3, 3.3.9 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe > Attachments: foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact > http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5939) Problem doing release when sources are generate as well
[ https://issues.apache.org/jira/browse/MNG-5939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15028777#comment-15028777 ] Joerg Schaible commented on MNG-5939: - You have configured the sources plugin to run two goals: jar and jar-no-fork. So Maven does what you have told. > Problem doing release when sources are generate as well > --- > > Key: MNG-5939 > URL: https://issues.apache.org/jira/browse/MNG-5939 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.3, 3.3.9 > Environment: Ubuntu 12.04.5 LTS > Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; > 2014-02-14T18:37:52+01:00) > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; > 2015-11-10T17:41:47+01:00) > Java version: 1.7.0_76, vendor: Oracle Corporation >Reporter: chibbe > Attachments: foo.bar.zip > > > If I specified that sources should be generated with jar-no-fork goal > https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html . > When doing a release with maven-release-plugin it will build the source again > when useReleaseProfile is true (use the release profile that adds sources and > javadocs to the released artifact > http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile). > The outcome is that it will run with both jar and jar-no-fork and generate > and deploy 2 -sources.jar artifacts, with same version. That makes the > release build fails. > > The same behavior could be reproduced when running both jar and jar-no-fork > goal between maven 3.2.1. and maven 3.3.9. > > Please find the logs for maven 3.2.1 and 3.3.9 in the foo.bar.zip > With maven 3.3.9 it uploads it 2 times : > Uploaded: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > (722 B at 15.3 KB/sec) > Uploading: > http://127.0.0.1:8081/nexus/content/repositories/releases/foo/bar/0.0.1/bar-0.0.1-sources.jar > 722/722 B -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] Commented: (MJARSIGNER-12) It should be possible to save the keystore in one location for multi module projects
[ http://jira.codehaus.org/browse/MJARSIGNER-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264672#action_264672 ] Joerg Schaible commented on MJARSIGNER-12: -- We do this and use the dependency plugin to copy dependent p12 files from the repo for local usage of the jarsigner plugin. > It should be possible to save the keystore in one location for multi module > projects > > > Key: MJARSIGNER-12 > URL: http://jira.codehaus.org/browse/MJARSIGNER-12 > Project: Maven 2.x Jar Signer Plugin > Issue Type: New Feature >Reporter: Sven Kirmess > > We have a multi module maven setup. The problem is that this plugin requires > us to have the keystore either in the same location on all machines or in the > source code along each and every pom.xml file. > I would like to have one of the following: > - Save the file on one location in Subversion and use something like >svn://svn.example.com/trunk/keystore >and the plugin would have to take care to check out the keystore into > every project as needed. > or > - Put the keystore into a JAR file and save that JAR file on the Nexus > server. Then make the jarsigner plugin depend on this JAR file, download it > for every project and extract the keystore from there. This would be like > what the assembly plugin can do for its descriptors. > http://docs.codehaus.org/display/MAVENUSER/Assembly+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] Commented: (MEAR-138) Ear plugin doesn't attach jars with timestamp
[
http://jira.codehaus.org/browse/MEAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=265206#action_265206
]
Joerg Schaible commented on MEAR-138:
-
You may configure the ejb-plugin instead to use non-unique versions in the
manifest:
{noformat}
false
{noformat}
Otherwise you will always have to rebuild all EJBs and EARs at once in
development. That would create a major headache for us.
> Ear plugin doesn't attach jars with timestamp
> -
>
> Key: MEAR-138
> URL: http://jira.codehaus.org/browse/MEAR-138
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: maven 3.0.3
>Reporter: Michal Hlavac
>
> Since maven 3 ignore true all snapshots are
> built with timestamp. EJB plugin creates manifest with classpath that
> contains jars with timestamps (e.g. artefact-1.0-20110429.071946-2.jar) but
> ear plugin attach file artefact-1.0-SNAPSHOT.jar).
--
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] Commented: (MEAR-138) Ear plugin doesn't attach jars with timestamp
[ http://jira.codehaus.org/browse/MEAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=265301#action_265301 ] Joerg Schaible commented on MEAR-138: - The only problem with my solution is, that it does not work if the snapshot dependency had not been built locally, but downloaded from remote repository. In this case there will be also a mismatch between manifest entry and bundled jar. > Ear plugin doesn't attach jars with timestamp > - > > Key: MEAR-138 > URL: http://jira.codehaus.org/browse/MEAR-138 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: maven 3.0.3 >Reporter: Michal Hlavac > > Since maven 3 ignore true all snapshots are > built with timestamp. EJB plugin creates manifest with classpath that > contains jars with timestamps (e.g. artefact-1.0-20110429.071946-2.jar) but > ear plugin attach file artefact-1.0-SNAPSHOT.jar). -- 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] Commented: (MPIR-220) IOException: Failed to open file During Site generation
[
http://jira.codehaus.org/browse/MPIR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=265506#action_265506
]
Joerg Schaible commented on MPIR-220:
-
Simply take the two dependencies from MPIR-222, they are available in public
repo http://nexus.magnolia-cms.com/content/repositories/magnolia.public.releases
> IOException: Failed to open file During Site generation
> ---
>
> Key: MPIR-220
> URL: http://jira.codehaus.org/browse/MPIR-220
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.3.1
> Environment: Linux (Ubuntu)
> java -version
> java version "1.6.0_22"
> Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
> Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
> Apache Maven 3.0.2 (r1056850; 2011-01-09 01:58:10+0100)
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-27-generic", arch: "amd64", family: "unix"
>Reporter: Karl Heinz Marbaise
>
> I have build which is working completely fine which means mvn clean package
> works perfect.
> If i try to do a mvn site i got the following Exception message:
> {code}[INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.3.1
> [ERROR] IOException: Failed to open file
> /home/ubuntu/ws-git/pustefix-workspace/pws-config/target/classes : error in
> opening zip file
> java.util.zip.ZipException: Failed to open file
> /home/ubuntu/ws-git/pustefix-workspace/pws-config/target/classes : error in
> opening zip file
> at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:109)
> at
> org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:273)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1374)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:544)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:271)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:206)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:165)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:159)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
> 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:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.
[jira] Commented: (MDEP-231) Create a single dependency resolution plugin
[ https://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272459#comment-272459 ] Joerg Schaible commented on MDEP-231: - What's the difference to existing "get" goal? > Create a single dependency resolution plugin > > > Key: MDEP-231 > URL: https://jira.codehaus.org/browse/MDEP-231 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: resolve >Affects Versions: 2.1, 2.2 >Reporter: Marvin Froeder >Assignee: John Casey > Fix For: 2.4 > > Attachments: maven-dependency-plugin.patch, > maven-dependency-plugin.patch, maven-dependency-plugin.patch > > > The attached patch has a new goal that allows a single dependency to be > resolved, like this: > mvn > org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single > -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272497#comment-272497 ] Joerg Schaible commented on MNG-5127: - It's closed, because it behaves as designed. Profiles are always valid in the scope of the POM they are defined in, they are not inherited. The help plugin does unfortunately only show active profiles of the *current* POM, but not the ones of the parent. You have to repeat the activation for he current POM, otherwise the profile will not be active. > CLONE - Maven profile activation does not work when profile is defined in > inherited 'parent' pom > > > Key: MNG-5127 > URL: https://jira.codehaus.org/browse/MNG-5127 > Project: Maven 2 & 3 > Issue Type: Bug >Reporter: Gilles Scokart >Assignee: John Casey > > The goal is to activate a maven profile based on OS user name. > When I create a standalone project with a profile activation, it works, > however, when I define the profile in a "parent" pom, it is never activated. > this works: > ... > > TONY > > > user.name > WINTONY > > > > > > So in this case, my profile is activated based on my OS user name > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': > The following profiles are active: > - TONY (source: pom) > -- > However, if I now have the profiles definition in the "parent" pom, it > doesn't work when I build a child project > So the child project references the parent pom containing the profiles and > the activation, but when it is built, > the profile is not activated > PARENT POM: > ... > > > TONY > > > user.name > WINTONY > > > > ... > CHILD POM (the one being built) > > > com.capgemini.be.proj1 > parent > 4.0.2 > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 Application > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': > There are no active profiles. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272567#comment-272567 ] Joerg Schaible commented on MNG-5127: - Just in case you mean "activeByDefault": It's active *unless* you explicitly specify other ones to be active. > CLONE - Maven profile activation does not work when profile is defined in > inherited 'parent' pom > > > Key: MNG-5127 > URL: https://jira.codehaus.org/browse/MNG-5127 > Project: Maven 2 & 3 > Issue Type: Bug >Reporter: Gilles Scokart >Assignee: John Casey > > The goal is to activate a maven profile based on OS user name. > When I create a standalone project with a profile activation, it works, > however, when I define the profile in a "parent" pom, it is never activated. > this works: > ... > > TONY > > > user.name > WINTONY > > > > > > So in this case, my profile is activated based on my OS user name > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': > The following profiles are active: > - TONY (source: pom) > -- > However, if I now have the profiles definition in the "parent" pom, it > doesn't work when I build a child project > So the child project references the parent pom containing the profiles and > the activation, but when it is built, > the profile is not activated > PARENT POM: > ... > > > TONY > > > user.name > WINTONY > > > > ... > CHILD POM (the one being built) > > > com.capgemini.be.proj1 > parent > 4.0.2 > > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'help'. > [INFO] > > [INFO] Building Proj1 Application > [INFO] task-segment: [help:active-profiles] (aggregator-style) > [INFO] > > [INFO] [help:active-profiles] > [INFO] > Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': > There are no active profiles. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[ https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274961#comment-274961 ] Joerg Schaible commented on MRELEASE-699: - The more interesting question is: Why do you want to do this? IMHO this functionality was not implemented on purpose, because you should never have locally a non-SNAPSHOT version. > release:update-versions should support -DreleaseVersion too (not only > -DdevelopmentVersion), so it also supports not suffixing the version with > -SNAPSHOT > - > > Key: MRELEASE-699 > URL: https://jira.codehaus.org/browse/MRELEASE-699 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Reporter: Geoffrey De Smet > Attachments: > 0001-MRELEASE-699-release-update-versions-should-support-.patch > > > The documentation > > http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html > states "The update-versions goal can use the same properties used by the > prepare goal for specifying the versions to be used." > That's not true, as releaseVersion is not supported: > > http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion > This means, that if you do this: > mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0 > that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279045#comment-279045 ] Joerg Schaible commented on MWAR-260: - Why do you need a new packaging type? We do this since years using packaging type jar and add the war as attached artifact with classifier 'webapp'. > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279052#comment-279052 ] Joerg Schaible commented on MWAR-260: - bq. Does it need to declare two dependencies for each overlay, one for the jar and one for the webapp type? Yes. I've recommended it more than once, e.g. here: http://www.mailinglistarchive.com/us...@maven.apache.org/msg58383.html The main problem is IMHO not the declaration of the second artifact, but the proper configuration of the war plugin for each case. # The webapp should have the resulting jar within its WEB-INF/lib and it should not contain anything in WEB-INF/classes. # The assembling webapp must (apart from the declaration of the two dependencies) exclude everything coming from the overlay's WEB-INF/libs, because it calculates its dependencies now on its own. # In a cascading build you have to ensure that you don't inherit unwanted overlays, e.g. webapp A is used as overlay for webapp B which is in turn used as overlay for webapp C. You have to ensure that A is not used directly as overlay again in C, because of the now _visible_ dependency tree. So does your solution address any of this 3 points automatically or do you only spare the declaration of the 2nd artifact? > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279112#comment-279112 ] Joerg Schaible commented on MWAR-260: - OK, it seems you have a slightly different model in mind. I assume now that a war-overlay project from your proposal generates a war file with a jar file extension, that is only used as an overlay in a real war project. We have actually a different approach. We assemble in our main web application also several other (overlay) web applications i.e. small web applications (modules) that can be used also on their own. Additionally our main web application might be customized in a project and is used there as overlay. Any of those web applications are standard Maven projects producing a jar as main artifact that is also included in the attached web application. As result we have at any time a web application (individual modules, main web application or the customized one) that can be deployed on its own or that can be used again as overlay without loosing the dependency information. bq. C depends on B and B depends on A then surely both B and A should be overlaid on C? No, not in our model. If B excludes or overwrites some web resources of A, you want the B version in C. You don't want to have the changes made in B clobbered (or added) by resources from A in C again. Building C you should not really have to know that A exists and you may have to take care for something. However, this case cannot happen in your model, since you use only overlay-wars for overlays. > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-260) Patch to provide new war-overlay type
[ https://jira.codehaus.org/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279168#comment-279168 ] Joerg Schaible commented on MWAR-260: - Hi Alex, bq. You would expect the following: Exaclty. bq. It almost works except I cannot seem to stop artifacts from A appearing in C. Declare A with scope _provided_ in the depMgmt section. We have a global parent POM where all our attached webapps are declared with this scope (and with the version). To use them as overlay, we have to set the scope to _runtime_ in the individual project. bq. I hope that that helps to clarify the differences between the two approaches and hopefully makes the patch a more attractive proposition. I just want to be sure, that everyone understands the implicit part of the model. The war plugin supports already different kind of concepts (e.g. it can create a jar from the class files on its own) which has other implications. With all the explanation here it is now clear what is achieved by the patch. bq. BTW are you a committer for maven-war-plugin? No, just a long time user. > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://jira.codehaus.org/browse/MWAR-260 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-325) Incorrect -link is generated for 1.5
[
https://jira.codehaus.org/browse/MJAVADOC-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279899#comment-279899
]
Joerg Schaible commented on MJAVADOC-325:
-
Oracle uses dots for the official links to the various javadoc versions:
http://www.oracle.com/technetwork/java/javase/documentation/api-jsp-136079.html
> Incorrect -link is generated for 1.5
>
>
> Key: MJAVADOC-325
> URL: https://jira.codehaus.org/browse/MJAVADOC-325
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: Maven home: c:\apache-maven-3.0.3\bin\..
> Java version: 1.6.0_22, vendor: Sun Microsystems Inc.
> Java home: C:\Progra~2\Java\jdk1.6.0_22\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Paul Benedict
>
> I consistently get this error when generating javadoc:
> bq. Exit code: 1 - javadoc: error - Illegal package name: ""
> I tracked it down to how the plugin's options file is generated. The new
> Oracle JDK 1.5 javadoc link is this:
> http://download.oracle.com/javase/1,5,0/docs/api/
> There's a comma between the 1 and the 5. The comma is somehow being used as a
> separator for the plugin because this gets generated:
> {quote}
> -link
> 'http://download.oracle.com/javase/1
> -link
> 5.0/docs/api'
> {quote}
> Bascially, I can't generate 1.5 javadoc with the new Oracle link.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280127#comment-280127
]
Joerg Schaible commented on MEAR-143:
-
This works for us since years and I am sure we're not alone. So, without
providing a small project that exhibit this behavior, this issue will probably
simply closed with "cannot reproduce".
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-143) Plugin does not respect transitive dependency scopes properly
[
https://jira.codehaus.org/browse/MEAR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280177#comment-280177
]
Joerg Schaible commented on MEAR-143:
-
This is exactly how dependencyManagement works!
http://maven.apache.org/pom.html#Dependency_Management
> Plugin does not respect transitive dependency scopes properly
> -
>
> Key: MEAR-143
> URL: https://jira.codehaus.org/browse/MEAR-143
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Laird Nelson
> Attachments: mear-143.zip
>
>
> The [Introduction to the Dependency Mechanism
> page|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> has a handy table for deciding what to do with transitive dependencies and
> various scopes. The Maven ear plugin does not honor it in all cases.
> Suppose I have a {{.jar}} file. Its name is {{b.jar}}. It declares a
> {{runtime}} dependency on {{a.jar}}.
> Suppose now I have an {{.ear}} project. It declares a {{compile}} scope
> dependency on {{b.jar}}.
> By the rules of the chart, {{a.jar}} should end up being a {{runtime}}
> dependency (transitively) of the {{.ear}}, and should be included in the
> {{lib}} directory. It is not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281586#comment-281586 ] Joerg Schaible commented on MNG-1977: - bq. compile -> compile = runtime bq. This would make many builds far more robust to changes in child dependencies. You can simulate this if you use a global master pom. Then you would not only set the version in the depMgmt, but also the scope of all deps to runtime. That will have the same effect, you would have to set compile scope explicitly everywhere in our project. Been there and reverted it ... you'll see yourself, if you try ;-) > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1 > > Attachments: global_excls_it-test_v2.patch, > global_excls_maven3_v2.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-81) Request enhancement to pattern matching for packagingIncludes/packagingExcludes functionality (regular expressions?)
[ https://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282176#comment-282176 ] Joerg Schaible commented on MWAR-81: Have a look at: http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html IIRC, this include/exclude stuff is provided by a plexus component and it might already work ;-) > Request enhancement to pattern matching for > packagingIncludes/packagingExcludes functionality (regular expressions?) > > > Key: MWAR-81 > URL: https://jira.codehaus.org/browse/MWAR-81 > Project: Maven 2.x WAR Plugin > Issue Type: Wish > Environment: n/a >Reporter: Bryan Loofbourrow >Priority: Minor > Attachments: maven-war-plugin-2.1.1-NM.patch > > > The Maven War Plugin currently permits choosing what files will wind up in > the .war. It does this via two parameters, warSourceIncludes, and > warSourceExcludes. The rule appears to be that the includes are computed, > and a list of matches made, then that list is run against the excludes, and > any matches taken out of the include list. > The only wildcards that appear to be supported are *, **, and ?. > That doesn't work well if you are packaging wars in ears, and therefore want > to exclude all jars from the war, except for one or two that have to be in > the war in order to run properly. "Exclude all but foo.jar and bar.jar" just > doesn't translate well to "here's your simple include template, here's your > simple exclude template" representation, at least with current wildcards. > So this is a wish specifically for something to address the "exclude all but > x, y, and z" need for war source includes/excludes, and a suggestion that it > might be best to deprecate the warSourceIncludes/warSourceExcludes approach > in favor of a single parameter that supports regular expressions instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-81) Request enhancement to pattern matching for packagingIncludes/packagingExcludes functionality (regular expressions?)
[
https://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28#comment-28
]
Joerg Schaible commented on MWAR-81:
This is what I mean: You don't have to patch anything, it already works! I can
use this without any problems to exclude files with log4j in their names:
{noformat}
%regex[.*log4j.*]
{noformat}
> Request enhancement to pattern matching for
> packagingIncludes/packagingExcludes functionality (regular expressions?)
>
>
> Key: MWAR-81
> URL: https://jira.codehaus.org/browse/MWAR-81
> Project: Maven 2.x WAR Plugin
> Issue Type: Wish
> Environment: n/a
>Reporter: Bryan Loofbourrow
>Priority: Minor
> Attachments: maven-war-plugin-2.1.1-NM.patch
>
>
> The Maven War Plugin currently permits choosing what files will wind up in
> the .war. It does this via two parameters, warSourceIncludes, and
> warSourceExcludes. The rule appears to be that the includes are computed,
> and a list of matches made, then that list is run against the excludes, and
> any matches taken out of the include list.
> The only wildcards that appear to be supported are *, **, and ?.
> That doesn't work well if you are packaging wars in ears, and therefore want
> to exclude all jars from the war, except for one or two that have to be in
> the war in order to run properly. "Exclude all but foo.jar and bar.jar" just
> doesn't translate well to "here's your simple include template, here's your
> simple exclude template" representation, at least with current wildcards.
> So this is a wish specifically for something to address the "exclude all but
> x, y, and z" need for war source includes/excludes, and a suggestion that it
> might be best to deprecate the warSourceIncludes/warSourceExcludes approach
> in favor of a single parameter that supports regular expressions instead.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MWAR-81) Request enhancement to pattern matching for packagingIncludes/packagingExcludes functionality (regular expressions?)
[
https://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28#comment-28
]
Joerg Schaible edited comment on MWAR-81 at 10/27/11 9:06 AM:
--
This is what I mean: You don't have to patch anything, it already works (at
least tested with 2.1.1)! I can use this without any problems to exclude files
with log4j in their names:
{noformat}
%regex[.*log4j.*]
{noformat}
was (Author: joehni):
This is what I mean: You don't have to patch anything, it already works! I
can use this without any problems to exclude files with log4j in their names:
{noformat}
%regex[.*log4j.*]
{noformat}
> Request enhancement to pattern matching for
> packagingIncludes/packagingExcludes functionality (regular expressions?)
>
>
> Key: MWAR-81
> URL: https://jira.codehaus.org/browse/MWAR-81
> Project: Maven 2.x WAR Plugin
> Issue Type: Wish
> Environment: n/a
>Reporter: Bryan Loofbourrow
>Priority: Minor
> Attachments: maven-war-plugin-2.1.1-NM.patch
>
>
> The Maven War Plugin currently permits choosing what files will wind up in
> the .war. It does this via two parameters, warSourceIncludes, and
> warSourceExcludes. The rule appears to be that the includes are computed,
> and a list of matches made, then that list is run against the excludes, and
> any matches taken out of the include list.
> The only wildcards that appear to be supported are *, **, and ?.
> That doesn't work well if you are packaging wars in ears, and therefore want
> to exclude all jars from the war, except for one or two that have to be in
> the war in order to run properly. "Exclude all but foo.jar and bar.jar" just
> doesn't translate well to "here's your simple include template, here's your
> simple exclude template" representation, at least with current wildcards.
> So this is a wish specifically for something to address the "exclude all but
> x, y, and z" need for war source includes/excludes, and a suggestion that it
> might be best to deprecate the warSourceIncludes/warSourceExcludes approach
> in favor of a single parameter that supports regular expressions instead.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2903) Snapshots are being packaged with datestamps in their filename instead of "SNAPSHOT",
[ https://jira.codehaus.org/browse/MNG-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284060#comment-284060 ] Joerg Schaible commented on MNG-2903: - The difference is based on the fact, how the snapshot artifact was added to your local repository. If it was downloaded from a remote repository, you get the time stamped version, if it was installed locally, you get the snapshot. And yes - this behavior is very annoying, because it actually breaks applications. > Snapshots are being packaged with datestamps in their filename instead of > "SNAPSHOT", > -- > > Key: MNG-2903 > URL: https://jira.codehaus.org/browse/MNG-2903 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Tim Cederman >Priority: Critical > Fix For: Issues to be reviewed for 3.x > > > When I run mvn package on a project, it collects all the correct and most > recent > jar files for me in the lib directory, however in the zip file instead > of naming them -3.0-SNAPSHOT.jar (for example) it will name > them -20070318.080720-37.jar. > Meanwhile in the project's own jar file, the manifest will point to > ./lib/-3.0-SNAPSHOT.jar. This means the packaged project does > not run. > It doesn't do this for every single dependency snapshot, and I can't > seem to work out a pattern as to which get named correctly and which > don't. > I have two repositories in my pom file: > > > common-repository >Common Repository > http://repository/common-repository > > > snapshot-repository > Trovix Snapshot Repository > http://repository/snapshots > > true > always > > > > If I try to disable them manually (and use only the local repository), > the problem persists. However, this is where it gets weird. If I > unplug my network cable - my package file is created perfectly! > However - if I unplug my network cable with the snapshot repository > removed, it creates the package incorrectly once again! > This seems to be the key part of what is making it work (blacklisting > the snapshot-repository): > [INFO]task-segment: [package] > [INFO] > - > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] snapshot com:com.benchmark:3.0-SNAPSHOT: checking for updates > from snapshot-repository > [WARNING] repository metadata for: 'snapshot > com:com.benchmark:3.0-SNAPSHOT' could not be retrieved from repository: > snapshot-repository due to an error: Error transferring file > [INFO] Repository 'snapshot-repository' will be blacklisted > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] No sources to compile > [INFO] [surefire:test] > [INFO] No tests to run. > [INFO] [jar:jar] > I have also run mvn -X package, and the debug log shows that it thinks > it is collecting all the correct SNAPSHOT named jars, even though it > then stores the date-stamped ones. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5207) [Regression] Maven 3 fails to calculate proper build order
[Regression] Maven 3 fails to calculate proper build order -- Key: MNG-5207 URL: https://jira.codehaus.org/browse/MNG-5207 Project: Maven 2 & 3 Issue Type: Bug Components: Reactor and workspace Affects Versions: 3.0.3 Reporter: Joerg Schaible Priority: Critical Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in proper order, if a transitive dependency (that is part of the reactor build) is overruled in the dependencyManagement section with the current SNAPSHOT version. Build order is perfectly calculated with Maven 2.2.1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5207) [Regression] Maven 3 fails to calculate proper build order
[ https://jira.codehaus.org/browse/MNG-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated MNG-5207: Attachment: MNG-5207.tgz Attachment contains demo project. First run script _prepare.sh_ in directory _prepare_ to populate local repo with necessary stuff (anything uses groupId _bugs.maven.issue_). _application_ artifact uses released version of _delegate_ artifact that depends on a ejb-client dependency which is overruled in the depMgmt section as snapshot (EJB uses updated runtime dependency to be added in the manifest's classpath). Build from root with M303 (or M304rc1) ==> build fails with missing dependency in _application_. Build from root with M221 ==> build starts with building _ejb_ component first and succeeds. > [Regression] Maven 3 fails to calculate proper build order > -- > > Key: MNG-5207 > URL: https://jira.codehaus.org/browse/MNG-5207 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 3.0.3 >Reporter: Joerg Schaible >Priority: Critical > Attachments: MNG-5207.tgz > > > Maven 3.0.3 and 3.0.4 RC1 fails to build the projects of the reactor in > proper order, if a transitive dependency (that is part of the reactor build) > is overruled in the dependencyManagement section with the current SNAPSHOT > version. Build order is perfectly calculated with Maven 2.2.1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2363) does not work in a multi-project build
[
https://jira.codehaus.org/browse/MNG-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285046#comment-285046
]
Joerg Schaible commented on MNG-2363:
-
Works for inherited profiles in Maven 3 only.
> does not work in a multi-project build
> ---
>
> Key: MNG-2363
> URL: https://jira.codehaus.org/browse/MNG-2363
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Profiles
>Reporter: David Boden
>Assignee: Benjamin Bentmann
>Priority: Critical
> Fix For: 3.0-alpha-3
>
> Attachments: DefaultMavenProjectBuilder.java,
> DefaultMavenProjectBuilder.java, DefaultMavenProjectBuilder.java.diff,
> problemactivation.zip, screenshot-1.jpg
>
>
> I would expect each subproject to have the profile turned on or off depending
> on whether ${basedir}/file-to-check-for exists.
> Instead, during a multi-project build the profile is either on or off
> depending on whether the file exists relative to the *aggregator pom*. The
> decision is made once.
> Variable substitution doesn't work, so I can't explicitly use
> ${basedir}/file-to-check-for or any variation on this theme
> to workaround the bug.
> Some background to my particular problem. I have 10 modules to build. Some of
> them are GUI modules and contain a file called plugin.xml in the subproject
> directory. I want to package these up specially and sign them, ready for
> deployment to webstart. The other modules are shared and server code and I
> don't want these packaged in the same way. So, I've got a dependency in my
> *parent* pom file which activates a profile called "guibundle" if a
> plugin.xml file exists in the subproject directory.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-267) Maven WAR plugin does not copy dependencies of type "bundle" into WEB-INF/lib
[
https://jira.codehaus.org/browse/MWAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289244#comment-289244
]
Joerg Schaible commented on MWAR-267:
-
Actually this complete list of types is nonsense! Every Maven plugin has an
extension flag that enables custom artifact types to be respected (defined in a
META-INF/plexus/components.xml). The WAR plugin should simply respect any
artifact on the classpath required for runtime. I cannot see any reason for the
WAR plugin to behave different.
> Maven WAR plugin does not copy dependencies of type "bundle" into WEB-INF/lib
> -
>
> Key: MWAR-267
> URL: https://jira.codehaus.org/browse/MWAR-267
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Any
>Reporter: Thomas Vandahl
>
> A WAR project has transitive dependencies of type "bundle" (mina-core, ...).
> These dependencies do not end up in the WAR file structure under WEB-INF/lib
> as they are supposed to.
> My guess would be the method ArtifactsPackagingTask.performPackaging(), where
> only known types of dependencies are handled, AFAICS. Could the type "bundle"
> be added there? Like:
> {code}
> else if ( "jar".equals( type ) || "ejb".equals( type ) ||
> "ejb-client".equals( type )
> || "test-jar".equals( type ) || "bundle".equals( type ))
> {
> copyFile( id, context, artifact.getFile(), LIB_PATH + targetFileName );
> }
> {code}
--
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] (MWAR-257) dependentWarExcludes is deprecated but
[ https://jira.codehaus.org/browse/MWAR-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289245#comment-289245 ] Joerg Schaible commented on MWAR-257: - The deprecation should be simply reverted. Even the plugin overlay documentation (http://maven.apache.org/plugins/maven-war-plugin/overlays.html) explicitly refers dependentWarExcludes and dependentWarIncludes as *the only* possibility to make global settings in a plugin management section that is inherited in multiple projects. There is no equivalent possible with overlays/overlay/excludes or overlays/overlay/includes and actually it is also not necessary to introduce something else for a mechanism that is working properly. > dependentWarExcludes is deprecated but > --- > > Key: MWAR-257 > URL: https://jira.codehaus.org/browse/MWAR-257 > Project: Maven 2.x WAR Plugin > Issue Type: Bug > Components: overlay >Affects Versions: 2.1.1 >Reporter: dool > > Hello, > DependentWarExcludes is marked as deprecated. Documentation says to use > / instead. > But it seems to me that it is not possible to get the same behaviour with > / as in this case we have to provide groupIds and > artifactIds. > Maybe this behaviour could be reproduced when setting both groupId and > artifactId to * as below : > > > > * > * > **/* > > > > > By the way, I found this, by looking for a way to disable overlay. The > workaround I thought was configuring your plugin to exclude every files when > overlaying. > I think it would be nice to have a configuration parameter for that. > Many thanks, > Dool -- 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] (MNG-5235) Profiles not activated according to property values
[ https://jira.codehaus.org/browse/MNG-5235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290303#comment-290303 ] Joerg Schaible commented on MNG-5235: - This is by design. Properties are explicitly not mentioned in [How can a profile be triggered? How does this vary according to the type of profile being used?|http://maven.apache.org/guides/introduction/introduction-to-profiles.html]. Profiles are the first thing evaluated *before* anything else to determine the effective POM. > Profiles not activated according to property values > --- > > Key: MNG-5235 > URL: https://jira.codehaus.org/browse/MNG-5235 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0.3 > Environment: Windows 7 >Reporter: Jérôme Verstrynge > Attachments: pom.xml > > > I am trying to activate profiles according to properties defined in the > pom.xml. Unfortunately, the profiles are never activated, no matter what > value is set for the defined property. I double-checked my pom.xml with > existing documentation. > The attached example contains two profiles who echo the property value. These > are never displayed in the output. However, documentation says a profile > should be invoked if the activation section property values are met. > There is also something unclear in the existing documentation. Is it possible > to enable multiple profiles with properties in a single run or is only one > profile selected at most in a single run? > -- 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] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MSITE-604:
-
Attachment: MSITE-604.tgz
We face the same problems. In our case we deploy the site documentation to our
intranet and depending on the environment the base URL is a file protocol with
different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project demonstrates the effect. Since our property contains
the protocol, we get this "{{Wagon protocol '' doesn't support directory
copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
mvn -s settings.xml clean package site site:deploy
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290463#comment-290463
]
Joerg Schaible edited comment on MSITE-604 at 2/1/12 5:23 AM:
--
We face the same problems. In our case we deploy the site documentation to our
intranet and depending on the environment the base URL is a file protocol with
different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project MSITE-604.tgz demonstrates the effect. Since our
property contains the protocol, we get this "{{Wagon protocol '' doesn't
support directory copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
{noformat}
mvn -s settings.xml clean package site site:deploy
{noformat}
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
I've also linked this issue to MSITE-617, MSITE-585 and MSITE-501 that seem to
be related.
was (Author: joehni):
We face the same problems. In our case we deploy the site documentation to
our intranet and depending on the environment the base URL is a file protocol
with different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project MSITE-604.tgz demonstrates the effect. Since our
property contains the protocol, we get this "{{Wagon protocol '' doesn't
support directory copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
{noformat}
mvn -s settings.xml clean package site site:deploy
{noformat}
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
I've also linked this issue to MNG-617, MNG-585 and MNG-501 that seem to be
related.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290463#comment-290463
]
Joerg Schaible edited comment on MSITE-604 at 2/1/12 5:23 AM:
--
We face the same problems. In our case we deploy the site documentation to our
intranet and depending on the environment the base URL is a file protocol with
different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project MSITE-604.tgz demonstrates the effect. Since our
property contains the protocol, we get this "{{Wagon protocol '' doesn't
support directory copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
{noformat}
mvn -s settings.xml clean package site site:deploy
{noformat}
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
I've also linked this issue to MNG-617, MNG-585 and MNG-501 that seem to be
related.
was (Author: joehni):
We face the same problems. In our case we deploy the site documentation to
our intranet and depending on the environment the base URL is a file protocol
with different paths or scpexe. Therefore we have to use a property from
settings.xml.
The attached test project demonstrates the effect. Since our property contains
the protocol, we get this "{{Wagon protocol '' doesn't support directory
copying}}" error.
However, it seems that the usage of a parent located in the repository is part
of the problem.
You may test the project with the call
mvn -s settings.xml clean package site site:deploy
Have a look at the README.txt for simple preparation and alternate calls to
select the site-plugin version from command-line.
M3 fails with site-plugin 3.0, but succeeds with 3.0-beta-3 and will generate
no HTMLs for site-plugin version 2.x. M221 fails with site-plugin versions 3.0
and 2.3.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: 3.1
>
> Attachments: MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
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] (MNG-5237) Cannot download maven dependencies through proxy
[ https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290696#comment-290696 ] Joerg Schaible commented on MNG-5237: - Take a closer look at the URLs. Maven central has been moved and M304 default settings use the new location directly. Possibly you have to update your firewall rules. > Cannot download maven dependencies through proxy > > > Key: MNG-5237 > URL: https://jira.codehaus.org/browse/MNG-5237 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: windows xp64 using cygwin >Reporter: Niels Mordt-Ostergaard > > Using proxy in settings.xml, I was able to download maven dependencies in > 3.0.3, but this seems to be broken with 3.0.4: > Proxy definition in settings.xml (hidden ip adress below, but correct proxy > ip on my system): > > > optional > true > http > > > xxx.xx.xx.xx > 8080 > localhost|127.0.0.1 > > > Output from 3.0.3: > $ mvn -V clean > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: C:\Program Files\apache-maven-3.0.3 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > Downloaded: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > (5 KB at 4.9 KB/sec) > . and so on... > Output from 3.0.4: > $ mvn -V clean > Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) > Maven home: C:\Program Files\apache-maven-3.0.4 > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: no_NO, platform encoding: Cp1252 > OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows" > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building > [INFO] > > Downloading: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 0.390s > [INFO] Finished at: Fri Feb 03 13:14:35 CET 2012 > [INFO] Final Memory: 5M/490M > [INFO] > > [ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of > its dependencies could not be resolved: Failed to read artifact descriptor > for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer > artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to > central (http://repo.maven.apache.org/maven2): Access denied to: > http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom, > ReasonPhrase:Forbidden. -> [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 errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException -- 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-735) Profile activation working unpredictably
[
https://jira.codehaus.org/browse/MRELEASE-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290995#comment-290995
]
Joerg Schaible commented on MRELEASE-735:
-
You should definitely also document the Maven version in use, since
activationByFile is behaving differently between M3 and M221.
> Profile activation working unpredictably
>
>
> Key: MRELEASE-735
> URL: https://jira.codehaus.org/browse/MRELEASE-735
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.2.2
>Reporter: Thorsten Koch
> Attachments: parent.zip
>
>
> In an attempt to work around issue
> http://jira.codehaus.org/browse/MASSEMBLY-457 I tried to use the following
> profiles to set a property depending of the existens of a certain directory
> in my multimodule build:
>
>
> runAssembly
>
>
> src/main/sql
>
>
>
> false
>
>
>
> dontRunAssembly
>
>
> src/main/sql
>
>
>
> true
>
>
>
> This is working well in normal builds. I can use the ${skipAssembly} property
> to switch on and of the assembly plugin depending of the directory existence
> in my modules.
> However, in the build run by the release:perform goal, this does not work. In
> this case always the second profile from the above is activated, regardless
> if the directory exists or not.
> But I found out (after a lot of tries), that it DOES work if the order of the
> profiles above is just changed. So when I write it like this
>
>
> dontRunAssembly
>
>
> src/main/sql
>
>
>
> true
>
>
>
> runAssembly
>
>
> src/main/sql
>
>
>
> false
>
>
>
> THEN it's working even in release:perform builds. I have no idea what the
> triggering change is, but it seems worth creating an issue.
--
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-346) maven-dependency-plugin violates artifact dependencies, causing unstable incremental builds
[
https://jira.codehaus.org/browse/MDEP-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293149#comment-293149
]
Joerg Schaible commented on MDEP-346:
-
It's easy: Use copy-dependencies (resp. unpack-dependencies) if you rely on
artifacts created within the same multi-project. Goals copy/unpack are only for
released artifacts that can be resolved from a repository.
> maven-dependency-plugin violates artifact dependencies, causing unstable
> incremental builds
> ---
>
> Key: MDEP-346
> URL: https://jira.codehaus.org/browse/MDEP-346
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies, unpack, unpack-dependencies
>Affects Versions: 2.4
> Environment: Tested on Ubuntu Linux 10.10 (Maverick) with maven 3.0.4
>Reporter: Scott Glajch
>
> If you tell the dependency plugin to unpack or copy a dependency, you are for
> some reason allowed to specify and artifact that's not in the project's
> dependency listing, whether it be transitively or specifically called out in
> the pom file.
> What this then means is that your project can depend an another module (since
> the dependency plugin will use it), but as far as maven knows, it is not a
> dependency of the project. Therefore the reactor will not consider it when
> ordering modules on a build, as well as ignore it when running incremental
> builds (such as the -amd flag).
> In our case we have a very large project (200+ modules) that we build
> incrementally, with help from the "incremental build" option in jenkins.
> This will determine which projects need building by looking at the recent
> changes in source control, thus building a list of projects to build. It
> passes those projects into maven using the project list option (i.e. -pl
> groupId1:artifactId1,groupId2:artifactId2). It also passes the -amd flag to
> then build all the modules that those projects depend on.
> I have provided a very simple test case to show the problem. There is a
> toplevel project named "maven-toplevel-test", and 3 sub-modules named
> component1, component2, and component3.
> Component1 depends on component3 the normal way, as an explicit dependency,
> and you can see that maven knows about this because when you run, from the
> toplevel, "mvn clean install -pl :component3 -amd", maven will correctly
> build component3 and any component that depends on it, which will be
> component1.
> Component1 also depends on component2, though not explicity, but instead by
> running the "copy" goal of the maven-dependency-plugin and specifying
> component2 there. If you try run "mvn clean install -pl :component2 -amd",
> you'll see that only component2 gets built, because maven doesn't know enough
> to dig into the plugin configuration for component1 and see that component2
> should be a dependency.
> Now there is another similar bug open (since 2008), but that has a very
> different focus. http://jira.codehaus.org/browse/MDEP-153
> You'll see in that bug it is trying to somehow fix the maven reactor to dig
> into these plugin configurations and inject dependencies.
> I argue for a much different solution. I think that the
> maven-dependency-plugin shouldn't let you specify an artifact that isn't
> already a dependency of your project, or at the very least, have a flag
> ("strict mode" or something?) that requires all of the artifacts you are
> trying to copy/unpack to be dependencies of your project.
> The obvious fix for our project for now is to go through all of the poms that
> use maven-dependency-plugin, figure out which artifacts are being manipulated
> and add them as dependencies to the projects, but this solution makes it hard
> to future-proof our projects from further mistakes. Who's to say that
> developers won't just keep adding new copy/unpack goals to their projects and
> not add those dependencies to the pom file? After all it won't break the
> build so the problem will only manifest itself as an unstable incremental
> build further down the line.
--
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-346) maven-dependency-plugin violates artifact dependencies, causing unstable incremental builds
[
https://jira.codehaus.org/browse/MDEP-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293154#comment-293154
]
Joerg Schaible commented on MDEP-346:
-
But this *is* the whole point: With copy/unpack you don't have to declare the
artifacts as project dependencies. This is why these goals are duplicated with
the "-dependencies" postfix.
> maven-dependency-plugin violates artifact dependencies, causing unstable
> incremental builds
> ---
>
> Key: MDEP-346
> URL: https://jira.codehaus.org/browse/MDEP-346
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, copy-dependencies, unpack, unpack-dependencies
>Affects Versions: 2.4
> Environment: Tested on Ubuntu Linux 10.10 (Maverick) with maven 3.0.4
>Reporter: Scott Glajch
>
> If you tell the dependency plugin to unpack or copy a dependency, you are for
> some reason allowed to specify and artifact that's not in the project's
> dependency listing, whether it be transitively or specifically called out in
> the pom file.
> What this then means is that your project can depend an another module (since
> the dependency plugin will use it), but as far as maven knows, it is not a
> dependency of the project. Therefore the reactor will not consider it when
> ordering modules on a build, as well as ignore it when running incremental
> builds (such as the -amd flag).
> In our case we have a very large project (200+ modules) that we build
> incrementally, with help from the "incremental build" option in jenkins.
> This will determine which projects need building by looking at the recent
> changes in source control, thus building a list of projects to build. It
> passes those projects into maven using the project list option (i.e. -pl
> groupId1:artifactId1,groupId2:artifactId2). It also passes the -amd flag to
> then build all the modules that those projects depend on.
> I have provided a very simple test case to show the problem. There is a
> toplevel project named "maven-toplevel-test", and 3 sub-modules named
> component1, component2, and component3.
> Component1 depends on component3 the normal way, as an explicit dependency,
> and you can see that maven knows about this because when you run, from the
> toplevel, "mvn clean install -pl :component3 -amd", maven will correctly
> build component3 and any component that depends on it, which will be
> component1.
> Component1 also depends on component2, though not explicity, but instead by
> running the "copy" goal of the maven-dependency-plugin and specifying
> component2 there. If you try run "mvn clean install -pl :component2 -amd",
> you'll see that only component2 gets built, because maven doesn't know enough
> to dig into the plugin configuration for component1 and see that component2
> should be a dependency.
> Now there is another similar bug open (since 2008), but that has a very
> different focus. http://jira.codehaus.org/browse/MDEP-153
> You'll see in that bug it is trying to somehow fix the maven reactor to dig
> into these plugin configurations and inject dependencies.
> I argue for a much different solution. I think that the
> maven-dependency-plugin shouldn't let you specify an artifact that isn't
> already a dependency of your project, or at the very least, have a flag
> ("strict mode" or something?) that requires all of the artifacts you are
> trying to copy/unpack to be dependencies of your project.
> The obvious fix for our project for now is to go through all of the poms that
> use maven-dependency-plugin, figure out which artifacts are being manipulated
> and add them as dependencies to the projects, but this solution makes it hard
> to future-proof our projects from further mistakes. Who's to say that
> developers won't just keep adding new copy/unpack goals to their projects and
> not add those dependencies to the pom file? After all it won't break the
> build so the problem will only manifest itself as an unstable incremental
> build further down the line.
--
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] (MNG-5178) Substitute environment variable M2_HOME by M3_HOME
[
https://jira.codehaus.org/browse/MNG-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293671#comment-293671
]
Joerg Schaible commented on MNG-5178:
-
And why do you set the env variable at all?
> Substitute environment variable M2_HOME by M3_HOME
> --
>
> Key: MNG-5178
> URL: https://jira.codehaus.org/browse/MNG-5178
> Project: Maven 2 & 3
> Issue Type: Wish
> Components: Command Line
>Reporter: Oliver B. Fischer
>Priority: Minor
>
> Maven 3 uses the environment variable {{M2_HOME}} to point to it's
> installation directory. This variable should be replaced by {{M3_HOME}} to
> allow users to have parallel installations of Maven 2 and Maven 3 without any
> special handling of the environment variable {{M2_HOME}}.
--
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-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294081#comment-294081 ] Joerg Schaible commented on MRELEASE-749: - ?? This is exactly how it should work. A release is a release it does not matter if it was created from a branch or not. > release:prepare copies contents of source of Subversion branch into release > tag > --- > > Key: MRELEASE-749 > URL: https://jira.codehaus.org/browse/MRELEASE-749 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.2 > Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x >Reporter: Bindul Bhowmik > > When releasing from a branch, release:prepare copies the content of the > source of the branch into the release tag rather than the content of the > branch -- 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-749) release:prepare copies contents of source of Subversion branch into release tag
[ https://jira.codehaus.org/browse/MRELEASE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=294090#comment-294090 ] Joerg Schaible commented on MRELEASE-749: - How did you create the branch? When you do this manually, did you realize, that you have to adjust the SCM URLs in the POM? > release:prepare copies contents of source of Subversion branch into release > tag > --- > > Key: MRELEASE-749 > URL: https://jira.codehaus.org/browse/MRELEASE-749 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.2 > Environment: Windows 7; Silk Subversion 1.6x client; SVN 1.6x >Reporter: Bindul Bhowmik > > When releasing from a branch, release:prepare copies the content of the > source of the branch into the release tag rather than the content of the > branch -- 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: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ http://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234744#action_234744 ] Joerg Schaible commented on MRELEASE-594: - Such a functionality must be activated via configuration only. In an enviornment using a parent POM for an organization it is *normal* to have some deps in the depMgmt set to SNAPSHOT. This is totally fine as long as they are not used for a release. A strict requirement for all of them to be non-SNAPSHOTs would break our Maven process completely. > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: http://jira.codehaus.org/browse/MRELEASE-594 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: thomas bruyelle >Assignee: Olivier Lamy > Fix For: 2.1 > > -- 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] Commented: (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ http://jira.codehaus.org/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234770#action_234770 ] Joerg Schaible commented on MRELEASE-594: - @Thomas: Yes, it has to. The parent is an artifact on its own defining the versions for any shared artifact (external and internal ones) in the organization. It is in the responsibility of the project to ensure that any of those shared artifacts is released before the project's own release. If not, the required shared artifacts have to be released first, the depMgmt version of the global POM is updated and released also. @Olivier: Yes, the release of the child will fail, but only if it depends on a SNAPSHOT. See, in an organizational POM you manage different components that may or may not be used together. Typically one 3rd of all our internal artifacts (~250) stay on SNAPSHOT for minor releases of individual components or projects. It would be a QA nightmare forcing a release for all of them and would make the release plugin completely unusable for us. And I am quite sure that this *is* normal for an organizational POM. > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: http://jira.codehaus.org/browse/MRELEASE-594 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Thomas Bruyelle >Assignee: Olivier Lamy > Fix For: 2.1 > > -- 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: (MNG-4834) Site descriptor of parent is no longer found in local repository
Site descriptor of parent is no longer found in local repository Key: MNG-4834 URL: http://jira.codehaus.org/browse/MNG-4834 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0-beta-3 Environment: $ mvn -v Apache Maven 3.0-RC2 (r1000119; 2010-09-22 20:23:26+0200) Java version: 1.6.0_21 Java home: /opt/sun-jdk-1.6.0.21/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.34-gentoo-r6" arch: "i386" Family: "unix" Reporter: Joerg Schaible Priority: Minor Attachments: MNG-settings.xml The site descriptor from the parent project is no longer found in the local repository. The site plugin tries always to resolve the artifact from the remote repository using the attach-descriptor goal. This is nasty if that repo is not reachable and Maven will wait always until the connection times out before continuing. With M2 this descriptor is found in the local repo: "Parent project loaded from repository.". In both cases version 2.1.1 of the site plugin is used. There's no change in behavior for M3 if the site plugin is upgraded to 3.x. -- 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] Updated: (MNG-4834) Site descriptor of parent is no longer found in local repository
[ http://jira.codehaus.org/browse/MNG-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated MNG-4834: Attachment: MNG-4834-remote-repo.tgz The remote repository with the parent pom. Referenced in the settings with file:/tmp/repo. > Site descriptor of parent is no longer found in local repository > > > Key: MNG-4834 > URL: http://jira.codehaus.org/browse/MNG-4834 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-3 > Environment: $ mvn -v > Apache Maven 3.0-RC2 (r1000119; 2010-09-22 20:23:26+0200) > Java version: 1.6.0_21 > Java home: /opt/sun-jdk-1.6.0.21/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.34-gentoo-r6" arch: "i386" Family: "unix" >Reporter: Joerg Schaible >Priority: Minor > Attachments: MNG-4834-remote-repo.tgz, MNG-settings.xml > > > The site descriptor from the parent project is no longer found in the local > repository. The site plugin tries always to resolve the artifact from the > remote repository using the attach-descriptor goal. This is nasty if that > repo is not reachable and Maven will wait always until the connection times > out before continuing. With M2 this descriptor is found in the local repo: > "Parent project loaded from repository.". In both cases version 2.1.1 of the > site plugin is used. There's no change in behavior for M3 if the site plugin > is upgraded to 3.x. -- 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] Updated: (MNG-4834) Site descriptor of parent is no longer found in local repository
[
http://jira.codehaus.org/browse/MNG-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MNG-4834:
Attachment: MNG-4834.tgz
Archive with the projects for the parent pom and the main artifact. Calling
{noformat}mvn-3.0 -s MNG-settings.xml clean install{noformat}
demonstrates the download attempt, while
{noformat}mvn-2.2 -s MNG-settings.xml clean install{noformat}
grabs the site descriptor from the local repo.
> Site descriptor of parent is no longer found in local repository
>
>
> Key: MNG-4834
> URL: http://jira.codehaus.org/browse/MNG-4834
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0-beta-3
> Environment: $ mvn -v
> Apache Maven 3.0-RC2 (r1000119; 2010-09-22 20:23:26+0200)
> Java version: 1.6.0_21
> Java home: /opt/sun-jdk-1.6.0.21/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.34-gentoo-r6" arch: "i386" Family: "unix"
>Reporter: Joerg Schaible
>Priority: Minor
> Attachments: MNG-4834-remote-repo.tgz, MNG-4834.tgz, MNG-settings.xml
>
>
> The site descriptor from the parent project is no longer found in the local
> repository. The site plugin tries always to resolve the artifact from the
> remote repository using the attach-descriptor goal. This is nasty if that
> repo is not reachable and Maven will wait always until the connection times
> out before continuing. With M2 this descriptor is found in the local repo:
> "Parent project loaded from repository.". In both cases version 2.1.1 of the
> site plugin is used. There's no change in behavior for M3 if the site plugin
> is upgraded to 3.x.
--
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] Reopened: (MNG-4834) Site descriptor of parent is no longer found in local repository
[ http://jira.codehaus.org/browse/MNG-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible reopened MNG-4834: - No, you may not install the parent pom locally. Then it's always found. Therefore I've provided the "remote" repo as archive. > Site descriptor of parent is no longer found in local repository > > > Key: MNG-4834 > URL: http://jira.codehaus.org/browse/MNG-4834 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-3 > Environment: $ mvn -v > Apache Maven 3.0-RC2 (r1000119; 2010-09-22 20:23:26+0200) > Java version: 1.6.0_21 > Java home: /opt/sun-jdk-1.6.0.21/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.34-gentoo-r6" arch: "i386" Family: "unix" >Reporter: Joerg Schaible >Assignee: Benjamin Bentmann >Priority: Minor > Attachments: MNG-4834-remote-repo.tgz, MNG-4834.tgz, MNG-settings.xml > > > The site descriptor from the parent project is no longer found in the local > repository. The site plugin tries always to resolve the artifact from the > remote repository using the attach-descriptor goal. This is nasty if that > repo is not reachable and Maven will wait always until the connection times > out before continuing. With M2 this descriptor is found in the local repo: > "Parent project loaded from repository.". In both cases version 2.1.1 of the > site plugin is used. There's no change in behavior for M3 if the site plugin > is upgraded to 3.x. -- 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] Commented: (MNG-4834) [regression] MavenProject.getParent() ignores configured repositories
[ http://jira.codehaus.org/browse/MNG-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236459#action_236459 ] Joerg Schaible commented on MNG-4834: - OK, thanks for looking into it. > [regression] MavenProject.getParent() ignores configured repositories > - > > Key: MNG-4834 > URL: http://jira.codehaus.org/browse/MNG-4834 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-3 > Environment: $ mvn -v > Apache Maven 3.0-RC2 (r1000119; 2010-09-22 20:23:26+0200) > Java version: 1.6.0_21 > Java home: /opt/sun-jdk-1.6.0.21/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.34-gentoo-r6" arch: "i386" Family: "unix" >Reporter: Joerg Schaible >Assignee: Benjamin Bentmann >Priority: Minor > Fix For: 3.0 > > Attachments: MNG-4834-remote-repo.tgz, MNG-4834.tgz, MNG-settings.xml > > > The site descriptor from the parent project is no longer found in the local > repository. The site plugin tries always to resolve the artifact from the > remote repository using the attach-descriptor goal. This is nasty if that > repo is not reachable and Maven will wait always until the connection times > out before continuing. With M2 this descriptor is found in the local repo: > "Parent project loaded from repository.". In both cases version 2.1.1 of the > site plugin is used. There's no change in behavior for M3 if the site plugin > is upgraded to 3.x. -- 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] Commented: (MEV-667) plexus-utils-1.0.4.pom contains no valid XML
[
http://jira.codehaus.org/browse/MEV-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240301#action_240301
]
Joerg Schaible commented on MEV-667:
It's a simple replace "s/ø/o/" in Tryvge's last name.
> plexus-utils-1.0.4.pom contains no valid XML
>
>
> Key: MEV-667
> URL: http://jira.codehaus.org/browse/MEV-667
> Project: Maven Evangelism
> Issue Type: Bug
> Components: Invalid POM
>Reporter: Joerg Schaible
>Assignee: Juven Xu
>
> plexus-utils-1.0.4.pom contains an 'ø' in Tryvge's last name. However,
> the file declares no XML header and therefore a conforming XML parser handles
> the file as UTF-8. Unfortunately this character imples an ISO-8859-1
> encoding. This character is the reason why quite all the Apache commons
> builds of the last years fail with strange errors, if build with IBM JDK 1.4
> or 1.5. Building with jamvm 1.5.4 revealed now at least for me the reason:
> {noformat}
> [WARNING] POM for 'org.codehaus.plexus:plexus-utils:pom:1.0.4:runtime' is
> invalid. It will be ignored for
> artifact resolution. Reason: Parse error reading POM. Reason: TEXT must be
> immediately followed by END_TAG
> and not START_TAG (position: START_TAG seen ...Trygve
> Laugst\ufffdname>\n ... @116:14)
> for project org.codehaus.plexus:plexus-utils at
> /home/joehni/.m2/repository/org/codehaus/plexus/plexus-
> utils/1.0.4/plexus-utils-1.0.4.pom
> {noformat}
> So either add an XML header with correct encoding or fix the file encoding.
--
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] Commented: (MNG-2172) 's are not used when evaluating
[ http://jira.codehaus.org/browse/MNG-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241977#action_241977 ] Joerg Schaible commented on MNG-2172: - You silently imply that dependency management is only applied for the explicitly declared dependencies of a plugin. Applying it for all dependencies of a plugin would be desastrous and make very brittle builds, because an upgrade of a dependency of my project could break a plugin used in teh lifecycle. > 's are not used when evaluating > > - > > Key: MNG-2172 > URL: http://jira.codehaus.org/browse/MNG-2172 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Inheritance and Interpolation > Environment: 2.0.2-SNAPSHOT >Reporter: John Allen >Assignee: Jason van Zyl > > dep management is not honoured for plugins dep evaluation. > hm.. looks like inheritance, after investigating.. the > MavenMetaDataSource doesn't use the MavenProject.getDependencyManagement > jah.. found it. > NICE, estimate... 30 mins or 30 hrs? > 30 mins > the maven-project DefaultMavenProjectBuilder uses a different method > in the ArtifactResolved to resolve deps than the maven-core > DefaultPluginManager > but all the info is available.. -- 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] Commented: (MNG-4885) Why incremental build is not supported natively by Maven?
[
http://jira.codehaus.org/browse/MNG-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243119#action_243119
]
Joerg Schaible commented on MNG-4885:
-
It is more a problem of the plugins and the concept of plugins itself. The
Maven core has no idea about the processed files and the actual result. Some
plugins work implicitely incremental (compiler plugin using javac, because
javac works this way), others are more ignorant (xmlbeans plugin generates the
Java files *always*). So it seems better to create issues for the individual
plugins to be more "intelligent" at detecting changes. E.g. the jar plugin does
not have to run if the produced jar file is newer than anything that has to be
collected. In case of the surefire plugin it is not so easy: It might omit the
tests if all test reports are newer than anything in the classes or
test-classdes folder, but it has also to check that no dependency has been
updated ...
> Why incremental build is not supported natively by Maven?
> -
>
> Key: MNG-4885
> URL: http://jira.codehaus.org/browse/MNG-4885
> Project: Maven 2 & 3
> Issue Type: New Feature
>Reporter: Vincenzo Mancini
>
> I have a multi-module project with two sub-modules. I compile and package it
> without mistakes. The build is complete. Then I make a change in one
> {{.java}} file in one of them. And now I'm trying to package the whole
> project again. Maven re-runs tests in both two modules, static code analysis
> in both modules, etc.
> Why so? It's a very ineffective way of building, as far as I understand.
> Maybe maven can introduce a mechanism of "dependency discovery" between
> files. Like:
> {noformat}
> foo.jar depends on:
> abc.java
> cde.java
> bar.jar depends on:
> xxx.java
> {noformat}
> When there is a change in {{cde.java}} only - maven SHOULD NOT do anything
> with {{bar.jar}}. This is how Unix {{make}} utility is working... Thanks.
--
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] Commented: (MDEP-251) Artifacts qualifier are NOT taken into accounts correctly
[
http://jira.codehaus.org/browse/MDEP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243724#action_243724
]
Joerg Schaible commented on MDEP-251:
-
@Andreas Brieg: Maven is absolute correct. Different classifier (even "no
classifier") address distinct dependencies. What you do in your profile is
simply adding a second dependency and Maven behaves accordingly.
> Artifacts qualifier are NOT taken into accounts correctly
> -
>
> Key: MDEP-251
> URL: http://jira.codehaus.org/browse/MDEP-251
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: OSX 10.6.2, java 1.6.0_17
>Reporter: Jean Seurin
>Assignee: Brian Fox
>Priority: Critical
> Attachments: test.maven-dependency-plugin.zip
>
>
> I just introduced some qualifier for some libs that require to be compiled in
> java5.
> I've been very confused when realizing that when packaging a webapp depending
> on those qualified artifacts, the non qualified versions are included instead.
> It seems to come from dependency plugin.
> Here is what happens:
> When I do a dependency:tree on an artifact that depends directly on qualified
> libs, I get something regular:
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
> [INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
>
> [INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile
> The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.
> When I do a dependency:tree on an upper level webapp that depends on this
> stageof lib:
> [INFO] org.company.project:webapp:war:1.13-SNAPSHOT
> [INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
> [INFO] | +- org.company.commons:jar:1.4.0:compile
> [INFO] | \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
> [INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
> ...
> it finds correctly the qualified version of stageof, but include non
> qualified commons and commons-xml.
> These unqualified versions are the dependencies of the also non qualified
> stageof-1.4-SNAPSHOT.
> From this behavior, I presume dependency plugin makes a mistake in looking
> from the wrong pom, probably not using the qualifier of the included
> dependency:
>
> org.company.project
> stageof
> 1.4-SNAPSHOT
> compile
> jdk1.5
>
> Hope this is clear.
> I could provide an example if you can't reproduce easily.
> Actually, just adding a qualifier to the jar-plugin to produce the artifact
> and to the section should do the job.
> rgds,
> jean
--
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] Commented: (MPIR-212) src/main/java does not exist for non-jar project
[
http://jira.codehaus.org/browse/MPIR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247665#action_247665
]
Joerg Schaible commented on MPIR-212:
-
Same here for a cutsom plugin with an own packaging type (specialized ZIP file).
> src/main/java does not exist for non-jar project
>
>
> Key: MPIR-212
> URL: http://jira.codehaus.org/browse/MPIR-212
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: ubuntu linux maven 2.2.1
>Reporter: Francis De Brabandere
>Priority: Critical
>
> We have our own custom packaging that does not compile java code.
> Since the 2.3 plugin we get this issue while running "mvn clean install site":
> ...
> [INFO] [site:site {execution: default-site}]
> [INFO] Not executing cobertura:report as the cobertura data file
> (xxx/cobertura/cobertura.ser) could not be found
> [INFO] Parent project loaded from repository: xxx-parent:pom:8-SNAPSHOT
> [INFO] Skipped "Surefire Report" report, file "surefire-report.html" already
> exists for the English version.
> [INFO] Generating "Continuous Integration" report.
> [INFO] Generating "Project Summary" report.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: error while invoking generate
> basedir xxx/src/main/java does not exist
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
> generation
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
> generation
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:123)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> rendering Maven report: error while invoking generate
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:171)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:118)
> ... 19 more
> Caused by: org.apache.maven.reporting.MavenReportException: error while
> invoking generate
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.generateMultiPage(ReportDocumentRenderer.java:248)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:157)
> ... 23 more
> Caused by: java.lang.reflect.InvocationTargetExcep
[jira] Commented: (MJAVADOC-279) Javadoc plugin doesn't set dependencies correctly when pom uses classifiers
[
http://jira.codehaus.org/browse/MJAVADOC-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251054#action_251054
]
Joerg Schaible commented on MJAVADOC-279:
-
And it happens for M2 only (at least using site plugin 2.1.1), but not for M3
with site-plugin 3.0-beta-2.
> Javadoc plugin doesn't set dependencies correctly when pom uses classifiers
> ---
>
> Key: MJAVADOC-279
> URL: http://jira.codehaus.org/browse/MJAVADOC-279
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Maven 2.2.1, Windows XP
>Reporter: James Nichols
> Attachments: mazix-mvn-logs.zip, mazix.zip
>
>
> Create a project which has dependencies like:
> {code:xml}
>
> com.xxx
> mydep
> 1.3.1
> core
>
>
> com.xxx
> mydep
> 1.3.1
> util
>
> {code}
> This will add dependencies to the javadoc options file something like this:
> classpath
> 'C:/dev/target/classes;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar'
> where it should yield:
> classpath
> 'C:/dev/target/classes;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-util.jar'
> i.e. the classifier for the artifacts is being ignored. This causes various
> dependencies to be missing from the javadoc task which will eventually fail
> with:
> {noformat}java.lang.NullPointerException
> at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67)
> at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29)
> at
> com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:441)
> at
> com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:386)
> at
> com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:424)
> at
> com.sun.tools.doclets.internal.toolkit.util.ClassTree.processType(ClassTree.java:162)
> at
> com.sun.tools.doclets.internal.toolkit.util.ClassTree.buildTree(ClassTree.java:114)
> at
> com.sun.tools.doclets.internal.toolkit.util.ClassTree.(ClassTree.java:73)
> at
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:104)
> at
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64)
> at
> com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42)
> at com.sun.tools.doclets.standard.Standard.start(Standard.java:23)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215)
> at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91)
> at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340)
> at com.sun.tools.javadoc.Start.begin(Start.java:128)
> at com.sun.tools.javadoc.Main.execute(Main.java:41)
> at com.sun.tools.javadoc.Main.main(Main.java:31){noformat}
--
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] Commented: (MARCHETYPES-37) The POM of generated projects should have xml prolog/header specifying encoding
[ http://jira.codehaus.org/browse/MARCHETYPES-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251601#action_251601 ] Joerg Schaible commented on MARCHETYPES-37: --- The XML spec defines UTF-8 if the header is missing. > The POM of generated projects should have xml prolog/header specifying > encoding > --- > > Key: MARCHETYPES-37 > URL: http://jira.codehaus.org/browse/MARCHETYPES-37 > Project: Maven Archetype Bundles > Issue Type: Improvement > Components: Maven Archetype Archetype, Maven Plugin Archetype, Maven > Plugin Site Archetype, Maven Portlet Archetype, Maven Quickstart Archetype, > Maven Simple J2EE Archetype, Maven Simple Project Archetype, Maven Simple > Site Archetype, Maven Site Archetype, Maven Webapp Archetype > Environment: n/a >Reporter: Anders Hammar > Attachments: archetypes.patch > > > The POM generated by the archetypes should have an xml prolog/header > specifying encoding. For anyone using non-ascii chars this is important as it > will ensure that chars are handled correctly. > I've attached a patch for this. Changes are relative the top level archetypes > project trunk. -- 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: (MPIR-222) Error reported for ZipException caused by dependency of type pom
Error reported for ZipException caused by dependency of type pom
Key: MPIR-222
URL: http://jira.codehaus.org/browse/MPIR-222
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 2.3.1
Reporter: Joerg Schaible
Priority: Minor
For projects generating webapps based on overlays, we usually exclude anything
in web-INF/lib and manage the dependencies by declaring a dependency explicitly
to the pom:
{code:xml}
info.magnolia
magnolia-empty-webapp
war
runtime
info.magnolia
magnolia-empty-webapp
pom
...
{code}
This works perfectly, but generating the dependency report, we face everytime a
reported ERROR and stack race, since the report generation tries to open
obviously any dependency as ZIP/JAR file:
{noformat}
[INFO] [INFO] --- maven-site-plugin:3.0-beta-3:site (default-site) @
musikgalerie ---
[INFO] [INFO] configuring report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin:2.3.1
[INFO] [INFO] configuring report plugin
com.googlecode.maven-overview-plugin:maven-overview-plugin:1.6
[INFO] [INFO] configuring report plugin
org.apache.maven.plugins:maven-changes-plugin:2.4
[INFO] [INFO] Parent project loaded from repository.
[INFO] [INFO] Parent project loaded from repository.
[INFO] [INFO] Rendering site with
org.apache.maven.skins:maven-default-skin:jar:1.0 skin.
[INFO] [INFO] Generating "Dependencies" report---
maven-project-info-reports-plugin:2.3.1
[INFO] [ERROR] IOException: Failed to open file
/home/joehni/.m2/repository/info/magnolia/magnolia-empty-webapp/4.4.2/magnolia-empty-webapp-4.4.2.pom
: error in opening zip file
[INFO] java.util.zip.ZipException: Failed to open file
/home/joehni/.m2/repository/info/magnolia/magnolia-empty-webapp/4.4.2/magnolia-empty-webapp-4.4.2.pom
: error in opening zip file
[INFO] at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:109)
[INFO] at
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:273)
[INFO] at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1374)
[INFO] at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:544)
[INFO] at
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:271)
[INFO] at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
[INFO] at
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:206)
[INFO] at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
[INFO] at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:165)
[INFO] at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
[INFO] at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
[INFO] at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:159)
[INFO] at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
[INFO] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
[INFO] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[INFO] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[INFO] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
[INFO] at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
[INFO] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
[INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
[INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
[INFO] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
[INFO] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
[INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
[INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[INFO] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[INFO] at java.lang.reflect.Method.invoke(Method.java:613
[jira] Commented: (MPH-79) help:active-profiles does not list active inherited profiles
[
http://jira.codehaus.org/browse/MPH-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261234#action_261234
]
Joerg Schaible commented on MPH-79:
---
It is required to document the fact that the activation of the profile in the
parent is not inherited. If the parent contains a profile activation like:
{noformat}
demo
pom.xml
{noformat}
Then the "parent stuff" is active in the child. However, this has no influence
on a profile in the child with same id:
{noformat}
demo
{noformat}
The "child stuff" is not activated. help:active-profiles does currently not
list the active parent profiles, only the ones for settings.xml and the current
pom. Therefore help:active-profiles should not say simply "pom" as source, but
the GAV of the pom:
{noformat}
$ mvn help:active-profiles
Active Profiles for Project 'G:A:V':
The following profiles are active:
- demo (source: pom in G:A:V)
{noformat}
Note, that if the demo had been activated in settings.xml, the "child stuff"
would have been active.
> help:active-profiles does not list active inherited profiles
>
>
> Key: MPH-79
> URL: http://jira.codehaus.org/browse/MPH-79
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
> Windows (XP,2003,2008), Java 1.6
>Reporter: Xavier D.
>Priority: Minor
>
> The code fix for http://jira.codehaus.org/browse/MPH-16 appears to have been
> removed and the test now breaks.
> Refer to http://jira.codehaus.org/browse/MPH-16 for the Testcase zip file.
--
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] Commented: (MSHARED-191) Specification-Version must not contain "-SNAPSHOT"
[
http://jira.codehaus.org/browse/MSHARED-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261787#action_261787
]
Joerg Schaible commented on MSHARED-191:
At least there is a workaround:
http://article.gmane.org/gmane.comp.jakarta.commons.devel/113911
> Specification-Version must not contain "-SNAPSHOT"
> --
>
> Key: MSHARED-191
> URL: http://jira.codehaus.org/browse/MSHARED-191
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: maven-archiver-2.4.1
> Environment: Ubuntu 10.10, Maven 2.2.1 and Maven 3.0.3, OpenJDK
> Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1) (64 bits)
>Reporter: Romain Buquet
> Attachments: patch maven-archiver
>
>
> When building an artifact with a SNAPSHOT version,
> Specification-Version and Implementation-Version are both set to
> ${pom.version} (as described in the documentation).
> But this will break the deployment in a container like WebLogic Server 10.3.4.
> This behavior is compliant with specification
> http://download.oracle.com/javase/6/docs/technotes/guides/versioning/spec/versioning2.html#wp89939
> where it is said that "Specification version numbers use a Dewey decimal
> notation consisting of numbers seperated by periods"
> Further in this spec, in § "1.5.10 Rationale for limiting Implementation
> version numbers to identity", it is explained why Implementation-Version need
> to be compared strictly for equality.
> So we can understand that:
> - Specification-Version must NOT have "-SNAPSHOT" suffix. This is legal to
> keep only the beginning of ${pom.version}, because it represents the spec
> version, not the build ;
> - Implementation-Version has to be set to ${pom.version} to represent the
> exact version of the build.
> This used to be the behavior in Maven 1:
> http://maven.apache.org/maven-1.x/plugins/jar/manifest.html
--
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] Commented: (MSITE-579) SCM URLs Incorrect for Multi-Module Build Where Module Name != artifactId
[ http://jira.codehaus.org/browse/MSITE-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=263033#action_263033 ] Joerg Schaible commented on MSITE-579: -- @James, it has a long history (MNG-3244 and linked ones). @Lukas, this behavior is annoying. Without it, it would be so easy to use properties without the need to overwrite the SCM section everywhere. > SCM URLs Incorrect for Multi-Module Build Where Module Name != artifactId > - > > Key: MSITE-579 > URL: http://jira.codehaus.org/browse/MSITE-579 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: multi module, relative links >Affects Versions: 3.0-beta-3 >Reporter: James Carman >Assignee: Lukas Theussl > > I have a multi-module project: > https://wicketopia.svn.sourceforge.net/svnroot/wicketopia/trunk/ > In the main pom.xml file, I have: > > ... > example > > In my generated site, here: > http://wicketopia.sourceforge.net/wicketopia-example/source-repository.html > The SCM urls are all messed up. They have "wicketopia-example" rather than > just "example" in them. I do not set up SCM URLs in the submodules. I just > let it inherit stuff from the parent POM. Since we specify > example in the parent pom rather than > wicketopia-example, shouldn't it know that the SCM URLs > shouldn't have "wicketopia-example" in them? -- 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] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130835#comment-15130835
]
Joerg Schaible commented on MNG-5227:
-
I just reported MNG-1577, the patch was provided by [~ralphgoers] and
[~pschneider]. Personally I only cared about the version and scope management.
However, it looks wrong to me dropping the test scope and setting optional to
false should not matter for your changes. Do you have now a test case where you
set optional to true in the dependencyManagement section and set it explicitly
to false again in the dependencies?
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130839#comment-15130839
]
Joerg Schaible commented on MNG-5227:
-
Oh, well. And managing the scope is *essential*.
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130852#comment-15130852
]
Joerg Schaible commented on MNG-5227:
-
If your fix means that the dependencyManagement can no longer be used to manage
the scope, you break things. This functionality is used in the real world!
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130858#comment-15130858
]
Joerg Schaible commented on MNG-5227:
-
However, there's no need to drop the scope now. It has been part of the test
for long and it changing it now makes your changes only suspicious.
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
