[jira] (ARCHETYPE-446) Generate Mojo should use security for repository access
[ https://jira.codehaus.org/browse/ARCHETYPE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354889#comment-354889 ] Carlo Sciolla commented on ARCHETYPE-446: - I believe this is a dupe of ARCHETYPE-204 Generate Mojo should use security for repository access --- Key: ARCHETYPE-446 URL: https://jira.codehaus.org/browse/ARCHETYPE-446 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.2 Environment: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 07:51:28-0600) Maven home: C:\dev\tools\build\apache-maven-3.0.5 Java version: 1.7.0_25, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk\7\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Bryan Stopp Priority: Blocker Attachments: mvn.log My organization uses Artifactory to host our repositories. It is secured against unauthorized access. I have managed to expose the archetype-catalog.xml file to public anonymous access, which allows me to access a custom archetype. However whenever I attempt to select my custom archetype, I receive a message stating that the archetype cannot be found. Using debug, i can see that the Mojo is receiving an Unauthorized response from the remote system. While I understand that the password configured in my settings.xml would not be used for the 'vml-aem-archetype-repo', it should be used for the second resolving entry 'central'. The archetype resolver should use the same communication protocols, security included, when resolving archetypes as the build tool uses for resolving/dependencies. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-460) archetype:generate does not use settings.xml when archetype is in repository with restricted access
[ https://jira.codehaus.org/browse/ARCHETYPE-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354888#comment-354888 ] Carlo Sciolla commented on ARCHETYPE-460: - I believe this is a dupe of ARCHETYPE-204 archetype:generate does not use settings.xml when archetype is in repository with restricted access --- Key: ARCHETYPE-460 URL: https://jira.codehaus.org/browse/ARCHETYPE-460 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.2 Environment: Apache Maven 3.2.2 Java version: 1.8.0_05, vendor: Oracle Corporation Default locale: de_DE, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: dos Reporter: heapifyman Priority: Blocker I have an archetype deployed to an Artifactory repository with restricted access. I have defined the server with id, username and password in my settings.xml. When I run mvn archetype:generate -DarchetypeRepository=my_artifactory_reop_with_restricted_access I get Caused by: org.apache.maven.wagon.authorization.AuthorizationException: Not authorized , ReasonPhrase:Unauthorized. Apparently, archetype:generate does not take into account the access rights defined in settings.xml -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ https://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301527#comment-301527 ] Carlo Sciolla commented on MNG-3283: @William Ashley same here Plugins that require dependency resolution in early phases cause dependency resolution issue Key: MNG-3283 URL: https://jira.codehaus.org/browse/MNG-3283 Project: Maven 2 3 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.7 Reporter: Alfie Kirkpatrick Assignee: Brian Fox Fix For: Issues to be reviewed for 3.x Attachments: maven-dependency-bug.zip What we're seeing is that some multi-project configurations succeed on 'mvn package' but fail on 'mvn generate-sources'. They are failing when one project in the reactor references another project in the reactor which is not installed in the local repo. It seems that the referenced project has not quite made it into the reactor this early in the phase lifecycle. But it does work correctly if you target a later phase at the outset which is really confusing. The problem only occurs when a plugin binds itself to the generate-sources phase and has @requiresDependencyResolution, presumably because this is what triggers resolution of the referenced dependency too early in the lifecycle, and hence the error. We are seeing this problem when trying to run 'mvn eclipse:eclipse' because this only executes the generate-sources phase by default and we have other mojos which genuinely do generate source, such as java2wsdl. A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. Attached is a really simple project that exhibits this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4988) API to calculate execution plan without full mojo execution configuration
[ https://jira.codehaus.org/browse/MNG-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=297241#comment-297241 ] Carlo Sciolla commented on MNG-4988: Is there any way to exploit this enhancement on the command line? API to calculate execution plan without full mojo execution configuration - Key: MNG-4988 URL: https://jira.codehaus.org/browse/MNG-4988 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Affects Versions: 3.0 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.0.3 Attachments: MNGECLIPSE-2724.diff, MNGECLIPSE-2724.diff m2e uses project execution plan to determine how to configure the project in eclipse workspace and what to do during workbench build. Not all mojo execution bound to execution plan are relevant for this (think enforcer or deploy plugin), so m2e needs an API to analyse execution plan and perform full configuration of interesting mojo execution only. Original m2e jira https://issues.sonatype.org/browse/MNGECLIPSE-2724 Proposed patch attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4988) API to calculate execution plan without full mojo execution configuration
[ https://jira.codehaus.org/browse/MNG-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=297241#comment-297241 ] Carlo Sciolla edited comment on MNG-4988 at 4/26/12 5:39 AM: - Is there any way to leverage this enhancement on the command line? was (Author: skuro): Is there any way to exploit this enhancement on the command line? API to calculate execution plan without full mojo execution configuration - Key: MNG-4988 URL: https://jira.codehaus.org/browse/MNG-4988 Project: Maven 2 3 Issue Type: Improvement Components: Embedding Affects Versions: 3.0 Reporter: Igor Fedorenko Assignee: Igor Fedorenko Fix For: 3.0.3 Attachments: MNGECLIPSE-2724.diff, MNGECLIPSE-2724.diff m2e uses project execution plan to determine how to configure the project in eclipse workspace and what to do during workbench build. Not all mojo execution bound to execution plan are relevant for this (think enforcer or deploy plugin), so m2e needs an API to analyse execution plan and perform full configuration of interesting mojo execution only. Original m2e jira https://issues.sonatype.org/browse/MNGECLIPSE-2724 Proposed patch attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira