[jira] Updated: (MCOMPILER-93) encoding/ not passed to the compiler.
[ http://jira.codehaus.org/browse/MCOMPILER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MCOMPILER-93: --- Attachment: MCOMPILER-93.zip The attached project works for me so I suspect a misconfiguration of the plugin. encoding/ not passed to the compiler. --- Key: MCOMPILER-93 URL: http://jira.codehaus.org/browse/MCOMPILER-93 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Reporter: benson margulies Attachments: MCOMPILER-93.zip My configuration include encodingutf-8/encoding -X shows no sign of it, and I get problems in compile that stem from not having it set. [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -- [DEBUG] (f) basedir = /home/benson/tip/rlp/utilities/source/java [DEBUG] (f) buildDirectory = /home/benson/tip/rlp/utilities/source/java/target [DEBUG] (f) classpathElements = [/home/benson/tip/rlp/utilities/source/java/target/classes] [DEBUG] (f) compileSourceRoots = [/home/benson/tip/rlp/utilities/source/java/src] [DEBUG] (f) compilerId = javac [DEBUG] (f) debug = true [DEBUG] (f) failOnError = true [DEBUG] (f) fork = false [DEBUG] (f) maxmem = 256M [DEBUG] (f) optimize = true [DEBUG] (f) outputDirectory = /home/benson/tip/rlp/utilities/source/java/target/classes [DEBUG] (f) outputFileName = utilities-7.0-SNAPSHOT [DEBUG] (f) projectArtifact = com.basistech:utilities:jar:7.0-SNAPSHOT [DEBUG] (f) showDeprecation = true [DEBUG] (f) showWarnings = true [DEBUG] (f) source = 1.5 [DEBUG] (f) staleMillis = 0 [DEBUG] (f) target = 1.5 [DEBUG] (f) verbose = false [DEBUG] -- end configuration -- -- 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-3951) Hide drive-relative paths from plugins
[ http://jira.codehaus.org/browse/MNG-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3951: --- Fix Version/s: 3.0-alpha-3 Merged to 3.x in [r739735|http://svn.eu.apache.org/viewvc?view=revrevision=739735]. Hide drive-relative paths from plugins -- Key: MNG-3951 URL: http://jira.codehaus.org/browse/MNG-3951 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0.9, 2.1.0-M1 Environment: Windows Reporter: Benjamin Bentmann Assignee: Benjamin Bentmann Priority: Minor Fix For: 2.0.11, 2.1.0-M2, 3.0-alpha-3 Attachments: MNG-3951.patch Take this nice path: /tmp (note the leading slash). This is an absolute path on Unix derivates but a drive-relative path on a Windows box. Drive-relative paths are resolved by prepending the drive of the current directory, not the entire current directory. This notation of a drive-relative path is not well-known, even among Windows users, and in particular not easy going for cross-platform Java tools. A Java developer usually assumes that a path is either (directory-)relative or absolute. To avoid unnecessary complications as seen on our own multi-OS CI grid (cf. dev@ thread [CI Grid, Windows and Paths|http://www.nabble.com/CI-Grid%2C-Windows-and-Paths-to21153292.html]) and as reported by users (e.g. MECLIPSE-404), the core should not only align directory-relative paths but also resolve drive-relative paths. -- 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-4017) Properties not correctly propagated from parent to child
Properties not correctly propagated from parent to child
Key: MNG-4017
URL: http://jira.codehaus.org/browse/MNG-4017
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Environment: XP. May effect other versions.
Reporter: Chris Graham
I have a parent pom, that has these properties defined in them (amongst others):
properties
java.source.version1.4/java.source.version
java.target.version${java.source.version}/java.target.version
pmd.target.jdk${java.target.version}/pmd.target.jdk
/properties
When I have a pom that uses the above as a parent (either directly, or further
up the tree), the java.source.version is lost, and set to 1.5 - when run under
java 1.5.
mvn help:effective-pom (and verified by looking at the versions of the
generated classes) shows that the child is set to 1.5.
Does this not break the inheritance model of POMS?
This is the output from help:effective-pom (of the child):
properties
java.source.version1.5/java.source.version
java.target.version1.5/java.target.version
pmd.target.jdk1.5/pmd.target.jdk
/properties
This is the output from help:effective-pom (of the parent):
properties
java.source.version1.4/java.source.version
java.target.version1.4/java.target.version
pmd.target.jdk1.4/pmd.target.jdk
/properties
-Chris
--
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: (MASSEMBLY-329) Filter fail to initialize when build from parent pom while assembly is in child pom
[ http://jira.codehaus.org/browse/MASSEMBLY-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Johnson updated MASSEMBLY-329: --- Attachment: maven-assembly-plugin-bug-filtered.zip Maven project which illustrates filtered working with file but not fileSet. Filter fail to initialize when build from parent pom while assembly is in child pom --- Key: MASSEMBLY-329 URL: http://jira.codehaus.org/browse/MASSEMBLY-329 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: maven 2.0.9 Windows XP Reporter: Andy Yeung Attachments: maven-assembly-plugin-bug-filtered.zip, project-structure.zip I have the project structure which is the same as the attached file. When I try to execute mvn package in the user-ear project directly, the filters are initialized and executed. However if I try to execute mvn package in the parent directory. The filter is gone. When I use -X options, I didn't find the log message [DEBUG] Initializing assembly filters... -- 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: (MASSEMBLY-329) Filter fail to initialize when build from parent pom while assembly is in child pom
[ http://jira.codehaus.org/browse/MASSEMBLY-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163466#action_163466 ] Jeff Johnson commented on MASSEMBLY-329: I have experienced the same issue and have a few more details. Please see attachment maven-assembly-plugin-bug-filtered.zip. When running from the parent aggregator POM filtered works with file elements but not with fileSet elements. When running from the child module POM both file and fileSet elements are properly filtered. Note that when running from the child module POM the resulting target/archive-tmp directory contains fileSetFormatter.*.tmp directories, but not when running from the parent aggregator POM. I will attach the resulting target directories as target-aggregator.zip and target-module.zip. Filter fail to initialize when build from parent pom while assembly is in child pom --- Key: MASSEMBLY-329 URL: http://jira.codehaus.org/browse/MASSEMBLY-329 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: maven 2.0.9 Windows XP Reporter: Andy Yeung Attachments: maven-assembly-plugin-bug-filtered.zip, project-structure.zip I have the project structure which is the same as the attached file. When I try to execute mvn package in the user-ear project directly, the filters are initialized and executed. However if I try to execute mvn package in the parent directory. The filter is gone. When I use -X options, I didn't find the log message [DEBUG] Initializing assembly filters... -- 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: (MASSEMBLY-329) Filter fail to initialize when build from parent pom while assembly is in child pom
[ http://jira.codehaus.org/browse/MASSEMBLY-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Johnson updated MASSEMBLY-329: --- Attachment: target-module.zip target-aggregator.zip Filter fail to initialize when build from parent pom while assembly is in child pom --- Key: MASSEMBLY-329 URL: http://jira.codehaus.org/browse/MASSEMBLY-329 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: maven 2.0.9 Windows XP Reporter: Andy Yeung Attachments: maven-assembly-plugin-bug-filtered.zip, project-structure.zip, target-aggregator.zip, target-module.zip I have the project structure which is the same as the attached file. When I try to execute mvn package in the user-ear project directly, the filters are initialized and executed. However if I try to execute mvn package in the parent directory. The filter is gone. When I use -X options, I didn't find the log message [DEBUG] Initializing assembly filters... -- 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-4017) Properties not correctly propagated from parent to child
[
http://jira.codehaus.org/browse/MNG-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4017:
---
Attachment: mng-4017.zip
The attached parent-child setup should follow your setup but I could not
reproduce the issue you describe. Please provide more details, e.g. a
ready-made archive that exhibits the issue.
Properties not correctly propagated from parent to child
Key: MNG-4017
URL: http://jira.codehaus.org/browse/MNG-4017
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Environment: XP. May effect other versions.
Reporter: Chris Graham
Attachments: mng-4017.zip
I have a parent pom, that has these properties defined in them (amongst
others):
properties
java.source.version1.4/java.source.version
java.target.version${java.source.version}/java.target.version
pmd.target.jdk${java.target.version}/pmd.target.jdk
/properties
When I have a pom that uses the above as a parent (either directly, or
further up the tree), the java.source.version is lost, and set to 1.5 - when
run under java 1.5.
mvn help:effective-pom (and verified by looking at the versions of the
generated classes) shows that the child is set to 1.5.
Does this not break the inheritance model of POMS?
This is the output from help:effective-pom (of the child):
properties
java.source.version1.5/java.source.version
java.target.version1.5/java.target.version
pmd.target.jdk1.5/pmd.target.jdk
/properties
This is the output from help:effective-pom (of the parent):
properties
java.source.version1.4/java.source.version
java.target.version1.4/java.target.version
pmd.target.jdk1.4/pmd.target.jdk
/properties
-Chris
--
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] Closed: (MCOMPILER-93) encoding/ not passed to the compiler.
[ http://jira.codehaus.org/browse/MCOMPILER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MCOMPILER-93. -- Assignee: Benjamin Bentmann Resolution: Cannot Reproduce Please provide a failing example project in case this needs further investigation. encoding/ not passed to the compiler. --- Key: MCOMPILER-93 URL: http://jira.codehaus.org/browse/MCOMPILER-93 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Reporter: benson margulies Assignee: Benjamin Bentmann Attachments: MCOMPILER-93.zip My configuration include encodingutf-8/encoding -X shows no sign of it, and I get problems in compile that stem from not having it set. [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile' -- [DEBUG] (f) basedir = /home/benson/tip/rlp/utilities/source/java [DEBUG] (f) buildDirectory = /home/benson/tip/rlp/utilities/source/java/target [DEBUG] (f) classpathElements = [/home/benson/tip/rlp/utilities/source/java/target/classes] [DEBUG] (f) compileSourceRoots = [/home/benson/tip/rlp/utilities/source/java/src] [DEBUG] (f) compilerId = javac [DEBUG] (f) debug = true [DEBUG] (f) failOnError = true [DEBUG] (f) fork = false [DEBUG] (f) maxmem = 256M [DEBUG] (f) optimize = true [DEBUG] (f) outputDirectory = /home/benson/tip/rlp/utilities/source/java/target/classes [DEBUG] (f) outputFileName = utilities-7.0-SNAPSHOT [DEBUG] (f) projectArtifact = com.basistech:utilities:jar:7.0-SNAPSHOT [DEBUG] (f) showDeprecation = true [DEBUG] (f) showWarnings = true [DEBUG] (f) source = 1.5 [DEBUG] (f) staleMillis = 0 [DEBUG] (f) target = 1.5 [DEBUG] (f) verbose = false [DEBUG] -- end configuration -- -- 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: (MASSEMBLY-329) Filter fail to initialize when build from parent pom while assembly is in child pom
[ http://jira.codehaus.org/browse/MASSEMBLY-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163467#action_163467 ] Jeff Johnson commented on MASSEMBLY-329: These issues are fixed in version 2.2-beta-3, so this issue can be closed. Filter fail to initialize when build from parent pom while assembly is in child pom --- Key: MASSEMBLY-329 URL: http://jira.codehaus.org/browse/MASSEMBLY-329 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: maven 2.0.9 Windows XP Reporter: Andy Yeung Attachments: maven-assembly-plugin-bug-filtered.zip, project-structure.zip, target-aggregator.zip, target-module.zip I have the project structure which is the same as the attached file. When I try to execute mvn package in the user-ear project directly, the filters are initialized and executed. However if I try to execute mvn package in the parent directory. The filter is gone. When I use -X options, I didn't find the log message [DEBUG] Initializing assembly filters... -- 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-820) Over-zealous transitive dependencies during mediation
[
http://jira.codehaus.org/browse/MNG-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-820:
--
Description:
The attached zip sets up the following project hierarchy:
{noformat}
main.war
projecta
shared:1.0
librarya
projectb
projectc
shared:2.0
libraryb
{noformat}
From what I understand of dependency mediation shared:2.0 should be chosen in
preference to shared:1.0, and hence libraryb should be included instead of
librarya. Using the latest m2 the main.war WEB-INF/lib contains:
projecta
projectb
projectc
shared:2.0
librarya
libraryb
Thus librarya is included when it shouldn't be.
was:
The attached zip sets up the following project hierarchy:
main.war
projecta
shared:1.0
librarya
projectb
projectc
shared:2.0
libraryb
From what I understand of dependency mediation shared:2.0 should be chosen in
preference to shared:1.0, and hence libraryb should be included instead of
librarya. Using the latest m2 the main.war WEB-INF/lib contains:
projecta
projectb
projectc
shared:2.0
librarya
libraryb
Thus librarya is included when it shouldn't be.
Over-zealous transitive dependencies during mediation
-
Key: MNG-820
URL: http://jira.codehaus.org/browse/MNG-820
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0-beta-1
Environment: Windows XP, Cygwin
Reporter: Mark Hobson
Assignee: Brett Porter
Priority: Blocker
Fix For: 2.0-beta-2
Attachments: test.zip
Original Estimate: 2 hours
Time Spent: 2 hours
Remaining Estimate: 0 minutes
The attached zip sets up the following project hierarchy:
{noformat}
main.war
projecta
shared:1.0
librarya
projectb
projectc
shared:2.0
libraryb
{noformat}
From what I understand of dependency mediation shared:2.0 should be chosen in
preference to shared:1.0, and hence libraryb should be included instead of
librarya. Using the latest m2 the main.war WEB-INF/lib contains:
projecta
projectb
projectc
shared:2.0
librarya
libraryb
Thus librarya is included when it shouldn't be.
--
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: (MAVENUPLOAD-2346) Upload appframework and swinghelper-debug
Upload appframework and swinghelper-debug - Key: MAVENUPLOAD-2346 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2346 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandre Navarro Attachments: appframework-1.03-bundle.jar, swinghelper-debug-1.0-bundle.jar Alexandre Navarro a contributor of theses 2 projects, contributor on fest and developer on JavaBuilder and SwingJavaBuilder where we need theses jars. Alexander Potochkin and Hans Muller (https://swinghelper.dev.java.net/ and https://appframework.dev.java.net/), main developers on theses 2 projects. Thanks, upload! -- 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: (MAVENUPLOAD-2347) Upload scenario jar
Upload scenario jar --- Key: MAVENUPLOAD-2347 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2347 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexandre Navarro Attachments: scenario-1.0.1-bundle.jar I'm a developer on SwingJavaBuilder and I need this jar (which is in the javafx distribution) for my project. I asked on http://forums.sun.com/thread.jspa?threadID=5362457 the upload request but nobody answer me. Thanks to upload it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4017) Properties not correctly propagated from parent to child
[
http://jira.codehaus.org/browse/MNG-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Graham closed MNG-4017.
-
Resolution: Not A Bug
See previous comment.
Properties not correctly propagated from parent to child
Key: MNG-4017
URL: http://jira.codehaus.org/browse/MNG-4017
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Environment: XP. May effect other versions.
Reporter: Chris Graham
Attachments: mng-4017.zip
I have a parent pom, that has these properties defined in them (amongst
others):
properties
java.source.version1.4/java.source.version
java.target.version${java.source.version}/java.target.version
pmd.target.jdk${java.target.version}/pmd.target.jdk
/properties
When I have a pom that uses the above as a parent (either directly, or
further up the tree), the java.source.version is lost, and set to 1.5 - when
run under java 1.5.
mvn help:effective-pom (and verified by looking at the versions of the
generated classes) shows that the child is set to 1.5.
Does this not break the inheritance model of POMS?
This is the output from help:effective-pom (of the child):
properties
java.source.version1.5/java.source.version
java.target.version1.5/java.target.version
pmd.target.jdk1.5/pmd.target.jdk
/properties
This is the output from help:effective-pom (of the parent):
properties
java.source.version1.4/java.source.version
java.target.version1.4/java.target.version
pmd.target.jdk1.4/pmd.target.jdk
/properties
-Chris
--
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-4017) Properties not correctly propagated from parent to child
[
http://jira.codehaus.org/browse/MNG-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163504#action_163504
]
Chris Graham commented on MNG-4017:
---
Never mind. Stupid me. I thought that it may have been related to:
http://jira.codehaus.org/browse/MNG-3666
In this instance, something else have been changed up the stream that I did not
find (until now).
Sorry for the trouble.
-Chris
Properties not correctly propagated from parent to child
Key: MNG-4017
URL: http://jira.codehaus.org/browse/MNG-4017
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Environment: XP. May effect other versions.
Reporter: Chris Graham
Attachments: mng-4017.zip
I have a parent pom, that has these properties defined in them (amongst
others):
properties
java.source.version1.4/java.source.version
java.target.version${java.source.version}/java.target.version
pmd.target.jdk${java.target.version}/pmd.target.jdk
/properties
When I have a pom that uses the above as a parent (either directly, or
further up the tree), the java.source.version is lost, and set to 1.5 - when
run under java 1.5.
mvn help:effective-pom (and verified by looking at the versions of the
generated classes) shows that the child is set to 1.5.
Does this not break the inheritance model of POMS?
This is the output from help:effective-pom (of the child):
properties
java.source.version1.5/java.source.version
java.target.version1.5/java.target.version
pmd.target.jdk1.5/pmd.target.jdk
/properties
This is the output from help:effective-pom (of the parent):
properties
java.source.version1.4/java.source.version
java.target.version1.4/java.target.version
pmd.target.jdk1.4/pmd.target.jdk
/properties
-Chris
--
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-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3719:
--
Fix Version/s: 2.1.0-M2
Patch Submitted: [Yes]
[regression] plugin execution ordering no longer POM ordered in 2.0.9
-
Key: MNG-3719
URL: http://jira.codehaus.org/browse/MNG-3719
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
Environment: Maven 2.0.9, java version 1.5.0_13 Java(TM) 2 Runtime
Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
Reporter: Gary S. Weaver
Priority: Critical
Fix For: 2.0.11, 2.1.0-M2
Attachments: MNG-3719-maven-project.patch,
plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
I extend my sincere apologies if there is a much easier way of doing this,
but so far I haven't found any.
There should be some way to ensure order of plugin executions through
dependencies on other executions. See attached project for example, or see
below for the applicable example in a pom.xml. When plugins are defined in
pom.xml in the following manner to ensure correct execution order, they are
not executed sequentially and there is no way to indicate dependencies, as
would be expected (note- I'm not expecting that it interpret the step 1...,
..., step 5... IDs, I'm only suggesting that either the plugins be executed
in order that they are found in the XML (most intuitive) or that there be
some concept of priority/ordinal added, or even perhaps (this would be most
ant-like) that plugin executions (and maybe even plugin goal executions) be
allowed to define prequisite execution IDs to be run (even if they are IDs
not defined in the pom, but maybe a parent pom, even though I don't need that
right now).
I know that this could be problematic if a plugin execution from one
lifecycle phase depends on another from another lifecycle phase (and you
could get into circular references that way that would have to be recognized
during pom validation after loading/merging pom.xmls). However, not being
able to at the very least define order of execution of different (or the
same) plugin executions as noted below and in attached project makes it
difficult to chain plugin executions that depend on each other, thereby
reducing the practicality of the pom.xml and Maven 2.
For example, these plugin executions cannot be ordered properly in Maven
2.0.9, since there appears to be no way to indicate dependencies of one
execution on another:
{code}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin
plugin
!-- backup original source web.xml in preparation for
chaining of plugin modifications to it --
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idstep 1 - backup-original-web.xml-from-src/id
phasegenerate-resources/phase
goals
goalrun/goal
/goals
configuration
tasks
mkdir dir=${pom.basedir}/target/
mkdir dir=${pom.basedir}/target/tmpwebxml/
copy
file=${pom.basedir}/src/main/webapp/WEB-INF/web.xml
todir=${pom.basedir}/target/tmpwebxml//
/tasks
/configuration
/execution
/executions
/plugin
plugin
!-- this plugin converts to
${basedir}/src/main/webapp/WEB-INF/web.xml to ${basedir}/target/jspweb.xml --
groupIdorg.codehaus.mojo/groupId
artifactIdjspc-maven-plugin/artifactId
executions
execution
idstep 2 - jspc/id
phasegenerate-resources/phase
goals
goalcompile/goal
/goals
/execution
/executions
configuration
injectStringlt;!-- [INSERT JSPC FRAGMENT HERE]
--gt;/injectString
/configuration
dependencies
[jira] Updated: (MNG-1957) jdk/jdk clause in the activation section has to provide more complex expressions.
[ http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1957: -- Fix Version/s: (was: 2.0.x) 2.1.0-M2 2.0.11 Patch Submitted: [Yes] jdk/jdk clause in the activation section has to provide more complex expressions. - Key: MNG-1957 URL: http://jira.codehaus.org/browse/MNG-1957 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0, 2.0.1 Reporter: Trustin Lee Fix For: 2.0.11, 2.1.0-M2 Attachments: MNG-1957-maven-project.patch For now, jdk/jdk provides only one operator '!' which means negation, but it would be great if i can use '+' and ~ operator: jdk1.5+/jdk !-- this will be activated when the current JDK version is 1.5 or above (e.g. 1.6) -- jdk1.1 ~ 1.4/jdk !-- this will be activated when the current JDK version is between 1.1 and 1.4 -- jdk~ 1.3/jdk !-- this will be activated when the current JDK version is 1.3 or below -- jdk1.4 ~/jdk. !-- the same with 1.5+ -- -- 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-3999) validation of Id's too restrictive
[ http://jira.codehaus.org/browse/MNG-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163510#action_163510 ] Brett Porter commented on MNG-3999: --- most of the other characters you've listed tend to incur some special meaning in various usage scenarios (eg, ~ at the end is a backup file). It is best that such clashes be avoided, and the artifact Id's are meant to be easily readable/managed IDs. Allowing more characters might inadvertently break external tools that have come to depend on it, so I think it's best left unchanged. It sounds like you are converting from an M1 repo to an M2 repo - if you are using a tool for that maybe it can be enhanced to convert IDs for you. If you are doing that artifact by artifact, there'll be a number of more complicated other changes to the POM anyway that this should be a trivial search and replace by comparison. validation of Id's too restrictive -- Key: MNG-3999 URL: http://jira.codehaus.org/browse/MNG-3999 Project: Maven 2 Issue Type: Improvement Components: POM Environment: xp, SAP NetWeaver, maven 2.x Reporter: Sven Pressler Attachments: pom.xml I guess the validation of the Id's were introduced after issue MNG-801. I think the validation is too strong. The problem is that a lot of valid filenames are not validated as true. The problem is caused by the DefaultModelValidator: private static final String ID_REGEX = [A-Za-z0-9_\\-.]+; This regular expression is far too restrictive since something like x=+%$ยง~!#^.jar would be a valid filename on a windows operating system I stumbled upon this because I'm developing tools for SAP NetWeaver, currently we still use maven 1 to build our projects but we're in the process of upgrading to maven 2. maven 1 doesn't have this problem, since Id's didn't get validated like that. Problem is SAP have a lot of libraries that have '~' in their names, like 'tc~epbc~pcm~adminapi~java-5.x.y.jar'. Doesn't look any good, I don't like it, I didn't make it like that but I have to work with it. Maybe someone can explain why it's a good idea to be that restrictive about the Ids, but as far as I see it, it's more like: before MNG-801 there was no validation, and after MNG-801 there was some validation, and until now, there was not too much complaining about it. Attached is a pom which produces the following when trying to run mvn install: Project ID: group:com~company~my~project Validation Messages: [0] 'artifactId' with value 'com~company~my~project' does not match a valid id pattern. Reason: Failed to validate POM for project group:com~company~my~project at C:\test\validate\pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for project group:com~company~my~project at C:\test\validate\pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:324) 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.project.InvalidProjectModelException: Failed to validate POM for project group:com~company~my~project at C:\test\validate\pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) ... 11 more -- This message is automatically generated by JIRA. - If you think
Unable to read POM file from repo1.maven.org
My maven application is unable to read the file below from repo1.maven.org. Some of the bytes are received, but the system then hangs. The same thing happens when I attempt to access the file via a web-browser. Note that other files can be read successfully. I first noticed the problem approx. 12 hours ago, and it is still persisting. http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-8/plexus-container-default-1.0-alpha-8.pom -- View this message in context: http://www.nabble.com/Unable-to-read-POM-file-from-repo1.maven.org-tp21785448p21785448.html Sent from the Maven - Issues mailing list archive at Nabble.com.
