[jira] [Updated] (MDEP-694) Include import-scoped dependency in the output of the dependency plugin goals (e.g. `analyze`, `resolve`, `tree`, `list`, ...)
[ https://issues.apache.org/jira/browse/MDEP-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wu updated MDEP-694: - Description: * Currently, there is no way to include/show an import-scoped dependency in the output of `dependency:list` (and other similar goals). It is understood that an import-scoped dependency won't result in any binary form artifact (such as jar, war, zip, etc). But it is, by definition, a project dependency. Not listing it in the output prevents tools/scripts from detecting such dependency relationship (without parsing the POM file), thus further messing up the build/manipulation process; * See the attached POM file of `hello-bom` and `hello-model` for examples; * It's acceptable to add an option to control if import-scoped dependency should be included in the output. > Include import-scoped dependency in the output of the dependency plugin goals > (e.g. `analyze`, `resolve`, `tree`, `list`, ...) > -- > > Key: MDEP-694 > URL: https://issues.apache.org/jira/browse/MDEP-694 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: John Wu >Priority: Major > Attachments: hello-bom.pom.xml, hello-model.pom.xml > > > * Currently, there is no way to include/show an import-scoped dependency in > the output of `dependency:list` (and other similar goals). It is understood > that an import-scoped dependency won't result in any binary form artifact > (such as jar, war, zip, etc). But it is, by definition, a project dependency. > Not listing it in the output prevents tools/scripts from detecting such > dependency relationship (without parsing the POM file), thus further messing > up the build/manipulation process; > * See the attached POM file of `hello-bom` and `hello-model` for examples; > * It's acceptable to add an option to control if import-scoped dependency > should be included in the output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-694) Include import-scoped dependency in the output of the dependency plugin goals (e.g. `analyze`, `resolve`, `tree`, `list`, ...)
[ https://issues.apache.org/jira/browse/MDEP-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Wu updated MDEP-694: - Attachment: hello-model.pom.xml hello-bom.pom.xml > Include import-scoped dependency in the output of the dependency plugin goals > (e.g. `analyze`, `resolve`, `tree`, `list`, ...) > -- > > Key: MDEP-694 > URL: https://issues.apache.org/jira/browse/MDEP-694 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: John Wu >Priority: Major > Attachments: hello-bom.pom.xml, hello-model.pom.xml > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MDEP-694) Include import-scoped dependency in the output of the dependency plugin goals (e.g. `analyze`, `resolve`, `tree`, `list`, ...)
John Wu created MDEP-694: Summary: Include import-scoped dependency in the output of the dependency plugin goals (e.g. `analyze`, `resolve`, `tree`, `list`, ...) Key: MDEP-694 URL: https://issues.apache.org/jira/browse/MDEP-694 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: John Wu -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] (MNG-5682) Parent POMs not resolved in multi-module project
[
https://jira.codehaus.org/browse/MNG-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354097#comment-354097
]
John Wu commented on MNG-5682:
--
Got similar issue here.
My workaround is to build and install the parent pom first, then build the rest
modules.
Ideally, if the parent pom is in the reactor build plan, the reactor should 1)
build the parent pom prior to build its child modules, 2) pick up the parent
pom from within the reactor and use it for the child modules.
> Parent POMs not resolved in multi-module project
>
>
> Key: MNG-5682
> URL: https://jira.codehaus.org/browse/MNG-5682
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.0.4, 3.1.1, 3.2.3
> Environment: Apache Maven 3.2.3
> (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T22:58:10+02:00)
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Default locale: en_US, platform encoding: Cp1250
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Kek
>Priority: Minor
> Attachments: test-project.zip
>
>
> I have multi-module project - I attach the similar simple project structure
> to this issue, to simulate the problem => !test-project.zip!.
> The structure is:
> {noformat}
> A- aggregating project, parent for "parent"
> |_parent - parent for B and C
> |_B
> |_C
> {noformat}
> In reality we have more parents under A for diferent types of A-submodules,
> but now it does not matter.
> When we run build under maven 2.2.1 - everything is OK, the reactor sorts
> the projects like A, PARENT, B,C and build success.
> When we run the same build under maven 3.x (3.0.4, 3.1.1, 3.2.3 was tested),
> the build fails with following errors:
> a>mvn clean
> [INFO] Scanning for projects...
> [ERROR] The build could not read 2 projects -> [Help 1]
> [ERROR]
> [ERROR] The project a:b:[unknown-version] (\a\b\pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM: Could not find artifact
> a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local
> POM @ line 6, column 10 -> [Help 2]
> [ERROR]
> [ERROR] The project a:c:[unknown-version] (\a\c\pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM: Could not find artifact
> a:parent:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at wrong local
> POM @ line 6, column 10 -> [Help 2]
> [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/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> There is no explicit "relativePath" set in project POMs.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SCM-666) TfsEditCommand should not report error if the file is also checked out by others
John Wu created SCM-666: --- Summary: TfsEditCommand should not report error if the file is also checked out by others Key: SCM-666 URL: https://jira.codehaus.org/browse/SCM-666 Project: Maven SCM Issue Type: Bug Affects Versions: 1.6 Reporter: John Wu While checking out a file for editing, the TfsEditCommand reports error, if the file is already checked out by others, as the following: $/path/to/the/file: opened for edit in ; One file is checked out and being editing by multiple people is quite common in a team environment, which should not prevent yet another from checking it out for editing successfully. -- 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] (SCM-665) TfsChangeLogCommand does not display the change log for directories
John Wu created SCM-665: --- Summary: TfsChangeLogCommand does not display the change log for directories Key: SCM-665 URL: https://jira.codehaus.org/browse/SCM-665 Project: Maven SCM Issue Type: Bug Affects Versions: 1.6 Reporter: John Wu The TfsChangeLogCommand can get change log of specific file(s), but cannot work for directory. In TfsChangeLogCommand.java of version 1.6, line 83 is command.addArgument( file.getName() ); But I believe it should be command.addArgument( file.getAbsolutePath() ); -- 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] Issue Comment Edited: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203235#action_203235
]
John Wu edited comment on MJAVADOC-276 at 12/17/09 11:26 AM:
-
I encountered the similar problems. After multi-scenario verifications, I'd say
that
This is a regression, compare to version 2.6.
In a multi-module project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
In my tests, maven 2.2.1 and maven-release-plugin 2.0-beta-9 were used.
was (Author: phantom_john):
I encountered the similar problems. After multi-scenario verifications, I'd
say that
This is a regression, compare to version 2.6.
In a multi-module project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this
[jira] Issue Comment Edited: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203235#action_203235
]
John Wu edited comment on MJAVADOC-276 at 12/17/09 11:18 AM:
-
I encountered the similar problems. After multi-scenario verifications, I'd say
that
This is a regression, compare to version 2.6.
In a multi-module project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
was (Author: phantom_john):
I encountered the similar problems. After verifications, I'd say that
This is a regression, compare to version 2.6.
In a multi-modules project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this is being built,
> the submodule does not exist (yet).
> I have replicated this problem
[jira] Commented: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203235#action_203235
]
John Wu commented on MJAVADOC-276:
--
I encountered the similar problems. After verifications, I'd say that
This is a regression, compare to version 2.6.
In a multi-modules project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this is being built,
> the submodule does not exist (yet).
> I have replicated this problem on two different computing environments, so
> I'm convinced that the Maven version is not relevant.
> (It is unclear to me if this problem also existed with Javadoc 2.6, but I
> don't think so.)
--
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
