[jira] (SCM-681) Git blame fails to report line authors on windows with core.autocrlf = true
David Gageot created SCM-681: Summary: Git blame fails to report line authors on windows with core.autocrlf = true Key: SCM-681 URL: https://jira.codehaus.org/browse/SCM-681 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.7 Environment: Windows git configured with core.autocrlf = true Reporter: David Gageot Git blame cannot report line authors when each line is modified locally by the autocrlf parameter. It thinks every line is Not Yet Committed. The fix is to use git blame -w instead of plain git blame, to ignore whitespaces. See discussion here: http://stackoverflow.com/questions/4638500/git-blame-showing-no-history -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIASITETOOLS-69) ConcurrentModificationException when using site:run
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christof Schöll updated DOXIASITETOOLS-69:
--
Attachment: testmvnsite.zip
Here is an example project with the described behaviour -
When executing mvn site:run and clicking on the goals menu link the error occurs
ConcurrentModificationException when using site:run
---
Key: DOXIASITETOOLS-69
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-69
Project: Maven Doxia Sitetools
Issue Type: Bug
Components: Site renderer
Affects Versions: 1.2
Environment: Maven 2.2.1 with maven-site-plugin 3.0
Reporter: Christof Schöll
Attachments: testmvnsite.zip
When using maven with site:run I get the following exception, which seem to
originate from the Doxia Site Renderer
2012-04-04 12:27:07.653:WARN::/css/maven-theme.css
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.locateDocumentFiles(DefaultSiteRenderer.java:149)
at
org.apache.maven.plugins.site.webapp.DoxiaFilter.doFilter(DoxiaFilter.java:174)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
2012-04-04 12:27:07.656:WARN::/images/logos/maven-feather.png
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.locateDocumentFiles(DefaultSiteRenderer.java:149)
at
org.apache.maven.plugins.site.webapp.DoxiaFilter.doFilter(DoxiaFilter.java:174)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
The following source code in
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer (line 149) seems to
contain the problem:
149 for ( File siteDirectory : siteRenderingContext.getSiteDirectories() )
150 {
151 if ( siteDirectory.exists() )
152 {
153
[jira] (DOXIASITETOOLS-69) ConcurrentModificationException when using site:run
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301817#comment-301817 ] Christof Schöll edited comment on DOXIASITETOOLS-69 at 6/25/12 4:56 AM: I attached an example project with the described behaviour - When executing mvn site:run and clicking on the goals menu link the error occurs was (Author: c.schoell): Here is an example project with the described behaviour - When executing mvn site:run and clicking on the goals menu link the error occurs ConcurrentModificationException when using site:run --- Key: DOXIASITETOOLS-69 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-69 Project: Maven Doxia Sitetools Issue Type: Bug Components: Site renderer Affects Versions: 1.2 Environment: Maven 2.2.1 with maven-site-plugin 3.0 Reporter: Christof Schöll Attachments: testmvnsite.zip When using maven with site:run I get the following exception, which seem to originate from the Doxia Site Renderer 2012-04-04 12:27:07.653:WARN::/css/maven-theme.css java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.locateDocumentFiles(DefaultSiteRenderer.java:149) at org.apache.maven.plugins.site.webapp.DoxiaFilter.doFilter(DoxiaFilter.java:174) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) 2012-04-04 12:27:07.656:WARN::/images/logos/maven-feather.png java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.locateDocumentFiles(DefaultSiteRenderer.java:149) at org.apache.maven.plugins.site.webapp.DoxiaFilter.doFilter(DoxiaFilter.java:174) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) The following source code in
[jira] (DOXIASITETOOLS-69) ConcurrentModificationException when using site:run
[
https://jira.codehaus.org/browse/DOXIASITETOOLS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301818#comment-301818
]
Christof Schöll commented on DOXIASITETOOLS-69:
---
When creating the project I found out that the problem only occurs when the
maven-plugin-plugin is added in the reporting section.
ConcurrentModificationException when using site:run
---
Key: DOXIASITETOOLS-69
URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-69
Project: Maven Doxia Sitetools
Issue Type: Bug
Components: Site renderer
Affects Versions: 1.2
Environment: Maven 2.2.1 with maven-site-plugin 3.0
Reporter: Christof Schöll
Attachments: testmvnsite.zip
When using maven with site:run I get the following exception, which seem to
originate from the Doxia Site Renderer
2012-04-04 12:27:07.653:WARN::/css/maven-theme.css
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.locateDocumentFiles(DefaultSiteRenderer.java:149)
at
org.apache.maven.plugins.site.webapp.DoxiaFilter.doFilter(DoxiaFilter.java:174)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
2012-04-04 12:27:07.656:WARN::/images/logos/maven-feather.png
java.util.ConcurrentModificationException
at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.locateDocumentFiles(DefaultSiteRenderer.java:149)
at
org.apache.maven.plugins.site.webapp.DoxiaFilter.doFilter(DoxiaFilter.java:174)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
The following source code in
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer (line 149) seems to
contain the problem:
149 for ( File siteDirectory : siteRenderingContext.getSiteDirectories() )
150 {
151 if ( siteDirectory.exists() )
152
[jira] (MAVEN-1870) summary1
Alex created MAVEN-1870: --- Summary: summary1 Key: MAVEN-1870 URL: https://jira.codehaus.org/browse/MAVEN-1870 Project: Maven 1 Issue Type: Bug Reporter: Alex Priority: Blocker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MAVEN-1870) summary1
[ https://jira.codehaus.org/browse/MAVEN-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex closed MAVEN-1870. --- Resolution: Fixed summary1 Key: MAVEN-1870 URL: https://jira.codehaus.org/browse/MAVEN-1870 Project: Maven 1 Issue Type: Bug Reporter: Alex Priority: Blocker Original Estimate: 1 day Remaining Estimate: 1 day -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[
https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301560#comment-301560
]
Rakesh edited comment on MNG-5255 at 6/25/12 9:12 AM:
--
Ok here it goes these are the entries in the dependency tree related to jboss
for this WAR project when ran with -X maven option and they end up in the
WEB-INF/lib and I am repeating the same fact again I ran with Maven 2.2.1 and
it is working as desired:
{noformat}
[DEBUG]org.jboss.jbossas:jboss-as-tomcat:jar:5.0.1.GA:provided
[DEBUG] commons-logging:commons-logging:jar:1.1.0.jboss:compile
[DEBUG] apache-xerces:xml-apis:jar:2.9.1:compile
[DEBUG] com.sun:jsf-impl:jar:1.2_10:provided
[DEBUG] jacorb:jacorb:jar:2.3.0jboss.patch5-brew:provided
[DEBUG] javax.security:jaas:jar:1.0.01:runtime
[DEBUG] javax.transaction:jta:jar:1.1:compile
[DEBUG] org.jboss.logging:jboss-logging-spi:jar:2.0.5.GA:compile
[DEBUG] org.jboss.security:jboss-security-spi:jar:2.0.2.SP6:runtime
[DEBUG] jboss:jboss-serialization:jar:1.0.3.GA:provided
[DEBUG] org.jboss.integration:jboss-deployment-spi:jar:5.0.3.GA:runtime
[DEBUG] org.jboss.security:jbosssx-client:jar:2.0.2.SP6:compile
[DEBUG] jboss.web:jbossweb:jar:2.1.2.GA:provided
[DEBUG] org.jboss.ws.native:jbossws-native-jaxws:jar:3.0.5.GA:runtime
[DEBUG] org.jboss.ws.native:jbossws-native-saaj:jar:3.0.5.GA:compile
[DEBUG] jgroups:jgroups:jar:2.6.7.GA:provided
[DEBUG] log4j:log4j:jar:1.2.14:compile
[DEBUG] org.jboss:jboss-common-core:jar:2.2.11.GA:compile
[DEBUG] org.jboss.metadata:jboss-metadata:jar:1.0.0.CR16:compile
[DEBUG] org.jboss.ejb3:jboss-ejb3-ext-api:jar:1.0.0:compile
[DEBUG] org.jboss.javaee:jboss-jms-api:jar:1.1.0.GA:compile
[DEBUG] org.jboss.javaee:jboss-transaction-api:jar:1.0.1.GA:compile
[DEBUG] jboss.jbossws:jboss-jaxws:jar:3.0.1-native-2.0.4.GA:compile
[DEBUG] org.jboss:jboss-mdr:jar:2.0.0.GA:compile
[DEBUG] sun-jaxb:jaxb-api:jar:2.1.4:compile
[DEBUG] org.jboss:jboss-vfs:jar:2.1.0.GA:compile
[DEBUG] org.jboss.ws:jbossws-spi:jar:1.0.7.GA:compile
[DEBUG] org.apache.ant:ant:jar:1.7.0:compile
[DEBUG] org.apache.ant:ant-launcher:jar:1.7.0:compile
[DEBUG] dom4j:dom4j:jar:1.6.1:compile
[DEBUG] xml-apis:xml-apis:jar:1.0.b2:compile
[DEBUG] gnu-getopt:getopt:jar:1.0.13:compile
[DEBUG] org.jboss:jbossxb:jar:2.0.0.GA:compile
[DEBUG] org.jboss:jboss-reflect:jar:2.0.0.GA:compile
[DEBUG] apache-xerces:xercesImpl:jar:2.9.1:compile
[DEBUG] wutka-dtdparser:dtdparser121:jar:1.2.1:compile
[DEBUG] org.jboss.aop:jboss-aop:jar:2.0.1.GA:runtime
[DEBUG] javassist:javassist:jar:3.9.0.GA:runtime
[DEBUG] qdox:qdox:jar:1.6.1:compile
[DEBUG] trove:trove:jar:2.1.1:compile
[DEBUG] org.jboss.logging:jboss-logging-log4j:jar:2.0.5.GA:compile
[DEBUG] org.jboss.javaee:jboss-jaspi-api:jar:1.0.0.GA:compile
[DEBUG] org.jboss.jbossas:jboss-as-connector:jar:5.0.1.GA:provided
[DEBUG] org.jboss.jbossas:jboss-as-profileservice:jar:5.0.1.GA:provided
[DEBUG] org.jboss.jbossas:jboss-as-aspects:jar:5.0.1.GA:provided
[DEBUG]org.jboss.aop:jboss-aop-aspects:jar:2.0.1.GA:provided
[DEBUG]
org.jboss.aop:jboss-aop-asintegration-core:jar:2.0.1.GA:provided
[DEBUG]
org.jboss.aop:pluggable-instrumentor:jar:2.0.1.GA:provided
[DEBUG]
org.jboss.aop:jboss-aop-asintegration-jmx:jar:2.0.1.GA:provided
[DEBUG]
org.jboss.aop:jboss-aop-asintegration-mc:jar:2.0.1.GA:provided
[DEBUG]org.jboss.test:jboss-test:jar:1.1.3.GA:compile
[DEBUG] org.apache.ant:ant-junit:jar:1.7.0:compile
[DEBUG]
jboss.profiler.jvmti:jboss-profiler-jvmti:jar:1.0.0.CR5:compile
[DEBUG]
org.jboss.jbossas:jboss-server-manager:jar:1.0.0.GA:compile
[DEBUG]
org.jboss.jbossas:jboss-as-server:jar:client:5.0.0.CR2:runtime
[DEBUG]
org.jboss.jbossas:jboss-as-server:jar:jmx-invoker-adaptor-client:5.0.0.CR2:runtime
[DEBUG]
org.jboss.integration:jboss-profileservice-spi:jar:5.0.3.GA:compile
[DEBUG] org.jboss.microcontainer:jboss-aop-mc-int:jar:2.0.4.GA:runtime
[DEBUG] org.jboss.jbossas:jboss-as-system:jar:5.0.1.GA:runtime
[DEBUG]
org.jboss.integration:jboss-transaction-spi:jar:5.0.3.GA:runtime
[DEBUG] org.jboss.integration:jboss-integration:jar:5.0.3.GA:provided
[DEBUG] org.jboss.jbossas:jboss-as-main:jar:5.0.1.GA:compile
[DEBUG] org.jboss.man:jboss-metatype:jar:2.0.0.GA:compile
[DEBUG] org.jboss.man:jboss-managed:jar:2.0.0.GA:compile
[DEBUG] org.jboss.jbossas:jboss-as-ejb3:jar:5.0.1.GA:provided
[jira] (MASSEMBLY-616) do not included artifacts with scope system as dependencies
Radim Kolar created MASSEMBLY-616:
-
Summary: do not included artifacts with scope system as
dependencies
Key: MASSEMBLY-616
URL: https://jira.codehaus.org/browse/MASSEMBLY-616
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: FreeBSD 8, 64bit, openjdk6/7
Reporter: Radim Kolar
If you are building assembly with dependencies included:
useTransitiveDependenciestrue/useTransitiveDependencies
and one of dependencies has scope like that:
dependencies
dependency
groupIdjdk.tools/groupId
artifactIdjdk.tools/artifactId
version1.6/version
scopesystem/scope
systemPath${java.home}/../lib/tools.jar/systemPath
/dependency
/dependencies
then assembly plugin tries to fetch that artifact from repository. Artifact of
course is not there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SCM-682) Maven release fails when releasing from a named branch
João Loureiro created SCM-682: - Summary: Maven release fails when releasing from a named branch Key: SCM-682 URL: https://jira.codehaus.org/browse/SCM-682 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Affects Versions: 1.7 Environment: openSUSE 11.4 (x86_64) java version 1.6.0_26 Maven 3.0.4 maven-release-plugin 2.3.2 Hg version: 1.7.5 Jenkins ver. 1.471 Reporter: João Loureiro When trying to build a release from a named branch, maven release plugin fails when trying to tag. The first character of the name of the branch appears to be trimmed for no apparent reason. (Some details omitted with '*'.) [workspace] $ /usr/bin/hg update --rev RELEASE_2.4 (...) [INFO] [INFO] BUILD SUCCESS (...) [INFO] Checking in modified POMs... [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg branch [DEBUG] RELEASE_2.4 [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg outgoing [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg commit --message '[maven-release-plugin]' (files ommitted) [DEBUG] No username found, using '**' instead [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg push ssh://**//home/hgroot/**/ [DEBUG] pushing to ssh://**//home/hgroot/**/ [DEBUG] searching for changes [DEBUG] remote: adding changesets [DEBUG] remote: adding manifests [DEBUG] remote: adding file changes [DEBUG] remote: added 1 changesets with 19 changes to 19 files [INFO] Tagging release with the label **... [DEBUG] ScmTagPhase :: scmTagParameters remotingTag true [DEBUG] ScmTagPhase :: scmTagParameters scmRevision null [DEBUG] ScmTagPhase :: fileSet basedir = /var/lib/jenkins/jobs/**/workspace; files = [] [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg tag --message '[maven-release-plugin] copy for tag **' ** [DEBUG] No username found, using '**' instead [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg branch [DEBUG] RELEASE_2.4 [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg outgoing [WARNING] A different branch than ELEASE_2.4 was found in outgoing changes, branch name was RELEASE_2.4. Only local branch named ELEASE_2.4 will be pushed. [INFO] EXECUTING: /bin/sh -c cd /var/lib/jenkins/jobs/**/workspace hg push -rELEASE_2.4 ssh://**//home/hgroot/**/ [DEBUG] pushing to ssh://**//home/hgroot/**/ [DEBUG] abort: unknown revision 'ELEASE_2.4'! [ERROR] EXECUTION FAILED Execution of cmd : push failed with exit code: 255. Working directory was: /var/lib/jenkins/jobs/**/workspace Your Hg installation seems to be valid and complete. Hg version: 1.7.5 (OK) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301872#comment-301872 ] Joerg Schaible commented on MNG-5255: - OK, dependency tree is visible now. However, the result is really strange in this case. Dependency with 'provided' scope has its transitive dependency included in final artifact - Key: MNG-5255 URL: https://jira.codehaus.org/browse/MNG-5255 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) Maven home: D:\bin\apache-maven-3.0.4 Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: D:\bin\java\jdk1.6.0_27\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Bart Skondin Attachments: provided-scope-not-working.zip Expected: A dependency declared with a scope of 'provided', along with any transitive dependencies, should not be included in the final artifact. Actual: I have a dependency, jsp-api, declared with 'provided' scope. This dependency has a dependency of its own, servlet-api. The servlet-api.jar is being included in the web-inf/lib folder of the resultant war file. Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem was not witnessed until after the upgrade. Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib folder. Notice that the servlet-api.jar has been included. Additional Info: It seems that I can only reproduce this behavior when declaring a specific dependency in my pom, spring-ldap. Here is the dependency tree for the given pared-down project (attached): --- maven-dependency-plugin:2.1:tree (default-cli) @ provided-scope-not-working --- com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT +- javax.servlet:jsp-api:jar:2.0:provided | \- javax.servlet:servlet-api:jar:2.4:provided \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile +- commons-logging:commons-logging:jar:1.0.4:compile +- commons-lang:commons-lang:jar:2.1:compile +- org.springframework:spring-beans:jar:2.0.6:compile | +- (commons-logging:commons-logging:jar:1.1:compile - omitted for conflict with 1.0.4) | \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for duplicate) \- org.springframework:spring-core:jar:2.0.6:compile \- (commons-logging:commons-logging:jar:1.1:compile - omitted for conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301873#comment-301873 ] Rakesh commented on MNG-5255: - Maven 3.0.2 3.0.3 and 3.0.4 ended the same way which is totally against the Maven basic foundation principles about the scope , transitive dependencies and the packaging. Dependency with 'provided' scope has its transitive dependency included in final artifact - Key: MNG-5255 URL: https://jira.codehaus.org/browse/MNG-5255 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) Maven home: D:\bin\apache-maven-3.0.4 Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: D:\bin\java\jdk1.6.0_27\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Bart Skondin Attachments: provided-scope-not-working.zip Expected: A dependency declared with a scope of 'provided', along with any transitive dependencies, should not be included in the final artifact. Actual: I have a dependency, jsp-api, declared with 'provided' scope. This dependency has a dependency of its own, servlet-api. The servlet-api.jar is being included in the web-inf/lib folder of the resultant war file. Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem was not witnessed until after the upgrade. Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib folder. Notice that the servlet-api.jar has been included. Additional Info: It seems that I can only reproduce this behavior when declaring a specific dependency in my pom, spring-ldap. Here is the dependency tree for the given pared-down project (attached): --- maven-dependency-plugin:2.1:tree (default-cli) @ provided-scope-not-working --- com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT +- javax.servlet:jsp-api:jar:2.0:provided | \- javax.servlet:servlet-api:jar:2.4:provided \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile +- commons-logging:commons-logging:jar:1.0.4:compile +- commons-lang:commons-lang:jar:2.1:compile +- org.springframework:spring-beans:jar:2.0.6:compile | +- (commons-logging:commons-logging:jar:1.1:compile - omitted for conflict with 1.0.4) | \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for duplicate) \- org.springframework:spring-core:jar:2.0.6:compile \- (commons-logging:commons-logging:jar:1.1:compile - omitted for conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-217) HelpMojo (always) contains description for the maven-plugin-plugin
Robert Scholte created MPLUGIN-217:
--
Summary: HelpMojo (always) contains description for the
maven-plugin-plugin
Key: MPLUGIN-217
URL: https://jira.codehaus.org/browse/MPLUGIN-217
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Robert Scholte
The HelpMojo.java generated for the m-release-p contains the following
description:
{code}
/**
* Display help information on maven-plugin-plugin.br/
* Call codemvn plugin:help -Ddetail=true -Dgoal=lt;goal-namegt;/code to
display parameter details.
* @author
* @version
* @goal help
* @requiresProject false
* @threadSafe
*/
public class HelpMojo
extends AbstractMojo
{code}
This seems to be for the wrong plugin...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301876#comment-301876 ] Sean Gurevich commented on MEAR-146: FYI, the library-directory entry in application.xml causes WebLogic 12.1.1 to throw a weblogic.deployment.EnvironmentException: duplicate persistence units with name when using local development mode and copying EAR to autodeploy directory. (Not certain of outcome when deploying through AdminServer.) This problem isn't present under WebLogic 10.3.x even with the same EAR structure, i.e. packaging libs under APP-INF/lib per spec. Removing the library-directory entry manually from the application.xml makes the app work normally under WebLogic 12. I've been watching this issue, hoping to get an alternative workaround in case WebLogic decided this was a feature in their app server. The specific problem with the library-directory entry is that, under WebLogic 12, the server attempts to load persistence.xml out of the autodeploy folder as well as under the server/tmp/_WL_user (working area for the deployment). It's actually the same persistence.xml file, just placed in the tmp work space by WebLogic. PS: Our application doesn't care about custom classloading. Expose parameter to not write library-directory element in application.xml -- Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.8 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Attachments: ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically Generic File Loading) when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301876#comment-301876 ] Sean Gurevich edited comment on MEAR-146 at 6/25/12 4:17 PM: - FYI, the library-directory entry in application.xml causes WebLogic 12.1.1 to throw a weblogic.deployment.EnvironmentException: duplicate persistence units with name when using local development mode and copying EAR to autodeploy directory. (Not certain of outcome when deploying through AdminServer using WebLogic's deployer tool.) This problem isn't present under WebLogic 10.3.x even with the same EAR structure, i.e. packaging libs under APP-INF/lib per spec. Removing the library-directory entry manually from the application.xml makes the app work normally under WebLogic 12. I've been watching this issue, hoping to get an alternative workaround in case WebLogic decided this was a feature in their app server. The specific problem with the library-directory entry is that, under WebLogic 12, the server attempts to load persistence.xml out of the autodeploy folder as well as under the server/tmp/_WL_user (working area for the deployment). It's actually the same persistence.xml file, just placed in the tmp work space by WebLogic. PS: Our application doesn't care about custom classloading. was (Author: seanpublic): FYI, the library-directory entry in application.xml causes WebLogic 12.1.1 to throw a weblogic.deployment.EnvironmentException: duplicate persistence units with name when using local development mode and copying EAR to autodeploy directory. (Not certain of outcome when deploying through AdminServer.) This problem isn't present under WebLogic 10.3.x even with the same EAR structure, i.e. packaging libs under APP-INF/lib per spec. Removing the library-directory entry manually from the application.xml makes the app work normally under WebLogic 12. I've been watching this issue, hoping to get an alternative workaround in case WebLogic decided this was a feature in their app server. The specific problem with the library-directory entry is that, under WebLogic 12, the server attempts to load persistence.xml out of the autodeploy folder as well as under the server/tmp/_WL_user (working area for the deployment). It's actually the same persistence.xml file, just placed in the tmp work space by WebLogic. PS: Our application doesn't care about custom classloading. Expose parameter to not write library-directory element in application.xml -- Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.8 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Attachments: ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically Generic File Loading) when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=301876#comment-301876 ] Sean Gurevich edited comment on MEAR-146 at 6/25/12 4:19 PM: - FYI, the library-directory entry in application.xml causes WebLogic 12.1.1 to throw a weblogic.deployment.EnvironmentException: duplicate persistence units with name when using local development mode and copying EAR to autodeploy directory. (Not certain of outcome when deploying through AdminServer using WebLogic's deployer tool.) This problem isn't present under WebLogic 10.3.x even with the same EAR structure, i.e. packaging libs under APP-INF/lib per spec. Removing the library-directory entry manually from the application.xml makes the app work normally under WebLogic 12. I've been watching this issue, hoping to get an alternative workaround in case WebLogic decided this was a feature in their app server. The specific problem with the library-directory entry is that, under WebLogic 12, the server attempts to load persistence.xml out of the autodeploy folder as well as under the server/tmp/_WL_user (working area for the deployment). It's actually the same persistence.xml file, just placed in the tmp work space by WebLogic. PS: Our application doesn't care about custom classloading. I understand our issues are unrelated, but this fix would solve my problem. was (Author: seanpublic): FYI, the library-directory entry in application.xml causes WebLogic 12.1.1 to throw a weblogic.deployment.EnvironmentException: duplicate persistence units with name when using local development mode and copying EAR to autodeploy directory. (Not certain of outcome when deploying through AdminServer using WebLogic's deployer tool.) This problem isn't present under WebLogic 10.3.x even with the same EAR structure, i.e. packaging libs under APP-INF/lib per spec. Removing the library-directory entry manually from the application.xml makes the app work normally under WebLogic 12. I've been watching this issue, hoping to get an alternative workaround in case WebLogic decided this was a feature in their app server. The specific problem with the library-directory entry is that, under WebLogic 12, the server attempts to load persistence.xml out of the autodeploy folder as well as under the server/tmp/_WL_user (working area for the deployment). It's actually the same persistence.xml file, just placed in the tmp work space by WebLogic. PS: Our application doesn't care about custom classloading. Expose parameter to not write library-directory element in application.xml -- Key: MEAR-146 URL: https://jira.codehaus.org/browse/MEAR-146 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.8 Environment: Oracle WebLogic Reporter: Alex Halovanic Priority: Minor Attachments: ear-remove-librarydirectory-IT.patch, ear-remove-librarydirectory.patch The current handling of defaultLibBundleDir leads to some issues on Oracle Weblogic 10+. The Ear plugin currently sets library-directory to the value of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's classloading features break (specifically Generic File Loading) when this element is set. defaultLibBundleDir has to be set to APP-INF/lib since this is the magic library folder for WebLogic. The patch adds a parameter to prevent setting library-directory for cases like this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-217) HelpMojo (always) contains description for the maven-plugin-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MPLUGIN-217:
--
Assignee: Robert Scholte
HelpMojo (always) contains description for the maven-plugin-plugin
---
Key: MPLUGIN-217
URL: https://jira.codehaus.org/browse/MPLUGIN-217
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Robert Scholte
Assignee: Robert Scholte
The HelpMojo.java generated for the m-release-p contains the following
description:
{code}
/**
* Display help information on maven-plugin-plugin.br/
* Call codemvn plugin:help -Ddetail=true -Dgoal=lt;goal-namegt;/code
to display parameter details.
* @author
* @version
* @goal help
* @requiresProject false
* @threadSafe
*/
public class HelpMojo
extends AbstractMojo
{code}
This seems to be for the wrong plugin...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-217) HelpMojo (always) contains description for the maven-plugin-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Chemit updated MPLUGIN-217:
Attachment: MPLUGIN-217.diff
Here is a patch to fix this.
Could it be applied before release 3.1?
Thanks.
HelpMojo (always) contains description for the maven-plugin-plugin
---
Key: MPLUGIN-217
URL: https://jira.codehaus.org/browse/MPLUGIN-217
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Robert Scholte
Assignee: Robert Scholte
Attachments: MPLUGIN-217.diff
The HelpMojo.java generated for the m-release-p contains the following
description:
{code}
/**
* Display help information on maven-plugin-plugin.br/
* Call codemvn plugin:help -Ddetail=true -Dgoal=lt;goal-namegt;/code
to display parameter details.
* @author
* @version
* @goal help
* @requiresProject false
* @threadSafe
*/
public class HelpMojo
extends AbstractMojo
{code}
This seems to be for the wrong plugin...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
