[jira] Commented: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGONSSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102132 ] Benjamin Bentmann commented on WAGONSSH-42: --- Thanks for your advice about using umask, I will try this at the next occasion. As for the ScpWagon, I recently discovered the related discussion at http://jira.codehaus.org/browse/WAGONSSH-44. If the world of SSH server implementations is indeed so evil that there is no standard/reliable way of setting the file permissions, I would appreciate a configuration setting for the ScpWagon to enforce the (otherwise costly) usage of chmod. After all, a long but successful deploy is still better than a quick but improper deploy. Cannot deploy files over existing files if someone else originally uploaded them. - Key: WAGONSSH-42 URL: http://jira.codehaus.org/browse/WAGONSSH-42 Project: wagon-ssh Issue Type: Bug Affects Versions: 1.0-alpha-6 Environment: Desktop OS is Windows XP. Deploying to Solaris server using Tectia SSH2 Client. Reporter: Frank Russo Priority: Critical Attachments: File sharing issue with maven-deploy using wagon.txt On first deploy, everything works fine. On next deploy, if a different developer runs the command, the attached error occurs(see attached the original email posted to the Maven Users Mailing List.) The file is owned by the first developer, but has full rwx access (777). If developer 2 directly connects to the machine, they can do anything to the file, so it's not a Unix permissions issue... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1345) Create projects from metadata fails with Malformed URL if port is present (http://[EMAIL PROTECTED]/svn/...)
[ http://jira.codehaus.org/browse/CONTINUUM-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1345. --- Assignee: Emmanuel Venisse Resolution: Duplicate Create projects from metadata fails with Malformed URL if port is present (http://[EMAIL PROTECTED]/svn/...) Key: CONTINUUM-1345 URL: http://jira.codehaus.org/browse/CONTINUUM-1345 Project: Continuum Issue Type: Bug Affects Versions: 1.1-alpha-2 Environment: kubuntu feisty Reporter: Greg Johnson Assignee: Emmanuel Venisse Failure when adding project via Url - MungedHttpsURL is missing : if svn url includes a port number. Add project POM Url of http://www.xxx.com:44302/svn/***/trunk/***/pom.xml; results in: INFO Action:create-projects-from-metadata - Malformed URL (MungedHttpsURL is not valid): http://user:[EMAIL PROTECTED]/svn/***/trunk/***/pom.xml Impact: Product cannot be used if repository URL contains a port number. -- 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: (CONTINUUM-1093) After validation, logged in user is shown the login page
[ http://jira.codehaus.org/browse/CONTINUUM-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1093: Comment: was deleted After validation, logged in user is shown the login page Key: CONTINUUM-1093 URL: http://jira.codehaus.org/browse/CONTINUUM-1093 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak Fix For: 1.1-beta-2 After registering, clicking the validation email link, and completing validation, the user is already logged in, but the login page is displayed. The Project Groups page seems to be the default for the rest of the app, and would be more appropriate. -- 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: (CONTINUUM-1093) After validation, logged in user is shown the login page
[ http://jira.codehaus.org/browse/CONTINUUM-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated CONTINUUM-1093: Fix Version/s: (was: 1.1-beta-1) 1.1-beta-2 After validation, logged in user is shown the login page Key: CONTINUUM-1093 URL: http://jira.codehaus.org/browse/CONTINUUM-1093 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak Fix For: 1.1-beta-2 After registering, clicking the validation email link, and completing validation, the user is already logged in, but the login page is displayed. The Project Groups page seems to be the default for the rest of the app, and would be more appropriate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (CONTINUUM-1194) Project is stuck in the Build in Progress state if the associated exception has more than 8192 chars
[ http://jira.codehaus.org/browse/CONTINUUM-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse reopened CONTINUUM-1194: - Project is stuck in the Build in Progress state if the associated exception has more than 8192 chars -- Key: CONTINUUM-1194 URL: http://jira.codehaus.org/browse/CONTINUUM-1194 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-alpha-1 Reporter: Stephane Nicoll Assignee: Emmanuel Venisse Fix For: 1.1-beta-1 Attachments: screenshot.png We have added unit tests to one of our project and some of them are crashing from time to time due to a race condition with the database connections. Since then, the project is always in the Build In progress state even if the build is actually terminated in the log (Build failure because one test failed). The project never leaves this state, if we consult the builds summary we have a couple of builds in the Build In progress state (?!) See screenshot. -- 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-3104) can not get results when i use maven eclipse plugins
can not get results when i use maven eclipse plugins Key: MNG-3104 URL: http://jira.codehaus.org/browse/MNG-3104 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: robinson wang i use the artifactory as the cach repository, i have defined a Private-internal-repository and a Ibiblio-cache-repository in the artifactory . then i deploy a private jar like 'aaa.jar' to the Private-internal-repository . but when i open the repository search window and type 'aaa' in the query textfield , i can not see any results then i edit the pom.xml and add this : dependency groupIdaaa/groupId artifactIdaaa/artifactId version0.92/version /dependency when i save this file , the maven eclipse plugins can import the aaa.jar automatically. now i try to search 'aaa' in the query textfield again , there is a result. -- 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: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGONSSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102133 ] Benjamin Bentmann edited comment on WAGONSSH-42 at 7/13/07 2:30 AM: umask 002 really works fine. Great thanks! One final note about the explicit chmod for the ScpWagon: If this gets implemented, chmod must not fail the deployment if the currently executing user is not the file owner. Either chmod is only issued for an initial deployment of the file or it silently fails if executed on behalf of a foreign user. Otherwise, we will run into the problem this issue for SftpWagon is already about. was: umask 002 really works fine. Great thanks! One final note about the explicit chmod for the ScpWagon: If this gets implemented, chmod must not fail the deployment if the currently executing user is not the file owner. Either chmod is only issued for an initial deployment of the file or it silently fails if executed on behave of a foreign user. Otherwise, we will run into the problem this issue for SftpWagon is already about. Cannot deploy files over existing files if someone else originally uploaded them. - Key: WAGONSSH-42 URL: http://jira.codehaus.org/browse/WAGONSSH-42 Project: wagon-ssh Issue Type: Bug Affects Versions: 1.0-alpha-6 Environment: Desktop OS is Windows XP. Deploying to Solaris server using Tectia SSH2 Client. Reporter: Frank Russo Priority: Critical Attachments: File sharing issue with maven-deploy using wagon.txt On first deploy, everything works fine. On next deploy, if a different developer runs the command, the attached error occurs(see attached the original email posted to the Maven Users Mailing List.) The file is owned by the first developer, but has full rwx access (777). If developer 2 directly connects to the machine, they can do anything to the file, so it's not a Unix permissions issue... -- 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: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGONSSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102133 ] Benjamin Bentmann commented on WAGONSSH-42: --- umask 002 really works fine. Great thanks! One finally note about the explicit chmod for the ScpWagon: If this gets implemented, chmod must not fail the deploy if the currently executing user is not the file owner. Either chmod is only issued for an initial deploy of the file or it silently fails if executed on behave of a foreign user. Otherwise, we will run into the problem this issue for SftpWagon is already about. Cannot deploy files over existing files if someone else originally uploaded them. - Key: WAGONSSH-42 URL: http://jira.codehaus.org/browse/WAGONSSH-42 Project: wagon-ssh Issue Type: Bug Affects Versions: 1.0-alpha-6 Environment: Desktop OS is Windows XP. Deploying to Solaris server using Tectia SSH2 Client. Reporter: Frank Russo Priority: Critical Attachments: File sharing issue with maven-deploy using wagon.txt On first deploy, everything works fine. On next deploy, if a different developer runs the command, the attached error occurs(see attached the original email posted to the Maven Users Mailing List.) The file is owned by the first developer, but has full rwx access (777). If developer 2 directly connects to the machine, they can do anything to the file, so it's not a Unix permissions issue... -- 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: (WAGONSSH-42) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGONSSH-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102133 ] Benjamin Bentmann edited comment on WAGONSSH-42 at 7/13/07 2:29 AM: umask 002 really works fine. Great thanks! One final note about the explicit chmod for the ScpWagon: If this gets implemented, chmod must not fail the deployment if the currently executing user is not the file owner. Either chmod is only issued for an initial deployment of the file or it silently fails if executed on behave of a foreign user. Otherwise, we will run into the problem this issue for SftpWagon is already about. was: umask 002 really works fine. Great thanks! One finally note about the explicit chmod for the ScpWagon: If this gets implemented, chmod must not fail the deploy if the currently executing user is not the file owner. Either chmod is only issued for an initial deploy of the file or it silently fails if executed on behave of a foreign user. Otherwise, we will run into the problem this issue for SftpWagon is already about. Cannot deploy files over existing files if someone else originally uploaded them. - Key: WAGONSSH-42 URL: http://jira.codehaus.org/browse/WAGONSSH-42 Project: wagon-ssh Issue Type: Bug Affects Versions: 1.0-alpha-6 Environment: Desktop OS is Windows XP. Deploying to Solaris server using Tectia SSH2 Client. Reporter: Frank Russo Priority: Critical Attachments: File sharing issue with maven-deploy using wagon.txt On first deploy, everything works fine. On next deploy, if a different developer runs the command, the attached error occurs(see attached the original email posted to the Maven Users Mailing List.) The file is owned by the first developer, but has full rwx access (777). If developer 2 directly connects to the machine, they can do anything to the file, so it's not a Unix permissions issue... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1194) Project is stuck in the Build in Progress state if the associated exception has more than 8192 chars
[ http://jira.codehaus.org/browse/CONTINUUM-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1194. --- Assignee: Emmanuel Venisse Resolution: Fixed Fixed by truncating the exception string Project is stuck in the Build in Progress state if the associated exception has more than 8192 chars -- Key: CONTINUUM-1194 URL: http://jira.codehaus.org/browse/CONTINUUM-1194 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-alpha-1 Reporter: Stephane Nicoll Assignee: Emmanuel Venisse Fix For: 1.1-beta-2 Attachments: screenshot.png We have added unit tests to one of our project and some of them are crashing from time to time due to a race condition with the database connections. Since then, the project is always in the Build In progress state even if the build is actually terminated in the log (Build failure because one test failed). The project never leaves this state, if we consult the builds summary we have a couple of builds in the Build In progress state (?!) See screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1194) Project is stuck in the Build in Progress state if the associated exception has more than 8192 chars
[ http://jira.codehaus.org/browse/CONTINUUM-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1194. --- Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 Project is stuck in the Build in Progress state if the associated exception has more than 8192 chars -- Key: CONTINUUM-1194 URL: http://jira.codehaus.org/browse/CONTINUUM-1194 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-alpha-1 Reporter: Stephane Nicoll Assignee: Emmanuel Venisse Fix For: 1.1-beta-1 Attachments: screenshot.png We have added unit tests to one of our project and some of them are crashing from time to time due to a race condition with the database connections. Since then, the project is always in the Build In progress state even if the build is actually terminated in the log (Build failure because one test failed). The project never leaves this state, if we consult the builds summary we have a couple of builds in the Build In progress state (?!) See screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1228) OgnlException while setting property 'projectGroupId' on redirect
[ http://jira.codehaus.org/browse/CONTINUUM-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1228. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1-beta-2) 1.1-beta-1 I changed the loglevel to ERROR OgnlException while setting property 'projectGroupId' on redirect - Key: CONTINUUM-1228 URL: http://jira.codehaus.org/browse/CONTINUUM-1228 Project: Continuum Issue Type: Bug Affects Versions: 1.1-alpha-1 Environment: build 20070327.03 Reporter: David Roussel Assignee: Emmanuel Venisse Priority: Minor Fix For: 1.1-beta-1 On a multi-module project, any group action like build or release causes the following exception. Is assuming it's only the redirect after post that is afftected so it's minor severity. Has occured in builds I downloaded from the CI mails. Affects builds continuum-20070317.05.tar.gz and continuum-20070327.03.tar.gz not sure what SVN revision that relates too. Issue may be related to CONTINUUM-959, but doesn't seem like a duplicate. 2007-03-28 14:36:39,752 [SocketListener0-0] WARN OgnlUtil - Caught OgnlException while setting property 'projectGroupId' on type 'com.opensymphony.webwork.dispatcher.ServletActionRedirectResult'. ognl.NoSuchPropertyException: com.opensymphony.webwork.dispatcher.ServletActionRedirectResult.projectGroupId at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:133) at com.opensymphony.xwork.util.OgnlValueStack$ObjectAccessor.setProperty(OgnlValueStack.java:64) at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1629) at ognl.ASTProperty.setValueBody(ASTProperty.java:105) at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177) at ognl.SimpleNode.setValue(SimpleNode.java:246) at ognl.Ognl.setValue(Ognl.java:476) at com.opensymphony.xwork.util.OgnlUtil.setValue(OgnlUtil.java:186) at com.opensymphony.xwork.util.OgnlUtil.internalSetProperty(OgnlUtil.java:360) at com.opensymphony.xwork.util.OgnlUtil.setProperties(OgnlUtil.java:76) at com.opensymphony.xwork.util.OgnlUtil.setProperties(OgnlUtil.java:49) at com.opensymphony.xwork.ObjectFactory.buildResult(ObjectFactory.java:186) at org.codehaus.plexus.xwork.PlexusObjectFactory.buildResult(PlexusObjectFactory.java:166) at com.opensymphony.xwork.DefaultActionInvocation.createResult(DefaultActionInvocation.java:171) at com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:308) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:206) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:73) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.security.ui.web.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:102) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.security.ui.web.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:174) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
[jira] Commented: (MRM-426) Search does not work for snapshots because of different version values in index and database when the snapshot version is unique
[ http://jira.codehaus.org/browse/MRM-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102151 ] Maria Odea Ching commented on MRM-426: -- From the discussions posted in the dev list thread, the approach for this would be: - index all versions (timestamped snapshots, generic snapshots and released versions) - add all versions in the database - include *-SNAPSHOT when artifact is browsed. This should point to the latest timestamped version if no *-SNAPSHOT exists in repo/db. Search does not work for snapshots because of different version values in index and database when the snapshot version is unique Key: MRM-426 URL: http://jira.codehaus.org/browse/MRM-426 Project: Archiva Issue Type: Bug Affects Versions: 1.0-alpha-2 Reporter: Maria Odea Ching Assignee: Maria Odea Ching When an artifact with unique snapshots is searched from Archiva, the search result would contain different hits for that artifact which has the same version but when you click the version to browse the artifact.. an ObjectNotFound error is returned. Below is an example of this behavior. The artifact to be searched is castor-anttasks. Let's say it has 3 SNAPSHOT versions 1.1.2-20070427.065136-1, 1.1.2-20070506.163513-2 and 1.1.2-20070506.163513-3 in the repository, and the path to this artifact is [REPO]/org/codehaus/castor/castor-anttasks/1.1.2-SNAPSHOT. The search results would then look like this: Hits: 3 of 3 castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT castor-anttasks org / codehaus / castor / castor-anttasks | Version(s): 1.1.2-SNAPSHOT When you click either of the versions to browse the artifact, what you would get is this error: 'Unable to find project model for [org.codehaus.castor:castor-anttasks:1.1.2-SNAPSHOT]' -- 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: (NMAVEN-84) Reseach feasability of SHFB plugin
Reseach feasability of SHFB plugin -- Key: NMAVEN-84 URL: http://jira.codehaus.org/browse/NMAVEN-84 Project: NMaven Issue Type: Sub-task Reporter: Campbell Boucher-Burnet -- 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: (NMAVEN-68) Sandcastle Maven Plugin
[ http://jira.codehaus.org/browse/NMAVEN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102159 ] Campbell Boucher-Burnet commented on NMAVEN-68: --- - should look into invoking sandcastle through the Sandcastle Help File Builder API / config document... See: http://www.codeplex.com/SHFB Sandcastle Maven Plugin --- Key: NMAVEN-68 URL: http://jira.codehaus.org/browse/NMAVEN-68 Project: NMaven Issue Type: New Feature Environment: Microsoft, Windows Reporter: Shane Isbell Priority: Minor A Maven plugin for sandcastle, which is Microsoft's API document generator. -- 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: (CONTINUUM-1347) WebDAV enable the working copies
[ http://jira.codehaus.org/browse/CONTINUUM-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trygve Laugstol updated CONTINUUM-1347: --- Description: When debugging test failures it would be nice to be able to mount the working copies on my local laptop so I can browse and view files with Finder (on os x), Nautilus on Gnome or cadaver. Complexity: Expert (was: Intermediate) WebDAV enable the working copies Key: CONTINUUM-1347 URL: http://jira.codehaus.org/browse/CONTINUUM-1347 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Trygve Laugstol When debugging test failures it would be nice to be able to mount the working copies on my local laptop so I can browse and view files with Finder (on os x), Nautilus on Gnome or cadaver. -- 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: (NMAVEN-84) Reseach feasability of SHFB plugin
[ http://jira.codehaus.org/browse/NMAVEN-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102160 ] Campbell Boucher-Burnet commented on NMAVEN-84: --- 1. Sorry about getting the priority wrong... please bump it down. 2. I'd be happy to do the research... I've played with, patched and recompiled SHFB recently, so I know it a bit, but I could benefit from your experience with trying to invoke sandcastle directly. Reseach feasability of SHFB plugin -- Key: NMAVEN-84 URL: http://jira.codehaus.org/browse/NMAVEN-84 Project: NMaven Issue Type: Sub-task Reporter: Campbell Boucher-Burnet -- 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: (CONTINUUM-1346) Error while parsing test results
[
http://jira.codehaus.org/browse/CONTINUUM-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated CONTINUUM-1346:
Fix Version/s: 1.1-beta-2
Error while parsing test results
Key: CONTINUUM-1346
URL: http://jira.codehaus.org/browse/CONTINUUM-1346
Project: Continuum
Issue Type: Bug
Affects Versions: 1.1-alpha-2
Reporter: Trygve Laugstol
Fix For: 1.1-beta-2
{code}
2007-07-13 14:16:42,290 [pool-1-thread-1] ERROR Action:execute-builder
- Error getting test results
java.lang.NumberFormatException: For input string: 1,721.377
at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Double.parseDouble(Double.java:482)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:307)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:272)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:184)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:613)
{code}
--
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: (CONTINUUM-1347) WebDAV enable the working copies
WebDAV enable the working copies Key: CONTINUUM-1347 URL: http://jira.codehaus.org/browse/CONTINUUM-1347 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Trygve Laugstol -- 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: (CONTINUUM-1346) Error while parsing test results
[
http://jira.codehaus.org/browse/CONTINUUM-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102155
]
Trygve Laugstol commented on CONTINUUM-1346:
Additional locale info:
{code}
$ locale
LANG=
LC_COLLATE=C
LC_CTYPE=C
LC_MESSAGES=C
LC_MONETARY=C
LC_NUMERIC=C
LC_TIME=C
LC_ALL=C
{code}
Error while parsing test results
Key: CONTINUUM-1346
URL: http://jira.codehaus.org/browse/CONTINUUM-1346
Project: Continuum
Issue Type: Bug
Affects Versions: 1.1-alpha-2
Reporter: Trygve Laugstol
{code}
2007-07-13 14:16:42,290 [pool-1-thread-1] ERROR Action:execute-builder
- Error getting test results
java.lang.NumberFormatException: For input string: 1,721.377
at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Double.parseDouble(Double.java:482)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:307)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:272)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:184)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:613)
{code}
--
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: (CONTINUUM-1346) Error while parsing test results
Error while parsing test results
Key: CONTINUUM-1346
URL: http://jira.codehaus.org/browse/CONTINUUM-1346
Project: Continuum
Issue Type: Bug
Affects Versions: 1.1-alpha-2
Reporter: Trygve Laugstol
{code}
2007-07-13 14:16:42,290 [pool-1-thread-1] ERROR Action:execute-builder
- Error getting test results
java.lang.NumberFormatException: For input string: 1,721.377
at
sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1224)
at java.lang.Double.parseDouble(Double.java:482)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:307)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.getTestResults(MavenTwoBuildExecutor.java:272)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:184)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:613)
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-226) Filters as read-only parameter can break the assembly build of a multi-module project
[ http://jira.codehaus.org/browse/MASSEMBLY-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD closed MASSEMBLY-226. Resolution: Fixed Fixed in trunk, with an integration test. Filters as read-only parameter can break the assembly build of a multi-module project - Key: MASSEMBLY-226 URL: http://jira.codehaus.org/browse/MASSEMBLY-226 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: Fabrice BELLINGARD Assignee: Fabrice BELLINGARD Attachments: FiltersNotReadOnly.patch, FiltersTest.zip When I specify buildfilters in the root project for filtering files of an assembly, then running assembly:assembly breaks. This is because buildfilters configuration is inherited in the modules, and Maven does not correctly inherit this configuration (see MNG-2445). I attached an example project to test this: - run assembly:attached on the root project: it works fine - run assembly:assembly on the root project: it breaks I think the filters argument of the assembly plugin should not be read-only. Instead, it should be possible to redefine it locally, or leave it blank if we want the plugin to take the buildfilters definition instead. What do you think of this? I can work on this. -- 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-3108) Add some way of accessing the command line arguments from within a unit test running under surefire
Add some way of accessing the command line arguments from within a unit test running under surefire --- Key: MNG-3108 URL: http://jira.codehaus.org/browse/MNG-3108 Project: Maven 2 Issue Type: Improvement Components: Command Line, Plugin Requests Affects Versions: 2.0.7, 2.0.6 Reporter: Kev Jackson Add some way of accessing the command line arguments from within a unit test running under surefire It would be useful to be able to tell what options mvn is running with from within a unit test. options like -o or -X, not the -D properties -- 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: (MAVENUPLOAD-1628) Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102148 ] Roberto Lo Giacco commented on MAVENUPLOAD-1628: Sorry to bother you Carlos, but: 1. what do you mean with fixed the test artifact? I still see smartweb/test-1.0.0 AND smartweb-test/1.0.0... is this going to remain this way? And wat went wrong with the release? Did I made something wrong I must fix? 2. if I correctly understand the metadata purpose I'll need it updated to have support for version ranges (which I actually use) ... am I right? Thanks for all your patience with such a noob as I am :-) Upload Request -- Key: MAVENUPLOAD-1628 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1628 Project: maven-upload-requests Issue Type: Task Reporter: Roberto Lo Giacco Assignee: Carlos Sanchez SmartWeb is a rapid web application development framework based on apache struts and hibernate. This package is a JUnit extension to allow easy unit test of framework based web applications. Please upload! P.S. Whenever I need to upload a new release, should I reply to this issue or create a new one? -- 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-3106) Multiple profile activation conditions broken
[ http://jira.codehaus.org/browse/MNG-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102141 ] Andy Bryant commented on MNG-3106: -- If the intention is that multiple conditions are not supported currently for maven activation, it would be much better to fail with an error message rather than current behaviour. Multiple profile activation conditions broken - Key: MNG-3106 URL: http://jira.codehaus.org/browse/MNG-3106 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.4 Reporter: Andy Bryant Having multiple profile activation conditions behaves in an unexpected manner. It doesn't cause a build failure, but the actual algorithm for activating a profile is very different from expected. My expectation was that if you include multiple conditions, they are ANDed together. However what appears to happen is that the conditions overwrite each other. If an os condition is added, it overrides any property or file conditions regardless of their results. If a file condition is added, it overrides any property condition regardless of results The following table gives a sample of conditions matched, and whether the profile was activated as a result: Property File OS Result Expected T T - TT T F - FF F T - TF F F - FF T - T TT T - F FF F - T TF F - F FF F F T TF T T FFF -- 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-3106) Multiple profile activation conditions broken
Multiple profile activation conditions broken - Key: MNG-3106 URL: http://jira.codehaus.org/browse/MNG-3106 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.4 Reporter: Andy Bryant Having multiple profile activation conditions behaves in an unexpected manner. It doesn't cause a build failure, but the actual algorithm for activating a profile is very different from expected. My expectation was that if you include multiple conditions, they are ANDed together. However what appears to happen is that the conditions overwrite each other. If an os condition is added, it overrides any property or file conditions regardless of their results. If a file condition is added, it overrides any property condition regardless of results The following table gives a sample of conditions matched, and whether the profile was activated as a result: Property File OS Result Expected T T - TT T F - FF F T - TF F F - FF T - T TT T - F FF F - T TF F - F FF F F T TF T T FFF -- 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: (MECLIPSE-266) plugin applies java facet to ear project
[
http://jira.codehaus.org/browse/MECLIPSE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102138
]
Thierry Levieux commented on MECLIPSE-266:
--
- Regarding the strange dependency analysis, I am a little confused too.
One solution would consist in adding the ear version within the *eclipse
plugin* configuration.
In my opinion this is not a good solution because an ear version attribute
depends on the project context:
the ear version has no sense if you generate a war or an ejb wtp project.
On the other hand I don't agree to look at the *ear plugin* at all. Cross
plugin dependencies must be avoid
as much as possible. For instance, what's happen if you decide to use a
proprietary/commercial
*ear plugin* instead of the default one ? The *eclipse plugin* is broken !
So I think the dependency analysis is a not-so-bad solution.
However my favourite solution would be a dedicated plugin for each wtp artifact
(ear, war, ejb), with their dedicated
attributes (j2ee version, servlet version, ejb version). No more dependencies
analysis.
A last think, don't be afraid with duplicate attributes accross plugins (a
consequence of the separation of concerns).
I recommend you to use ant annotations (version${ear.version}version for
instance), with global properties located
in a master pom.
- Regarding the Java facet, I agree with you (a bug ?).
And what's about your project ? Have you succeed ?
Thierry
plugin applies java facet to ear project
Key: MECLIPSE-266
URL: http://jira.codehaus.org/browse/MECLIPSE-266
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: WTP support
Affects Versions: 2.3
Environment: Windows XP
Reporter: Srepfler Srgjan
In .settings/org.eclipse.wst.common.project.facet.core.xml of the EAR module
I'm getting this:
faceted-project
fixed facet=jst.java/
fixed facet=jst.ear/
installed facet=jst.ear version=1.3/
installed facet=jst.java version=1.4/
/faceted-project
This is a wrong facet on a EAR module and I can't compile if I don't edit
this file manually (I can't do it from the project properties - facets dialog)
--
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-3105) Maven-cobertura-plugin does not work for RAR packaging projects
Maven-cobertura-plugin does not work for RAR packaging projects
---
Key: MNG-3105
URL: http://jira.codehaus.org/browse/MNG-3105
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.6
Reporter: Peter Liljenberg
For a project with packaging rar the codehaus maven plugin for Cobertura does
not work.
During instrumentation the following message is displayed:
Not executing cobertura:instrument as the project is not a Java
classpath-capable package
The reason for this is that in the CoberturaInstrumentMojo.execute() the code
checks which language that the artifact is implemented in, like this:
ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
if ( !java.equals( artifactHandler.getLanguage() ) )
{
getLog().info( Not executing cobertura:instrument as the project
is not a Java classpath-capable package );
}
Looking at the components.xml in the Maven sources, we find that the rar
packaging is not specified at all, meaning that it will be handled with the
DefaultArtifactHandler and all properties set to null, including the language
property.
This can be fixed with the following addition to components.xml:
components
component
roleorg.apache.maven.artifact.handler.ArtifactHandler/role
role-hintrar/role-hint
implementationorg.apache.maven.artifact.handler.DefaultArtifactHandler/implementation
configuration
typerar/type
extensionrar/extension
includesDependenciestrue/includesDependencies
languagejava/language
addedToClasspathfalse/addedToClasspath
/configuration
/component
...
/components
--
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: (MECLIPSE-235) Eclipse Maven plugin has its own Classpath Container that conflicts with generated class paths when enabled.
[ http://jira.codehaus.org/browse/MECLIPSE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102169 ] John Casey commented on MECLIPSE-235: - I added an eclipse:m2eclipse mojo in maven-eclipse-plugin 2.4-snapshot...will this suffice? It's not that well-tested, but I've been using it for over 6 months now without any problems... Eclipse Maven plugin has its own Classpath Container that conflicts with generated class paths when enabled. Key: MECLIPSE-235 URL: http://jira.codehaus.org/browse/MECLIPSE-235 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Environment: Should be OK for ALL Reporter: Hasan Ceylan Fix For: 2.5 Attachments: eclipseM2Plugin.diff When we create eclipse projects using the maven-eclipse-plugin, all the class path entries for the dependent libraries are added to the .classpath. For those like me who has eclipse maven plugin, enabling maven2 for the generated project creates duplicate libraries as maven also introduces its own container based on the information in the pom.xml. I took the liberty to modify the head, and introduced the eclipse.withM2Plugin parameter. If this parameter is true in the runtime, 1) In EclipsePlugin.setup() a) If org.maven.ide.eclipse.maven2Nature nature is not added in the configuration, it is added automatically. b) If org.maven.ide.eclipse.maven2Builder builder is not added in the configuration, it is added automatically. c) If org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER container is added automatically. 2) In config introduced the method hasMaven2Nature() which indicates if Maven2 nature is available 3) M2_REPO's skipped in EclipseClasspathWriter if config returns true for hasMaven2Nature() Hope you like the patch... Regards, Hasan Ceylan -- 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: (MCHECKSTYLE-74) invalid report heading html
invalid report heading html --- Key: MCHECKSTYLE-74 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-74 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Cliffano Subagio Priority: Trivial Attachments: reportheadinginvalidhtml-patch.txt The report heading has an open div which is not closed, and this causes report layout to be messed up plus page html won't validate. Attached is a simple patch to fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-170) Create a branch during prepare
[ http://jira.codehaus.org/browse/MRELEASE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102171 ] werner mueller commented on MRELEASE-170: - plus one vote from me a command line option during the release steps or a config option in the pom to create a branch in addition to the tag would be nice of course with svn its easy to manually copy the tag to the branches folder. nonetheless cvs migration users still stick with tagging and branching :) Create a branch during prepare -- Key: MRELEASE-170 URL: http://jira.codehaus.org/browse/MRELEASE-170 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: scm Reporter: Jonathan Komorek Priority: Minor It is typical with some of my projects that as I'm cutting the release I am already thinking about the next patch. In other words, creating a branch to allow patching of a release is a part of my release process. I would like a way to create a branch during the prepare goal of a release. For instance, if I'm releasing 4.0-SNAPSHOT I would like to create a 4.0 tag as is currently done, but also a 4.0.1-SNAPSHOT branch. Please note that I have recently migrated from CVS / ANT to SVN / Maven so I'm open to alternatives from someone with more experience on these platforms. Although I have not written any code for a Maven plugin previously, I would be willing to make these additions myself if nobody minds and I can get someone to review my code - the experience would help me better understand Maven and this plugin in particular. -- 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: (MECLIPSE-303) Debugger does not stop at breakpoints when maven goal test/package is run within eclispe
Debugger does not stop at breakpoints when maven goal test/package is run within eclispe Key: MECLIPSE-303 URL: http://jira.codehaus.org/browse/MECLIPSE-303 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: Eclipse - 3.2.2, Maven -2.0.7, Windows xp Reporter: Archana mathur Priority: Minor I have created a web project within eclipse. I am using test/package goal and want to see if build stops at break points.I have set up break points in test/java classes but running test does not stop build at break points. I am not sure what is missing. My application (.jar) is built properly and all test run properly but they don't stop at break points within eclipse when I run goals of pom.xml. Please could you advise what should be done to enable maven build to stop at break points within eclipse. -- 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: (MAVENUPLOAD-1628) Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102181 ] Carlos Sanchez commented on MAVENUPLOAD-1628: - 1. tell me the complete urls of things that shouldn't be there 2. yes, you need metadata for ranges Upload Request -- Key: MAVENUPLOAD-1628 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1628 Project: maven-upload-requests Issue Type: Task Reporter: Roberto Lo Giacco Assignee: Carlos Sanchez SmartWeb is a rapid web application development framework based on apache struts and hibernate. This package is a JUnit extension to allow easy unit test of framework based web applications. Please upload! P.S. Whenever I need to upload a new release, should I reply to this issue or create a new one? -- 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-535) xmlbeans 2.3.0 is located in the wrong directory (even though the pom file is correct
[ http://jira.codehaus.org/browse/MEV-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102183 ] Carlos Sanchez commented on MEV-535: added relocations from xmlbeans to org.apache.xmlbeans xmlbeans 2.3.0 is located in the wrong directory (even though the pom file is correct - Key: MEV-535 URL: http://jira.codehaus.org/browse/MEV-535 Project: Maven Evangelism Issue Type: Bug Components: Relocation Reporter: Severin Ecker Assignee: Carlos Sanchez the xmlbeans version 2.3.0 are located in the maven2 main repository in xmlbeans/xmlbeans/2.3.0/ xmlbeans/xmlbeans-xpath/2.3.0/ ... but in the pom files the groupId is set to org.apache.xmlbeans therefore the xmlbeans are not found, and neither are the dependencies that refer to xmlbeans. they should be moved to org/apache/xmlbeans/xmlbeans/2.3.0 org/apache/xmlbeans/xmlbeans-xpath/2.3.0 ... -- 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: (MAVENUPLOAD-1628) Upload Request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102185 ] Roberto Lo Giacco commented on MAVENUPLOAD-1628: 1. everything is ok now... 2. than I'm going to setup a maven synched repo on sourceforge... hoping not to get stuck :-) Thank you for all your time, Roberto Upload Request -- Key: MAVENUPLOAD-1628 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1628 Project: maven-upload-requests Issue Type: Task Reporter: Roberto Lo Giacco Assignee: Carlos Sanchez SmartWeb is a rapid web application development framework based on apache struts and hibernate. This package is a JUnit extension to allow easy unit test of framework based web applications. Please upload! P.S. Whenever I need to upload a new release, should I reply to this issue or create a new one? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1641) Request to upload the jflex 1.4.1 distribution into the ibiblio maven2 repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1641. --- Assignee: Carlos Sanchez Resolution: Fixed Request to upload the jflex 1.4.1 distribution into the ibiblio maven2 repository - Key: MAVENUPLOAD-1641 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1641 Project: maven-upload-requests Issue Type: Wish Reporter: César Varona Assignee: Carlos Sanchez http://simplyrdf.ptbsl.net/jflex.jar http://jflex.de/ JFlex is a lexical analyzer generator (also known as scanner generator) for Java(tm), written in Java(tm). It is also a rewrite of the very useful tool JLex which was developed by Elliot Berk at Princeton University. As Vern Paxson states for his C/C++ tool flex: They do not share any code though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1639) Upload ZK 2.4.1 to the central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1639. --- Assignee: Carlos Sanchez Resolution: Fixed Upload ZK 2.4.1 to the central repository - Key: MAVENUPLOAD-1639 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1639 Project: maven-upload-requests Issue Type: Task Reporter: Tom M. Yeh Assignee: Carlos Sanchez http://www.zkoss.org/maven/bundles/2.4.1/zcommon-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zweb-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zk-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zul-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zhtml-2.4.1-bundle.jar http://www.zkoss.org/maven/bundles/2.4.1/zkplus-2.4.1-bundle.jar http://www.zkoss.org http://sourceforge.net/users/tomyeh/ ZK is an open-source Ajax Web framework that enables rich user interface for Web applications with no JavaScript and little programming. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1640) Jackcess 1.1.9 release
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1640. --- Assignee: Carlos Sanchez Resolution: Fixed Jackcess 1.1.9 release -- Key: MAVENUPLOAD-1640 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1640 Project: maven-upload-requests Issue Type: Task Reporter: james ahlborn Assignee: Carlos Sanchez Latest jar of the jackcess package. Jackcess ia a pure Java library for reading from and writing to MS Access databases. -- 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: (MECLIPSE-304) Removing @execute phase=generate-resources
Removing @execute phase=generate-resources Key: MECLIPSE-304 URL: http://jira.codehaus.org/browse/MECLIPSE-304 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.4 Environment: Windows 2003 Reporter: Auston McReynolds Priority: Minor eclipse:m2eclipse and eclipse:eclipse shouldn't have to @execute phase=generate-resources. By removing this line and adding @phase generate-resources I can now run eclipse:eclipse at the parent POM level as well as at the module level, with ONE CATCH: In org.apache.maven.plugin.eclipse.EclipsePlugin theres a TODO: // TODO: Why are we using project in some places, and executedProject in others?? Well, once you remove the @execute you receive a barrage of NPE's. However if within org.apache.maven.plugin.eclipse.EclipsePlugin @ validate() I add executedProject = this.project; to the top, everything works like a charm. Can a configuration or flag be added that allows no @execution with the above modification? Regards, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-214) java.lang.NullPointerException: version was null for junit:junit
[ http://jira.codehaus.org/browse/MASSEMBLY-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-214. Assignee: John Casey Resolution: Cannot Reproduce Fix Version/s: 2.2-beta-2 In the future, please provide more information. A stack trace by itself gives us no means of reproducing the error, and therefore little hope of fixing it. java.lang.NullPointerException: version was null for junit:junit Key: MASSEMBLY-214 URL: http://jira.codehaus.org/browse/MASSEMBLY-214 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: Christian Schulte Assignee: John Casey Priority: Blocker Fix For: 2.2-beta-2 Released version completely does not work for me anymore. [INFO] [INFO] version was null for junit:junit [INFO] [INFO] Trace java.lang.NullPointerException: version was null for junit:junit at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364) at org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) at org.apache.maven.shared.artifact.filter.ScopeArtifactFilter.include(ScopeArtifactFilter.java:142) at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:345) at org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencies(DefaultDependencyResolver.java:82) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.resolveDependencyArtifacts(AddDependencySetsTask.java:155) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:100) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:90) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:54) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:98) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:278) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) 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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-129) BaseDirectory Ignored When Including a Repository
[ http://jira.codehaus.org/browse/MASSEMBLY-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-129. Assignee: John Casey Resolution: Fixed Fix Version/s: 2.2-beta-2 BaseDirectory Ignored When Including a Repository - Key: MASSEMBLY-129 URL: http://jira.codehaus.org/browse/MASSEMBLY-129 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Todd Wolff Assignee: John Casey Fix For: 2.2-beta-2 repositories repository includeMetadatafalse/includeMetadata outputDirectorylib/outputDirectory /repository /repositories Using goal assembly:assembly, outputDirectory, i.e. 'lib' in this case, is added to root of assembly archive rather than beneath the BaseDirectory. If includeBaseDirectory=false, outputDirectory is ommitted altogether and repository is written to archive root. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-73) Sharing a default assembly descriptor across sub modules
[
http://jira.codehaus.org/browse/MASSEMBLY-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-73.
---
Assignee: John Casey
Resolution: Fixed
Fix Version/s: 2.2-beta-2
I just enabled this feature, with a slightly different solution. What you're
really talking about is a standard assembly descriptor for more than one
project. If your descriptor were built into the assembly plugin, it'd simply be
a standard descriptorRef configuration. To enable this sort of behavior for
standardized descriptors outside the assembly plugin itself, you can do the
following:
Define a project that contains the standardized descriptor. Here's an example
layout based on the integration test in:
http://svn.apache.org/repos/asf/maven/plugins/maven-assembly-plugin/src/it/basic-features/assemblyDescriptor-artifact
The pom.xml looks like this:
{code:xml}
project
modelVersion4.0.0/modelVersion
parent
groupIdorg.test/groupId
artifactIdassemblyDescriptor-artifact/artifactId
version1/version
/parent
artifactIddescriptor/artifactId
packagingassembly-descriptor/packaging
build
extensions
extension
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-artifact-types/artifactId
version2.2-beta-2-SNAPSHOT/version
/extension
/extensions
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2-SNAPSHOT/version
/plugin
/plugins
/build
/project
{code}
The assembly descriptor is in src/main/resources/assembly-descriptor.xml by
default, and looks like this in the example:
{code:xml}
assembly
idfromArtifact/id
formats
formatdir/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
files
file
sourcesrc/config/a/file.txt/source
outputDirectorya/outputDirectory
filteredtrue/filtered
/file
file
sourcesrc/config/b/file.txt/source
outputDirectoryb/outputDirectory
destNamefile.txt/destName
filteredtrue/filtered
/file
/files
/assembly
{code}
(so, pretty much normal).
You can use the standard descriptor after installing it into the repository
with a pom.xml like the following:
{code:xml}
project
modelVersion4.0.0/modelVersion
parent
groupIdorg.test/groupId
artifactIdassemblyDescriptor-artifact/artifactId
version1/version
/parent
artifactIdassembly/artifactId
build
filters
filtera.properties/filter
/filters
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2-SNAPSHOT/version
configuration
descriptors
descriptororg.test:descriptor:1/descriptor
/descriptors
/configuration
executions
execution
idassembly/id
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
{code}
Note the extension in the standard descriptor's pom.xml.
Sharing a default assembly descriptor across sub modules
Key: MASSEMBLY-73
URL: http://jira.codehaus.org/browse/MASSEMBLY-73
Project: Maven 2.x Assembly Plugin
Issue Type: New Feature
Affects Versions: 2.0.1
Reporter: vinoth rajasekaran
Assignee: John Casey
Fix For: 2.2-beta-2
I have a multi-project folders setup like one shown below,
root
|_ sub-folder1
|_ sub-folder2
|_ sub-folder3
|_ etc
Have a root pom.xml at the root folder level and in that I have defined
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorsrc/main/assembly/descriptor.xml
/descriptor
/descriptors
/configuration
/plugin
Above descriptor works fine only if I have defined a descriptor file on the
src/main/assembly folder for each sub-folder1, sub-folder2, etc.
It would be great if maven supports me in defining a common assembly
descriptor and can be shared by all the sub modules from a common location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-163) In a multiproject environment Assembly causes many unneded rebuilds
[ http://jira.codehaus.org/browse/MASSEMBLY-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102201 ] John Casey commented on MASSEMBLY-163: -- which mojo are you binding into the plugin execution? If you're using assembly:assembly, assembly:directory, or assembly:attached, then you may see this behavior. (not entirely sure about assembly:attached, but I think it's in that group.) This is because these mojos were meant to be run outside the context of a normal build, and therefore fork a new lifecycle to build the package phase. To address this shortcoming for bound assembly-plugin use cases, we've created the assembly:single mojo, which assumes that it's bound into the lifecycle at the appropriate point to ensure that the resources it needs are available...you should give this one a spin. In a multiproject environment Assembly causes many unneded rebuilds Key: MASSEMBLY-163 URL: http://jira.codehaus.org/browse/MASSEMBLY-163 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Linux Gentoo, Java 1.5.0_07_b3 sun, Maven 2.0.4, plugin 2.1 Reporter: Simone Gianni I have a project subdivided in 10 modules. 2 of these modules uses the assembly plugin with the built-in descriptor jar-with-dependencies. When running mvn clean install (or also only maven install) from the root of the project, I see that every time it is building one of the two sub-projects that uses the assembly plugin, it rebuilds some already built projects, even if they are not dependencies of the to be assembled project, nor they have any other apparent motivation to be rebuilded. One of the two project using assembly doesn't even has a single dependency on other project, but triggers a nearly complete rebuild. One of the projects is a WAR overlaying another war, useless to say that it consumes a lot of time, and gets built 3 times. I've tested also with -o to exclude possible changes in external dependencies, checked all the dependency tree to make sure that there were no circular or otherwise crossed dependencies, changed the order of modules in the parent pom to the best build order, checked by hand starting from an empty local repository that building the artifacts (by hand, one by one, commenting out the assembly) in that order satisfies all the dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-196) use of repository assembly is no longer working
[ http://jira.codehaus.org/browse/MASSEMBLY-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-196: - Fix Version/s: 2.2-beta-2 we're cleaning up some other things related to repo's, so we should be able to knock this one out. use of repository assembly is no longer working --- Key: MASSEMBLY-196 URL: http://jira.codehaus.org/browse/MASSEMBLY-196 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: Brett Porter Fix For: 2.2-beta-2 I have the following that works in 2.1: repositories repository outputDirectoryrepository/releases/outputDirectory includeMetadatatrue/includeMetadata groupVersionAlignments groupVersionAlignment idorg.apache.maven/id version2.0.5/version excludes excludemaven-plugin-surrogate-parent/exclude excludemaven-archetype/exclude excludemaven-archetype-core/exclude excludemaven-archiver/exclude excludemaven-parent/exclude excludemaven-jxr/exclude excludemaven-plugin-tools-java/exclude excludemaven-plugin-tools-beanshell/exclude excludemaven-plugin-tools-api/exclude excludemaven-plugin-tools/exclude /excludes /groupVersionAlignment /groupVersionAlignments /repository /repositories However, in 2.2-beta-1 it results in an empty directory being created in the assembly instead of copying the repository contents. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-193) ModuleSet Binaries does not support attachmentClassifier tag
[ http://jira.codehaus.org/browse/MASSEMBLY-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-193. Assignee: John Casey Resolution: Fixed Fix Version/s: 2.2-beta-1 should have been fixed with the 2.2-beta-1 release. This was a documentation issue, where the docs leaked out ahead of the 2.2-beta-1 release. ModuleSet Binaries does not support attachmentClassifier tag -- Key: MASSEMBLY-193 URL: http://jira.codehaus.org/browse/MASSEMBLY-193 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Windows XP SP2 Reporter: Peter Murray Assignee: John Casey Fix For: 2.2-beta-1 Embedded error: Unrecognised tag: 'attachmentClassifier' errors occur when the attachmentClassifier tag is specified for ModuleSet Binaries. The part of the script that was producing this error is as follows; moduleSet includes includetransformer:transformer-gui/include /includes binaries attachmentClassifierbin/attachmentClassifier outputDirectorybinaries/outputDirectory /binaries /moduleSet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-202) Silent failure: outputFileNameMapping declared with multiple includes
[
http://jira.codehaus.org/browse/MASSEMBLY-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102209
]
John Casey commented on MASSEMBLY-202:
--
where is ${os-platform} coming from? Are you sure this is being interpolated
correctly? You can run with -X to see warnings about unused filters, like those
includes would be if deps were just being ignored...
Silent failure: outputFileNameMapping declared with multiple includes
---
Key: MASSEMBLY-202
URL: http://jira.codehaus.org/browse/MASSEMBLY-202
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Environment: java version 1.5.0_09
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode)
Reporter: Graham Leggett
When attempting to add a dependency to an assembly _without_ unpacking the
dependency using the following snippet of assembly, the dependecies are
silently ignored:
dependencySet
outputDirectory/outputDirectory
outputFileNameMapping/outputFileNameMapping
includes
includealchemy:alchemy-quant:jar:${os-platform}/include
includealchemy:alchemy-quant:ctf:${os-platform}/include
/includes
unpackfalse/unpack
scoperuntime/scope
/dependencySet
It turns out the above config makes no sense - multiple dependencies match
the includes rule, and yet an outputFileNameMapping has been defined, which
only makes sense when it matches a single include line.
In this case a proper error message needs to be thrown to explain that when
outputFileNameMapping is present, only one include can be present. Currently
assembly succeeds silently while doing nothing, causing much confusion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-75) Unpacked TAR dependencies do not preserve file mode nor uid/gid
[ http://jira.codehaus.org/browse/MASSEMBLY-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-75: Fix Version/s: 2.2-beta-2 Unpacked TAR dependencies do not preserve file mode nor uid/gid --- Key: MASSEMBLY-75 URL: http://jira.codehaus.org/browse/MASSEMBLY-75 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.0.1 Reporter: Maciej Szefler Fix For: 2.2-beta-2 TAR Assemblies generated from unpacking another TAR do not preserver the extended file information (uid/gid/mod). For example: if bar.tar contains an executable file baz and if our .pom has the following dependency: dependency groupIdfoo/groupId artifactIdbar/artifactId typetar/type scopecompile/scope /dependency and our assembly.xml has the following: assembly id/id formats formattar.gz/format /formats dependencySets dependencySet scopecompile/scope outputDirectory/ includes includefoo:bar/include /includes unpacktrue/unpack /dependencySet then the generated assembly will contain baz, but it will no longer be executable. -- 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: (MSANDBOX-30) minor doc tweak
minor doc tweak --- Key: MSANDBOX-30 URL: http://jira.codehaus.org/browse/MSANDBOX-30 Project: Maven 2.x Sandbox Issue Type: Improvement Components: maven-antlr3-plugin Reporter: David Holroyd Priority: Trivial Attachments: doc-update-patch.diff someone reported a problem after following the advice to use packagingjar/packaging. Don't know why that should be, but it shouldn't be needed, so simplify the doc by removing the line. -- 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: (MECLIPSE-303) Debugger does not stop at breakpoints when maven goal test/package is run within eclispe
[ http://jira.codehaus.org/browse/MECLIPSE-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102215 ] Dan Tran commented on MECLIPSE-303: --- Can you assemble a small web project and proves that debugger is not working? I have no problem here. Debugger does not stop at breakpoints when maven goal test/package is run within eclispe Key: MECLIPSE-303 URL: http://jira.codehaus.org/browse/MECLIPSE-303 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: Eclipse - 3.2.2, Maven -2.0.7, Windows xp Reporter: Archana mathur Priority: Minor I have created a web project within eclipse. I am using test/package goal and want to see if build stops at break points.I have set up break points in test/java classes but running test does not stop build at break points. I am not sure what is missing. My application (.jar) is built properly and all test run properly but they don't stop at break points within eclipse when I run goals of pom.xml. Please could you advise what should be done to enable maven build to stop at break points within eclipse. -- 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: (MIDEA-100) Module file (.iml) is generated in a way that sources and javadocs are not recognized by Intellij Idea
[
http://jira.codehaus.org/browse/MIDEA-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102223
]
Dennis Lundberg commented on MIDEA-100:
---
I just tried this on another project and I can not reproduce what you describe.
I only get one SOURCES and one JAVADOC tag per dependency/module-library. Did
you check the .iml file *before* opening it in IDEA?
Please supply a sample project that can be used to illustrate the problem.
Module file (.iml) is generated in a way that sources and javadocs are not
recognized by Intellij Idea
--
Key: MIDEA-100
URL: http://jira.codehaus.org/browse/MIDEA-100
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: WIndows XP, Maven 2.0.7, Java 1.6, IntelliJ IDEA 7.0M1b
Reporter: Gerhard Mueller
Priority: Critical
When a new iml file is generated with mvn idea:idea -DdownloadSources=true
-DdownloadJavadocs=true
the generated .iml-file contains invalid entries for the javadocs and
sources, like in this example:
orderEntry type=module-library
library
JAVADOC/
SOURCES/
CLASSES
root url=jar://C:/Dokumente und
Einstellungen/muellerg/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0.jar!/
/
/CLASSES
SOURCES
root url=jar://C:/Dokumente und
Einstellungen/muellerg/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0-sources.jar!/
/
/SOURCES
JAVADOC
root url=jar://C:/Dokumente und
Einstellungen/muellerg/.m2/repository/commons-beanutils/commons-beanutils/1.7.0/commons-beanutils-1.7.0-javadoc.jar!/
/
/JAVADOC
/library
/orderEntry
Removing the empty
JAVADOC/
SOURCES/
entries allows me to see the sources, but this is not a good solution.
By looking at the source code
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-idea-plugin/src/main/java/org/apache/maven/plugin/idea/IdeaModuleMojo.java
the reason might be the method
private Element createOrGetElement( Element lib, String name )
{
Element el = lib.element( name );
if ( el == null )
{
el = createElement( lib, name );
}
return el;
}
In my opinion, the method should look like this:
private Element createOrGetElement( Element lib, String name )
{
Element el = lib.element( name ); // CHANGE DONE HERE
if ( el == null )
{
el = createElement( lib, name );
}
return el;
}
as otherwiese ALWAYS new element instances are created, regardless the
provided name to look for,
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-205) Files mapped anywhere under META-INF ignored
[
http://jira.codehaus.org/browse/MASSEMBLY-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102224
]
John Casey commented on MASSEMBLY-205:
--
It's just that particular filename, actually:
/META-INF/plexus/components.xml...it's the only container descriptor that's
aggregated at this point. When you say it's ignored, do you mean it simply
disappears out of the resulting assembly altogether?
Files mapped anywhere under META-INF ignored
Key: MASSEMBLY-205
URL: http://jira.codehaus.org/browse/MASSEMBLY-205
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Eric Redmond
In an assembly descriptor moving a components.xml file under META-INF is
ignored
files
file
source${basedir}/src/main/components/xstream-components.xml/source
destNamecomponents.xml/destName
outputDirectory/META-INF/plexus/outputDirectory
filteredtrue/filtered
/file
/files
However, moving anywhere else, such as /meta-inf/plexus (lowercase) works
file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-216) archive element in assembly descriptor
[ http://jira.codehaus.org/browse/MASSEMBLY-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-216: - Fix Version/s: 2.2 archive element in assembly descriptor -- Key: MASSEMBLY-216 URL: http://jira.codehaus.org/browse/MASSEMBLY-216 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Greg Wilkins Fix For: 2.2 Currently it is not possible to have an archive element (and thus manipulate the manifest) in an assembly descriptor. This means that manifest entries must be set in the assembly plugin configuration and this makes it difficult to have different manifests for different assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-217) outputFileNameMapping needs to report collision.
[
http://jira.codehaus.org/browse/MASSEMBLY-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MASSEMBLY-217:
-
Fix Version/s: 2.2-beta-2
outputFileNameMapping needs to report collision.
--
Key: MASSEMBLY-217
URL: http://jira.codehaus.org/browse/MASSEMBLY-217
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Kohsuke Kawaguchi
Fix For: 2.2-beta-2
If outputFileNameMapping maps two or more artifacts into the same name, it
needs to be reported as an error.
Maven currently just takes the last one without reporting anything, and as a
result I didn't notice that my assembly descriptor had a problem until I
debug the plugin source code.
This problem is particularly made worse by a broken jar-with-dependencies
example in [the
documentation|http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html],
which says:
{noformat}
dependencySets
dependencySet
outputDirectory/outputDirectory
outputFileNameMapping/outputFileNameMapping
unpacktrue/unpack
scoperuntime/scope
/dependencySet
/dependencySets
{noformat}
... which maps every dependency to
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-220) unpacked assemblies render different results when enumerating dependencies vs. using wildcards
[ http://jira.codehaus.org/browse/MASSEMBLY-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-220: - Fix Version/s: 2.2-beta-2 unpacked assemblies render different results when enumerating dependencies vs. using wildcards -- Key: MASSEMBLY-220 URL: http://jira.codehaus.org/browse/MASSEMBLY-220 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: mvn 2.0.6, jdk 1.4.2 Reporter: Dirk Olmes Fix For: 2.2-beta-2 Attachments: assembly-wildcard.xml, assembly.xml, pom.xml When using wildcards for assemblies which unpack jars, the contents of META-INF of the unpacked jars do not end up in the final JAR. This breaks systems which rely on the contents of the META-INF directory, e.g. Mule. I have attached a pom and two assemblies, one using wildcards and one enumerating all the dependencies. Run the assembly plugin on both descriptors and compare the resulting jars. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-213) jar-with-dependencies and signed jars issue again
[ http://jira.codehaus.org/browse/MASSEMBLY-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-213: - Fix Version/s: 2.2-beta-2 I'll update the dependency and re-deploy the 2.2-beta-2-SNAPSHOT plugin in just a couple minutes...can you retry with this new version, or (much preferred, actually) attach a failing test project, so I can incorporate it into the plugin's integration-tests? jar-with-dependencies and signed jars issue again - Key: MASSEMBLY-213 URL: http://jira.codehaus.org/browse/MASSEMBLY-213 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: TAKATA, Satoshi Fix For: 2.2-beta-2 Attachments: alpha9.patch /META-INF/*.RSA /META-INF/*.SF /META-INF/*.rsa /META-INF/*.sf These files are not excluded with the configuration below. plugin artifactIdmaven-assembly-plugin/artifactId configuration descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs archive manifest mainClassmy.MainClass/mainClass packageNamemy/packageName /manifest /archive /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-182) document behavior when two sources selected for single archived file
[ http://jira.codehaus.org/browse/MASSEMBLY-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-182: - Fix Version/s: 2.2-beta-2 document behavior when two sources selected for single archived file Key: MASSEMBLY-182 URL: http://jira.codehaus.org/browse/MASSEMBLY-182 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: John Franey Priority: Minor Fix For: 2.2-beta-2 Attachments: archive-rule.patch I was befuddled by how this plugin decides which source file to use when, for example, a file element and fileSet element identify different sources for the same archived file. So, I worked through the ones that got me bugged most and wrote them down. Attached is a diff of changes to document the behavior I observed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-136) outputDirectory to support absolute paths
[ http://jira.codehaus.org/browse/MASSEMBLY-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MASSEMBLY-136. Assignee: John Casey Resolution: Won't Fix Fix Version/s: 2.2-beta-2 This use case isn't really a part of the assembly plugin's goals. Maybe you'd be better off with a custom plugin to copy files from dependencies, etc. into your tests... Actually, such a plugin might be really useful. I'm not sure whether the maven-remote-resources-plugin could be made to accomplish this (dependencies would be remote resources for your tests, after all), but something like that would be a nice addition to the mojo.codehaus.org suite of plugins, I'd imagine. outputDirectory to support absolute paths - Key: MASSEMBLY-136 URL: http://jira.codehaus.org/browse/MASSEMBLY-136 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.0.1 Environment: Linux Reporter: Kalle Korhonen Assignee: John Casey Priority: Minor Fix For: 2.2-beta-2 Can you please make the assembly parameter outputDirectory support absolute paths, just like directory in fileSets. Currently all paths are relative to the root directory of the assembly, whether or not you specify the path separator in the beginning or not. I see no reason why it should only support relative paths. I'm using assembly:directory to deploy some resources for my unit/integration tests that are normally available on a production environment. I realize I'm using the plugin the wrong way, but the directory goal and format isn't suitable for deploying to the repository anyways. Also, either I don't know how to use appendAssemblyId correctly or it doesn't work for directory format. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-183) assembly:attached does not work with filter- ERROR: Cannot override read-only parameter
[ http://jira.codehaus.org/browse/MASSEMBLY-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MASSEMBLY-183: - Fix Version/s: 2.2-beta-2 just a note to fix the documentation... assembly:attached does not work with filter- ERROR: Cannot override read-only parameter --- Key: MASSEMBLY-183 URL: http://jira.codehaus.org/browse/MASSEMBLY-183 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Maven 2.0.4 - Mac OSx - JDK 1.5 Reporter: Franz Garsombke Priority: Minor Fix For: 2.2-beta-2 Filtering does not work when you use the attached goal on the assembly plugin. When you add a filters tag to the configuration and run assembly:attached the following error is generated: ERROR: Cannot override read-only parameter Sample configuration: artifactIdmaven-assembly-plugin/artifactId configuration filters filtersrc/assemble/dev.properties/filter /filters descriptors descriptorsrc/assemble/distribution.xml/descriptor /descriptors /configuration -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-213) jar-with-dependencies and signed jars issue again
[ http://jira.codehaus.org/browse/MASSEMBLY-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102229 ] John Casey commented on MASSEMBLY-213: -- This is going to take more work than I realized, since there are new methods and classes involved. I have a specialized archiver proxy implementation in the assembly plugin that adds a prefix root to everything, and I'll need to make that work before I can turn this loose. jar-with-dependencies and signed jars issue again - Key: MASSEMBLY-213 URL: http://jira.codehaus.org/browse/MASSEMBLY-213 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Reporter: TAKATA, Satoshi Fix For: 2.2-beta-2 Attachments: alpha9.patch /META-INF/*.RSA /META-INF/*.SF /META-INF/*.rsa /META-INF/*.sf These files are not excluded with the configuration below. plugin artifactIdmaven-assembly-plugin/artifactId configuration descriptorRefs descriptorRefjar-with-dependencies/descriptorRef /descriptorRefs archive manifest mainClassmy.MainClass/mainClass packageNamemy/packageName /manifest /archive /configuration /plugin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGELOG-65) documentation samples for working changelog reports for each supported SCM
[ http://jira.codehaus.org/browse/MCHANGELOG-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102230 ] Dennis Lundberg commented on MCHANGELOG-65: --- I have added more content to the FAQ now. Can you have a look at it and comment, please. The site for the plugin has been staged here: http://people.apache.org/~dennisl/maven-changelog-plugin/faq.html documentation samples for working changelog reports for each supported SCM -- Key: MCHANGELOG-65 URL: http://jira.codehaus.org/browse/MCHANGELOG-65 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Paul Sundling Assignee: Dennis Lundberg Fix For: 2.1 I've spent quite a while trying to get a changelog report that wasn't blank using perforce. It would be nice to have a sample pom.xml listed for each of the supported SCMs. That way I could know for sure it wasn't my setup and whether I'm experiencing a bug or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-74) invalid report heading html
[ http://jira.codehaus.org/browse/MCHECKSTYLE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-74. -- Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.2 Fixed in SVN r556183. invalid report heading html --- Key: MCHECKSTYLE-74 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-74 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Cliffano Subagio Assignee: Dennis Lundberg Priority: Trivial Fix For: 2.2 Attachments: reportheadinginvalidhtml-patch.txt The report heading has an open div which is not closed, and this causes report layout to be messed up plus page html won't validate. Attached is a simple patch to fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-82) Issue Management URL not ending in a '/' result in an incorrect issue link on the change report.
[ http://jira.codehaus.org/browse/MCHANGES-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102234 ] Dennis Lundberg commented on MCHANGES-82: - Are you using a changes.xml file to produce the report? What does it look like? How is this problem made worse by the example that you mention? Can you please supply a full issue management element that exemplifies this issue. Issue Management URL not ending in a '/' result in an incorrect issue link on the change report. Key: MCHANGES-82 URL: http://jira.codehaus.org/browse/MCHANGES-82 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: changes-report Affects Versions: 2.0-beta-2 Reporter: Paul Spencer Issue Management URL not ending in a '/' result in an incorrect issue link on the change report. If the Url is http://issues.foo.com;, then the link to issue 1 is http://ViewIssue.jspa?key=1;. This problem is made worse by the issue management example in http://maven.apache.org/pom.html. In that example the url is urlhttp://127.0.0.1/bugzilla/url. I believe the source of the problem is in ChangesReportGenerator.parseIssueLink(). This method assumes the URL will end in a /, instead of checking for an ending / String url = this.url.substring( 0, this.url.lastIndexOf( / ) ); -- 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: (MIDEA-98) Module filepath is generated incorrectly
[
http://jira.codehaus.org/browse/MIDEA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102235
]
Dennis Lundberg commented on MIDEA-98:
--
Thanks to Christian I had something to test on. So I gave it a try. The top
level .ipr file looks like this for me:
{code}
component name=ProjectModuleManager
modules
!-- module filepath=$$PROJECT_DIR$$/${pom.artifactId}.iml/ --
module filepath=$PROJECT_DIR$/webapp-reference.iml/
module
filepath=$PROJECT_DIR$/webapp-reference-core/webapp-reference-core.iml/
module
filepath=$PROJECT_DIR$/webapp-reference-web/webapp-reference-web.iml/
/modules
/component
{code}
This test was done using Maven 2.0.7 with Sun Java 1.5.0_11 on Windows XP.
So to me everything is working as expected.
Module filepath is generated incorrectly
Key: MIDEA-98
URL: http://jira.codehaus.org/browse/MIDEA-98
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: $ mvn -v
Maven version: 2.0.7
Java version: 1.5.0_11
OS name: windows xp version: 5.1 arch: x86
Reporter: Ben Hood
I have a multi-module mvn project.
When I do an mvn idea:clean idea:idea, the following ProjectModuleManager
snippet in the top level .ipr is generated:
component name=ProjectModuleManager
modules
!-- module filepath=$$PROJECT_DIR$$/${pom.artifactId}.iml/ --
module filepath=$PROJECT_DIR$/gateway.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml/
/modules
/component
The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
But this path is being appended in a hard-coded fashion after the
$PROJECT_DIR entry.
The symptom in Intellij is the following error message:
Cannot load module: File
C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not
exist
Would you like to remove the module from the project?
The workaround is to delete the extra appended file path from each module
entry in the above mentioned snippet.
--
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: (MIDEA-99) Allow the library to define a link to external javadoc.
[ http://jira.codehaus.org/browse/MIDEA-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MIDEA-99: - Affects Version/s: (was: 2.2) 2.1 Patch Submitted: [Yes] Allow the library to define a link to external javadoc. --- Key: MIDEA-99 URL: http://jira.codehaus.org/browse/MIDEA-99 Project: Maven 2.x IDEA Plugin Issue Type: New Feature Affects Versions: 2.1 Environment: Any envirohment Reporter: Roman Zenka Attachments: diff.txt Setting javadocs for your project requires having them deployed as a jar of specific name. Many javadocs are available only online, so the procedure involves downloading, jaring, mavenizing and deploying to your repository. It would be much more convenient to simply specify javadoc url in your libary configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-96) generated projects do not load in Selena #7020
[
http://jira.codehaus.org/browse/MIDEA-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102237
]
Dennis Lundberg commented on MIDEA-96:
--
Are you saying that it is now illegal to have xml comments in the .ipr and .iml
files?
Do you have a link to the issue at JetBrains that was rejected with a Won't
Fix?
generated projects do not load in Selena #7020
--
Key: MIDEA-96
URL: http://jira.codehaus.org/browse/MIDEA-96
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: maven 2.0.4
windows
IntelliJ build #7020
Reporter: zak jacobson
Attachments: MIDEA-96.patch
Idea trows an error:
Error during dispatching of
java.awt.event.MouseEvent[MOUSE_RELEASED,(47,53),button=1,modifiers=Button1,clickCount=1]
on ###overrideRedirect###: Wrong node: [Comment: !-- output
url=file://$C:/P4/TPE/te/tpe/main/Util$/${maven.build.dest}/ --]
java.lang.IllegalArgumentException: Wrong node: [Comment: !-- output
url=file://$project path$/${maven.build.dest}/ --]
at com.intellij.openapi.util.JDOMUtil.internElement(JDOMUtil.java:181)
Manually editing the .iml .ipr files to remove all comments, such as:
!-- Next include each dependency:
orderEntry type=module module-name=${dep.artifactId}/
orderEntry type=module-library
library name=${dep.artifactId}
CLASSES
root url=jar://${lib.path}!//
/CLASSES
JAVADOC/
SOURCES/
/library
/orderEntry
--
is a work around.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHECKSTYLE-68) Use Release 4.3 of Checkstyle
[ http://jira.codehaus.org/browse/MCHECKSTYLE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-68. -- Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.2 Fixed in SVN r556193. Use Release 4.3 of Checkstyle - Key: MCHECKSTYLE-68 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-68 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: Anthony Whitford Assignee: Dennis Lundberg Fix For: 2.2 4.3 of Checkstyle was released on January 25, 2007. Please update Maven 2.x Checkstyle Plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-98) Module filepath is generated incorrectly
[
http://jira.codehaus.org/browse/MIDEA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102245
]
Christian Nelson commented on MIDEA-98:
---
Same thing, but from a non-cygwin shell:
{code}
component name=ProjectModuleManager
modules
!-- module filepath=$$PROJECT_DIR$$/${pom.artifactId}.iml/ --
module filepath=$PROJECT_DIR$/webapp-reference.iml/
module
filepath=$PROJECT_DIR$/webapp-reference-core/webapp-reference-core.iml/
module
filepath=$PROJECT_DIR$/webapp-reference-web/webapp-reference-web.iml/
/modules
/component
{code}
Looks like cygwin IS the problem.
Module filepath is generated incorrectly
Key: MIDEA-98
URL: http://jira.codehaus.org/browse/MIDEA-98
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: $ mvn -v
Maven version: 2.0.7
Java version: 1.5.0_11
OS name: windows xp version: 5.1 arch: x86
Reporter: Ben Hood
I have a multi-module mvn project.
When I do an mvn idea:clean idea:idea, the following ProjectModuleManager
snippet in the top level .ipr is generated:
component name=ProjectModuleManager
modules
!-- module filepath=$$PROJECT_DIR$$/${pom.artifactId}.iml/ --
module filepath=$PROJECT_DIR$/gateway.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml/
module
filepath=$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml/
/modules
/component
The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
But this path is being appended in a hard-coded fashion after the
$PROJECT_DIR entry.
The symptom in Intellij is the following error message:
Cannot load module: File
C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not
exist
Would you like to remove the module from the project?
The workaround is to delete the extra appended file path from each module
entry in the above mentioned snippet.
--
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: (MCHANGELOG-65) documentation samples for working changelog reports for each supported SCM
[ http://jira.codehaus.org/browse/MCHANGELOG-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102246 ] Paul Sundling commented on MCHANGELOG-65: - It's useful information, but Please check your changelog plugin configuration. is not definitive. The link to your configuration helps. The XML file is empty: ?xml version=1.0 encoding=ISO-8859-1? changelog changeset datePattern=MMdd HH:mm:ss z start=20070613 18:13:34 PDT end=20070714 18:13:34 PDT /changeset /changelog Seriously I give up. I've already wasted pretty much a day on this. I've already resigned myself not to get the changelog plugin working with perforce. documentation samples for working changelog reports for each supported SCM -- Key: MCHANGELOG-65 URL: http://jira.codehaus.org/browse/MCHANGELOG-65 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Paul Sundling Assignee: Dennis Lundberg Fix For: 2.1 I've spent quite a while trying to get a changelog report that wasn't blank using perforce. It would be nice to have a sample pom.xml listed for each of the supported SCMs. That way I could know for sure it wasn't my setup and whether I'm experiencing a bug or not. -- 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: (MIDEA-96) generated projects do not load in Selena #7020
[
http://jira.codehaus.org/browse/MIDEA-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102248
]
Andrew Perepelytsya commented on MIDEA-96:
--
Jetbrains have a huge volume of incoming issues, some of them duplicates.
However, my (and others' ) noise caught the right guy's attention at Jetbrains
and it has since been fixed (after b7041 or so)
generated projects do not load in Selena #7020
--
Key: MIDEA-96
URL: http://jira.codehaus.org/browse/MIDEA-96
Project: Maven 2.x IDEA Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: maven 2.0.4
windows
IntelliJ build #7020
Reporter: zak jacobson
Attachments: MIDEA-96.patch
Idea trows an error:
Error during dispatching of
java.awt.event.MouseEvent[MOUSE_RELEASED,(47,53),button=1,modifiers=Button1,clickCount=1]
on ###overrideRedirect###: Wrong node: [Comment: !-- output
url=file://$C:/P4/TPE/te/tpe/main/Util$/${maven.build.dest}/ --]
java.lang.IllegalArgumentException: Wrong node: [Comment: !-- output
url=file://$project path$/${maven.build.dest}/ --]
at com.intellij.openapi.util.JDOMUtil.internElement(JDOMUtil.java:181)
Manually editing the .iml .ipr files to remove all comments, such as:
!-- Next include each dependency:
orderEntry type=module module-name=${dep.artifactId}/
orderEntry type=module-library
library name=${dep.artifactId}
CLASSES
root url=jar://${lib.path}!//
/CLASSES
JAVADOC/
SOURCES/
/library
/orderEntry
--
is a work around.
--
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
