[jira] Commented: (MEV-550) Missing castor version or incorrect groovy/openejb dependencies
[ http://jira.codehaus.org/browse/MEV-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111643 ] Paul King commented on MEV-550: --- Please swap to using the groovy-all-minimal artifact for 1.0. If you need the optional dependencies, then you can swap back to groovy or groovy-all once the bug in the repo has been worked out. Thanks, Paul. > Missing castor version or incorrect groovy/openejb dependencies > --- > > Key: MEV-550 > URL: http://jira.codehaus.org/browse/MEV-550 > Project: Maven Evangelism > Issue Type: Bug > Components: Dependencies >Reporter: Nicolas Kyriazopoulos-Panagiotopoulos > > We have a problem of dependencies: > [INFO] Path to dependency: > [INFO]1) [OUR PROJECT] > [INFO]2) groovy:groovy:jar:1.0 > [INFO]3) openejb:openejb-loader:jar:1.0 > [INFO]4) openejb:openejb-core:jar:1.0 > [INFO]5) castor:castor:jar:0.9.9.0-pre > The problem is new (we are using groovy for almost a year) . It seems that > someone very recently erased this version of the castor jar and grovy cannot > work without it (unless the problem is caused by newly changed poms). Finding > this particular version of castor on the web seems very difficult. > This is VERY URGENT: there is no newer stable version of groovy so we have > no alternative, and the problem makes new application deployments impossible > (unless we do kung fu with the downloaded poms to refer to other versions, > which is impractical and dangerous). > Thanks in advance! -- 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: (MRM-572) Migrate continuum builds of archiva-security to new svn url
[ http://jira.codehaus.org/browse/MRM-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111623 ] Brett Porter commented on MRM-572: -- good to think ahead, but not really an archiva issue? Maybe just note it in the parent - but the broken build will remind you if not :) > Migrate continuum builds of archiva-security to new svn url > --- > > Key: MRM-572 > URL: http://jira.codehaus.org/browse/MRM-572 > Project: Archiva > Issue Type: Sub-task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > -- 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-549) Strange Groovy entries in the repository
[ http://jira.codehaus.org/browse/MEV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111616 ] Paul King commented on MEV-549: --- Seems like the sanctioned way forward is to leave these spurious entries where they are but we should really fix the poms to have a matching artifactId. I'll see if I can do that using the normal mechanism. If that fails I may need some assistance. Also, if we could get rid of: maven/groovy/jars/-0.2.jar as that does seem to be unusable, that would be great. Thanks, Paul. > Strange Groovy entries in the repository > > > Key: MEV-549 > URL: http://jira.codehaus.org/browse/MEV-549 > Project: Maven Evangelism > Issue Type: Task > Components: Relocation >Reporter: Paul King > > Hi, I am trying to track down why some spurious entries are showing up for > Groovy. Please let me know if this is not the appropriate forum. > Groovy used to publish into the maven1 repo and there was some magic in place > that "republished" artifacts into the maven 2 repo. > Groovy now publishes into the maven2 repo and some magic "republishes" the > jars back into repo1. > Unfortunately, the old magic still seems to be in place and a spurious entry > appears (under the old groupId) in the maven 2 repo. > Does anyone know how to turn off the old magic? I guess then we need to clean > up the spurious artifacts but I can submit separate issue(s) for that if > needed. > Here is my understanding of the trail: > (1) Project publishes to http://repository.codehaus.org/org/codehaus/groovy/ > (2) Sync happens to copy artifacts to > http://repo1.maven.org/maven2/org/codehaus/groovy/ > (3) Magic happens here to copy artifacts back to maven 1 land ending up at > http://repo1.maven.org/maven/groovy/jars/ > This is actually broken in that it should be being copied to > http://repo1.maven.org/maven/org.codehaus.groovy/jars/ > and also the copying of the poms to http://repo1.maven.org/maven/groovy/poms > (which of course should also > be changed to http://repo1.maven.org/maven/org.codehaus.groovy/poms) has > stopped working at some point. > (4) Additional magic which should be turned off now occurs at this point and > copies the artifacts back to the maven 2 > repo. An example of this from 1.1-rc-1 (12 Oct 2007) can be found here: > http://repo1.maven.org/maven2/groovy/groovy-all/1.1-rc-1/ > This is in the wrong place given the groupId and doesn't contain a POM. > I am trying to track this down so I can request that step (4) be turned off. > Thanks, Paul. -- 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: (MRM-571) Create UserRepositories object in archiva-security
[ http://jira.codehaus.org/browse/MRM-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-571: --- Priority: Critical (was: Major) Affects Version/s: (was: 1.0-beta-2) 1.0-beta-3 Fix Version/s: 1.0-beta-4 > Create UserRepositories object in archiva-security > -- > > Key: MRM-571 > URL: http://jira.codehaus.org/browse/MRM-571 > Project: Archiva > Issue Type: Sub-task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > Create a component to aide in filtering of ManagedRepositories based on user > permissions. > The two methods definitely needed (could be more) > * List getAllowedObservingRepositories( > String principal ); > * List getAllowedManagingRepositories( String > principal ); > Care will be needed to ensure that these lookups performs well (possible > caching needed). -- 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: (MRM-569) Browse shows results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-569: --- Priority: Critical (was: Major) Affects Version/s: (was: 1.0-beta-2) 1.0-beta-3 Fix Version/s: 1.0-beta-4 > Browse shows results for all repositories, regardless of security. > -- > > Key: MRM-569 > URL: http://jira.codehaus.org/browse/MRM-569 > Project: Archiva > Issue Type: Bug > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > When browsing archiva (using the browse link on the left hand navigation > bar), the results are for all repositories, regardless of security. > This needs to be filtered based on access rights of the user. -- 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: (MRM-572) Migrate continuum builds of archiva-security to new svn url
[ http://jira.codehaus.org/browse/MRM-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-572: --- Priority: Critical (was: Major) Affects Version/s: 1.0-beta-3 Fix Version/s: 1.0-beta-4 Component/s: Users/Security > Migrate continuum builds of archiva-security to new svn url > --- > > Key: MRM-572 > URL: http://jira.codehaus.org/browse/MRM-572 > Project: Archiva > Issue Type: Sub-task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > -- 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: (MRM-572) Migrate continuum builds of archiva-security to new svn url
Migrate continuum builds of archiva-security to new svn url --- Key: MRM-572 URL: http://jira.codehaus.org/browse/MRM-572 Project: Archiva Issue Type: Sub-task Components: Users/Security Affects Versions: 1.0-beta-3 Reporter: Joakim Erdfelt Fix For: 1.0-beta-4 -- 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: (MRM-516) Search results return results for all repositories, regardless of security.
[ http://jira.codehaus.org/browse/MRM-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-516: --- Fix Version/s: (was: 1.0-beta-3) 1.0-beta-4 > Search results return results for all repositories, regardless of security. > --- > > Key: MRM-516 > URL: http://jira.codehaus.org/browse/MRM-516 > Project: Archiva > Issue Type: Bug > Components: indexing >Affects Versions: 1.0-beta-2 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > The UserAllowedToSearchRepositoryPredicate needs to be finished. > It should take the current user, their RBAC roles, and filter based on the > roles available to the user. -- 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: (MRM-570) archiva-security/ needs to move from archiva-webapp/ to archiva-base/
[ http://jira.codehaus.org/browse/MRM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-570: --- Priority: Critical (was: Major) Affects Version/s: (was: 1.0-beta-2) 1.0-beta-3 Fix Version/s: 1.0-beta-4 > archiva-security/ needs to move from archiva-webapp/ to archiva-base/ > - > > Key: MRM-570 > URL: http://jira.codehaus.org/browse/MRM-570 > Project: Archiva > Issue Type: Task > Components: Users/Security >Affects Versions: 1.0-beta-3 >Reporter: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-4 > > > Since we need to implement backend security around the browse (MRM-569) and > search (MRM-516) facilities, the archiva-security module needs to be > decoupled from archiva-webapp and brought into archiva-base for the general > use of all archiva-base modules. > Leaving archiva-security like it is now will result in pulling in many webapp > specific libraries and concepts that are not needed in the archiva-base > heirarchy. -- 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: (MRM-571) Create UserRepositories object in archiva-security
Create UserRepositories object in archiva-security -- Key: MRM-571 URL: http://jira.codehaus.org/browse/MRM-571 Project: Archiva Issue Type: Sub-task Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Create a component to aide in filtering of ManagedRepositories based on user permissions. The two methods definitely needed (could be more) * List getAllowedObservingRepositories( String principal ); * List getAllowedManagingRepositories( String principal ); Care will be needed to ensure that these lookups performs well (possible caching needed). -- 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: (MRM-570) archiva-security/ needs to move from archiva-webapp/ to archiva-base/
archiva-security/ needs to move from archiva-webapp/ to archiva-base/ - Key: MRM-570 URL: http://jira.codehaus.org/browse/MRM-570 Project: Archiva Issue Type: Task Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Since we need to implement backend security around the browse (MRM-569) and search (MRM-516) facilities, the archiva-security module needs to be decoupled from archiva-webapp and brought into archiva-base for the general use of all archiva-base modules. Leaving archiva-security like it is now will result in pulling in many webapp specific libraries and concepts that are not needed in the archiva-base heirarchy. -- 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: (MRM-569) Browse shows results for all repositories, regardless of security.
Browse shows results for all repositories, regardless of security. -- Key: MRM-569 URL: http://jira.codehaus.org/browse/MRM-569 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt When browsing archiva (using the browse link on the left hand navigation bar), the results are for all repositories, regardless of security. This needs to be filtered based on access rights of the user. -- 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: (MRM-560) Dependency Tree causes an Exception
[
http://jira.codehaus.org/browse/MRM-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111609
]
Joakim Erdfelt commented on MRM-560:
I've updated archiva/trunk (as of revision 588808) to be more resilient when it
comes to bad graph data, and also present more information on what archiva
considers to be bad graph data.
I am unable to reproduce this error, and I need more information on what is
going on.
The information that olamy has provided me in IRC is insufficient to reproduce
this bug.
olamy, can you use the current archiva/trunk and attempt to reproduce this bug?
If you can, I need the entire complete stack trace. (it'll be pretty big).
> Dependency Tree causes an Exception
> ---
>
> Key: MRM-560
> URL: http://jira.codehaus.org/browse/MRM-560
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: solaris 9 + tomcat 6.0.14
>Reporter: Olivier Lamy
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-3
>
>
> Using the Dependency Tree link generates the following stack trace :
> {noformat}
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
> exception
> javax.servlet.ServletException: org.apache.jasper.JasperException: An
> exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:284)
>
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
>
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> root cause
> org.apache.jasper.JasperException: An exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:524)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:417)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> com.opensymphony.webwork.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:114)
>
> com.opensymphony.webwork.dispatcher.WebWorkResultSupport.execute(WebWorkResultSupport.java:143)
>
> com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:313)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:208)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:53)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.intercept
[jira] Commented: (MRM-560) Dependency Tree causes an Exception
[
http://jira.codehaus.org/browse/MRM-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111608
]
Joakim Erdfelt commented on MRM-560:
That last exception mentioning "Unable to create ArchivaArtifact with empty
version" should have some follow up Caused-By exceptions with some more details.
Can you get those to us?
Attach them to this jira (if you feel it is too big of a stack trace)
> Dependency Tree causes an Exception
> ---
>
> Key: MRM-560
> URL: http://jira.codehaus.org/browse/MRM-560
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-3
> Environment: solaris 9 + tomcat 6.0.14
>Reporter: Olivier Lamy
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-beta-3
>
>
> Using the Dependency Tree link generates the following stack trace :
> {noformat}
> HTTP Status 500 -
> type Exception report
> message
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
> exception
> javax.servlet.ServletException: org.apache.jasper.JasperException: An
> exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:284)
>
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
>
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
>
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> root cause
> org.apache.jasper.JasperException: An exception occurred processing JSP page
> /WEB-INF/jsp/artifact/dependencyTree.jsp at line 24
> 21: <%@ taglib prefix="my" tagdir="/WEB-INF/tags" %>
> 22: <%@ taglib prefix="archiva" uri="http://maven.apache.org/archiva"; %>
> 23:
> 24: version="${version}"
> 25: modelVersion="${model.version}">
> 26:artifactId="${node.artifactId}"
> 27:version="${node.version}"/>
> Stacktrace:
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:524)
>
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:417)
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>
> com.opensymphony.webwork.dispatcher.ServletDispatcherResult.doExecute(ServletDispatcherResult.java:114)
>
> com.opensymphony.webwork.dispatcher.WebWorkResultSupport.execute(WebWorkResultSupport.java:143)
>
> com.opensymphony.xwork.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:313)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:208)
>
> com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
>
> com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.apache.maven.archiva.web.interceptor.ConfigurationInterceptor.intercept(ConfigurationInterceptor.java:53)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:178)
>
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
>
> com.opensymphony.xwork.interceptor.ParameterFilterInterceptor.intercept(ParameterFilterInt
[jira] Commented: (MSOURCES-21) Allow classes to be bundled with the source code
[ http://jira.codehaus.org/browse/MSOURCES-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111601 ] Wendy Smoak commented on MSOURCES-21: - Wouldn't it make more sense to include the source code in the normal jar file? > Allow classes to be bundled with the source code > > > Key: MSOURCES-21 > URL: http://jira.codehaus.org/browse/MSOURCES-21 > Project: Maven 2.x Source Plugin > Issue Type: New Feature >Affects Versions: 2.0.3 >Reporter: Tom Schneider >Priority: Minor > Attachments: sourceplugin-includeClasses.patch > > > We have the need to bundle the compiled class files with the source code and > other resources. So I created a patch that adds a new configuration point > (includeClasses) that when set to true, will bundle not only the source code > and resources, but also the generated class files. -- 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: (MANTRUN-68) Use ant-1.7.0
[ http://jira.codehaus.org/browse/MANTRUN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Shemansky updated MANTRUN-68: -- Attachment: MANTRUN-68-maven-antrun-plugin.patch I recently stumbled upon this issue while trying to use Ant 1.7.0 features in the maven-antrun-plugin. Please review the attached patch. I believe this should fix the maven-antrun-plugin issue regardless of [MNG-3083|http://jira.codehaus.org/browse/MNG-3083]. The patch changes the ant dependency version numbers to 1.7.0. It also changes the maven-antrun-plugin's version number to match Ant in order to make usage more intuitive. I believe the two should be synchronized for clarity to the end-user. > Use ant-1.7.0 > - > > Key: MANTRUN-68 > URL: http://jira.codehaus.org/browse/MANTRUN-68 > Project: Maven 2.x Antrun Plugin > Issue Type: New Feature >Affects Versions: 1.2 > Environment: xp, linux >Reporter: Dan Tran > Attachments: MANTRUN-68-maven-antrun-plugin.patch > > > with out this upgrade, i will need to ant 1.7.0 to use its new > features like abily to do delete,move, etc using filelist -- 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: (MRM-481) Artifact requests with a .xml.zip extension fail with a 404 Error
[ http://jira.codehaus.org/browse/MRM-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-481. -- Resolution: Fixed Fixed in archiva/trunk revision 588732. > Artifact requests with a .xml.zip extension fail with a 404 Error > - > > Key: MRM-481 > URL: http://jira.codehaus.org/browse/MRM-481 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Cédric Vidal >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: multi-dots-ext-404-error.htm > > > This issue might also apply to any multi dots extension request but I didn't > check. > Regards, > Cédric -- 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: (MSITE-267) Relative path in inherited sites broken for depth of 2
[ http://jira.codehaus.org/browse/MSITE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111566 ] Dennis Lundberg commented on MSITE-267: --- Could you please supply us with an example including both pom.xml files and site.xml files. I think this might have something to do with the values of in your poms. The site-plugin uses the values of to calculate links relative to other modules (parent or child). > Relative path in inherited sites broken for depth of 2 > -- > > Key: MSITE-267 > URL: http://jira.codehaus.org/browse/MSITE-267 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: relative links >Affects Versions: 2.0-beta-6 > Environment: SunOS >Reporter: Dave Meibusch > > Parent site.xml has bannerLeft with absolute URL in that is > /images/logo.gif > First child module has (correctly) rendered relative path of: > ../images/logo.gif > Grandchild module (child of first child) has (incorrectly) rendered path of: > ../../../images/logo.gif > An extra depth has been added to the relative URL. > If the bannerLeft URL is a relative URL, the first child module has an > incorrectly rendered path (again, extra '../' depth). -- 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-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111548 ] Richard van Nieuwenhoven commented on MECLIPSE-333: --- as far as i know one should not make a dependency between war's. Does the war plugin handle such things at all? When i need such a requirement i use a system like tobago uses. a jar resource that will be extracted in the dependent war resource . As far as i know WTP has no other way to split the WebContent into to directories or even in two modules/projects. The classes of a dependent jar will never be exploded in the WEB-INF/classes directory. WTP will package your dependent jar into WEB-INF/lib, as it should! and as maven does! WTP will also do the hot deployment of your changed classes during debugging so no need of copying classes. When it can't update them just do a republish. regards, Ritchie > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Attachments: maven-eclipse-plugin_only_new.tar.gz, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- 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-1538) Continuum gets confused with flat projects
Continuum gets confused with flat projects -- Key: CONTINUUM-1538 URL: http://jira.codehaus.org/browse/CONTINUUM-1538 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Environment: Windows Server 2003. Reporter: Erick Dovale Attachments: continuum-confused-stacktrace.txt, continuum-confused.JPG When adding the parent pom of a maven2 project with flat structure continuum gets confused and ends up adding repeated instances of the same project. What's even worst, sometimes, removing one of the duplicated project will end up in a foreign key constraint violation. See attachments. -- 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-333) WTP-2.0 support with howto apt, refactoring and contextroot handling
[ http://jira.codehaus.org/browse/MECLIPSE-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111545 ] Martin Zeltner commented on MECLIPSE-333: - I've patched the plugin but in Eclipse I still not have the expected result. I have a jar artifact A and two war artifacts B & C. C depends on B depends on A. In A I've defined some general usable classes. In B I've added some web resources like the index.html (in web root), my.css and so on. In C I've added another index.html (also in web root). What I would expect when A, B and C are as projects (Maven reactor projects) imported in Eclipse workspace: When I deploy C on server (Tomcat, within Eclipse of course) I would expect the index.html of C, the my.css of B (and all other web resources of B) in web's root dir and the classes of A in WEB-INF/classes. What I get: As web resources I just get the index.html of C and NO web resources of B. Instead I get a JAR in WEB-INF/lib/B.jar with the complete artifact tree!! The classes of A are not directly placed in WEB-INF/classes but packed as jar in WEB-INF/lib. I can live with that but copy the classes in WEB-INF/classes would be even faster (shorter round trips). Could anyone correct this web resource bug? I can (if Eclipse "allows" it) do it but I need the "complete" "specification" (xsd?, would be great!) how does the generated files (.classpath, .project and the files in folder .settings) has to look like for WTP 2(.0.1). Thanks for any comment! Have a nice weekend! Cheers, Martin > WTP-2.0 support with howto apt, refactoring and contextroot handling > - > > Key: MECLIPSE-333 > URL: http://jira.codehaus.org/browse/MECLIPSE-333 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: multiproject, WTP support >Affects Versions: 2.5 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Attachments: maven-eclipse-plugin_only_new.tar.gz, > wtp-2.0-and-more-2.5-SNAPSHOT.patch > > > This patch contains: > - WTP.2.0 support for ear and war's (includes MECLIPSE-264) > - context root handling very much improved > (war takes configuration from the ear, if available) > - refactoring (constant usage, foreign plug-in access centralized) > - a detailed description how we use maven-2 with WTP in multi module projects > - testing code included > the patch is attached, together with a tar with all the new files. -- 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-143) eclipse:eclipse adds sourcepath or javadocpath to .classpath but not both
[
http://jira.codehaus.org/browse/MECLIPSE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111529
]
Tony Falabella commented on MECLIPSE-143:
-
I have the following configuration:
Windows XP
maven 2.0.7 (not sure if the plugin uses it's own or not so this might not be
needed)
org.maven.ide.eclipse_0.0.11.20070916-2300
org.maven.ide.eclipse.feature_0.0.11.20070916-2300
eclipse 3.3
As of 2007-10-26, this still appears to be an issue. It is as the other bug
http://jira.codehaus.org/browse/MECLIPSE-143 describes. If you have both
"Download Artifact Sources" and "Download Artifact JavaDocs" options checked,
if sources are found for a library it doesn't even look for JavaDocs.
As a test I created a repository that has both the xxx-javadoc.jar and
xxx-sources.jar. I've turned DEBUG logging on. If I have both "Download
Artifact Sources" and "Download Artifact JavaDocs" options checked I never see
anything in the log for it attempting to even look for the xxx-javadoc.jar .
Thus no xxx-javadoc.jar ends up in the localrepos. It does properly find the
xxx-sources.jar and that then appears in the localrepos. If I remove the
dependency, clear out the localrepos, and only check the "Download Artifact
JavaDocs" option and try again, I see the following in the log:
{noformat}
10/26/07 9:06:28 AM EDT: [DEBUG] Trying repository tonylocal2
10/26/07 9:06:28 AM EDT: [DEBUG] SHA1 not found, trying MD5 File: C:\Documents
and
Settings\af25830\.m2\futures-source-repository2\org\acegisecurity\acegi-security\1.0.3\acegi-security-1.0.3-javadoc.jar.sha1
does not exist
10/26/07 9:06:28 AM EDT: [WARN] *** CHECKSUM FAILED - Error retrieving checksum
file for
org/acegisecurity/acegi-security/1.0.3/acegi-security-1.0.3-javadoc.jar -
IGNORING
10/26/07 9:06:28 AM EDT: [DEBUG] Artifact resolved
10/26/07 9:06:28 AM EDT: Scanned javadoc C:/Documents and
Settings/af25830/.m2/localrepository/org/acegisecurity/acegi-security/1.0.3/acegi-security-1.0.3-javadoc.jar
0.0
{noformat}
In this case it does properly find the xxx-javadocs.jar and they then appear in
the localrepos and are properly associated as javadocs with the jar in Eclipse.
I agree though, it should not be an "either-or" in regards to downloading
source or javadocs.
> eclipse:eclipse adds sourcepath or javadocpath to .classpath but not both
> -
>
> Key: MECLIPSE-143
> URL: http://jira.codehaus.org/browse/MECLIPSE-143
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Environment: Windows XP
> Maven 2.0.4
> maven-eclipse-plugin 2.2
>Reporter: Edin Pezerovic
>Assignee: Kenney Westerhof
>
> issuing a mvn eclipse:eclipse generates the .classpath file with either
> tag within classpathentry or a sourcepath-attribute for the
> classpathentry, but never both.
> I think, the "else" in the code below is the bug and should be removed. (File
> EclipseClasspathWriter, Method addDependency)
> ..
> if ( sourcepath != null )
> {
> writer.addAttribute( ATTR_SOURCEPATH, sourcepath );
> }
> ELSE if ( javadocpath != null )
> {
> writer.startElement( "attributes" ); //$NON-NLS-1$
> writer.startElement( "attribute" ); //$NON-NLS-1$
> writer.addAttribute( "value", "jar:file:/" + javadocpath + "!/"
> ); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
> writer.addAttribute( "name", "javadoc_location" ); //$NON-NLS-1$
> //$NON-NLS-2$
> writer.endElement();
> writer.endElement();
> }
> .
--
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-292) Behaviour for sources and Javadoc attachement for dependencies should be consistent
[
http://jira.codehaus.org/browse/MECLIPSE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111528
]
Tony Falabella commented on MECLIPSE-292:
-
I have the following configuration:
Windows XP
maven 2.0.7 (not sure if the plugin uses it's own or not so this might not be
needed)
org.maven.ide.eclipse_0.0.11.20070916-2300
org.maven.ide.eclipse.feature_0.0.11.20070916-2300
eclipse 3.3
As of 2007-10-26, this still appears to be an issue. It is as the other bug
[http://jira.codehaus.org/browse/MECLIPSE-143] describes. If you have both
"Download Artifact Sources" and "Download Artifact JavaDocs" options checked,
if sources are found for a library it doesn't even look for JavaDocs.
As a test I created a repository that has both the xxx-javadoc.jar and
xxx-sources.jar. I've turned DEBUG logging on. If I have both "Download
Artifact Sources" and "Download Artifact JavaDocs" options checked I never see
anything in the log for it attempting to even look for the xxx-javadoc.jar .
Thus no xxx-javadoc.jar ends up in the localrepos. It does properly find the
xxx-sources.jar and that then appears in the localrepos. If I remove the
dependency, clear out the localrepos, and only check the "Download Artifact
JavaDocs" option and try again, I see the following in the log:
{noformat}
10/26/07 9:06:28 AM EDT: [DEBUG] Trying repository tonylocal2
10/26/07 9:06:28 AM EDT: [DEBUG] SHA1 not found, trying MD5 File: C:\Documents
and
Settings\af25830\.m2\futures-source-repository2\org\acegisecurity\acegi-security\1.0.3\acegi-security-1.0.3-javadoc.jar.sha1
does not exist
10/26/07 9:06:28 AM EDT: [WARN] *** CHECKSUM FAILED - Error retrieving checksum
file for
org/acegisecurity/acegi-security/1.0.3/acegi-security-1.0.3-javadoc.jar -
IGNORING
10/26/07 9:06:28 AM EDT: [DEBUG] Artifact resolved
10/26/07 9:06:28 AM EDT: Scanned javadoc C:/Documents and
Settings/af25830/.m2/localrepository/org/acegisecurity/acegi-security/1.0.3/acegi-security-1.0.3-javadoc.jar
0.0
{noformat}
In this case it does properly find the xxx-javadocs.jar and they then appear in
the localrepos and are properly associated as javadocs with the jar in Eclipse.
I agree though, it should not be an "either-or" in regards to downloading
source or javadocs.
> Behaviour for sources and Javadoc attachement for dependencies should be
> consistent
> ---
>
> Key: MECLIPSE-292
> URL: http://jira.codehaus.org/browse/MECLIPSE-292
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: dependency resolution
>Affects Versions: 2.4
> Environment: Windows XP, Maven 2.0.6, maven-eclipse-plugin
> 2.4-20070628.215652-24
>Reporter: Denis Cabasson
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 2.5
>
> Attachments: MECLIPSE-292-fixbug.patch, MECLIPSE-292-updated.patch,
> MECLIPSE-292.patch
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Why couldn't we have a consistent behaviour for javadoc and sources jar
> attachment?
> Why not adding a downloadJavadoc property, which, when set to true, would
> download and attach the javadoc to the dependency.
> I don't really see why javadoc should be a fallback if sources are not
> available.
> Some developpers might prefer to have javadoc linked, some sources linked and
> some both. Shouldn't the eclipse plugin allow for all the possiblities
> instead of stating that the preferred option is always to get the sources
> instead of the Javadoc?
--
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: (DOXIA-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111513 ] Vincent Massol commented on DOXIA-176: -- You can use: 1) the shelve changes feature of IDEA 7 2) a tool that handles patches like Quilt (http://www.coffeebreaks.org/blogs/wp-content/archives/talks/2005/quilt/quiltintro-s5.html) 3) wait for the patch to be applied My preference goes to 1) but that's because I'm an IDEA user. > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: mylyn-context.zip, mylyn-context.zip, > section-title-patch-1.txt, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "Hello". -- 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: (DOXIA-177) Invalid XHTML because of wrong position of table caption
Invalid XHTML because of wrong position of table caption Key: DOXIA-177 URL: http://jira.codehaus.org/browse/DOXIA-177 Project: Maven Doxia Issue Type: Bug Components: Module - Xhtml Affects Versions: 1.0-alpha-9 Reporter: Lukas Theussl Currently a table caption is most of the time emitted after the table body (mainly because apt puts the caption after the table). However, for a valid xhtml-1.0, the table caption has to come before the first table row. Since we don't have a mechanism yet to enforce the order of parsing events (see DOXIA-132), and I am not sure if this can be achieved in general, any sink should be flexible enough to deal with any reasonable order of events, to produce some valid output. -- 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: (DOXIA-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111509 ] Dave Syer commented on DOXIA-176: - Agreed, but it's also impossible to create a patch for one issue if the changes from another issue have not been comitted yet - unless you know something I don't. > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: mylyn-context.zip, mylyn-context.zip, > section-title-patch-1.txt, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "Hello". -- 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: (DOXIA-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-176. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.0-beta-1 Applied, thanks! I think it's generally a good idea to only attach patches for the issue under consideration. It's not a big deal for simple fixes like this one, but otherwise it's hard to keep things apart when reviewing the patch, especially if the code has evolved in the meantime. > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: mylyn-context.zip, mylyn-context.zip, > section-title-patch-1.txt, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "Hello". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated MNG-3259: Attachment: MNG-3259.zip Attachment with zipped demo project. Build instructions: - extract ZIP - go into extracted root directory - install parent pom first: mvn -f parent/pom.xml - install multi-module: mvn install The build should fail (*). Go into module5 and build from there: mvn install This time it should succeed. *) Before I've zipped the project I tried to replace any occurrence of "XXX" with "3259" in the 7 pom.xml files, but after that action M208 can suddenly build this! Therefore I've added also an "install.log" to the project root that demonstrates the problem. This means additionally that this build might behave differently on different JDKs. I highly assume that there are still some HashMaps used internally that have influence about the sequence the dependencies are processed, therefore I'd expect Maven to behave differently, e.g. this sequence is different for HashMaps in JDK 6 and the project can be build running M208 with JDK 6! See also first lines of install.log for my environment: Maven version: 2.0.8-SNAPSHOT Java version: 1.4.2_13 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Priority: Blocker > Attachments: MNG-3259.zip > > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- 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-3259) Regression: Maven drops dependencies in multi-module build
Regression: Maven drops dependencies in multi-module build -- Key: MNG-3259 URL: http://jira.codehaus.org/browse/MNG-3259 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.7, 2.0.8 Reporter: Joerg Schaible Priority: Blocker Under some circumstances Maven "forgets" about test dependencies in multi-module builds. The affected module can be build only if the build is started from its local project directory. If the build is run from a parent directory, the test fails because of missing classes. This issue applies to M207 and recent M208-RC1, the project can be build without problems with M205 (M206 is completely bogus). The problem was for us already the show stopper for M207 and I thought with some of the now resolved issues it has been gone, but I was wrong. I did not report it earlier, because I was never able to reproduce the problem with a minimal build ... until now and it took me about 3 days to create a demonstrating multi module project. -- 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: (DOXIA-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-176: Attachment: section-title-patch-1.txt I could't provide a separate patch until you applied the other one. It's not very efficient, but I guess it's the only way? New patch is *-1 > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol > Attachments: mylyn-context.zip, mylyn-context.zip, > section-title-patch-1.txt, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "Hello". -- 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: (DOXIA-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Syer updated DOXIA-176: Attachment: mylyn-context.zip > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol > Attachments: mylyn-context.zip, mylyn-context.zip, > section-title-patch-1.txt, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "Hello". -- 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: (MRM-454) Index not updated after repository purge
[ http://jira.codehaus.org/browse/MRM-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-454. Resolution: Fixed Fix Version/s: (was: 1.0-beta-4) 1.0-beta-3 Fixed in -r588598 - synchronized the index operations in LuceneRepositoryContentIndex (used 'repository' as the lock) to avoid index locking - added method for deleting artifacts from the index during repository purge - updated repository purge tests > Index not updated after repository purge > > > Key: MRM-454 > URL: http://jira.codehaus.org/browse/MRM-454 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-beta-1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.0-beta-3 > > > Please see comments MRM-294 for more info -- 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: (DOXIA-169) Confluence module does not recognize line breaks (\\)
[ http://jira.codehaus.org/browse/DOXIA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111500 ] Dave Syer commented on DOXIA-169: - I get a compile error when I update from SVN after the patch weas applied - EOL is not resolved. Did you mean to expose it in the base class? > Confluence module does not recognize line breaks (\\) > - > > Key: DOXIA-169 > URL: http://jira.codehaus.org/browse/DOXIA-169 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: linebeak-patch-1.txt, linebeak-patch.txt > > > Confluence module does not recognize line breaks (\\) -- 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-1537) Error during build configuration
Error during build configuration Key: CONTINUUM-1537 URL: http://jira.codehaus.org/browse/CONTINUUM-1537 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-2 Reporter: Jean-Baptiste David Priority: Minor Attachments: trace.log During project build configuration : - I keep the default "clean install" task (group task) - I add a "site-deploy" build task (project task) Both tasks are configured with "true" for default field. When I come back to project task configuration and change something (anything but default field), I've got this error during the validation (see trace.log). Returning to the project : - group task : "false" for default field - project : still "true". -- 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: (DOXIA-176) Confluence parser doesn't strip leading space for section titles
[ http://jira.codehaus.org/browse/DOXIA-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111497 ] Lukas Theussl commented on DOXIA-176: - Dave, this patch gives me a build error, I think you forgot to include the LinebreakBlock class from DOXIA-169. Anyway, I have applied the patch there, could you attach a separate patch for only this issue here? Thanks. > Confluence parser doesn't strip leading space for section titles > > > Key: DOXIA-176 > URL: http://jira.codehaus.org/browse/DOXIA-176 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol > Attachments: mylyn-context.zip, section-title-patch.txt > > > For example for "h1. Hello", it'll send " Hello" to the text() Sink API > instead of "Hello". -- 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: (ARCHETYPE-109) plugins should have a auto-generated goal "help"
plugins should have a auto-generated goal "help" Key: ARCHETYPE-109 URL: http://jira.codehaus.org/browse/ARCHETYPE-109 Project: Maven Archetype Issue Type: Improvement Components: Plugin Reporter: Eirik Maus All plugins should have a goal "help". This should be auto-generated if it doesn't exist, listing the other goals (and settable properties) of the plugin. See also issue MPLUGIN-40 (http://jira.codehaus.org/browse/MPLUGIN-40). -- 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: (DOXIA-169) Confluence module does not recognize line breaks (\\)
[ http://jira.codehaus.org/browse/DOXIA-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-169. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.0-beta-1 Patch applied, thanks! Note that I have put the LineBreak test into ConfluenceParserTest, if you extend it then the base tests get executed twice. > Confluence module does not recognize line breaks (\\) > - > > Key: DOXIA-169 > URL: http://jira.codehaus.org/browse/DOXIA-169 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: linebeak-patch-1.txt, linebeak-patch.txt > > > Confluence module does not recognize line breaks (\\) -- 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: (MPLUGIN-40) All plugins should by default have an auto-generated goal 'help'
All plugins should by default have an auto-generated goal 'help' Key: MPLUGIN-40 URL: http://jira.codehaus.org/browse/MPLUGIN-40 Project: Maven 2.x Plugin Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Eirik Maus All plugins should have a goal called "help" providing help on how to use the plugin. This should be auto-generated if it doesn't already exist as a goal in the mojo. The autogenerated help should typically list the goals (and settable properties) of the plugin, and probably also print out the url to the plugin's website (if available). This will most likely affect the plugin archetype as well, I guess. -- 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-3258) the command "mvn -help" should describe the usage of the maven help plugin
the command "mvn -help" should describe the usage of the maven help plugin -- Key: MNG-3258 URL: http://jira.codehaus.org/browse/MNG-3258 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.7, 2.0.6, 2.0.5, 2.0.4 Reporter: Eirik Maus The help system in maven (and any other program as well) is typically what you use if you can't remember the syntax for a given command. The syntax for the help plugin is, however no simpler than any other command, and I always find myself ending up with searching google for info on how to use the help system to find out how to use, for instance, the dependency plugin. I have suggested a new goal "mvn help:help" in the help plugin to use for getting info on how to use the help system. The same info should be printed when a user types "mvn -help". -- 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: (MPH-26) New goal help:help to provide help on how to use helper plugins in maven
New goal help:help to provide help on how to use helper plugins in maven Key: MPH-26 URL: http://jira.codehaus.org/browse/MPH-26 Project: Maven 2.x Help Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Eirik Maus It is almost impossible to remember the usage of the helper utility plugins in maven. Every single time I have problems with transient dependencies I end up searching google for "maven help plugin" and "maven dependency plugin". That is not good enough. The help plugin should have a goal called help, describing the usage of the plugin. This would make help (or, rather, a bootstrap on how to use the help system) available under the obvious command "mvn help:help". This goal could also hint about the existence of the dependency plugin, since many of the difficult problems when using maven are related to complex transitive dependencies. The command "mvn -help" should also describe the use of the maven-help-plugin, but I will create a separate issue in the maven core module for that. -- 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-1536) Data management cli doesn't read settings.xml
[
http://jira.codehaus.org/browse/CONTINUUM-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated CONTINUUM-1536:
Fix Version/s: 1.1
> Data management cli doesn't read settings.xml
> -
>
> Key: CONTINUUM-1536
> URL: http://jira.codehaus.org/browse/CONTINUUM-1536
> Project: Continuum
> Issue Type: Bug
> Components: Data Management
>Affects Versions: 1.1-beta-2, 1.1-beta-3
>Reporter: Damien Lecan
>Priority: Critical
> Fix For: 1.1
>
>
> DMC doesn't read settings.xml file (proxy + Continuum beta-4 stage repository)
> settings.xml file is located under ${user.home}/.m2/
> Here is what I get when I try to execute DMC and then dependency:resolve with
> DMC pom file.
> DMC alone :
> [EMAIL PROTECTED] ~]$ java -jar data-management-cli-1.1-beta-4-app.jar ...
> 0 [main] INFO org.apache.maven.continuum.management.DataManagementCli
> - Processing Continuum database...
> Exception in thread "main"
> org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException:
> Missing:
> --
> 1) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-4
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.maven.continuum
> -DartifactId=data-management-jdo \
> -Dversion=1.1-beta-4 -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
>1) dummy:dummy:pom:1.0
>2) org.apache.maven.continuum:data-management-jdo:jar:1.1-beta-4
> --
> 1 required artifact is missing.
> for artifact:
> dummy:dummy:pom:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
>at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305)
>at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
>at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:243)
>at
> org.apache.maven.continuum.management.DataManagementCli.downloadArtifact(DataManagementCli.java:304)
>at
> org.apache.maven.continuum.management.DataManagementCli.processDatabase(DataManagementCli.java:185)
>at
> org.apache.maven.continuum.management.DataManagementCli.main(DataManagementCli.java:158)
> <= same session, same maven 2, same settings.xml =>
> Then, with DMC pom file :
> [EMAIL PROTECTED] ~]$ mvn dependency:resolve
> [INFO] Scanning for projects...
> Downloading:
> http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-data-management/1.1-beta-4/continuum-data-management-1.1-beta-4.pom
> 2K downloaded
> Downloading:
> http://people.apache.org/builds/maven/continuum/1.1-beta-4/org/apache/maven/continuum/continuum-parent/1.1-beta-4/continuum-parent-1.1-beta-4.pom
> 25K downloaded
> ...
> Maven itself finds settings.xml and its configuration, but DMC fails.
--
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-253) Create a matrix of databases that Continuum can work with
[ http://jira.codehaus.org/browse/CONTINUUM-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-253. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1) 1.1-beta-4 > Create a matrix of databases that Continuum can work with > - > > Key: CONTINUUM-253 > URL: http://jira.codehaus.org/browse/CONTINUUM-253 > Project: Continuum > Issue Type: Task > Components: Database, Documentation >Reporter: Jason van Zyl >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-4 > > > t -- 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-150) Continuum site needs screenshots
[ http://jira.codehaus.org/browse/CONTINUUM-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-150. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1) 1.1-beta-4 > Continuum site needs screenshots > > > Key: CONTINUUM-150 > URL: http://jira.codehaus.org/browse/CONTINUUM-150 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Reporter: Henri Yandell >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-beta-4 > > > The Continuum site needs to show screenshots to better sell Continuum to > interested parties. -- 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-570) Documentation to add for war deployment in several container
[ http://jira.codehaus.org/browse/CONTINUUM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111490 ] Emmanuel Venisse commented on CONTINUUM-570: Tomcat: DONE Geronimo: DONE > Documentation to add for war deployment in several container > > > Key: CONTINUUM-570 > URL: http://jira.codehaus.org/browse/CONTINUUM-570 > Project: Continuum > Issue Type: Task > Components: Documentation >Reporter: Emmanuel Venisse > Fix For: 1.1 > > > - Need doc for Jetty 6 > - Need doc for Jetty 5 > - Need doc for Tomcat 4 > - Need doc for Tomcat 5 > - Need doc for Weblogic (if we can access to a server) > - Need doc for Websphere (if we can access to a server) > - [Add other here] -- 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-815) directory configuration
[ http://jira.codehaus.org/browse/CONTINUUM-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-815. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1) 1.1-beta-4 > directory configuration > --- > > Key: CONTINUUM-815 > URL: http://jira.codehaus.org/browse/CONTINUUM-815 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.0.3 >Reporter: Torsten Curdt >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-4 > > > When I was installing maven it was not clear what the directories are for > that I had to specify. > - working directory > - build output directory > - local repository > The installation guide should explain values like these. Especially awkward > is that the builds happen in the working area - not in the build output area. > Just needs some documentation. -- 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-811) Documentation of Deployment Repository Directory
[ http://jira.codehaus.org/browse/CONTINUUM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-811. -- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1) 1.1-beta-4 > Documentation of Deployment Repository Directory > > > Key: CONTINUUM-811 > URL: http://jira.codehaus.org/browse/CONTINUUM-811 > Project: Continuum > Issue Type: Bug > Components: Documentation >Affects Versions: 1.0.3 >Reporter: Scott Cytacki >Assignee: Emmanuel Venisse > Fix For: 1.1-beta-4 > > > I can't find any good documenation on how the deployment repository directory > works. As far as I can tell continuum magically runs a special mvn deploy > goal after any sucess build. > But I can't find this in the log. Also it isn't clear how this relates to an > explicit mvn deploy. -- 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-1254) Clarification of Configuring Continuum as a Service in "Getting Started" Guide
[ http://jira.codehaus.org/browse/CONTINUUM-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1254. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: (was: 1.1) 1.1-beta-4 > Clarification of Configuring Continuum as a Service in "Getting Started" Guide > -- > > Key: CONTINUUM-1254 > URL: http://jira.codehaus.org/browse/CONTINUUM-1254 > Project: Continuum > Issue Type: Improvement > Components: Documentation >Reporter: James Williamson >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-beta-4 > > > I was running the service using the Local System account Log On credentials. > I changed the Log On credentials to specify my NT Login and password and now > it works fine. > Looking back at the Continuum "Getting Started" Guide, it explicitly states: > "By default, the service logs on as the Local System account. Be sure to > change this to an account where you want the service to start upon login." > However, I had supposed this meant change it if you want the service to run > in some location other than your local machine. In fact, I discovered that > you will need to change it if you want your service to work correctly. > This document could be improved by stating: "Be sure to change this to an > account where you want the service to start upon login. If you are hosting > the service on your local machine you still need to specify your login > credentials in order for your service to function properly." -- 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
