[jira] Updated: (MRM-329) The Reports link gives an HTTP 500
[ http://jira.codehaus.org/browse/MRM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-329: - Fix Version/s: (was: 1.0.x) 1.0-beta-1 > The Reports link gives an HTTP 500 > -- > > Key: MRM-329 > URL: http://jira.codehaus.org/browse/MRM-329 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Napoleon Esmundo C. Ramirez >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-beta-1 > > Attachments: MRM-329-archiva-database-20070725.patch, > MRM-329-archiva-webapp-20070725.patch > > > Clicking the Reports link in the side navigation menu displays the following > (edited/snipped stacktrace): > HTTP ERROR: 500 > RequestURI=/admin/reports.action > Caused by: javax.el.PropertyNotFoundException: The class > 'org.apache.maven.archiva.reporting.artifact.OldArtifactReport' does not have > the property 'groupId'. > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:280) > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) > at com.sun.el.parser.AstValue.getValue(AstValue.java:118) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192) > at > org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:974) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspx_meth_c_forEach_0(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:143) > at > org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp._jspService(org.apache.jsp.WEB_002dINF.jsp.reports.reports_jsp:85) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) -- 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-1354) meta refresh causes build loop
[
http://jira.codehaus.org/browse/CONTINUUM-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated CONTINUUM-1354:
Fix Version/s: 1.1-beta-2
> meta refresh causes build loop
> --
>
> Key: CONTINUUM-1354
> URL: http://jira.codehaus.org/browse/CONTINUUM-1354
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.1-beta-1
> Environment: all
>Reporter: Olivier Lamy
> Fix For: 1.1-beta-2
>
>
> Simple scenario :
> - edit a project group
> - force a project build with the link "Build Now"
> - go to drink some coffe (longer than 5 minutes)
> - some project build have build enqueuing
> It due to the link
> http://${ip}:${pwd}/continuum/buildProject.action?fromGroupPage=true&projectGroupId=15&projectId=79
> The meta refresh force the build.
> As some browser have the tabs, this can cause a lot of not needed builds .
> --
> Olivier
> PS : I will provide a patch next week.
--
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-3122) MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile defined in LOCAL_HOME/.m2/settings.xml
MAVENPROJECT: getActiveProfiles() returning duplicate activeByDefault profile defined in LOCAL_HOME/.m2/settings.xml Key: MNG-3122 URL: http://jira.codehaus.org/browse/MNG-3122 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.7 Reporter: Ian Berry Attachments: settings.xml MavenProject:getActiveProfiles() is returning duplicate activeByDefault profiles defined in LOCAL_HOME/.m2/settings.xml. Attached settings.xml resides in LOCAL_HOME/.m2. Below is part of the output of a buildInformation plugin i am writing, which shows profile WLS8 twice. default-repositories settings.xml WLS8 settings.xml WLS8 settings.xml -- 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: (MAVENUPLOAD-1657) UrlRewriter
UrlRewriter --- Key: MAVENUPLOAD-1657 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1657 Project: maven-upload-requests Issue Type: Wish Reporter: Luc Pezet -- 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: (MJAVADOC-138) javadoc:test-javadoc failed if target/classes not already created
javadoc:test-javadoc failed if target/classes not already created
-
Key: MJAVADOC-138
URL: http://jira.codehaus.org/browse/MJAVADOC-138
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Vincent Siveton
Using
{noformat}
mvn clean javadoc:test-javadoc
{noformat}
it could produce unsuccessful build or warning (depending the javadoc version
used, i.e 1.4 vs 1.5)
The options file contains:
{noformat}
-classpath '[SNIP]/target/classes;[SNIP]/target/tests-classes;...'
{noformat}
The explanation is that no target\classes was created before executing
test-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: (CONTINUUM-1354) meta refresh causes build loop
[
http://jira.codehaus.org/browse/CONTINUUM-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103419
]
Olivier Lamy commented on CONTINUUM-1354:
-
read "the same project build have build enqueuing again" instead of "some
project build have build enqueuing"
> meta refresh causes build loop
> --
>
> Key: CONTINUUM-1354
> URL: http://jira.codehaus.org/browse/CONTINUUM-1354
> Project: Continuum
> Issue Type: Bug
> Components: Web interface
>Affects Versions: 1.1-beta-1
> Environment: all
>Reporter: Olivier Lamy
>
> Simple scenario :
> - edit a project group
> - force a project build with the link "Build Now"
> - go to drink some coffe (longer than 5 minutes)
> - some project build have build enqueuing
> It due to the link
> http://${ip}:${pwd}/continuum/buildProject.action?fromGroupPage=true&projectGroupId=15&projectId=79
> The meta refresh force the build.
> As some browser have the tabs, this can cause a lot of not needed builds .
> --
> Olivier
> PS : I will provide a patch next week.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGELOG-68) testReadFile unit test timebased comparisons fail
[
http://jira.codehaus.org/browse/MCHANGELOG-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103418
]
Dennis Lundberg commented on MCHANGELOG-68:
---
I can confirm that this is a bug. As a workaround you can set the timezone in
your OS to GMT+1. I know, it's not pretty but it's a workaround.
> testReadFile unit test timebased comparisons fail
> -
>
> Key: MCHANGELOG-68
> URL: http://jira.codehaus.org/browse/MCHANGELOG-68
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: 2.0.7
>Reporter: John Allen
>
> The unit tests in ChangeLogTest that test the changeset file for time
> comparisons such as:
> {code}
> ChangeSet changeSet = (ChangeSet) changelogSets.getChangeSets().get(
> 0 );
> Calendar cal = Calendar.getInstance(); // new cal with default TZ
> cal.set( 1977, 7, 6, 5, 30, 0); // expected date from
> min-changelog.xml
> cal.set( Calendar.MILLISECOND, 0);
> assertEquals( "Test changelog 1 set 1 date/time",
> cal.getTime().getTime(), changeSet.getDate().getTime() );
> {code}
> Fail on my UK GMT machine with trace:
> {code}
> junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time
> expected:<23967180> but was:<23968620>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:136)
> at
> org.apache.maven.plugin.changelog.ChangeLogTest.testReadFile(ChangeLogTest.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MIDEA-102. - Resolution: Duplicate The issue MIDEA-98 has been fixed and verified. It is only available in the the 2.2-SNAPSHOT version. It is not fixed in version 2.1 of this plugin. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1354) meta refresh causes build loop
meta refresh causes build loop
--
Key: CONTINUUM-1354
URL: http://jira.codehaus.org/browse/CONTINUUM-1354
Project: Continuum
Issue Type: Bug
Components: Web interface
Affects Versions: 1.1-beta-1
Environment: all
Reporter: Olivier Lamy
Simple scenario :
- edit a project group
- force a project build with the link "Build Now"
- go to drink some coffe (longer than 5 minutes)
- some project build have build enqueuing
It due to the link
http://${ip}:${pwd}/continuum/buildProject.action?fromGroupPage=true&projectGroupId=15&projectId=79
The meta refresh force the build.
As some browser have the tabs, this can cause a lot of not needed builds .
--
Olivier
PS : I will provide a patch next week.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103414 ] Dennis Lundberg commented on MIDEA-102: --- Which issue was this cloned from? Please create a link to it. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103413 ] Joern Huxhorn commented on MIDEA-102: - I'd also suggest to change protected String toRelative( File basedir, String absolutePath ) to static String toRelative( File basedir, String absolutePath ) and write some tests. I didn't want to change too much, though. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joern Huxhorn updated MIDEA-102: Attachment: maven-idea-plugin-MIDEA-102.patch the problem still exists if the master-module is at the same level as the child module, e.g. C:\foo\master and C:\foo\child. The attached patch fixes this problem. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
CLONE -still broken - Module filepath is generated incorrectly -- Key: MIDEA-102 URL: http://jira.codehaus.org/browse/MIDEA-102 Project: Maven 2.x IDEA Plugin Issue Type: Bug Affects Versions: 2.1 Environment: $ mvn -v Maven version: 2.0.7 Java version: 1.5.0_11 OS name: "windows xp" version: "5.1" arch: "x86" cygwin Reporter: Joern Huxhorn Assignee: Dennis Lundberg Fix For: 2.2 I have a multi-module mvn project. When I do an mvn idea:clean idea:idea, the following ProjectModuleManager snippet in the top level .ipr is generated: The $PROJECT_DIR in this case is C:/dev/voca/gateway/. But this path is being appended in a hard-coded fashion after the $PROJECT_DIR entry. The symptom in Intellij is the following error message: Cannot load module: File C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not exist Would you like to remove the module from the project? The workaround is to delete the extra appended file path from each module entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE
[ http://jira.codehaus.org/browse/MCHANGELOG-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGELOG-71: -- Affects Version/s: (was: 2.2) > Support a %REV% in displayFileDetailUrl in the same way we support %FILE > > > Key: MCHANGELOG-71 > URL: http://jira.codehaus.org/browse/MCHANGELOG-71 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: John Allen > > Reports are historical and by providing this we can keep the links to actual > revisions of the 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: (MCHANGELOG-71) Support a %REV% in displayFileDetailUrl in the same way we support %FILE
Support a %REV% in displayFileDetailUrl in the same way we support %FILE Key: MCHANGELOG-71 URL: http://jira.codehaus.org/browse/MCHANGELOG-71 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1, 2.2 Reporter: John Allen Reports are historical and by providing this we can keep the links to actual revisions of the 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: (MCHANGELOG-68) testReadFile unit test timebased comparisons fail
[
http://jira.codehaus.org/browse/MCHANGELOG-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGELOG-68:
--
Affects Version/s: (was: 2.2)
2.1
> testReadFile unit test timebased comparisons fail
> -
>
> Key: MCHANGELOG-68
> URL: http://jira.codehaus.org/browse/MCHANGELOG-68
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: 2.0.7
>Reporter: John Allen
>
> The unit tests in ChangeLogTest that test the changeset file for time
> comparisons such as:
> {code}
> ChangeSet changeSet = (ChangeSet) changelogSets.getChangeSets().get(
> 0 );
> Calendar cal = Calendar.getInstance(); // new cal with default TZ
> cal.set( 1977, 7, 6, 5, 30, 0); // expected date from
> min-changelog.xml
> cal.set( Calendar.MILLISECOND, 0);
> assertEquals( "Test changelog 1 set 1 date/time",
> cal.getTime().getTime(), changeSet.getDate().getTime() );
> {code}
> Fail on my UK GMT machine with trace:
> {code}
> junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time
> expected:<23967180> but was:<23968620>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:136)
> at
> org.apache.maven.plugin.changelog.ChangeLogTest.testReadFile(ChangeLogTest.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-70) Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs
Support a URL filter that enables JIRA/bugzilla/whatever IDs quoted in SCM message to be mapped to real URLs Key: MCHANGELOG-70 URL: http://jira.codehaus.org/browse/MCHANGELOG-70 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: John Allen Eclipse Mylyn, plus other good behaviours (see [JIRA Commit Acceptance Plugin|http://confluence.atlassian.com/display/JIRAEXT/Commit+Acceptance+Plugin]) make it necessary to quote a task upon check-in. These task IDs can easily be mapped to URLs using simple regex pattern rules that can be defined in the plugin config. -- 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: (MCHANGELOG-69) Print developer names regardless of whether they're listed in the POM
Print developer names regardless of whether they're listed in the POM - Key: MCHANGELOG-69 URL: http://jira.codehaus.org/browse/MCHANGELOG-69 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: 2.2 Reporter: John Allen It seems a waste to throw away good information from the SCM report just because a developer is not listed in the projects , lets just print the name from the SCM report (userid) if we cant find them in the 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: (MCHANGELOG-68) testReadFile unit test timebased comparisons fail
testReadFile unit test timebased comparisons fail
-
Key: MCHANGELOG-68
URL: http://jira.codehaus.org/browse/MCHANGELOG-68
Project: Maven 2.x Changelog Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: 2.0.7
Reporter: John Allen
The unit tests in ChangeLogTest that test the changeset file for time
comparisons such as:
{code}
ChangeSet changeSet = (ChangeSet) changelogSets.getChangeSets().get( 0
);
Calendar cal = Calendar.getInstance(); // new cal with default TZ
cal.set( 1977, 7, 6, 5, 30, 0); // expected date from min-changelog.xml
cal.set( Calendar.MILLISECOND, 0);
assertEquals( "Test changelog 1 set 1 date/time",
cal.getTime().getTime(), changeSet.getDate().getTime() );
{code}
Fail on my UK GMT machine with trace:
{code}
junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time
expected:<23967180> but was:<23968620>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:136)
at
org.apache.maven.plugin.changelog.ChangeLogTest.testReadFile(ChangeLogTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103404
]
John Allen commented on MSITE-129:
--
Kenney, how can we go about dealing with these two cases?
* A user wishes to have all the modules appear.
Okay so I guess with the tag being called then this is what it
was originally intended to do and the reactor based code should be changed to
only find the modules from the reactor, not the inheriting projects (as it does
at the moment).
The benefits to using the reactor is that it's quick and the projects are fully
interpolated. If there's no reactor we try and build the models from the
fileystem module POMs. I'm not sure how interpolated they are, ie if the module
has ${} values in it are they evaluated? (didnt used to be the case but could
be now). If there are no filesystem modules available then it's a pure nasty
hack of setting the module project's name and url to be the value found in the
root project's element, which for flat multimodule type
scenarios will be "../somename" ( ! )
* A user wishes to have the children appear in the site, regardless of the
modules.
This is what users like me want. I guess a configuration option could be used
to distinguish this behaviour rather than a new site.xml element. Either way
this is easy for the reactor based 'child project's find but for the mvn -N
situations one would need to create all the module projects from their file
system pom.xml files and then check if their parent clauses match the current
project.
Actually that doesn't sound to be bad to me. Thoughts?
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103400
]
Stephane Nicoll commented on MEAR-73:
-
also note that you don't need the ejbModule entry at all. It's only used if you
want to customize module's parameters (bundle file name, uri, etc)
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: ear.jpg, patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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] Commented: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103399
]
Stephane Nicoll commented on MEAR-73:
-
> I mean that the dependency:resolve with the property excludeTransitive don't
> have any effects to the ear plugin.
Well I wonder *how* it could have any effect.
And your patch is plain wrong anyway: it works as a side effect. since you have
a single dependency and non scope dependencies. Trust me, your simple project
does not reflect how this plugin is used at all.
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: ear.jpg, patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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: (MCLOVER-80) aggregate is not respecting the true module hierarchy and creates merged databases containing non-sibling data
[ http://jira.codehaus.org/browse/MCLOVER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Allen updated MCLOVER-80: -- Attachment: MCLOVER-80.diff After discussion it appears that some people would like aggregate to include all the projects within the reactor, regardless of their inheritance relationship to the parent project (i.e. the existing behaviour) and others would like the inheritance hierarchy to be honoured in aggregation. This latest patch supports both these configurations with the addition of a new configuration option 'aggregateOnlyChildren'. > aggregate is not respecting the true module hierarchy and creates merged > databases containing non-sibling data > -- > > Key: MCLOVER-80 > URL: http://jira.codehaus.org/browse/MCLOVER-80 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: John Allen > Attachments: MCLOVER-80.diff, MCLOVER-80.diff, MCLOVER-80.diff, > MCLOVER-80.diff > > > The reactor contains a very deep multi-project multi-module structure. We > would expect the aggregation to only go up the family tree and not pollute > across the ancestors. > A-->B-->C-->D > A-->B-->E > A-->Q-->P-->R > A-->Q-->P-->S > We would expect A to contain all the merged data but not to find that in P we > have data from C and D. -- 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: (MPCLOVER-59) clover report does not include instrumented test lines of code with junit report included
clover report does not include instrumented test lines of code with junit report included - Key: MPCLOVER-59 URL: http://jira.codehaus.org/browse/MPCLOVER-59 Project: Maven 1.x Clover Plugin Issue Type: Bug Affects Versions: 1.11.2 Environment: windows XP/cygwin maven 1.1 maven-junit-report-plugin 1.5.1 Reporter: Jeff Black Running the clover report as the only project report to obtain source lines of code works with the property maven.clover.instrument.tests set = true. However, if the project also specifies the junit report (maven-junit-report-plugin), then the clover report will not include test lines of code, even with the property maven.clover.instrument.tests=true. I looked at the junit-report-plugin plugin.jelly, put nothing jumped out at me as being suspect along the lines of modifying maven.test.compile.src.set, for example. This is can reproduced by adding the maven-junit-report-plugin to the existing clover plugin test case: testSiteReportAndGenerationOfDifferentFormats -- 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: (MDOCCK-3) Various problems with the plugin
[
http://jira.codehaus.org/browse/MDOCCK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MDOCCK-3.
Resolution: Fixed
Fix Version/s: 1.0-beta-2
All the issues have now been resolved.
> Various problems with the plugin
>
>
> Key: MDOCCK-3
> URL: http://jira.codehaus.org/browse/MDOCCK-3
> Project: Maven 2.x DOCCK Plugin
> Issue Type: Improvement
>Affects Versions: 1.0-beta-1
> Environment: Maven 2.0.4
>Reporter: Jimisola Laursen
>Assignee: Dennis Lundberg
> Fix For: 1.0-beta-2
>
>
> P1. "[ERROR] Missing examples."
> Q1. What is actually missing? The directory? Files in that directory?
> Proposed solution: Provide a more detailed error message and document it.
> Also, the SVN repo of DOCCK Plugin itself should act as a standard for
> plugins so that plugin developers has an example to look at.
> P2. "[WARN] license MIT license appears to have an invalid URL:
> 'LICENSE.txt'. Error: no protocol: LICENSE.txt Trying to access it as a file
> instead."
> Q2. LICENSE.txt shows correctly in the generated site. The file is in the
> same directory as the pom.xml. If I use file:// then I also get a warning
> ("[WARN] Non-HTTP license MIT license URL not verified."). Where shall the
> file be placed and how should I specify the url?
> P3. "[ERROR] Cannot reach project site with URL:
> 'http://mojo.codehaus.org/freemarker-maven-plugin'.
> [ERROR] Cannot reach scm with URL:
> 'https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin'.Error:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target"
> Q3. The url
> "https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin";
> works without any problems when I point to it in Firefox. What is the actual
> problem?
> P4. "[ERROR] Missing base FAQ.(fml|html|xml|apt)."
> Q4. I have the file site/fml/FAQ.fml. It's added to site.xml and generates
> correctly to html when generating the site. What is the actual problem?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MDOCCK-1) [plugins/docck] fail to run "org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"
[ http://jira.codehaus.org/browse/MDOCCK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103391 ] Dennis Lundberg edited comment on MDOCCK-1 at 7/26/07 1:33 PM: --- This was fixed in beta-1. was: This was fix in beta-1. > [plugins/docck] fail to run > "org.apache.commons.logging.LogConfigurationException: Class > org.apache.commons.logging.impl.Jdk14Logger does not implement Log" > > > Key: MDOCCK-1 > URL: http://jira.codehaus.org/browse/MDOCCK-1 > Project: Maven 2.x DOCCK Plugin > Issue Type: Bug > Environment: maven 2.0.4 >Reporter: Jerome Lacoste >Assignee: Dennis Lundberg > Fix For: 1.0-beta-1 > > Attachments: mvn.log > > > This happens when I try running it on the under the > mojo/webstart-maven-plugin/plugin directory -- 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: (MDOCCK-3) Various problems with the plugin
[
http://jira.codehaus.org/browse/MDOCCK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MDOCCK-3:
-
Assignee: Dennis Lundberg
Affects Version/s: 1.0-beta-1
> Various problems with the plugin
>
>
> Key: MDOCCK-3
> URL: http://jira.codehaus.org/browse/MDOCCK-3
> Project: Maven 2.x DOCCK Plugin
> Issue Type: Improvement
>Affects Versions: 1.0-beta-1
> Environment: Maven 2.0.4
>Reporter: Jimisola Laursen
>Assignee: Dennis Lundberg
> Fix For: 1.0-beta-2
>
>
> P1. "[ERROR] Missing examples."
> Q1. What is actually missing? The directory? Files in that directory?
> Proposed solution: Provide a more detailed error message and document it.
> Also, the SVN repo of DOCCK Plugin itself should act as a standard for
> plugins so that plugin developers has an example to look at.
> P2. "[WARN] license MIT license appears to have an invalid URL:
> 'LICENSE.txt'. Error: no protocol: LICENSE.txt Trying to access it as a file
> instead."
> Q2. LICENSE.txt shows correctly in the generated site. The file is in the
> same directory as the pom.xml. If I use file:// then I also get a warning
> ("[WARN] Non-HTTP license MIT license URL not verified."). Where shall the
> file be placed and how should I specify the url?
> P3. "[ERROR] Cannot reach project site with URL:
> 'http://mojo.codehaus.org/freemarker-maven-plugin'.
> [ERROR] Cannot reach scm with URL:
> 'https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin'.Error:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target"
> Q3. The url
> "https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin";
> works without any problems when I point to it in Firefox. What is the actual
> problem?
> P4. "[ERROR] Missing base FAQ.(fml|html|xml|apt)."
> Q4. I have the file site/fml/FAQ.fml. It's added to site.xml and generates
> correctly to html when generating the site. What is the actual problem?
--
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: (MDOCCK-3) Various problems with the plugin
[
http://jira.codehaus.org/browse/MDOCCK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103394
]
Dennis Lundberg commented on MDOCCK-3:
--
I was wrong about 3 in my previous comment.
It was the scm URL
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin
that wasn't working. I have tried it now and I don't get the error that you
got. I think it might have had something to do with a problem in the
certificate chain for https.
> Various problems with the plugin
>
>
> Key: MDOCCK-3
> URL: http://jira.codehaus.org/browse/MDOCCK-3
> Project: Maven 2.x DOCCK Plugin
> Issue Type: Improvement
>Affects Versions: 1.0-beta-1
> Environment: Maven 2.0.4
>Reporter: Jimisola Laursen
> Fix For: 1.0-beta-2
>
>
> P1. "[ERROR] Missing examples."
> Q1. What is actually missing? The directory? Files in that directory?
> Proposed solution: Provide a more detailed error message and document it.
> Also, the SVN repo of DOCCK Plugin itself should act as a standard for
> plugins so that plugin developers has an example to look at.
> P2. "[WARN] license MIT license appears to have an invalid URL:
> 'LICENSE.txt'. Error: no protocol: LICENSE.txt Trying to access it as a file
> instead."
> Q2. LICENSE.txt shows correctly in the generated site. The file is in the
> same directory as the pom.xml. If I use file:// then I also get a warning
> ("[WARN] Non-HTTP license MIT license URL not verified."). Where shall the
> file be placed and how should I specify the url?
> P3. "[ERROR] Cannot reach project site with URL:
> 'http://mojo.codehaus.org/freemarker-maven-plugin'.
> [ERROR] Cannot reach scm with URL:
> 'https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin'.Error:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target"
> Q3. The url
> "https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/freemarker-maven-plugin";
> works without any problems when I point to it in Firefox. What is the actual
> problem?
> P4. "[ERROR] Missing base FAQ.(fml|html|xml|apt)."
> Q4. I have the file site/fml/FAQ.fml. It's added to site.xml and generates
> correctly to html when generating the site. What is the actual problem?
--
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: (MDOCCK-2) Make errors more detailed
[ http://jira.codehaus.org/browse/MDOCCK-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MDOCCK-2: - Affects Version/s: 1.0-beta-1 > Make errors more detailed > - > > Key: MDOCCK-2 > URL: http://jira.codehaus.org/browse/MDOCCK-2 > Project: Maven 2.x DOCCK Plugin > Issue Type: Improvement >Affects Versions: 1.0-beta-1 > Environment: Maven 2.0.4 >Reporter: Jimisola Laursen >Assignee: Dennis Lundberg > Fix For: 1.0-beta-2 > > > It would be a big improvement if the plugin specifies the location of the > problem (i.e. pom.xml, site.xml etc) and not only what the problem is. > Possibly include line number and/or path to element/tag. > E.g. replace "[ERROR] Missing tag " with "[ERROR] pom.xml:20 > Missing tag /". -- 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: (MDOCCK-1) [plugins/docck] fail to run "org.apache.commons.logging.LogConfigurationException: Class org.apache.commons.logging.impl.Jdk14Logger does not implement Log"
[ http://jira.codehaus.org/browse/MDOCCK-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MDOCCK-1. Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 1.0-beta-1 This was fix in beta-1. > [plugins/docck] fail to run > "org.apache.commons.logging.LogConfigurationException: Class > org.apache.commons.logging.impl.Jdk14Logger does not implement Log" > > > Key: MDOCCK-1 > URL: http://jira.codehaus.org/browse/MDOCCK-1 > Project: Maven 2.x DOCCK Plugin > Issue Type: Bug > Environment: maven 2.0.4 >Reporter: Jerome Lacoste >Assignee: Dennis Lundberg > Fix For: 1.0-beta-1 > > Attachments: mvn.log > > > This happens when I try running it on the under the > mojo/webstart-maven-plugin/plugin directory -- 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: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Hart updated MEAR-73:
Attachment: ear.jpg
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: ear.jpg, patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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] Commented: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103389
]
Thomas Hart commented on MEAR-73:
-
I mean that the
[dependency:resolve|http://maven.apache.org/plugins/maven-dependency-plugin/resolve-mojo.html]
with the property {{excludeTransitive}} don't have any effects to the ear
plugin.
The patch works for me. The following pom.xml produces the right ear (see
image). Only the {{dependencies}} are included *not* the transitive
dependencies.
{code:xml}
...
org.apache.maven.plugins
maven-ear-plugin
2.3.1-SNAPSHOT
true
5
lib
suite4p.enabler.jb402
suite4p.enabler.jb402.server
4
suite4p.enabler.jb402
suite4p.enabler.jb402.server
ejb
{code}
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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] Commented: (MJAVADOC-137) javadoc:javadoc always runs as "aggregator"
[ http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103388 ] John Allen commented on MJAVADOC-137: - If you run the javadoc plugin as report then the @aggregator is ignored (see MNG-2184), I have removed the @aggregator from my local version of the plugin and it passes all its tests but i expect the JavadocJarMojo might suffer (haven't tested yet and i would have too look at the code some more). Personally I cant see why one would want any of the javadoc mojo's functionality to run as an aggregator. Note the 'aggregate' report mojo option is actually implemented inside the mojo, ie. the report exits if it's already been run in the reactor and aggregate is true. > javadoc:javadoc always runs as "aggregator" > --- > > Key: MJAVADOC-137 > URL: http://jira.codehaus.org/browse/MJAVADOC-137 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Peter Hendriks >Priority: Critical > > In version 2.2, javadoc aggregation was configurable using the configuration > property "aggregate". In version 2.3, all javadoc goals got the @aggregator > attribute added to its mojos (through a change in > org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now > always run aggregated regardless of the configuration setting. This breaks > our build as we require non-aggregated javadoc execution in our multi-module > poms. Please fix this so this is once again configurable and backwards > compatible with previous versions of the javadoc plug-in. -- 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: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103387
]
Stephane Nicoll commented on MEAR-73:
-
WDYM when you say "it doen't work"?
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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] Commented: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103386
]
Stephane Nicoll commented on MEAR-73:
-
no It won't do what you expect.
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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] Created: (SCM-332) Perforce provider give one changeset entry for each file
Perforce provider give one changeset entry for each file Key: SCM-332 URL: http://jira.codehaus.org/browse/SCM-332 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Affects Versions: 2.0 Environment: MacOSX Reporter: Jean-Pierre Matsumoto Attachments: p4-group_entries.patch When I call mvn changelog:changelog on my Perforce project, I get one entry in changelog for each couple (changelist,file) instead of one entry for each changelist. I have a patch to solve this bug. I group relevant entries. I updated existing TestCase. And I tested on my project and the bug is solved with this patch. -- 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-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103377 ] Denis Cabasson commented on MSITE-132: -- I guess we basically all agree on this report. Its point is just changing name to artifactId, when no distributionManagement section is available. Jörg later discussion should indeed be discussed somewhere else. Maybe in a wish task or an improvement. For the time being, let's apply this patch on the trunk and get rid with it :) > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103374 ] John Allen commented on MSITE-132: -- Guess I'm not explaining myself very well :) Re the name being used to create the path in the stage mojo when the POM has no distributionManagement section defined - that sounds like a mistake to me and thus my [comment to Denis|http://jira.codehaus.org/browse/MSITE-132#action_103351]. Additionally re Jorg's statements about what and how stage should work. It works based off maven's distributionManagement section to achieve the use case of 'mirroring' or staging a deployment to a local file-system location for local review before real deployment to the project's published location is performed. It does that just fine and is used by lots of users. Additionally, being a core plugin, it is designed to support the main Maven usage scenarios, if you don't do it that way, or want to do it another way, you are of course free to create your own plugin. For a wider discussion about Maven's usage including it's plugins i recommend the [Maven Users Mailing List|http://www.nabble.com/Maven---Users-f178.html] Lastly, I didn't write these plugins so have absolutely no say on their design but as an OSS project we can all contribute to Maven's improvement. Start on the mailing lists and see how others use it, you never know maybe everyone will agree and the core developers will consider a redesign. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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: (MAVENUPLOAD-1656) Netty2 1.9.2 Upload Request
Netty2 1.9.2 Upload Request --- Key: MAVENUPLOAD-1656 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1656 Project: maven-upload-requests Issue Type: Task Reporter: Trustin Lee Attachments: netty2-1.9.2-bundle.jar Netty2 is an event-driven NIO framework and the ancestor of Apache MINA. Apache MINA provides a few utility classes for smooth migration from Netty2 to Apache MINA, and therefore one of the MINA submodules depends of Netty2. And there are some people out there who uses Netty2 for historical reason. -- 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: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Hart updated MEAR-73:
Attachment: patch.txt
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
> Attachments: patch.txt
>
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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] Commented: (MSITE-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103366 ] Denis Cabasson commented on MSITE-132: -- John, I'm afraid I have to side with Jörg here. Using the name, which is described in the POM descriptor as "The full name of the project.", doesn't looks sensible to me. Using the artifactId seems ways more coherent (with the distributionManagement behaviour at least). > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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: (MJAVADOC-137) javadoc:javadoc always runs as "aggregator"
javadoc:javadoc always runs as "aggregator" --- Key: MJAVADOC-137 URL: http://jira.codehaus.org/browse/MJAVADOC-137 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Peter Hendriks Priority: Critical In version 2.2, javadoc aggregation was configurable using the configuration property "aggregate". In version 2.3, all javadoc goals got the @aggregator attribute added to its mojos (through a change in org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now always run aggregated regardless of the configuration setting. This breaks our build as we require non-aggregated javadoc execution in our multi-module poms. Please fix this so this is once again configurable and backwards compatible with previous versions of the javadoc plug-in. -- 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: (MJAVADOC-136) UmlGraph 4.8 - could not find map file
UmlGraph 4.8 - could not find map file -- Key: MJAVADOC-136 URL: http://jira.codehaus.org/browse/MJAVADOC-136 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Environment: Windows XP Reporter: gvsg Priority: Blocker I'm using the maven-javadoc-plugin with the umlgraph doclet. See below my partial pom.xml file. org.apache.maven.plugins maven-javadoc-plugin true gr.spinellis.umlgraph.doclet.UmlGraphDoc gr.spinellis UmlGraph 4.8 -inferrel -inferdep -quiet -hide java.* -collpackages java.util.* -qualify -postfixpackage -nodefontsize 9 -nodefontpackagesize 7 When executing the javadoc plugin I receive the following error: [WARNING] javadoc: warning - Could not find map file .\com\vangenechten\system\order\service\ConfirmationSloganManagementBean.map [WARNING] java.io.IOException: CreateProcess: dot -Tcmapx -o E:\erp\java\systems\order\internals\target\site\apidocs\.\com\vangenechten\system\order\service\CommercialDivisionManagementBean.map -Tpng -o E:\erp\java\systems\order\internals\target\site\apidocs\.\com\vangenechten\system\order\service\C ommercialDivisionManagementBean.png E:\erp\java\systems\order\internals\target\site\apidocs\.\com\vangenechten\system\order\service\CommercialDivisionManagementBean.dot error=2 [WARNING] at java.lang.ProcessImpl.create(Native Method) [WARNING] at java.lang.ProcessImpl.(ProcessImpl.java:81) [WARNING] at java.lang.ProcessImpl.start(ProcessImpl.java:30) [WARNING] at java.lang.ProcessBuilder.start(ProcessBuilder.java:451) [WARNING] at java.lang.Runtime.exec(Runtime.java:591) [WARNING] at java.lang.Runtime.exec(Runtime.java:464) [WARNING] at gr.spinellis.umlgraph.doclet.UmlGraphDoc.runGraphviz(UmlGraphDoc.java:131) [WARNING] at gr.spinellis.umlgraph.doclet.UmlGraphDoc.generateContextDiagrams(UmlGraphDoc.java:114) [WARNING] at gr.spinellis.umlgraph.doclet.UmlGraphDoc.start(UmlGraphDoc.java:64) [WARNING] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [WARNING] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [WARNING] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [WARNING] at java.lang.reflect.Method.invoke(Method.java:585) [WARNING] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) [WARNING] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) [WARNING] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) [WARNING] at com.sun.tools.javadoc.Start.begin(Start.java:128) [WARNING] at com.sun.tools.javadoc.Main.execute(Main.java:41) [WARNING] at com.sun.tools.javadoc.Main.main(Main.java:31) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-367) best practices: multi-user installation
[ http://jira.codehaus.org/browse/MNG-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103359 ] John Allen commented on MNG-367: Re installers - We deploy our developers java environment via a nice looking NSIS installer (all built using m2 of course) Anyway, that puts in place the m2, then runs (optionally) the JDK, SVN, Tortoise installers and sets up a correct m2/conf/settings and $HOME/.m2 as well as defines MVN_OPTS to ensure the correct keystore info is passed to the JVM so that webdav deployments work. Not hard. And because of the per user env and HOME setup works for multiple users on the same box. > best practices: multi-user installation > --- > > Key: MNG-367 > URL: http://jira.codehaus.org/browse/MNG-367 > Project: Maven 2 > Issue Type: Task > Components: Design, Patterns & Best Practices >Reporter: Brett Porter >Priority: Trivial > Fix For: 2.1.x > > > so we need to support: > - read only install > - setttings in the installation > - works with just the m2 executable in the path (no M2_HOME setting) > - possibility of a remote settings file for standalone installs, force a > regular (daily) check when online to push updates > encourage: > - storing of install on a shared, read only drive > - possibly use a CVS checkout > - may want to integrate with existing deployment policies (eg an MSI that can > be easily deployed) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-311) Project build error null
Project build error null
Key: MECLIPSE-311
URL: http://jira.codehaus.org/browse/MECLIPSE-311
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Reporter: Thomas Hart
Priority: Critical
In the problem view is a {{Project build error null}} entry for a pom.xml file.
Also on the console i get the same message. I don't know why it happens. I have
126 POM Files and sometimes some of these get this error message.
Plugin Version: 0.0.11.20070603-1200
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-41) best practices: site management
[
http://jira.codehaus.org/browse/MNG-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103358
]
John Allen edited comment on MNG-41 at 7/26/07 6:54 AM:
I know I've been banging this drum from day one so I'm obviously off 'Maven
message' in this regard but as far as i can see a maven site is just another
type of artifact generated by a project. It has all the same aspects, couplings
et al as the other products of a project and should not be seen as a convenient
way to knock up your OSS web pages.
Corporate use of a maven project site is to render the human readable view on
the project's constructs (UML models, javadoc, analysis reports, and yes even
user guides) and is thus directly coupled to the version that generated it.
This then leads to POMs with project.urls and distro.site.urls like this:
{code}
projects.examples.site.deployment
Examples: Site Deployment
dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
${project.url}
http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
{code}
Thus all our deployed sites attempt to maintain the rigour of a true version
controlled namespace.
How we then map to the 'latest' of these is another point, and again, one I
have written about before; currently we do this, in the absence of real
repository, with server side scripting (aka PHP hack) as there is no real
'release' semantic and we can't really afford to go creating one at the moment.
Hope I'm not missing the point and slipping into rant mode (I'm in bed with
flu!)
Re the staging - we don't currently do that in the same public way you have to.
At the moment we simply 'export' the SNAPSHOTs and get internal peer review
from those (version info is not lost on ours) and if we had to do
release:prepare then i would have the distro locations to point to a real
sandbox staging environment and get QA acceptance there before performing a
real release.
was:
I know I've been banging this drum from day one so I'm obviously off 'Maven
message' in this regard but as far as i can see a maven site is just another
type of artifact generated by a project. It has all the same aspects, couplings
et al as the other products of a project and should not be seen as a convenient
way to knock up your OSS web pages.
Corporate use of a maven project site is to render the human readable view on
the project's constructs (UML models, javadoc, analysis reports, and yes even
user guides) and is thus directly coupled to the version that generated it.
This then leads to POMs with project.urls and distro.site.urls like this:
{code}
projects.examples.site.deployment
Examples: Site Deployment
dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
${project.url}
http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
{code}
Thus all our deployed sites attempt to maintain the rigour of a true version
controlled namespace.
How we then map to the 'latest' of these is another point, and again, one I
have written about before; currently we do this, in the absence of real
repository, with server side scripting (aka PHP hack) as there is no real
'release' semantic and we can't really afford to go creating one at the moment.
Hope I've not missing the point.
Re the staging - we don't currently do that in the same public way you have to.
At the moment we simply 'export' the SNAPSHOTs and get internal peer review
from those (version info is not lost on ours) and if we had to do
release:prepare then i would have the distro locations to point to a real
sandbox staging environment and get QA acceptance there before performing a
real release.
> best practices: site management
> ---
>
> Key: MNG-41
> URL: http://jira.codehaus.org/browse/MNG-41
> Project: Maven 2
> Issue Type: Task
> Components: Design, Patterns & Best Practices
>Reporter: Jason van Zyl
>Priority: Trivial
> Fix For: 2.1.x
>
>
> * How to deal with multiple versions of the site
> * How to deal with staging directories for the site (will require a change to
> the POM)
--
This message is automatically generated by JIRA.
-
If you thi
[jira] Commented: (MNG-41) best practices: site management
[
http://jira.codehaus.org/browse/MNG-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103358
]
John Allen commented on MNG-41:
---
I know I've been banging this drum from day one so I'm obviously off 'Maven
message' in this regard but as far as i can see a maven site is just another
type of artifact generated by a project. It has all the same aspects, couplings
et al as the other products of a project and should not be seen as a convenient
way to knock up your OSS web pages.
Corporate use of a maven project site is to render the human readable view on
the project's constructs (UML models, javadoc, analysis reports, and yes even
user guides) and is thus directly coupled to the version that generated it.
This then leads to POMs with project.urls and distro.site.urls like this:
{code}
projects.examples.site.deployment
Examples: Site Deployment
dav:https://maven.example.com/maven/site/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
${project.url}
http://projects.examples.com/${scm.repositoryName}/${project.groupId}/${project.artifactId}/${project.version}
{code}
Thus all our deployed sites attempt to maintain the rigour of a true version
controlled namespace.
How we then map to the 'latest' of these is another point, and again, one I
have written about before; currently we do this, in the absence of real
repository, with server side scripting (aka PHP hack) as there is no real
'release' semantic and we can't really afford to go creating one at the moment.
Hope I've not missing the point.
Re the staging - we don't currently do that in the same public way you have to.
At the moment we simply 'export' the SNAPSHOTs and get internal peer review
from those (version info is not lost on ours) and if we had to do
release:prepare then i would have the distro locations to point to a real
sandbox staging environment and get QA acceptance there before performing a
real release.
> best practices: site management
> ---
>
> Key: MNG-41
> URL: http://jira.codehaus.org/browse/MNG-41
> Project: Maven 2
> Issue Type: Task
> Components: Design, Patterns & Best Practices
>Reporter: Jason van Zyl
>Priority: Trivial
> Fix For: 2.1.x
>
>
> * How to deal with multiple versions of the site
> * How to deal with staging directories for the site (will require a change to
> the POM)
--
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-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103353
]
Matt Read commented on MSITE-129:
-
Yep, horses for courses sounds about right. Certainly my example was fairly
simple and there is a strong likelihood of some mix and matching of approaches
when the hierarchies get deeper.
Both our examples seem to reinforce the notion that the site plug-in should
represent both inheritance and composition relationships regardless of how they
are being used.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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-3121) goal specified in execution but not found in plugin
goal specified in execution but not found in plugin --- Key: MNG-3121 URL: http://jira.codehaus.org/browse/MNG-3121 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: gvsg Priority: Blocker Hi all; I want to run the XML-MAVEN-Plugin when 'mvn site:run' goal has been executed. Whien doing this I receive the following exception: org.apache.maven.lifecycle.LifecycleExecutionException: 'run' was specified in an execution, but not found in the plugin at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindExecutionToLifecycle(DefaultLifecycleExecutor.java:1342) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1243) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:987) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Here is a partial example of my pom.xml file org.codehaus.mojo xml-maven-plugin 1.0-beta-2-patched org.codehaus.mojo xml-maven-plugin 1.0-beta-2-patched provided execution1 site run true target ./target/site/pmd-report-per-class.xslt .html pmd.xml target/site Note:: If I try to set this for other plugins this will also fail. Kind regards, Guy -- 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-159) Absolute URI rendered as relative URI if absolute URI related to domain of POM URI
[ http://jira.codehaus.org/browse/MSITE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103352 ] John Allen commented on MSITE-159: -- I think something along the lines of 'convert URLs to relative URLs where possible' is sensible. Note that even relatives can be converted into better relatives. i.e. foo/bar/../../foo/bar/../ is the same as .. > Absolute URI rendered as relative URI if absolute URI related to domain of > POM URI > -- > > Key: MSITE-159 > URL: http://jira.codehaus.org/browse/MSITE-159 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Ted Husted > > Under site-beta5 > if the POM references a URI like > http://struts.apache.org > absolute URLs used in the site.xml file are converted to relative references. > For example a reference to to "http://struts.apache.org/1.x"; becomes "1.x", > and a reference to > just "http://struts.apache.org"; becomes an empty string. > If the documentation is being used offline, there are many cases when we want > to refer people back to the website, to be sure the current information is > used. The best use case is a download page that determines the mirror via > CGI. > Another use case is referring to a sister site in the domain, that might > refer to another version. If used locally, the other site might not be in the > relative location. > Switching back to beta4 cures the behavior, and absolute URIs remain > absolute, as expected. -- 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-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103351 ] John Allen commented on MSITE-132: -- Denis, Ahh, it's only if you have no distroManagement section that it invents the path and this is why I've never seen it (we use a flat project structure and thus have to declare distroManagement and project.URL in every POM as maven's default assumptions are wrong for us). Seems a reasonable fix, will apply to my local patched plugin and play. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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-132) Use instead of for directories
[ http://jira.codehaus.org/browse/MSITE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103350 ] John Allen commented on MSITE-132: -- Jorg, The logic of stage is fairly obvious. one is simulating the real world deployment, where projects and modules from the internet namespace are mapped to residing within a root node of a filesystem. Your expectation regarding what the site:stage plugin should do and how it should do it is wrong. Adjust your expectation and you will be happier. > Use instead of for directories > -- > > Key: MSITE-132 > URL: http://jira.codehaus.org/browse/MSITE-132 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Environment: maven-2.0.4 on any operating system with the latests > released plugins (after the doxia-1.0-alpha-8.pom bug) >Reporter: Jörg Hohwiller > Attachments: MSITE-132.patch > > > The of a project in the POM may contain characters that cause trouble > when used in directory names. > E.g. my open-source project: > http://svn.projxpert.com/mmm/trunk/ > Uses names such as "MMM::Configuration". Now when I stage the site of the > entire project, the relative link "MMM::Configuration" causes mozilla to say > something like "Unknown protocol 'mmm:'". > Could you please use the artefactId instead. > I think personally think that this is a lot better anyways. > BTW - Thanks for your greate work. M2 is awesome!!! -- 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-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103349
]
John Allen commented on MSITE-129:
--
Matt,
In regards to your structure. We are a massive information services company and
as such our 'apps' are produced by accounts and project teams in isolation of
each other and with lifecycles measured in years and 10s of years and as such
each one of our account/project 'apps' (itself consisting of multiple maven
modules) needs its own 'management' POM to setup where its SVN, CI, issue
tracker and distro management locations are, define plugin versions, and all
that good stuff. The only way to do this and have it used by all of the apps
modules is via inheritance. I guess I world is much more akin to a sourceforge
in as much as although we're one company we have many very independent projects
and the only way they can share their per-project settings amongst their
modules is via inheritance.
Horses for courses really.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Kenney Westerhof
>Priority: Minor
> Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong
[ http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-67: --- Attachment: MANTTASKS-67.diff > artifact:deploy - The name of deploying element in snapshot repository is > wrong > --- > > Key: MANTTASKS-67 > URL: http://jira.codehaus.org/browse/MANTTASKS-67 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: deploy task >Affects Versions: 2.0.6, 2.0.7 >Reporter: David N'DIAYE > Fix For: 2.0.8 > > Attachments: MANTTASKS-67.diff, testSnapshots.zip > > > The zip file contains test with Ant. > To launch it : ant test. > I try to deploy a snapshot artifact in repository > So, my pom.xml contains a version with the extension '-SNAPSHOT' > And in my build file Ant i do this : > > > > > In the repository the name of the artifact is > --SNAPSHOT. instead of > --.-- > Another problem, i try to upload 2 attachments with my artifact (javadoc and > java-source), and the buildNumber in the meta-data.xml increment by 3 instead > of 1 > > > > > > > You can test it with : ant testWithAttach -- 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: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong
[ http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-67: --- Attachment: (was: MANTTASKS-67.diff) > artifact:deploy - The name of deploying element in snapshot repository is > wrong > --- > > Key: MANTTASKS-67 > URL: http://jira.codehaus.org/browse/MANTTASKS-67 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: deploy task >Affects Versions: 2.0.6, 2.0.7 >Reporter: David N'DIAYE > Fix For: 2.0.8 > > Attachments: MANTTASKS-67.diff, testSnapshots.zip > > > The zip file contains test with Ant. > To launch it : ant test. > I try to deploy a snapshot artifact in repository > So, my pom.xml contains a version with the extension '-SNAPSHOT' > And in my build file Ant i do this : > > > > > In the repository the name of the artifact is > --SNAPSHOT. instead of > --.-- > Another problem, i try to upload 2 attachments with my artifact (javadoc and > java-source), and the buildNumber in the meta-data.xml increment by 3 instead > of 1 > > > > > > > You can test it with : ant testWithAttach -- 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: (MASSEMBLY-228) UnpackOptions filtered does not work
UnpackOptions filtered does not work Key: MASSEMBLY-228 URL: http://jira.codehaus.org/browse/MASSEMBLY-228 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: Windows XP with maven 2.0.7 Reporter: Elid OR Here my configuration in my assembly descriptor file : true true my-groupId:my-artifactId And this correctly unpack my dependencies but it does not filter the token in it. The token are put in a profile that a activate when build the 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: (SCM-331) bug found in StarteamUpdateCommand when doing a delete-local when a (view)label is used
bug found in StarteamUpdateCommand when doing a delete-local when a (view)label is used --- Key: SCM-331 URL: http://jira.codehaus.org/browse/SCM-331 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-starteam Affects Versions: 1.0-beta-3 Reporter: Jan Edelbroek After a succesfull update the StarteamUpdateCommand fires a delete-local command. The command string that is created for the stcmd is wrong when a (view)label is used. stcmd delete-local -x -nologo -stop -p "[EMAIL PROTECTED]:port/Project/View/path" -fp path-to-working-directory -is "-cfgl " alpha-1-1 -filter N As you can see, the -cfgl option is between quotes and there is also an additional space character. The problem is in the StarteamUpdateCommand class file (also in the trunk version). The following line in the createDeleteLocalCommand method args.add( "-cfgl " ); should be replaced with args.add( "-cfgl" ); thus leaving out the additional space character. I can provide a patch when necessary. See also SCM-309 in which i indicate that i have a patch ready to be able to use promotion states instead of view labels -- 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-971) Symbolic links are traversed on deletion
[ http://jira.codehaus.org/browse/CONTINUUM-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103338 ] Stephan Heinze commented on CONTINUUM-971: -- Modified problem with version 1.1-beta-1: Symbolic links cause 'clean-working-directory' to fail. See Exception-StackTrace below. Project is a shell project (usual automake/autoconf/libtool C++ project). Symbol link points to a file that was removed by the clean-task itself .. inside the project. org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'clean-working-directory' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.cleanWorkingDirectory(DefaultBuildController.java:361) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:103) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.IOException: Directory /opt/continuum/working-directory/11/debug/xml/.libs unable to be deleted. at org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1390) at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1215) at org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1429) at org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1386) at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1215) at org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1429) at org.codehaus.plexus.util.FileUtils.deleteDirectory(FileUtils.java:1386) at org.codehaus.plexus.util.FileUtils.forceDelete(FileUtils.java:1215) at org.codehaus.plexus.util.FileUtils.cleanDirectory(FileUtils.java:1429) at org.apache.maven.continuum.core.action.CleanWorkingDirectoryAction.execute(CleanWorkingDirectoryAction.java:58) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406) ... 9 more > Symbolic links are traversed on deletion > > > Key: CONTINUUM-971 > URL: http://jira.codehaus.org/browse/CONTINUUM-971 > Project: Continuum > Issue Type: Bug > Components: Environmental >Affects Versions: 1.0.3 > Environment: Reproduced on Redhat Enterprise 4 but applicable to all > forms of UNIX >Reporter: Uri Moszkowicz >Priority: Critical > Fix For: Future > > > To reproduce: > 1. Create a project that checks out files from some SCM > 2. Create a build script that creates symbolic links outside of the checked > out project sandbox. This is often done to bring outside libraries into the > project. > 3. Delete the created project from the Continuum website. Notice how all > kinds of files disappear from your file system! > From looking at the release logs it looks like someone added follow symbolic > links as the default and mentioned that at some point in the future an option > should be added to disable this behavior. Following symbolic links is very > dangerous and if supported it should be disabled by default, not the reverse. > A warning should be posted in a visible place for the existing versions until > this can be fixed as it can result in significant data loss outside of the > Continuum program. -- 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: (MANTTASKS-84) VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"
[
http://jira.codehaus.org/browse/MANTTASKS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-84:
---
Fix Version/s: 2.0.8
Patch Submitted: [Yes]
> VersionMapper does not work on SNAPSHOT dependencies where
> uniqueVersion="true"
> ---
>
> Key: MANTTASKS-84
> URL: http://jira.codehaus.org/browse/MANTTASKS-84
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-84.diff
>
>
> When a dependency is SNAPSHOT and uniqueVersion="true", the version is not
> removed from the filename, nor the directory if to="flatten"
> for example, adding in test-deps target of sample.build.xml the following:
> {code:xml}
>
>
>classname="org.apache.maven.artifact.ant.VersionMapper"
> from="${dependency.versions}" to="flatten" />
>
> {code}
> creates
> /target/files/versionMapperFlatten/it/ant-tasks/snapshotUniqueTrue/2.0.7-SNAPSHOT/snapshotUniqueTrue-2.0.7-20070610.180356-1.jar
> where it should be /target/files/versionMapperFlatten/snapshotUniqueTrue.jar
--
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: (MANTTASKS-84) VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"
[
http://jira.codehaus.org/browse/MANTTASKS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MANTTASKS-84:
---
Attachment: MANTTASKS-84.diff
Here is a testcase and fix
> VersionMapper does not work on SNAPSHOT dependencies where
> uniqueVersion="true"
> ---
>
> Key: MANTTASKS-84
> URL: http://jira.codehaus.org/browse/MANTTASKS-84
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.0.7
>Reporter: Herve Boutemy
> Fix For: 2.0.8
>
> Attachments: MANTTASKS-84.diff
>
>
> When a dependency is SNAPSHOT and uniqueVersion="true", the version is not
> removed from the filename, nor the directory if to="flatten"
> for example, adding in test-deps target of sample.build.xml the following:
> {code:xml}
>
>
>classname="org.apache.maven.artifact.ant.VersionMapper"
> from="${dependency.versions}" to="flatten" />
>
> {code}
> creates
> /target/files/versionMapperFlatten/it/ant-tasks/snapshotUniqueTrue/2.0.7-SNAPSHOT/snapshotUniqueTrue-2.0.7-20070610.180356-1.jar
> where it should be /target/files/versionMapperFlatten/snapshotUniqueTrue.jar
--
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: (MANTTASKS-84) VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"
VersionMapper does not work on SNAPSHOT dependencies where uniqueVersion="true"
---
Key: MANTTASKS-84
URL: http://jira.codehaus.org/browse/MANTTASKS-84
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.0.7
Reporter: Herve Boutemy
When a dependency is SNAPSHOT and uniqueVersion="true", the version is not
removed from the filename, nor the directory if to="flatten"
for example, adding in test-deps target of sample.build.xml the following:
{code:xml}
{code}
creates
/target/files/versionMapperFlatten/it/ant-tasks/snapshotUniqueTrue/2.0.7-SNAPSHOT/snapshotUniqueTrue-2.0.7-20070610.180356-1.jar
where it should be /target/files/versionMapperFlatten/snapshotUniqueTrue.jar
--
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: (SCM-330) Bug when trying to commit a large number of source files using the SVN command line tool as a part of the Maven2 Release plugin
Bug when trying to commit a large number of source files using the SVN command line tool as a part of the Maven2 Release plugin --- Key: SCM-330 URL: http://jira.codehaus.org/browse/SCM-330 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0-beta-3 Environment: Windows XP Reporter: Jorgen Fastrup The SVN command generated by the "createCommandLine" method in the SvnCheckInCommand class does not consider the maximum length of the generated "svn commit" command line imposed by Windows XP, see http://support.microsoft.com/kb/830473 If using the SCM-SVN provider implementation as a part of the Maven2 Release plugin on a windows XP platform and you are trying to commit a lot of modified pom.xml's the SCM-SVN provider implementation will fail since it does not consider the maximum length of the generated "svn commit" command line imposed by the underlying operating system. We have implemented a temporary fix for this problem in the "createCommandLine" method of the SvnCheckInCommand class by simply removing the code line: SvnCommandLineUtils.addFiles( cl, fileSet.getFiles() ); from the "createCommandLine" method in release 1.0-beta-3. When studying the implementation of the "createCommandLine" method in release 1.0 it seems though this new release also has the same problem with handling "svn commit" command lines of great lengh. Would it not be possible to have "createCommandLine" method simply generate an implicit "svn commit" command line and not generate an explicit "svn commit" as currently implemented ... in this way the length of the commandl ine will never exceed the limits imposed by say Windows XP ? Regards Jorgen Fastrup -- 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: (MEAR-73) Property to disable transitive dependencies resolving
[
http://jira.codehaus.org/browse/MEAR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103336
]
Thomas Hart commented on MEAR-73:
-
I check the dependency plugin, it doesn't work. Can i submit a patch, that
excludes the code block above?
> Property to disable transitive dependencies resolving
> -
>
> Key: MEAR-73
> URL: http://jira.codehaus.org/browse/MEAR-73
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Reporter: Thomas Hart
>Assignee: Stephane Nicoll
>
> We have ears with a lot of modules. So the transitive dependencies are very
> huge and to exclude all these with {{true}} is no
> option. Also to mark these dependencies with optional is no way. It is
> possible to create a new property 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] Issue Comment Edited: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong
[ http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103314 ] Herve Boutemy edited comment on MANTTASKS-67 at 7/26/07 2:01 AM: - Here is a fix for the attachment numbering problem. For -SNAPSHOT vs .-, it's a question of supporting whether uniqueVersion="false" or uniqueVersion="true": such configuration support is a feature added in MANTTASKS-23 was: Here is a fix... > artifact:deploy - The name of deploying element in snapshot repository is > wrong > --- > > Key: MANTTASKS-67 > URL: http://jira.codehaus.org/browse/MANTTASKS-67 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: deploy task >Affects Versions: 2.0.6, 2.0.7 >Reporter: David N'DIAYE > Fix For: 2.0.8 > > Attachments: MANTTASKS-67.diff, testSnapshots.zip > > > The zip file contains test with Ant. > To launch it : ant test. > I try to deploy a snapshot artifact in repository > So, my pom.xml contains a version with the extension '-SNAPSHOT' > And in my build file Ant i do this : > > > > > In the repository the name of the artifact is > --SNAPSHOT. instead of > --.-- > Another problem, i try to upload 2 attachments with my artifact (javadoc and > java-source), and the buildNumber in the meta-data.xml increment by 3 instead > of 1 > > > > > > > You can test it with : ant testWithAttach -- 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: (ARCHETYPE-46) maven-archetype-archetype archetype places archetype.xml in the wrong location
[ http://jira.codehaus.org/browse/ARCHETYPE-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103335 ] Denis Cabasson commented on ARCHETYPE-46: - After forcing to an updated version of archetype plugins (1.0-alpha-4) everything runs fine. Juste wondering why I didn't get the more up-to-date version, but taht's another issue. > maven-archetype-archetype archetype places archetype.xml in the wrong location > -- > > Key: ARCHETYPE-46 > URL: http://jira.codehaus.org/browse/ARCHETYPE-46 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 1.0-alpha-4 > Environment: all >Reporter: Gregory Kick > Attachments: ARCHETYPE-46-bug.txt > > > the maven-archetype-archetype archetype places archetype.xml in > .../META-INF/maven/archetype.xml instead of .../META-INF/archetype.xml as > directed by http://maven.apache.org/guides/mini/guide-creating-archetypes.html -- 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-294) Repository purge feature for snapshots
[ http://jira.codehaus.org/browse/MRM-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103334 ] Maria Odea Ching commented on MRM-294: -- Thanks for your comments Barrie :) Anyway, there was also a discussion regarding this issue and MRM-275 as well in the Archiva Dev List. I've summarized below what has been agreed upon in the thread. For reference purposes, the subject of the thread was "Repository purge (MRM-294 and MRM-275)". Please feel free to add more.. Summary: 1. Configuration will be for each repository - the repository purge will be implemented as a consumer, which will be executed during repository scanning. Configuration will be incorporated on the repository configuration page. 2. Repository purge is configurable in archiva.xml 3. Snapshot retention policies will also be for each repository. For #3, these are the policies to be implemented: a. any artifacts that are not in active development will be deleted entirely (eg, 1.0-SNAPSHOT when 1.0 is released) b. time based** (e.g. any builds older than 1 month) c. artifact count retention** (e.g. if user specified "5", then archiva would keep 5 in total of the latest.. like 1.1-20070506.121113-1, 1.1-20070506.121113-2, 1.1-20070506.121113-3, 1.1-20070506.121113-4, 1.1-20070506.121113-5 and NOT 1.1-SNAPSHOT, 1.2-SNAPSHOT, 1.3-SNAPSHOT, 1.4-SNAPSHOT, 1.5-SNAPSHOT) **user will have the option to choose from either of these two criteria > Repository purge feature for snapshots > -- > > Key: MRM-294 > URL: http://jira.codehaus.org/browse/MRM-294 > Project: Archiva > Issue Type: New Feature >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Maria Odea Ching > Fix For: 1.0-beta-1 > > > We need a way to purge a repository of snapshots older than a certain date, > (optionally retaining the most recent one) and fixing the metadata. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MANTTASKS-67) artifact:deploy - The name of deploying element in snapshot repository is wrong
[ http://jira.codehaus.org/browse/MANTTASKS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103314 ] Herve Boutemy edited comment on MANTTASKS-67 at 7/26/07 2:02 AM: - Here is a fix for the attachment numbering problem. For x-SNAPSHOT vs x-.-, it's a question of supporting whether uniqueVersion="false" or uniqueVersion="true": such configuration support is a feature added in MANTTASKS-23 was: Here is a fix for the attachment numbering problem. For -SNAPSHOT vs .-, it's a question of supporting whether uniqueVersion="false" or uniqueVersion="true": such configuration support is a feature added in MANTTASKS-23 > artifact:deploy - The name of deploying element in snapshot repository is > wrong > --- > > Key: MANTTASKS-67 > URL: http://jira.codehaus.org/browse/MANTTASKS-67 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: deploy task >Affects Versions: 2.0.6, 2.0.7 >Reporter: David N'DIAYE > Fix For: 2.0.8 > > Attachments: MANTTASKS-67.diff, testSnapshots.zip > > > The zip file contains test with Ant. > To launch it : ant test. > I try to deploy a snapshot artifact in repository > So, my pom.xml contains a version with the extension '-SNAPSHOT' > And in my build file Ant i do this : > > > > > In the repository the name of the artifact is > --SNAPSHOT. instead of > --.-- > Another problem, i try to upload 2 attachments with my artifact (javadoc and > java-source), and the buildNumber in the meta-data.xml increment by 3 instead > of 1 > > > > > > > You can test it with : ant testWithAttach -- 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
