[jira] Commented: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126283 ] Piotr Tabor commented on MNG-1323: -- I wasn't able to repeat Jason's problems. I asked the dev group for help with repeating the issue and got no answer. Is any commiter able to promise that he will help me with checking/commiting this patch if I refactor it to work with current revisions (2.1 and 2.0.x) ? Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.10 Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing-2.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests-3.diff, MNG-1323-core-integration-tests.diff, MNG1323-maven-core-2.1.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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-1949) project-level plugin dependencies not handled correctly in multimodule builds
[ http://jira.codehaus.org/browse/MNG-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107520 ] Piotr Tabor commented on MNG-1949: -- Patch for MNG-1323 commited in trunk by Jason van Zyl. As MNG-1323 is dupliacate for this problem - this also should be resolved in trunk. To be tested by reported. Patch for 2.0.x is ready to be commited in MNG-1323. project-level plugin dependencies not handled correctly in multimodule builds - Key: MNG-1949 URL: http://jira.codehaus.org/browse/MNG-1949 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.1 Reporter: John Casey Fix For: 2.1 plugin containers are only initialized once per build, which means they may contain incorrect project-introduced dependencies for project Y in a multimodule build (polluted by project X predecessor). We should look at ways of dumping plugin containers with project-specific configurations, or else providing a container overlay to handle project-specific dependencies, etc. NOTE: This is tied into the notions of build extensions, which will have similar consequences on the core container. -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG1323-maven-core-2.1.diff Patch for trunk (2.1) - (rev. 575973.) All integration tests pass. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing-2.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff, MNG1323-maven-core-2.1.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-core-integration-tests-3.diff MNG-1323-core-integration-tests-3.diff IT0127 rewritten to not use Ant run plugin - as Jason wished. It uses enforcer plugin instead (with new rulu) to check if right dependencies are available from the plugin. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing-2.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests-3.diff, MNG-1323-core-integration-tests.diff, MNG1323-maven-core-2.1.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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] Issue Comment Edited: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107481 ] Piotr Tabor edited comment on MNG-1323 at 9/15/07 7:53 PM: --- MNG-1323-core-integration-tests-3.diff IT0127 rewritten to not use Ant run plugin - as Jason wished. It uses enforcer plugin instead (with new rule) to check if right dependencies are available from the plugin. was: MNG-1323-core-integration-tests-3.diff IT0127 rewritten to not use Ant run plugin - as Jason wished. It uses enforcer plugin instead (with new rulu) to check if right dependencies are available from the plugin. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing-2.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests-3.diff, MNG-1323-core-integration-tests.diff, MNG1323-maven-core-2.1.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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-1949) project-level plugin dependencies not handled correctly in multimodule builds
[ http://jira.codehaus.org/browse/MNG-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106739 ] Piotr Tabor commented on MNG-1949: -- Yes - it is still problem in trunk. JIRA for MNG-1323 contains patch for 2.0.x... I am preparing patch for 2.1... I hope to have it this weekend. project-level plugin dependencies not handled correctly in multimodule builds - Key: MNG-1949 URL: http://jira.codehaus.org/browse/MNG-1949 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.1 Reporter: John Casey Fix For: 2.1 plugin containers are only initialized once per build, which means they may contain incorrect project-introduced dependencies for project Y in a multimodule build (polluted by project X predecessor). We should look at ways of dumping plugin containers with project-specific configurations, or else providing a container overlay to handle project-specific dependencies, etc. NOTE: This is tied into the notions of build extensions, which will have similar consequences on the core container. -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-components-2.0.x.diff Patch for this issue for 2.0.x. All it's passed. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-tests.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-core-integration-testing.diff It test for this issue. Actualized to current tests numeration (127) Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-core-integration-testing-2.diff Corrected one thing in it. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing-2.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106351 ] Piotr Tabor commented on MNG-1323: -- Integration test was committed by Jason van Zyl. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing-2.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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] Issue Comment Edited: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106334 ] Piotr Tabor edited comment on MNG-1323 at 9/3/07 10:45 PM: --- Corrected one thing in Integration Test. was: Corrected one thing in it. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-components-2.0.x.diff, MNG-1323-core-integration-testing-2.diff, MNG-1323-core-integration-testing.diff, MNG-1323-core-integration-tests.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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-3160) IT 126 is failing on trunk and maven-2.0.x branch
[ http://jira.codehaus.org/browse/MNG-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106258 ] Piotr Tabor commented on MNG-3160: -- This bug is caused by not released version of Maven Jar Plugin. The sufficient patch (Connected to MJAR-75) was applied, by Maven Jar Plugin has not been released. It will work with maven-jar-plugin-2.2(-snapshot). If it tests can depend on SNAPSHOT version of plugins to correct the problem you need to add: pluginManagement plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.2-SNAPSHOT/version /plugin pluginManagement to core-integration-testing/core-integration-tests/src/test/resources/it0126-testJarDependency/pom.xml IT 126 is failing on trunk and maven-2.0.x branch - Key: MNG-3160 URL: http://jira.codehaus.org/browse/MNG-3160 Project: Maven 2 Issue Type: Bug Components: integration tests Affects Versions: 2.0.8, 2.1-alpha-1 Reporter: Brett Porter Priority: Blocker Fix For: 2.0.x [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.maven.its.it0126:model:test-jar:tests:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.its.it0126 -DartifactId=model \ -Dversion=1.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.its.it0126 -DartifactId=model \ -Dversion=1.0-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.maven.its.it0126:client:jar:1.0-SNAPSHOT 2) org.apache.maven.its.it0126:model:test-jar:tests:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.maven.its.it0126:client:jar:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) -- 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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2871: - Attachment: MNG-2871-core-integration-testing-2.diff New test case (that is only update to currently existing test that make the current it-120 covering the problem too). (I'm author of it-120 - so I am sure this patch will not destroy the idea of original test case) Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Assignee: John Casey Fix For: 2.1-alpha-1 Attachments: MavenProject.java, MNG-2871-core-integration-testing-2.diff, MNG-2871-core-integration-tests.diff, root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to
[jira] Updated: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2871: - Attachment: MNG-2871-maven-project.diff Clean patch for this issue. Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Assignee: John Casey Fix For: 2.1-alpha-1 Attachments: MavenProject.java, MNG-2871-core-integration-testing-2.diff, MNG-2871-core-integration-tests.diff, MNG-2871-maven-project.diff, root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using
[jira] Commented: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105485 ] Piotr Tabor commented on MNG-2871: -- Clean (i hope) view of this issue: The problem could be called internal dependencies in reactor when everything is build by phase lower then package. The real jar's for such a dependencies like client-jar or test-jar are created and attached to original artifacts in package phase. So if we call mvn test for a parent pom we will not get this (client-jar, test-jar) files build - so the dependencies will not be resolved internally... They will be resolved from repository (if they exist there - so not actual version may be used) or the build will fail. I see there two options: a) Close this bug as WON'T BE FIXED (because it's design issue) and answer is 'don't call mvn test' to do the tests... call mvn package instead. at least we can add warning in a such a case: Dependency ... has not been resolved internally. Calling 'mvn package' or greater phase may resolve your problem. If we decide to this solution, I can prepare such a patch. or b) Apply currently attached patches (MNG-2871-maven-project.diff, MNG-2871-core-integration-testing-2.diff) that will make things much better in case of ejb and ejb-client artifacts (that is IMHO the most frequent and important usage of attached artifact). I don't like exception's, but it may be worth. The main disadvantages are that it is exception and that we will provide more then client would need. The problem is most annoying because maven-release-plugin calls mvn test after upgrading version's number... So it leads to mvn release:prepare failure in case of ejb-client dependencies. Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Assignee: John Casey Fix For: 2.1-alpha-1 Attachments: MavenProject.java, MNG-2871-core-integration-testing-2.diff, MNG-2871-core-integration-tests.diff, MNG-2871-maven-project.diff, root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading:
[jira] Commented: (MNG-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104926 ] Piotr Tabor commented on MNG-3043: -- Kenney, could you check if your problem is resolved with current (SVN/SNAPSHOT) version of maven-jar-plugin. I hope MJAR-75 that was fixed, resolved this issue too. Thank you Allow 'mvn test' to work with test-jar dependencies in a reactor Key: MNG-3043 URL: http://jira.codehaus.org/browse/MNG-3043 Project: Maven 2 Issue Type: Bug Components: Dependencies, Reactor and workspace Affects Versions: 2.0.6, 2.0.7, 2.1 Reporter: Kenney Westerhof Fix For: Reviewed Pending Version Assignment Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn install', you run 'mvn test'. Test classes of dependencies should be resolved from the reactor, just as main classes, if there's no archive available. I'm not sure how to go about this. Specifying a dependency on something with typetest-jar/type, and having that dependency declare the maven-jar-plugin with the 'test-jar' goal is insufficient. Perhaps we can just add a standard classifier that maven is aware of, in this case 'tests'. The jar packaging would export this as a known classifier, and tells maven how it contributes to what classpath. Since test sources are a first class citizen, just as main sources are (they have the same phases, same elements in the pom (but differently named)). It seems logical to me that somehow the test classes should be made available to dependencies, if they declare a dependency with classifier 'tests'. -- 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-531) ant:ant:1.6.5 (completly wrong dependencies)
[ http://jira.codehaus.org/browse/MEV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104680 ] Piotr Tabor commented on MEV-531: - Proofs (to make commiter's live easier): * exists: http://mirrors.ibiblio.org/pub/mirrors/maven2/xerces/xercesImpl/2.6.2 * doesn't exist: http://mirrors.ibiblio.org/pub/mirrors/maven2/xerces/xerces-impl * exists: http://mirrors.ibiblio.org/pub/mirrors/maven2/xml-apis/xml-apis/1.3.4 * doesn't exist: http://mirrors.ibiblio.org/pub/mirrors/maven2/xml-apis/xml-apis/2.6.2 Link to official ant distribution: http://archive.apache.org/dist/ant/binaries/apache-ant-1.6.5-bin.zip ant:ant:1.6.5 (completly wrong dependencies) Key: MEV-531 URL: http://jira.codehaus.org/browse/MEV-531 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Piotr Tabor Current ant:ant pom is: project modelVersion4.0.0/modelVersion groupIdant/groupId artifactIdant/artifactId version1.6.5/version dependencies dependency groupIdxerces/groupId *artifactIdxerces-impl/artifactId* version2.6.2/version optionaltrue/optional /dependency dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId *version2.6.2/version* optionaltrue/optional /dependency /dependencies /project Instead of: artifactIdxerces-impl/artifactId should be artifactIdxercesImpl/artifactId (xerces-impl does not exist in repo) And the version of xml-apis should be: 1.3.04 (2.6.2 does not exist) -- 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: (MEV-531) ant:ant:1.6.5 (completly wrong dependencies)
[ http://jira.codehaus.org/browse/MEV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MEV-531: Attachment: ant-1.6.5.pom Corrected version of descriptor. ant:ant:1.6.5 (completly wrong dependencies) Key: MEV-531 URL: http://jira.codehaus.org/browse/MEV-531 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Piotr Tabor Attachments: ant-1.6.5.pom Current ant:ant pom is: project modelVersion4.0.0/modelVersion groupIdant/groupId artifactIdant/artifactId version1.6.5/version dependencies dependency groupIdxerces/groupId *artifactIdxerces-impl/artifactId* version2.6.2/version optionaltrue/optional /dependency dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId *version2.6.2/version* optionaltrue/optional /dependency /dependencies /project Instead of: artifactIdxerces-impl/artifactId should be artifactIdxercesImpl/artifactId (xerces-impl does not exist in repo) And the version of xml-apis should be: 1.3.04 (2.6.2 does not exist) -- 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: (MJAR-75) [PATCH] Wrong artifact type attached to the project by the test-jar goal
[
http://jira.codehaus.org/browse/MJAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Tabor updated MJAR-75:
Attachment: MJAR-75-core-integration-testing.diff
Dedicated IT for this issue attached.
[PATCH] Wrong artifact type attached to the project by the test-jar goal
-
Key: MJAR-75
URL: http://jira.codehaus.org/browse/MJAR-75
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.0, 2.1, 2.2
Environment: All
Reporter: Piotr Tabor
Assignee: Jason van Zyl
Priority: Critical
Attachments: maven-jar-plugin-MJAR-75.diff,
MJAR-75-core-integration-testing.diff
The test-jar goal attaches to the project
org.apache.maven.its.it0121:model:jar such a artifact:
- org.apache.maven.its.it0121:model:*jar*:tests
It should attach such an artifact:
- org.apache.maven.its.it0121:model:*test-jar*:tests
The wrong artifacts naming leads to MNG-2871 problem:
The code does not work (because the strings are different:
--MavenProject:
replaceWithActiveArtifact(...)-
Iterator itr = ref.getAttachedArtifacts().iterator();
while(itr.hasNext()) {
Artifact attached = (Artifact) itr.next();
if(
attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())
) {
... (resolve as active's project) ...
}
...
---
pluginArtifact.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*test-jar*:tests
attached.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*jar*:tests
For test-case: look at test (it121) attached to:
http://jira.codehaus.org/browse/MNG-2871
--
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] Issue Comment Edited: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[
http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102012
]
Piotr Tabor edited comment on MNG-1323 at 7/11/07 11:16 PM:
I am trying to work on the issue too.
The simplest solution is in DefaultPluginManager change the code to:
private PluginDescriptor verifyVersionedPlugin( Plugin plugin,
MavenProject project,
ArtifactRepository
localRepository )
File pluginFile = pluginArtifact.getFile();
if * /*( !pluginCollector.isPluginInstalled( plugin ) ||*/ * (
pluginContainer == null )
{
addPlugin( plugin, pluginArtifact, project, localRepository );
}
else * /*if ( pluginFile.lastModified()
pluginContainer.getCreationDate().getTime() )*/ *
{
getLogger().info(
Reloading plugin container for: + plugin.getKey() + .
The plugin artifact has changed. );
pluginContainer.dispose();
pluginCollector.flushPluginDescriptor( plugin );
addPlugin( plugin, pluginArtifact, project, localRepository );
}
But it slows Maven to much... I will trying to prepare know a little bit better
solution that checks if getted descriptor matches and if
not - to replace it.
The best solution is to build plugin's identifiers that contains hashcode of
dependencies.
Any comments from Commiters ?
was:
I am trying to work on the issue too.
The simplest solution is in DefaultPluginManager change the code to:
private PluginDescriptor verifyVersionedPlugin( Plugin plugin,
MavenProject project,
ArtifactRepository
localRepository )
File pluginFile = pluginArtifact.getFile();
if /*( !pluginCollector.isPluginInstalled( plugin ) ||*/(
pluginContainer == null )
{
addPlugin( plugin, pluginArtifact, project, localRepository );
}
else /*if ( pluginFile.lastModified()
pluginContainer.getCreationDate().getTime() )*/
{
getLogger().info(
Reloading plugin container for: + plugin.getKey() + .
The plugin artifact has changed. );
pluginContainer.dispose();
pluginCollector.flushPluginDescriptor( plugin );
addPlugin( plugin, pluginArtifact, project, localRepository );
}
But it slows Maven to much... I will trying to prepare know a little bit better
solution that checks if getted descriptor matches and if
not - to replace it.
The best solution is to build plugin's identifiers that contains hashcode of
dependencies.
Any comments from Commiters ?
Plugin extensions (dependencies) not resolved in reactor build
--
Key: MNG-1323
URL: http://jira.codehaus.org/browse/MNG-1323
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0
Reporter: Kenney Westerhof
Fix For: 2.0.x
Attachments: MNG-1323-core-integration-tests.diff
I've added a dependency on an Ant Task in
project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/
and run that anttask using the antrun plugin.
When run from the project dir itself it runs fine.
When running from the root of the project tree (reactor build, project one
level below root),
antrun bails out because the taskdef can't be found (not on classpath).
It looks like the dependency isn't resolved, or not added to the plugins'
classrealm.
--
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-1323) Plugin extensions (dependencies) not resolved in reactor build
[
http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102012
]
Piotr Tabor commented on MNG-1323:
--
I am trying to work on the issue too.
The simplest solution is in DefaultPluginManager change the code to:
private PluginDescriptor verifyVersionedPlugin( Plugin plugin,
MavenProject project,
ArtifactRepository
localRepository )
File pluginFile = pluginArtifact.getFile();
if /*( !pluginCollector.isPluginInstalled( plugin ) ||*/(
pluginContainer == null )
{
addPlugin( plugin, pluginArtifact, project, localRepository );
}
else /*if ( pluginFile.lastModified()
pluginContainer.getCreationDate().getTime() )*/
{
getLogger().info(
Reloading plugin container for: + plugin.getKey() + .
The plugin artifact has changed. );
pluginContainer.dispose();
pluginCollector.flushPluginDescriptor( plugin );
addPlugin( plugin, pluginArtifact, project, localRepository );
}
But it slows Maven to much... I will trying to prepare know a little bit better
solution that checks if getted descriptor matches and if
not - to replace it.
The best solution is to build plugin's identifiers that contains hashcode of
dependencies.
Any comments from Commiters ?
Plugin extensions (dependencies) not resolved in reactor build
--
Key: MNG-1323
URL: http://jira.codehaus.org/browse/MNG-1323
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0
Reporter: Kenney Westerhof
Fix For: 2.0.x
Attachments: MNG-1323-core-integration-tests.diff
I've added a dependency on an Ant Task in
project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/
and run that anttask using the antrun plugin.
When run from the project dir itself it runs fine.
When running from the root of the project tree (reactor build, project one
level below root),
antrun bails out because the taskdef can't be found (not on classpath).
It looks like the dependency isn't resolved, or not added to the plugins'
classrealm.
--
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] Issue Comment Edited: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[
http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102012
]
Piotr Tabor edited comment on MNG-1323 at 7/11/07 11:17 PM:
I am trying to work on the issue too.
The simplest solution is in DefaultPluginManager change the code to:
private PluginDescriptor verifyVersionedPlugin( Plugin plugin,
MavenProject project,
ArtifactRepository
localRepository )
File pluginFile = pluginArtifact.getFile();
*if /*( !pluginCollector.isPluginInstalled( plugin ) ||*/ (
pluginContainer == null ) *
{
addPlugin( plugin, pluginArtifact, project, localRepository );
}
*else /*if ( pluginFile.lastModified()
pluginContainer.getCreationDate().getTime() )/ * *
{
getLogger().info(
Reloading plugin container for: + plugin.getKey() + .
The plugin artifact has changed. );
pluginContainer.dispose();
pluginCollector.flushPluginDescriptor( plugin );
addPlugin( plugin, pluginArtifact, project, localRepository );
}
But it slows Maven to much... I will trying to prepare know a little bit better
solution that checks if getted descriptor matches and if
not - to replace it.
The best solution is to build plugin's identifiers that contains hashcode of
dependencies.
Any comments from Commiters ?
was:
I am trying to work on the issue too.
The simplest solution is in DefaultPluginManager change the code to:
private PluginDescriptor verifyVersionedPlugin( Plugin plugin,
MavenProject project,
ArtifactRepository
localRepository )
File pluginFile = pluginArtifact.getFile();
if * /*( !pluginCollector.isPluginInstalled( plugin ) ||*/ * (
pluginContainer == null )
{
addPlugin( plugin, pluginArtifact, project, localRepository );
}
else * /*if ( pluginFile.lastModified()
pluginContainer.getCreationDate().getTime() )*/ *
{
getLogger().info(
Reloading plugin container for: + plugin.getKey() + .
The plugin artifact has changed. );
pluginContainer.dispose();
pluginCollector.flushPluginDescriptor( plugin );
addPlugin( plugin, pluginArtifact, project, localRepository );
}
But it slows Maven to much... I will trying to prepare know a little bit better
solution that checks if getted descriptor matches and if
not - to replace it.
The best solution is to build plugin's identifiers that contains hashcode of
dependencies.
Any comments from Commiters ?
Plugin extensions (dependencies) not resolved in reactor build
--
Key: MNG-1323
URL: http://jira.codehaus.org/browse/MNG-1323
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0
Reporter: Kenney Westerhof
Fix For: 2.0.x
Attachments: MNG-1323-core-integration-tests.diff
I've added a dependency on an Ant Task in
project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/
and run that anttask using the antrun plugin.
When run from the project dir itself it runs fine.
When running from the root of the project tree (reactor build, project one
level below root),
antrun bails out because the taskdef can't be found (not on classpath).
It looks like the dependency isn't resolved, or not added to the plugins'
classrealm.
--
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-1323) Plugin extensions (dependencies) not resolved in reactor build
[
http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102015
]
Piotr Tabor commented on MNG-1323:
--
Sent to [EMAIL PROTECTED]:
Business (user's) problem:
The problem is that maven only once resolve dependencies for every plugin's KEY
(plugin's groupId:artifactId) - not for
every mavan USAGE. But the pom's plugindependencies/dependencies/plugin
tag allows for specifying plugin's dependencies per
every USAGE. In current maven's version (2.0.8-SNAPSHOT, 2.1-SNAPSHOT) the all
plugin's USAGES are using the same dependencies as the first USAGE.
It is especially annoying with maven-antrun-plugin (that is often used with
diffrent tags dependencies).
Implementation situation:
Facts:
*PluginDescriptors class constain's resolved plugin's dependencies
*MavenPluginCollector constains cache - map (pluginKey
(groupId:artifactId) into PluginDescriptors)
*DefaultPluginManager.verifyVersionedPlugin (is responsible for
transferring Plugin object into PluginDescriptor)
uses MavenPluginCollector to check if the right entry exists.
There are possible such a fixes:
1) The worst: Remove caching (every plugin's environment (including) child
plexusContainer has to be recalculated for each maven usage) - simplest to
implement (and working patch is in JIRA comments))
2) Better: Check after getting PluginDescriptor from MavenPluginCollector:
if(comutativeEquals(!pluginCollector.getPluginDescriptor(plugin).getIntroducedDependencyArtifacts(),
plugin.getDependencies()))
{
recalculateTheEntry();
}
adventages: simple to implement (change in single place)
disadventages: If there are two (or more) usage of the same plugin
(interlaced) the one will be cashed and the other will be recalculated
with each use.
3 ) to change the plugin identificator for this cashing from:
groupId:artifactId to groupId:artifactId:comutativeHashCode(getDependencies())
adventages: the best for performance
disadventages:
a) many changes in many places
b) I am a little bit afraid about resolving plugin's transitive
dependencies (they seems to be resolved lazily, so the dependencies list so
the cache key too)...
(but I'm sure it is to be worked out)
Am I right? Please comment... At least to motivate me to work on this issue
further.
Plugin extensions (dependencies) not resolved in reactor build
--
Key: MNG-1323
URL: http://jira.codehaus.org/browse/MNG-1323
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0
Reporter: Kenney Westerhof
Fix For: 2.0.x
Attachments: MNG-1323-core-integration-tests.diff
I've added a dependency on an Ant Task in
project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/
and run that anttask using the antrun plugin.
When run from the project dir itself it runs fine.
When running from the root of the project tree (reactor build, project one
level below root),
antrun bails out because the taskdef can't be found (not on classpath).
It looks like the dependency isn't resolved, or not added to the plugins'
classrealm.
--
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: (MEV-531) ant:ant:1.6.5 (completly wrong dependencies)
ant:ant:1.6.5 (completly wrong dependencies) Key: MEV-531 URL: http://jira.codehaus.org/browse/MEV-531 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Piotr Tabor Current ant:ant pom is: project modelVersion4.0.0/modelVersion groupIdant/groupId artifactIdant/artifactId version1.6.5/version dependencies dependency groupIdxerces/groupId *artifactIdxerces-impl/artifactId* version2.6.2/version optionaltrue/optional /dependency dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId *version2.6.2/version* optionaltrue/optional /dependency /dependencies /project Instead of: artifactIdxerces-impl/artifactId should be artifactIdxercesImpl/artifactId (xerces-impl does not exist in repo) And the version of xml-apis should be: 1.3.04 (2.6.2 does not exist) -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-core-integration-tests.diff Attached integration test to the issue - ready to commit. The test fails if run from parent directory and works if run from children directories. Plugin extensions (dependencies) not resolved in reactor build -- Key: MNG-1323 URL: http://jira.codehaus.org/browse/MNG-1323 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0 Reporter: Kenney Westerhof Fix For: 2.0.x Attachments: MNG-1323-core-integration-tests.diff I've added a dependency on an Ant Task in project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ and run that anttask using the antrun plugin. When run from the project dir itself it runs fine. When running from the root of the project tree (reactor build, project one level below root), antrun bails out because the taskdef can't be found (not on classpath). It looks like the dependency isn't resolved, or not added to the plugins' classrealm. -- 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: (MJAR-75) [PATCH] Wrong artifact type attached to the project by the test-jar goal
[PATCH] Wrong artifact type attached to the project by the test-jar goal
-
Key: MJAR-75
URL: http://jira.codehaus.org/browse/MJAR-75
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.0, 2.2
Environment: All
Reporter: Piotr Tabor
Priority: Critical
The test-jar goal attaches to the project
org.apache.maven.its.it0121:model:jar such a artifact:
- org.apache.maven.its.it0121:model:*jar*:tests
It should attach such an artifact:
- org.apache.maven.its.it0121:model:*test-jar*:tests
The wrong artifacts naming leads to MNG-2871 problem:
The code does not work (because the strings are different:
--MavenProject:
replaceWithActiveArtifact(...)-
Iterator itr = ref.getAttachedArtifacts().iterator();
while(itr.hasNext()) {
Artifact attached = (Artifact) itr.next();
if(
attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())
) {
... (resolve as active's project) ...
}
...
---
pluginArtifact.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*test-jar*:tests
attached.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*jar*:tests
For test-case: look at test (it121) attached to:
http://jira.codehaus.org/browse/MNG-2871
--
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: (MJAR-75) [PATCH] Wrong artifact type attached to the project by the test-jar goal
[
http://jira.codehaus.org/browse/MJAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Tabor updated MJAR-75:
Attachment: maven-jar-plugin-MJAR-75.diff
Patch
[PATCH] Wrong artifact type attached to the project by the test-jar goal
-
Key: MJAR-75
URL: http://jira.codehaus.org/browse/MJAR-75
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.0, 2.1, 2.2
Environment: All
Reporter: Piotr Tabor
Priority: Critical
Attachments: maven-jar-plugin-MJAR-75.diff
The test-jar goal attaches to the project
org.apache.maven.its.it0121:model:jar such a artifact:
- org.apache.maven.its.it0121:model:*jar*:tests
It should attach such an artifact:
- org.apache.maven.its.it0121:model:*test-jar*:tests
The wrong artifacts naming leads to MNG-2871 problem:
The code does not work (because the strings are different:
--MavenProject:
replaceWithActiveArtifact(...)-
Iterator itr = ref.getAttachedArtifacts().iterator();
while(itr.hasNext()) {
Artifact attached = (Artifact) itr.next();
if(
attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())
) {
... (resolve as active's project) ...
}
...
---
pluginArtifact.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*test-jar*:tests
attached.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*jar*:tests
For test-case: look at test (it121) attached to:
http://jira.codehaus.org/browse/MNG-2871
--
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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2871: - Attachment: MNG-2871-core-integration-tests.diff New integrating tests for the issue (ejb-client) and (test-jar) Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Assignee: John Casey Fix For: 2.1-alpha-1 Attachments: MavenProject.java, MNG-2871-core-integration-tests.diff, root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn
[jira] Issue Comment Edited: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98088 ] Piotr Tabor edited comment on MNG-2871 at 6/2/07 7:48 AM: -- New integrating tests for the issue (ejb-client) and (test-jar) attached. ejb-client test passes. test-jar test fails. The dependency types (classifiers) are the most popular... but the problem probably touch all classified (sub-)dependences. was: New integrating tests for the issue (ejb-client) and (test-jar) Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Assignee: John Casey Fix For: 2.1-alpha-1 Attachments: MavenProject.java, MNG-2871-core-integration-tests.diff, root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO]
[jira] Commented: (MWAR-97) War plugin and Overlays handling
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94149 ] Piotr Tabor commented on MWAR-97: - So I think there are need for such tasks (assigned to goals): Goals: *war:exploded* - GenerateClassesJarTask - GenerateManifestTask - CopyResourcesTask - CopyDependenciesTaks - RealizeOverlaysTask *war:inplace* - GenerateClassesJarTask - GenerateManifestTask - CopyResourcesTask - CopyDependenciesTask - RealizeOverlaysTask *war:war* - GenerateClassesJarTask - GenerateManifestTask - CopyResourcesTask - CopyDependenciesTaks - RealizeOverlaysTask - ArchiveWarTask *war:manifest* - GenerateManifestTask I think that every task should have constructor with one parameter that will AbstractWarMojo provide from do Mojo all important informations and some busines methods. War plugin and Overlays handling Key: MWAR-97 URL: http://jira.codehaus.org/browse/MWAR-97 Project: Maven 2.x War Plugin Issue Type: New Feature Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 Reporter: Piotr Tabor Assignee: Stephane Nicoll Attachments: MWAR-97.diff Piotr and I are currently working on the war plugin and especially this overlay mechanism that needs to be upgraded. Currently a couple of issues [1] in the war plugin are linked to this functionality and we should really address them. The idea here is to provide a better way to handle overlays through an explicit configuration. An overlay has the following parameters: * groupId * artifactId * classifier (optionnal) * includes (default includes everything) * excludes (default META-INF) The order in which overlays are specified defined the order in which they are applied. An overlay without a groupId/artifactId is considered as the current build. If no such overlay is defined, it is applied *last*. The behavior should be deterministic so the copy will happen not matter how if a file is newer than the one being applied. Overlays order always wins. If no overlays section is defined, the wars are processed as before; dependentWarIncludes and dependentWarExcludes are honored. If an overlays section is defined and those configuration items are defined, they are ignored and a warning is logged. If a dependent war is missing in the overlays section, it's applied after custom overlays *and* before the current build (if the current build is not specified of course) with the default includes/excludes. Does that sounds ok to you? If so I'll add the proposition to the war site and start the implementation with Piotr. We're also thinking about integrating the merge functionality of the cargo plugin but we still need to discuss with the cargo guys if it will be feasible. Please comment. Stéphane -- 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-2921) ejb-client dependency no longer working
[ http://jira.codehaus.org/browse/MNG-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2921: - Attachment: MNG-2921.diff Patch proposition ejb-client dependency no longer working --- Key: MNG-2921 URL: http://jira.codehaus.org/browse/MNG-2921 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: Fedora Core 6 Reporter: Frank Cornelis Priority: Blocker Attachments: MNG-2921.diff, test.zip When running 'mvn clean install' on the test project (see attachment) under Maven 2.0.5 every builds as expected. On Maven 2.0.6 it no longer compiles. On Maven 2.0.5 I get in the log: [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) Under Maven 2.0.6 I get: [DEBUG] be.frankcornelis.maven:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] be.frankcornelis.maven:model:ejb-client:client:1.0-SNAPSHOT (selected for null) and an error message saying it cannot find the required interfaces defined in Model. When I remove type:ejb-client in the Client pom.xml it compiles again. -- 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: (MWAR-22) patch to allow extra webapp and webapp/WEB-INF/classes files to be specified that override existing files
[ http://jira.codehaus.org/browse/MWAR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92278 ] Piotr Tabor commented on MWAR-22: - I will have to apply an overlay with new resources when 2.1 version will be released . Look at http://jira.codehaus.org/browse/MWAR-97. patch to allow extra webapp and webapp/WEB-INF/classes files to be specified that override existing files - Key: MWAR-22 URL: http://jira.codehaus.org/browse/MWAR-22 Project: Maven 2.x War Plugin Issue Type: Improvement Reporter: Cameron Braid Attachments: maven-war-plugin-extraWarResources.patch Currnelty, there is no way to execute a plugin inbetween the 'build exploded webapp' part of this plugin, and the 'zip up resources' bit. I have the need to override classpath resources, and sometimes other webapp resources, based on a deployment target, such as test / staging or production. With this patch, I will be able to have files layed out like this : /profile/test/config.properties /src/main/resources/config.properties then configure the war plugin : configuration extraWebappClassesprofile/test/extraWebappClasses /configuration thus producing a war that contains profile/test/config.properties instead of the default /src/main/resources/config.properties I have investigated alternative ways to achive this goal, and none of them seemed easy. Some ideas : * split the package phase into 2 phases - preparePackage and package * provide a generic technique to allow plugins to expose extension points where other plugins can hook into * create a plugin that runs after the war plugin, that creates a new war - slow since the ziping will need to be done twice i'm keen to hear anyone's thoughts on the mailing list or in irc - my nick is Fracture -- 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: (MWAR-97) War plugin and Overlays handling
[ http://jira.codehaus.org/browse/MWAR-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MWAR-97: Attachment: MWAR-97.diff I attached complete implementation with tests. The only problem with testExplodedWarMergeWarUpdated(org.apache.maven.plugin.war.WarExplodedMojoTest (connected with a copyFileIfModified method) needs some discuss. War plugin and Overlays handling Key: MWAR-97 URL: http://jira.codehaus.org/browse/MWAR-97 Project: Maven 2.x War Plugin Issue Type: New Feature Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3 Reporter: Piotr Tabor Attachments: MWAR-97.diff Piotr and I are currently working on the war plugin and especially this overlay mechanism that needs to be upgraded. Currently a couple of issues [1] in the war plugin are linked to this functionality and we should really address them. The idea here is to provide a better way to handle overlays through an explicit configuration. An overlay has the following parameters: * groupId * artifactId * classifier (optionnal) * includes (default includes everything) * excludes (default META-INF) The order in which overlays are specified defined the order in which they are applied. An overlay without a groupId/artifactId is considered as the current build. If no such overlay is defined, it is applied *last*. The behavior should be deterministic so the copy will happen not matter how if a file is newer than the one being applied. Overlays order always wins. If no overlays section is defined, the wars are processed as before; dependentWarIncludes and dependentWarExcludes are honored. If an overlays section is defined and those configuration items are defined, they are ignored and a warning is logged. If a dependent war is missing in the overlays section, it's applied after custom overlays *and* before the current build (if the current build is not specified of course) with the default includes/excludes. Does that sounds ok to you? If so I'll add the proposition to the war site and start the implementation with Piotr. We're also thinking about integrating the merge functionality of the cargo plugin but we still need to discuss with the cargo guys if it will be feasible. Please comment. Stéphane -- 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: (MWAR-53) WAR plugin does not allow for ignoring the web.xml file
[ http://jira.codehaus.org/browse/MWAR-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90955 ] Piotr Tabor commented on MWAR-53: - The issue depends on org.codehaus.plexus.archiver.war.WarArchiver class (initZipOutputStream method), which doesn't allow to create war file without web.xml descriptor. The Ant WAR task doesn't allow this neither (org.apache.tools.ant.taskdefs.War) When I changed the maven-war-plugin to ignore lack of the file (warn only), I got the result: [INFO] Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) 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:585) 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 assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:146) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) at org.codehaus.plexus.archiver.war.WarArchiver.initZipOutputStream(WarArchiver.java:148) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:348) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250) at org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:402) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:188) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) ... 18 more So I think, the issue shouldn't be fixed. The possibility to cope with overlay's problem will be provided in other way. WAR plugin does not allow for ignoring the web.xml file --- Key: MWAR-53 URL: http://jira.codehaus.org/browse/MWAR-53 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Andreas Schildbach The WAR plugin does not allow for ignoring the web.xml file. I know that a WAR without web.xml does not make any sense in the normal use case, but if I'd like to overlay/join WARs with the WAR plugin (by defining dependencies to other WARs), there can be only one web.xml in the candidates (the WAR plugin does not join web.xml like cargo uberwar does). If I do not have a web.xml in my src/main/webapp folder, the WAR plugin complains. -- 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: (MWAR-91) Dependency as type=test-jar and scope=compile not included in WEB-INF/lib on packaging.
[ http://jira.codehaus.org/browse/MWAR-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MWAR-91: Attachment: MWAR-91-maven-war-plugin.patch Patch to fix the issue (to revision 519283). Dependency as type=test-jar and scope=compile not included in WEB-INF/lib on packaging. --- Key: MWAR-91 URL: http://jira.codehaus.org/browse/MWAR-91 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Mac OSX. Maven 2.0.4 Reporter: Franz Garsombke Attachments: MWAR-91-maven-war-plugin.patch I have a dependency defined below: dependency groupIdcom.foo.ejb.server/groupId artifactIdslm-ejb-server/artifactId typetest-jar/type scopecompile/scope /dependency I would expect it in the WEB-INF/lib directory at time of packaging. Interestingly enough its transitive dependencies show up but not the actual test jar. The reason we need it in the WAR is for Cactus tests. I agree Cactus is evil but can not remove it in the short term. -- 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: (MWAR-91) Dependency as type=test-jar and scope=compile not included in WEB-INF/lib on packaging.
[ http://jira.codehaus.org/browse/MWAR-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MWAR-91: Attachment: MWAR-91-test.tar Simple project to reply the issue on 2.0.2 version, and not to reply the issue on patched 2.0.3 version Dependency as type=test-jar and scope=compile not included in WEB-INF/lib on packaging. --- Key: MWAR-91 URL: http://jira.codehaus.org/browse/MWAR-91 Project: Maven 2.x War Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Mac OSX. Maven 2.0.4 Reporter: Franz Garsombke Attachments: MWAR-91-maven-war-plugin.patch, MWAR-91-test.tar I have a dependency defined below: dependency groupIdcom.foo.ejb.server/groupId artifactIdslm-ejb-server/artifactId typetest-jar/type scopecompile/scope /dependency I would expect it in the WEB-INF/lib directory at time of packaging. Interestingly enough its transitive dependencies show up but not the actual test jar. The reason we need it in the WAR is for Cactus tests. I agree Cactus is evil but can not remove it in the short term. -- 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: (MWAR-82) setting archiveClasses to true create the jar in WEB-INF/lib but does not remove WEB-INF/classes
[
http://jira.codehaus.org/browse/MWAR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90278
]
Piotr Tabor commented on MWAR-82:
-
What commands have you been using to generate your war ?
I have an idea that the scenario was:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
*archiveClassesfalse/archiveClasses!--or missing--*
/configuration
/execution
/executions
/plugin
then:
mvn package
after that user changed in pom.xml to: *archiveClassestrue/archiveClasses*
then:
mvn package
In effect the final zzz.war constains both: classes and zzz.jar.
It is reason of the target/zzz directory, which constains zzz classes ofter
first mvn package,
and zzz.jar after the second mvn package.
Instead the second mvn package the user should use mvn clean package, to
run the
war plugin on an empty target/zzz dir.
If the scenario is true - I think that this issue is not a bug.
setting archiveClasses to true create the jar in WEB-INF/lib but does not
remove WEB-INF/classes
Key: MWAR-82
URL: http://jira.codehaus.org/browse/MWAR-82
Project: Maven 2.x War Plugin
Issue Type: Bug
Reporter: Sebastien Brunot
This bug has been explained on the maven users mailing list:
Hi Sebastien
It seems to be a bug.
In the code [1] we have :
if ( archiveClasses )
{
createJarArchive( libDirectory );
}
else
{
copyDirectoryStructureIfModified( classesDirectory,
webappClassesDirectory );
}
The content of the classes directory is never removed (neither in
createJarArchive nor somewhere else).
Can you create an issue please ?
Thx
Arnaud
[1]
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/AbstractWarMojo.java?revision=471624
Sebastien Brunot wrote:
Hi all,
i've got a war project which pom build section contains the following
statements:
!-- Package webapp classes into a jar instead of under
WEB-INF/classes --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
executions
execution
goals
goalwar/goal
/goals
configuration
archiveClassestrue/archiveClasses
/configuration
/execution
/executions
/plugin
As a result, all the classes and resources from my war project are
packaged in a jar that is copied in the WEB-INF/lib directory of the
war artifact.
But i don't understand why the war artifact still contains copy of the
classes and resources under WEB-INF/classes... Does anybody think that
i've misconfigured the war plugin ?
Thanks for your help,
Sebastien
--
View this message in context:
http://www.nabble.com/Configuring-war-plugin-for-using-a-jar-instead-of-WEB-INF-classes-tf2589199s177.html#a7219855
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: (MWAR-80) Classifier in jar file name is removed once assembled into war file
[ http://jira.codehaus.org/browse/MWAR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90281 ] Piotr Tabor commented on MWAR-80: - It is still true. When configuration is: artifactIdzzz/artifactId ... configuration classifierfine/classifies archiveClassestrue/archiveClasses /configuration as a result we will get: zzz-fine.war but also: *zzz-fine.war/WEB-INF/lib/zzz.jar* It is probably by design. So I think that there are two possibilities: a) to add to documentation comment about it and close the bug b) to add new parameter - for example achiveClassesClassifierbadachiveClassesClassifier which will create: *zzz-fine.war/WEB-INF/lib/zzz-bad.jar*. If it's useful (actually I don't see any use case for that stuff), I can prepare a patch. Classifier in jar file name is removed once assembled into war file --- Key: MWAR-80 URL: http://jira.codehaus.org/browse/MWAR-80 Project: Maven 2.x War Plugin Issue Type: Bug Environment: Maven 2.0.4, JDK 1.5, maven-war-plugin version 2.0 Reporter: Andreas Guther We use the Maven classifier to distinguish between different jar files of the same version build for different purposes. An example would be the classifier used for TestNG to distinguish between jdk15 and jdk14 jar files. I noticed that the jar file (for example test-1.0-classifier.jar) ends up in the WEB-INF/lib folder with the classifier removed (i.e. following the example test.1.0.jar). This is unexpected and confusing. Since there is very little documentation about the expected behavior while using classifiers, it is not clear if this is intenionally or a bug. If intenionally, it should be mentioned in the maven-war-plugin documentation. Maybe in that case it would be an enhancement to configure if the classifier should be preserved or removed. However, the current behavior is undocumented and unexpected. -- 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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.5, 2.0.4 Environment: Not platform dependent Reporter: Piotr Tabor I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: pl.waw.tabor:client:jar:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots
[jira] Updated: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-2871: - Attachment: root.tar The simple project - to repeat the bug. Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Attachments: root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT
[jira] Commented: (MNG-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89813 ] Piotr Tabor commented on MNG-2871: -- The bug is very serious - because it happens every time you use mvn release:prepare plugin (because there are started integration-tests in embedded maven session) - and they always fail - because there is no such a artifact in maven local repository after increasing version number. Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Attachments: root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1)
[jira] Created: (SUREFIRE-293) Possibility to run test with not isolated Classloader
Possibility to run test with not isolated Classloader - Key: SUREFIRE-293 URL: http://jira.codehaus.org/browse/SUREFIRE-293 Project: Maven Surefire Issue Type: Improvement Components: classloading Affects Versions: 2.3 Reporter: Piotr Tabor Attachments: useIsolatedClassLoaderPatch.diff I need a feature to run Maven's test in not isolated classloader. So I implemented it (and I attached patch to add it to maven trunk). I added useIsolatedClassLoader parameter (default to true), which is usefull only when forkMode is none/never. If it's false - the parent classloader is set to the tests classloader. The option of not isolated classloader is important when MVN is run embaded in another program. The use case for the feature is: I have J2EE system with complicated Integration Tests (as Junit test cases). I used them by mvn test -Di-tests (i-tests is my profile to integration tests). Then i found, that i have to be able to test my system with using only Local interfaces of EJB (there are same cases that everythink is ok by remote and there are problems by local interaces - so i have to do both tests ). So I need to run's tests on Jboss application server. So I have written a service to run MVN as jboss service. But i couldn't use my test's because of isolated classloader. So please -- apply the patch to next plugin version. -- 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
