[jira] Commented: (DOXIA-24) [PATCH] better docbook support through the use of docbook xsl stylesheets
[ http://jira.codehaus.org/browse/DOXIA-24?page=comments#action_58030 ] Jose Gonzalez Gomez commented on DOXIA-24: -- Jason, I don't know if you're talking about a plugin when you say to rework this as a module, but just in case, I submitted a while ago a docbook plugin to the mojo project that does this (uses the Docbook stylesheets to generate its output) and has a bit more of functionality (automatic creation of olink database and resolution of links among documents using olink). This plugin reads (by default) the stylesheets from the published Internet location but is able to read them from an user provided location if specified by a parameter of the plugin. You may find it at http://mojo.codehaus.org/docbook-maven-plugin/ [PATCH] better docbook support through the use of docbook xsl stylesheets - Key: DOXIA-24 URL: http://jira.codehaus.org/browse/DOXIA-24 Project: doxia Type: Improvement Reporter: Lars Trieloff Attachments: docbook-xsl-support.patch The current state of DocBook support in Doxia is still unsatisfactory. It is now able to handle the most important elements, but there is still an important problem left out: handling of xref-links. This type of links points to another docbook element and is expected to be replaced with a text describing the element by the processing system. For example an xref pointing to a chapter would be replaced with the text Chapter N: 'Title of Chapter N'. Implementing this functionality using the XML Pull Parser currently used in Doxia is a massive effort because it leads to duplicating a lot of functionality already available in the DocBook XSL Stylesheets, the standard solution for processing DocBook XML and involves caching of more or less the whole DocBook document. My proposed solution is simple, elegant, but quite heavyweight: I use the DocBook XSL Stylesheets (which will be bundled with the doxia.jar) and transform the DocBook input document into a temporary XHTML document. The stylesheets are driven by a customization layer that turns off any unnecessary features like autogenerated tables of contents and navigation graphics. The temporary XHTML document is processed by the Doxia's XhtmlParser into a DoxiaModel. The DocBook XSL stylesheets and the XhtmlParser take care of maintaining the section nesting of the document, so that no important information will be lost. If the DocBook DTD changes, no Java programming is neccessary, all you need to do is updating the enclosed DocBook XSL stylesheets. The system is able to handle all of the DocBook elements and offers all advanced features of the DocBook XSL stylesheets like autogenerated texts and so on. There is only one major drawback: Parsing the DocBook stylesheets takes an huge amount of memory, but it is still possible to run maven with the default java heap space. -- 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: (SCM-159) NumberFormatException when you include a port in your scm url
[ http://jira.codehaus.org/browse/SCM-159?page=all ] Emmanuel Venisse closed SCM-159: Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0-beta-3 Applied. Thanks. NumberFormatException when you include a port in your scm url - Key: SCM-159 URL: http://jira.codehaus.org/browse/SCM-159 Project: Maven SCM Type: Bug Components: maven-scm-provider-svn Versions: 1.0-beta-3 Environment: osx 10.4.4, java 1.4.2_09 Reporter: Julian Wood Assignee: Emmanuel Venisse Fix For: 1.0-beta-3 Attachments: SCM-159-maven-scm-provider-svn.patch This bug came about in a strange way. I have always had URLs like: scm:svn:http://[EMAIL PROTECTED]:8800/pmgt/trunk and they have always worked for me. But when I came to write a small plugin which used scm, I found I kept getting this error: org.apache.maven.lifecycle.LifecycleExecutionException: An error is occurred in the status process. ... Caused by: org.apache.maven.plugin.MojoExecutionException: An error is occurred in the status process. ... Caused by: org.apache.maven.scm.ScmException: Can't load the scm provider. ... Caused by: java.lang.NumberFormatException: For input string: :8800 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:468) at java.lang.Integer.parseInt(Integer.java:518) at org.apache.maven.scm.provider.svn.repository.SvnScmProviderRepository.parseUrl(SvnScmProviderRepository.java:126) at org.apache.maven.scm.provider.svn.repository.SvnScmProviderRepository.init(SvnScmProviderRepository.java:42) at org.apache.maven.scm.provider.svn.SvnScmProvider.parseScmUrl(SvnScmProvider.java:251) at org.apache.maven.scm.provider.svn.SvnScmProvider.makeProviderScmRepository(SvnScmProvider.java:80) at org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:134) at org.apache.maven.plugins.release.helpers.ScmHelper.getScmRepository(ScmHelper.java:86) Now this of course didn't happen during release:prepare, or with the changelog plugin. So I changed around the developerConnection tag, and it turns out that it can be anything and these two goals still work, presumably because sufficient svn information is somewhere else. In any case, I needed it to work for my plugin, and found that the index of the colon is off by one character in SvnScmProviderRepository.parseUrl, as the error message implies. This patch fixes that, and adds some unit tests. -- 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: (SCM-29) test with CVS NT
[ http://jira.codehaus.org/browse/SCM-29?page=comments#action_58139 ] Emmanuel Venisse commented on SCM-29: - I don't agree. I prefer remove my check for CVSNT and let cvs send the error message if it doesn't support a tag format. We'll have the same result (a ScmException) if it doesn't supported. test with CVS NT Key: SCM-29 URL: http://jira.codehaus.org/browse/SCM-29 Project: Maven SCM Type: Test Components: maven-scm-provider-cvs Reporter: Brett Porter Assignee: Emmanuel Venisse Fix For: 1.0-beta-3 Vincent reported test failures on CVS NT... test it and fix if required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MPWAR-33) Plugin generates multiple Class-Path entries in the manifest file
[ http://jira.codehaus.org/browse/MPWAR-33?page=all ] Lukas Theussl reopened MPWAR-33: Plugin generates multiple Class-Path entries in the manifest file - Key: MPWAR-33 URL: http://jira.codehaus.org/browse/MPWAR-33 Project: maven-war-plugin Type: Bug Versions: 1.6 Reporter: Jöran Stark Assignee: Felipe Leme Fix For: 1.6.1 Attachments: test.rar Hi, Running war:war (maven-war-plugin-1.6) the first time generates a manifest file with a single Class-Path entry (correctly including the dependencies), but running war:war a second time (with no clean-up done) generates multiple Class-Path entries. This problem does not occure when building the EJB's (maven-ejb-plugin-1.4). When I compared theese two I noticed that the war-plugin does an update while the ejb-plugin does not. By removing the update attribute the war-plugin works fine, for me anyway ;-) I have the same problem with 1.7-SNAPSHOT from CVS-HEAD. Since my project includes other developers and users I would like to avoid making (local) changes in the plugin. Currently the solution is to do a clean-up in the pre-goal to war:war. Cheers Joran [manifest after first run] Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.) Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Built-By: Joran Name: foo.bar Specification-Title: foo-web Specification-Version: 1.0 Specification-Vendor: Apache Software Foundation Implementation-Title: foo.bar Implementation-Version: 1.0 Implementation-Vendor: Apache Software Foundation [manifest after second run] Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.) Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Built-By: Joran Name: foo.bar Specification-Title: foo-web Specification-Version: 1.0 Specification-Vendor: Apache Software Foundation Implementation-Title: foo.bar Implementation-Version: 1.0 Implementation-Vendor: Apache Software Foundation [a snippet from project.xml] dependency groupIdjena/groupId artifactIdicu4j/artifactId jaricu4j.jar/jar properties war.manifest.classpathtrue/war.manifest.classpath /properties /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPWAR-22) war manifest file can't be specified like ejb and jar plugins
[ http://jira.codehaus.org/browse/MPWAR-22?page=all ] Lukas Theussl closed MPWAR-22: -- Resolution: Fixed Fix Version: (was: 1.7) 1.6.1 war manifest file can't be specified like ejb and jar plugins - Key: MPWAR-22 URL: http://jira.codehaus.org/browse/MPWAR-22 Project: maven-war-plugin Type: Improvement Reporter: dion gillard Priority: Minor Fix For: 1.6.1 The ejb and jar plugins have a variable which can be set to specify an existing manifest to be used in creating the artifacts. The war plugin doesn't and should. We need a maven.war.manifest property with the appropriate lines added to plugin.jelly. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPWAR-33) Plugin generates multiple Class-Path entries in the manifest file
[ http://jira.codehaus.org/browse/MPWAR-33?page=all ] Lukas Theussl updated MPWAR-33: --- Fix Version: (was: 1.7) 1.6.1 Plugin generates multiple Class-Path entries in the manifest file - Key: MPWAR-33 URL: http://jira.codehaus.org/browse/MPWAR-33 Project: maven-war-plugin Type: Bug Versions: 1.6 Reporter: Jöran Stark Assignee: Felipe Leme Fix For: 1.6.1 Attachments: test.rar Hi, Running war:war (maven-war-plugin-1.6) the first time generates a manifest file with a single Class-Path entry (correctly including the dependencies), but running war:war a second time (with no clean-up done) generates multiple Class-Path entries. This problem does not occure when building the EJB's (maven-ejb-plugin-1.4). When I compared theese two I noticed that the war-plugin does an update while the ejb-plugin does not. By removing the update attribute the war-plugin works fine, for me anyway ;-) I have the same problem with 1.7-SNAPSHOT from CVS-HEAD. Since my project includes other developers and users I would like to avoid making (local) changes in the plugin. Currently the solution is to do a clean-up in the pre-goal to war:war. Cheers Joran [manifest after first run] Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.) Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Built-By: Joran Name: foo.bar Specification-Title: foo-web Specification-Version: 1.0 Specification-Vendor: Apache Software Foundation Implementation-Title: foo.bar Implementation-Version: 1.0 Implementation-Vendor: Apache Software Foundation [manifest after second run] Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.) Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Built-By: Joran Name: foo.bar Specification-Title: foo-web Specification-Version: 1.0 Specification-Vendor: Apache Software Foundation Implementation-Title: foo.bar Implementation-Version: 1.0 Implementation-Vendor: Apache Software Foundation [a snippet from project.xml] dependency groupIdjena/groupId artifactIdicu4j/artifactId jaricu4j.jar/jar properties war.manifest.classpathtrue/war.manifest.classpath /properties /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPWAR-33) Plugin generates multiple Class-Path entries in the manifest file
[ http://jira.codehaus.org/browse/MPWAR-33?page=all ] Lukas Theussl closed MPWAR-33: -- Resolution: Fixed Plugin generates multiple Class-Path entries in the manifest file - Key: MPWAR-33 URL: http://jira.codehaus.org/browse/MPWAR-33 Project: maven-war-plugin Type: Bug Versions: 1.6 Reporter: Jöran Stark Assignee: Felipe Leme Fix For: 1.6.1 Attachments: test.rar Hi, Running war:war (maven-war-plugin-1.6) the first time generates a manifest file with a single Class-Path entry (correctly including the dependencies), but running war:war a second time (with no clean-up done) generates multiple Class-Path entries. This problem does not occure when building the EJB's (maven-ejb-plugin-1.4). When I compared theese two I noticed that the war-plugin does an update while the ejb-plugin does not. By removing the update attribute the war-plugin works fine, for me anyway ;-) I have the same problem with 1.7-SNAPSHOT from CVS-HEAD. Since my project includes other developers and users I would like to avoid making (local) changes in the plugin. Currently the solution is to do a clean-up in the pre-goal to war:war. Cheers Joran [manifest after first run] Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.) Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Built-By: Joran Name: foo.bar Specification-Title: foo-web Specification-Version: 1.0 Specification-Vendor: Apache Software Foundation Implementation-Title: foo.bar Implementation-Version: 1.0 Implementation-Vendor: Apache Software Foundation [manifest after second run] Manifest-Version: 1.0 Ant-Version: Apache Ant 1.5.3 Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.) Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Class-Path: jakarta-oro-jena-2.0.jar icu4j.jar antlr.jar Built-By: Joran Name: foo.bar Specification-Title: foo-web Specification-Version: 1.0 Specification-Vendor: Apache Software Foundation Implementation-Title: foo.bar Implementation-Version: 1.0 Implementation-Vendor: Apache Software Foundation [a snippet from project.xml] dependency groupIdjena/groupId artifactIdicu4j/artifactId jaricu4j.jar/jar properties war.manifest.classpathtrue/war.manifest.classpath /properties /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MPWAR-22) war manifest file can't be specified like ejb and jar plugins
[ http://jira.codehaus.org/browse/MPWAR-22?page=all ] Lukas Theussl reopened MPWAR-22: Assign To: (was: dion gillard) war manifest file can't be specified like ejb and jar plugins - Key: MPWAR-22 URL: http://jira.codehaus.org/browse/MPWAR-22 Project: maven-war-plugin Type: Improvement Reporter: dion gillard Priority: Minor Fix For: 1.6.1 The ejb and jar plugins have a variable which can be set to specify an existing manifest to be used in creating the artifacts. The war plugin doesn't and should. We need a maven.war.manifest property with the appropriate lines added to plugin.jelly. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MRESOURCES-12) Wrog filtering after at symbol using profiles
Wrog filtering after at symbol using profiles - Key: MRESOURCES-12 URL: http://jira.codehaus.org/browse/MRESOURCES-12 Project: Maven 2.x Resources Plugin Type: Bug Environment: All platforms Reporter: Motxilo Priority: Minor Using profiles, when a resource -for instance, a Spring XML context file- needs to be filtered before being deployed, it seems that after an at character (@) included in a comment in the middle of the file, properties aren't filtered at all, while others before the aforementioned comment are. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MANTRUN-42) Ant task for the optional package are not found by maven
Ant task for the optional package are not found by maven Key: MANTRUN-42 URL: http://jira.codehaus.org/browse/MANTRUN-42 Project: Maven 2.x Antrun Plugin Type: Bug Versions: 1.1 Reporter: Daniel Durette Priority: Minor Attachments: maven-antrun-plugin-1.1.pom We are using VSS for our source repository and we are currently setting maven for the first time. Since there is no plugin currently available for vss in maven, we decided to use the ant task vssget to get our files from vss. The following is our plugin configuration: plugin artifactIdmaven-antrun-plugin/artifactId executions execution phasegenerate-sources/phase goals goalrun/goal /goals configuration tasks vssget localPath=C:\Data\projects\test recursive=true login=?,? vsspath=\ serverPath=w: writable=true / /tasks /configuration /execution /executions /plugin The antrun plugin can't find the task vssget. I modified the file maven-antrun-plugin-1.1.pom to add the dependency for ant-optional. This way, the task vssget is now found by the plugin. The new .pom is attached to this bug. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNGECLIPSE-72) performace
performace -- Key: MNGECLIPSE-72 URL: http://jira.codehaus.org/browse/MNGECLIPSE-72 Project: Maven 2.x Extension for Eclipse Type: Improvement Environment: XP, jsdk 1.5.x, eclipse 3.1.x Reporter: Andrew Britz Assigned to: Eugene Kuleshov I have about six projects open in the ide and it takes about 25 minutes for the maven2 plug-in to get its lists of dependencies. (I have a local ibiblio mirror repository that is being hit) If I run the same builds on the command line it takes less then 10 seconds a build. Not sure if the problem it the plug-in or the embedded maven container. Has anyone else found this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MJAR-27) jar:sign doesn't check if project prouces an artifact
[ http://jira.codehaus.org/browse/MJAR-27?page=all ] Michael Böckling updated MJAR-27: - Attachment: MJAR-27-maven-jar-plugin.patch jar:sign doesn't check if project prouces an artifact - Key: MJAR-27 URL: http://jira.codehaus.org/browse/MJAR-27 Project: Maven 2.x Jar Plugin Type: Bug Environment: Maven 2.0.2 Latest Jar checkout Reporter: Michael Böckling Attachments: MJAR-27-maven-jar-plugin.patch, jarsign-patch.txt jar:sign does not skip projects that don't produce an artifact (=pom packaging). Attached patch to detect this situation and handle it gracefully. Since similar issues showed up in the Javadoc and Cobertura plugin, too, I was wondering if an additional mojo annotation like @requireLanguage (project must have e.e. java as its language) or @requireArtifact (don't execute if this project does not create an artifact, e.g. has pom packaging) would make sense. Stuff like this makes it much harder to establish a company-wide standardized build process, since there are always pom projects in the inheritance hierarchy... -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r375474 - /maven/maven-1/plugins/trunk/plugins-site/project.xml
I just use the alphabetical order. Why this order ? It's for the order in the menu ? Be careful to apply the same chages in the sandbox when you modify a commons part of the build (plugins-parent, plugins-site ...) Arnaud On 2/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: ltheussl Date: Mon Feb 6 20:21:03 2006 New Revision: 375474 URL: http://svn.apache.org/viewcvs?rev=375474view=rev Log: Re-order reports, add license report Modified: maven/maven-1/plugins/trunk/plugins-site/project.xml Modified: maven/maven-1/plugins/trunk/plugins-site/project.xml URL: http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/plugins-site/project.xml?rev=375474r1=375473r2=375474view=diff == --- maven/maven-1/plugins/trunk/plugins-site/project.xml (original) +++ maven/maven-1/plugins/trunk/plugins-site/project.xml Mon Feb 6 20:21:03 2006 @@ -176,15 +176,14 @@ defaultGoalplugins:site/defaultGoal /build reports -reportmaven-changelog-plugin/report -reportmaven-changes-plugin/report reportmaven-dashboard-plugin/report -reportmaven-developer-activity-plugin/report -reportmaven-faq-plugin/report +reportmaven-changelog-plugin/report reportmaven-file-activity-plugin/report -reportmaven-jdepend-plugin/report -reportmaven-linkcheck-plugin/report +reportmaven-developer-activity-plugin/report reportmaven-multichanges-plugin/report reportmaven-multiproject-plugin/report +reportmaven-faq-plugin/report +reportmaven-linkcheck-plugin/report +reportmaven-license-plugin/report /reports /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-29) test with CVS NT
[ http://jira.codehaus.org/browse/SCM-29?page=comments#action_58040 ] Emmanuel Venisse commented on SCM-29: - All tests are ok with cvsnt except CvsCheckoutCommandTest it run the following command : cvs -z3 -f -d D:\apache\maven\trunks\scm\maven-scm-providers\maven-scm-provider-cvs\src\test\repository -q checkout -r 1.107.4 -d testCheckOutWithTag test-repo/checkout CVSNT doesn't allow numeric tag name (1.107.4) : cvs [checkout aborted]: Numeric directory tags are not allowed. Need to check if user use CVSNT and verify tag format. test with CVS NT Key: SCM-29 URL: http://jira.codehaus.org/browse/SCM-29 Project: Maven SCM Type: Test Components: maven-scm-provider-cvs Reporter: Brett Porter Fix For: 1.0 Vincent reported test failures on CVS NT... test it and fix if required. -- 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: (MNGECLIPSE-72) performace
[ http://jira.codehaus.org/browse/MNGECLIPSE-72?page=comments#action_58041 ] Jochen Wiedmann commented on MNGECLIPSE-72: --- Isn't this a duplicate of MNGECLIPSE-70? performace -- Key: MNGECLIPSE-72 URL: http://jira.codehaus.org/browse/MNGECLIPSE-72 Project: Maven 2.x Extension for Eclipse Type: Improvement Environment: XP, jsdk 1.5.x, eclipse 3.1.x Reporter: Andrew Britz Assignee: Eugene Kuleshov I have about six projects open in the ide and it takes about 25 minutes for the maven2 plug-in to get its lists of dependencies. (I have a local ibiblio mirror repository that is being hit) If I run the same builds on the command line it takes less then 10 seconds a build. Not sure if the problem it the plug-in or the embedded maven container. Has anyone else found this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Brett Porter wrote: Steve Loughran wrote: something below hibernate3.1 pulls in junit3.7, which really annoyed me when I tracked it down. Do you know what it is from -X? I'm thinking commons-something. -X? do you mean verbose=true in the task? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MRELEASE-66) Source and Javadoc bundles should be optional
[ http://jira.codehaus.org/browse/MRELEASE-66?page=comments#action_58042 ] Brett Porter commented on MRELEASE-66: -- +1 to change the super POM. Please file it under MNG for 2.0.3. anything else to do in this issue? Source and Javadoc bundles should be optional - Key: MRELEASE-66 URL: http://jira.codehaus.org/browse/MRELEASE-66 Project: Maven 2.x Release Plugin Type: Bug Environment: xp Reporter: Dan Tran Fix For: 2.0-beta-5 The current release plugin generates: primary artifact, source, and javadoc. Source and Javadoc should be optional since my daily release build does not need them. The source does not seem to give indication how to disable those bundles. am I missing any thing? The closest I can see is cl.createArgument().setLine( -DperformRelease=true ); Please advice. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Yep, that's it. Sorry, force of habit. Steve Loughran wrote: Brett Porter wrote: Steve Loughran wrote: something below hibernate3.1 pulls in junit3.7, which really annoyed me when I tracked it down. Do you know what it is from -X? I'm thinking commons-something. -X? do you mean verbose=true in the task? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bringing plugins to Apache Maven
This is not a vote. +1's here are just I've read and think it's all good, but generally I'm just looking for feedback on specific plugins and decision points before taking this any further forward. Some of the plugins that wound up in mojo seem better suited to the main Apache project due to a) originally coming from there b) having the core libraries located there c) being essential to the day to day use of the project. These are the ones I'm thinking of: - jxr report (relates to jxr) - surefire report (relates to surefire) - changes/jira/announcement report (relates to issue stuff in sandbox) - changelog report (relates to scm) - dependency-maven-plugin (sounds generally handy in eliminating a lot of small antrunning). The other ones I'm tossing up: - taglist (generally useful report, originally came from m1) I put out a call for opinions and while the relevant mojo people were in favour, some of the Maven developers were either on the fence or against it. However, I didn't really receive an answer to my responses to those concerns. As a community we need to decide where we are going to develop individual plugins. As I understand it, mojo.codehaus.org was established to: - develop things that can't be entirely under the ASL. - avoid developing plugins that rotted and tied due to lack of community in m1 - give a place for individual plugin developers to start out but still operate in the same way as the Maven community. It's always been my thought that plugins at maven.apache.org should be those used by 80% of Maven users or essential to its operation, and those that relate to the Maven subprojects themselves. Also, plugins in like groups should be kept together. So, time to bring it here and get everyone's feedback again. If you already had objections, please voice them again if they are still a concern. What do others think? Note that this would imply bringing in a couple of new committers, but they are people that have been generally helpful. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2046) External property file in command line
External property file in command line -- Key: MNG-2046 URL: http://jira.codehaus.org/browse/MNG-2046 Project: Maven 2 Type: Improvement Components: Command Line Versions: 2.0.2 Reporter: Raphaël Corre Priority: Minor It would be great to allow the option -propertyfile in the command line, like Ant does to load multi properties. For the moment, it's possible to do 'D, but for a single property. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSITE-19) Various encoding problems with InputStream and XML
[ http://jira.codehaus.org/browse/MSITE-19?page=comments#action_58045 ] Brett Porter commented on MSITE-19: --- We still need to setup the native2ascii'ing. Various encoding problems with InputStream and XML -- Key: MSITE-19 URL: http://jira.codehaus.org/browse/MSITE-19 Project: Maven 2.x Site Plugin Type: Bug Reporter: Naoki Nose Fix For: 2.0 Attachments: plexus-i18n.diff, plexus-site-renderer.diff, plexus-utils.diff, plexus-utils_2.diff, project-info-report_ja.properties, site-plugin_ja.properties There is various encoding problems with InputStream and XML in different components. - Property resource file is encoded with UTF-8 , but Java reads bundle with UTF-8. - In different components Reader is constructed with default system encoding. - MXParser ignores encoding attribute in xml declaration. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ${modules}
Hi Ersin,
I had a tough time reproducing this the other day. Please file a bug
under MSITE and I'll get to it before the release.
Thanks,
Brett
Ersin Er wrote:
I've installed the 2.0-SNAPSHOT version and what I get is only a menu
title as Modules. Here is the deployed site:
http://directory.apache.org/newsite/subprojects/apacheds/
Any suggestions ?
Thanks.
On 2/4/06, Brett Porter [EMAIL PROTECTED] wrote:
I think it's only available in 2.0-SNAPSHOT of the plugin from SVN.
- Brett
Ersin Er wrote:
Sorry but I've to ask it again. When I want to use it the site gets
corrupted. Can you confirm that it actually works ?
Thanks.
On 1/26/06, Brett Porter [EMAIL PROTECTED] wrote:
Yes.
Ersin Er wrote:
Hi,
Is ${modules} substitution supported in site.xml? I'm asking because
it's mentioned here:
http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence
Thanks.
--
Ersin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ersin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ersin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
I think the solution is easier: Anyone that proves they are capable will be given access to do this. We won't be handing out responsibility to volunteers who have not yet proven they are capable at the task through patches - just like how commit access is granted in general. We do need better revision control, and at some point to draw a line in the sand and not change things. My single biggest regret about the first release is not sorting this out better, even though I knew it was coming I thought it would peak and get sorted out. I can't believe we *still* can't agree on how hibernate should be done. I actually wonder if we'd been better off starting from scratch and adding lovingly hand-crafted POMS by people that needed them. I guess there's still time to start over in a new repo :) Cheers, Brett Arik Kfir wrote: Hi, IMO the most urgent thing the ibiblio repository needs now is decentralized management - meaning: assiging certain people (or groups of people) to be responsible for managing a specific part of the repo (e.g. joe is managing all hibernate-related POMs...) These people can be among the maven dev team - but I think a more reasonable approach would be that these peole come from the maven community (see my mail on the user mailing list on december about this: http://mail-archives.apache.org/mod_mbox/maven-users/200512.mbox/[EMAIL PROTECTED]) This has the potential to solve most of the issues the author of the blog (justifiably) raises. I think that will remove most of the (heavy) load burdened on Carlos, Edwin and the other Maven team members and free some of their time. Of course, to make that happen, a set of guidelines for those maintainers will have to be laid out (if/when to update an existing POM, when to define dependencies as optional, etc) but once that is done, I think the QoS of the central repository will increase ten-folds and make Maven 2.x a real joy cruise for users: both quality-wise of the artifacts and the response time for fixes. Best regards, Arik Kfir. On 2/3/06, Robert Watts [EMAIL PROTECTED] wrote: http://www.ctoforaday.com/archives/49.html Seems fair to me, has mirrored may of the headaches with our own implementation. Rob. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, _ Arik Kfir[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r374306 - in /maven/repository-manager/trunk/maven-repository-utils: pom.xml src/main/java/org/apache/maven/repository/ArtifactUtils.java src/test/java/org/apache/maven/repository/Arti
[EMAIL PROTECTED] wrote: Modified: maven/repository-manager/trunk/maven-repository-utils/pom.xml URL: http://svn.apache.org/viewcvs/maven/repository-manager/trunk/maven-repository-utils/pom.xml?rev=374306r1=374305r2=374306view=diff == --- maven/repository-manager/trunk/maven-repository-utils/pom.xml (original) +++ maven/repository-manager/trunk/maven-repository-utils/pom.xml Thu Feb 2 00:52:25 2006 @@ -27,6 +27,10 @@ dependencies dependency groupIdorg.codehaus.plexus/groupId + artifactIdplexus-container-default/artifactId +/dependency +dependency + groupIdorg.codehaus.plexus/groupId artifactIdplexus-utils/artifactId /dependency dependency Should this be scopetest/scope ? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MSITE-86) ${modules} macro placed in site.xml does work properly
${modules} macro placed in site.xml does work properly
--
Key: MSITE-86
URL: http://jira.codehaus.org/browse/MSITE-86
Project: Maven 2.x Site Plugin
Type: Bug
Environment: FC4, Java 1.5.0_06, Maven 2.0.2
Reporter: Ersin Er
When I put a ${modules} in site.xml, only an empty menu with Modules title
appear on the left menu. No module entries are created in the left menu. Also
the general structure of the site gets messed. For example an the index page of
the parent project was replaced by a module's index page in my case.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSITE-60) Report Classloaders out of sync when executed from within the site:site goal.
[ http://jira.codehaus.org/browse/MSITE-60?page=all ] Brett Porter closed MSITE-60: - Assign To: Brett Porter Resolution: Won't Fix Fix Version: (was: 2.0) its not reproducible because the fix was added directly to the checkstyle plugin. I think we resolved to fix this in the core eventually, and to work around it in individual plugins for now. Please reopen if I'm mistaken. Report Classloaders out of sync when executed from within the site:site goal. - Key: MSITE-60 URL: http://jira.codehaus.org/browse/MSITE-60 Project: Maven 2.x Site Plugin Type: Bug Reporter: Joakim Erdfelt Assignee: Brett Porter Priority: Critical Attachments: MNG-1901.patch, dummy-maven-plugin.tar.bz2 When testing the classloaders from within a mojo and a report the following is discovered. ## Direct Mojo execution from command line. mvn -e dummy:dump Thread.currentThread().getContextClassLoader() = RealmDelegatingClassLoader for dummy:dump. this.getClass().getClassLoader() = RealmClassLoader for dummy:dump. ## Report execution via site:site mvn -e site:site Thread.currentThread().getContextClassLoader() = RealmDelegatingClassLoader for site:site. this.getClass().getClassLoader() = RealmClassLoader for dummy:report. When a report is executing, relying on the Thread.currentThread().getContextClassLoader() to obtain resources out of jar files (for example) will fail. This discovery was as a result of debugging MCHECKSTYLE-10 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-586) consider upgrades to JDO api JAR, jpox
consider upgrades to JDO api JAR, jpox -- Key: CONTINUUM-586 URL: http://jira.codehaus.org/browse/CONTINUUM-586 Project: Continuum Type: Task Components: Core system Reporter: Brett Porter jdo 2.0 beta is out, and jpox 1.1 beta-6 is out. I don' tknow if they might help with anything, but at least for jdo it'd be nice to be on a semi-official release. -- 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: (MSITE-86) ${modules} macro placed in site.xml does work properly
[ http://jira.codehaus.org/browse/MSITE-86?page=all ]
Brett Porter updated MSITE-86:
--
Fix Version: 2.0
is this on apacheds running mvn site ?
${modules} macro placed in site.xml does work properly
--
Key: MSITE-86
URL: http://jira.codehaus.org/browse/MSITE-86
Project: Maven 2.x Site Plugin
Type: Bug
Environment: FC4, Java 1.5.0_06, Maven 2.0.2
Reporter: Ersin Er
Fix For: 2.0
When I put a ${modules} in site.xml, only an empty menu with Modules title
appear on the left menu. No module entries are created in the left menu. Also
the general structure of the site gets messed. For example an the index page
of the parent project was replaced by a module's index page in my case.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r374170 - /maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
Kenney - any thoughts on this?
- Brett
Brett Porter wrote:
um, not quite :)
1) the equals check is redundant
2) type + classifier is valid
I think its just a simple append of .${classifier} if it is not null.
[EMAIL PROTECTED] wrote:
Author: kenney
Date: Wed Feb 1 12:56:07 2006
New Revision: 374170
URL: http://svn.apache.org/viewcvs?rev=374170view=rev
Log:
As per Brett's request, added a check for the classifier. If it's different
from the artifact type, the classifier will be used in the property name.
Modified:
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
Modified:
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
URL:
http://svn.apache.org/viewcvs/maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java?rev=374170r1=374169r2=374170view=diff
==
---
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
(original)
+++
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntPropertyHelper.java
Wed Feb 1 12:56:07 2006
@@ -64,11 +64,14 @@
for ( Iterator it = artifacts.iterator(); it.hasNext(); )
{
Artifact artifact = (Artifact) it.next();
-log.debug( Storing: maven.dependency. + artifact.getGroupId() +
. +
-artifact.getArtifactId() + . + artifact.getType() +
.path= + artifact.getFile().getPath() );
-artifactMap.put( maven.dependency. + artifact.getGroupId() +
. +
-artifact.getArtifactId() + . + artifact.getType() +
.path, artifact.getFile().getPath() );
+String key = maven.dependency. + artifact.getGroupId() + .
+ artifact.getArtifactId() + . +
+( artifact.getClassifier() == null ||
artifact.getType().equals( artifact.getClassifier() ) ?
+ artifact.getType() : artifact.getClassifier() ) + .path;
+
+log.debug( Storing: + key + = +
artifact.getFile().getPath() );
+
+artifactMap.put( key, artifact.getFile().getPath() );
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPA-41) Setup sync with objectweb m1 and m2 repositories
[ http://jira.codehaus.org/browse/MPA-41?page=comments#action_58049 ] Brett Porter commented on MPA-41: - Carlos - is this what you did today? Setup sync with objectweb m1 and m2 repositories Key: MPA-41 URL: http://jira.codehaus.org/browse/MPA-41 Project: Maven Project Administration Type: Task Components: repository management Reporter: Vincent Massol Assignee: Jason van Zyl ObjectWeb now has a maven2 repository. The following need to be synced to ibiblio: maven1: forge.objectweb.org:/var/lib/gforge/chroot/home/groups/maven/htdocs/maven1 Note that previously the maven1 repository was at forge.objectweb.org:/var/lib/gforge/chroot/home/groups/maven/htdocs/maven maven2 release repo: forge.objectweb.org:/var/lib/gforge/chroot/home/groups/maven/htdocs/maven2 maven2 snapshot repo: forge.objectweb.org:/var/lib/gforge/chroot/home/groups/maven/htdocs/maven2-snapshot I don't think we have a snapshot repo yet so syncing the m1 and m2 release repo is fine for now. Thanks -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPA-35) add Lukas Theussl to the PMC
[ http://jira.codehaus.org/browse/MPA-35?page=all ] Brett Porter closed MPA-35: --- Resolution: Fixed add Lukas Theussl to the PMC Key: MPA-35 URL: http://jira.codehaus.org/browse/MPA-35 Project: Maven Project Administration Type: Task Reporter: Brett Porter Assignee: Jason van Zyl Fix For: 2006-q1 Jason to add Lukas to the PMC roster in committee-info.txt 72 hours after the creation of this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPA-48) migrate all maven, mojo, mrm, continuum, etc projects to the new workflow where closed issues can be edited.
migrate all maven, mojo, mrm, continuum, etc projects to the new workflow where closed issues can be edited. Key: MPA-48 URL: http://jira.codehaus.org/browse/MPA-48 Project: Maven Project Administration Type: Task Components: Issue Management Reporter: Brett Porter Assigned to: Jason van Zyl Fix For: 2006-q1 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPA-49) consider IRC logging again
consider IRC logging again -- Key: MPA-49 URL: http://jira.codehaus.org/browse/MPA-49 Project: Maven Project Administration Type: Task Reporter: Brett Porter Assigned to: Jason van Zyl I wonder if it is a good idea to reconsider running logging on the #maven IRC channel as an extra source of finding answers to questions? Installing something like this: http://humdi.net/ircstats/ would also be interesting. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Brett Porter wrote: I think the solution is easier: Anyone that proves they are capable will be given access to do this. We won't be handing out responsibility to volunteers who have not yet proven they are capable at the task through patches - just like how commit access is granted in general. We do need better revision control, and at some point to draw a line in the sand and not change things. My single biggest regret about the first release is not sorting this out better, even though I knew it was coming I thought it would peak and get sorted out. I can't believe we *still* can't agree on how hibernate should be done. I actually wonder if we'd been better off starting from scratch and adding lovingly hand-crafted POMS by people that needed them. I guess there's still time to start over in a new repo :) Cheers, Brett I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses junit, or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSITE-86) ${modules} macro placed in site.xml does work properly
[ http://jira.codehaus.org/browse/MSITE-86?page=comments#action_58053 ]
Ersin Er commented on MSITE-86:
---
I'm having trouble generating the same issues. Now, I'm using the latest trunk
version of maven site plugin and I get a good site and empty modules menu here:
http://directory.apache.org/newsite/projects/apacheds/
and an intended site here:
http://directory.apache.org/newsite/projects/network/
(This is the first time I saw ${modules} macro worked.)
${modules} macro placed in site.xml does work properly
--
Key: MSITE-86
URL: http://jira.codehaus.org/browse/MSITE-86
Project: Maven 2.x Site Plugin
Type: Bug
Environment: FC4, Java 1.5.0_06, Maven 2.0.2
Reporter: Ersin Er
Fix For: 2.0
When I put a ${modules} in site.xml, only an empty menu with Modules title
appear on the left menu. No module entries are created in the left menu. Also
the general structure of the site gets messed. For example an the index page
of the parent project was replaced by a module's index page in my case.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m1.1] eclipse-plugin-1.11 trivial bug
Hello,
I'm using maven 1.1b2 + eclipse plugin from CVS (snapshot)
I'm using mutliproject to build the .classpath/.project of all my
subprojects.
To make it run as expceted, I have to set :
maven.eclipse.output.dir = bin/classes
maven.eclipse.test.output.dir = ${basedir}/bin/test-classes
I need to set ${basedir} in test.output.dir, and to avoid it in output.dir
${basedir}is required to make relative path to point to current
sub-project when ran from a multiproject goal.
In .classpath template, maven:makeRelativePath is used to build a
project-root relative path.
this transform is ALWAYS applied to testOutputDir.
this transform is applied to outputDir ONLY if it has not been set from
properties.
I think makeRelativePath should be always applied.
Nico.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1.1] eclipse-plugin-1.11 trivial bug
Hi Nicolas
Can you open an issue ?
We'll fix it soonly.
Arnaud
On 2/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
Hello,
I'm using maven 1.1b2 + eclipse plugin from CVS (snapshot)
I'm using mutliproject to build the .classpath/.project of all my
subprojects.
To make it run as expceted, I have to set :
maven.eclipse.output.dir = bin/classes
maven.eclipse.test.output.dir = ${basedir}/bin/test-classes
I need to set ${basedir} in test.output.dir, and to avoid it in output.dir
${basedir}is required to make relative path to point to current
sub-project when ran from a multiproject goal.
In .classpath template, maven:makeRelativePath is used to build a
project-root relative path.
this transform is ALWAYS applied to testOutputDir.
this transform is applied to outputDir ONLY if it has not been set from
properties.
I think makeRelativePath should be always applied.
Nico.
This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It is intended only for the person to
whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-121) Intermittent CVS test failures
[ http://jira.codehaus.org/browse/SCM-121?page=comments#action_58056 ] Emmanuel Venisse commented on SCM-121: -- Do you have always failures on cvs tests? Is it only for the diff command? Can you run manually commands that run by maven-scm? tell me what is the result. For the diff result, is it really an empty string or a problem with carriage return? I try it under windows with cvsnt and cygwin cvs (default end lines for cygwin are defined as unix end lines) Intermittent CVS test failures -- Key: SCM-121 URL: http://jira.codehaus.org/browse/SCM-121 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Versions: 1.0-beta-3 Reporter: Mike Perham Fix For: 1.0 Dan and I continue to have test failures when trying to compile the cvs plugin in our environment. I emailed these problems to the scm-dev list about a week ago. -- 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
Re: critique of maven 2.0.2
Hello, I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) Regards, Raphaël 2006/2/7, Steve Loughran [EMAIL PROTECTED]: I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses junit, or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1.1] eclipse-plugin-1.11 trivial bug
http://jira.codehaus.org/browse/MPECLIPSE-111
Arnaud HERITIER a écrit :
Hi Nicolas
Can you open an issue ?
We'll fix it soonly.
Arnaud
On 2/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
Hello,
I'm using maven 1.1b2 + eclipse plugin from CVS (snapshot)
I'm using mutliproject to build the .classpath/.project of all my
subprojects.
To make it run as expceted, I have to set :
maven.eclipse.output.dir = bin/classes
maven.eclipse.test.output.dir = ${basedir}/bin/test-classes
I need to set ${basedir} in test.output.dir, and to avoid it in output.dir
${basedir}is required to make relative path to point to current
sub-project when ran from a multiproject goal.
In .classpath template, maven:makeRelativePath is used to build a
project-root relative path.
this transform is ALWAYS applied to testOutputDir.
this transform is applied to outputDir ONLY if it has not been set from
properties.
I think makeRelativePath should be always applied.
Nico.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPECLIPSE-111) heterogeneous configuration when used from mutliproject
heterogeneous configuration when used from mutliproject
Key: MPECLIPSE-111
URL: http://jira.codehaus.org/browse/MPECLIPSE-111
Project: maven-eclipse-plugin
Type: Bug
Versions: 1.11
Reporter: nicolas de loof
Priority: Trivial
I'm using maven 1.1b2 + eclipse plugin from CVS (snapshot)
I'm using mutliproject to build the .classpath/.project of all my subprojects.
To make it run as expceted, I have to set :
maven.eclipse.output.dir = bin/classes
maven.eclipse.test.output.dir = ${basedir}/bin/test-classes
I need to set ${basedir} in test.output.dir, and to avoid it in output.dir
${basedir}is required to make relative path to point to current sub-project
when ran from a multiproject goal.
In .classpath template, maven:makeRelativePath is used to build a
project-root relative path.
this transform is ALWAYS applied to testOutputDir.
this transform is applied to outputDir ONLY if it has not been set from
properties.
I think makeRelativePath should be always applied.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m1.1] eclipse-plugin-1.11 trivial bug
thanks.
Arnaud
On 2/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
http://jira.codehaus.org/browse/MPECLIPSE-111
Arnaud HERITIER a écrit :
Hi Nicolas
Can you open an issue ?
We'll fix it soonly.
Arnaud
On 2/7/06, Nicolas De Loof [EMAIL PROTECTED] wrote:
Hello,
I'm using maven 1.1b2 + eclipse plugin from CVS (snapshot)
I'm using mutliproject to build the .classpath/.project of all my
subprojects.
To make it run as expceted, I have to set :
maven.eclipse.output.dir = bin/classes
maven.eclipse.test.output.dir = ${basedir}/bin/test-classes
I need to set ${basedir} in test.output.dir, and to avoid it in output.dir
${basedir}is required to make relative path to point to current
sub-project when ran from a multiproject goal.
In .classpath template, maven:makeRelativePath is used to build a
project-root relative path.
this transform is ALWAYS applied to testOutputDir.
this transform is applied to outputDir ONLY if it has not been set from
properties.
I think makeRelativePath should be always applied.
Nico.
This message contains information that may be privileged or confidential
and is the property of the Capgemini Group. It is intended only for the
person to whom it is addressed. If you are not the intended recipient, you
are not authorized to read, print, retain, copy, disseminate, distribute,
or use this message or any part thereof. If you receive this message in
error, please notify the sender immediately and delete all copies of this
message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It is intended only for the person to
whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPECLIPSE-111) heterogeneous configuration when used from mutliproject
[ http://jira.codehaus.org/browse/MPECLIPSE-111?page=all ]
Arnaud Heritier updated MPECLIPSE-111:
--
Fix Version: 1.11
heterogeneous configuration when used from mutliproject
Key: MPECLIPSE-111
URL: http://jira.codehaus.org/browse/MPECLIPSE-111
Project: maven-eclipse-plugin
Type: Bug
Versions: 1.11
Reporter: nicolas de loof
Priority: Trivial
Fix For: 1.11
I'm using maven 1.1b2 + eclipse plugin from CVS (snapshot)
I'm using mutliproject to build the .classpath/.project of all my subprojects.
To make it run as expceted, I have to set :
maven.eclipse.output.dir = bin/classes
maven.eclipse.test.output.dir = ${basedir}/bin/test-classes
I need to set ${basedir} in test.output.dir, and to avoid it in output.dir
${basedir}is required to make relative path to point to current sub-project
when ran from a multiproject goal.
In .classpath template, maven:makeRelativePath is used to build a
project-root relative path.
this transform is ALWAYS applied to testOutputDir.
this transform is applied to outputDir ONLY if it has not been set from
properties.
I think makeRelativePath should be always applied.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
Piéroni Raphaël wrote: Hello, I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) There are a couple attempts on graphing that have been merged and the code is available in the Mojo project: http://svn.mojo.codehaus.org/trunk/mojo/mojo-sandbox/maven-graphing/ Jung is a fine graphing library and it's BSD licensed and is what we intend to use for graph visualization. You can find it here: http://jung.sf.net Joekim and myself have been playing around with this and Joekim has something that looks pretty cool already. I highly recommend you look in there before attempting to start something different. The source for the graphs will come from the Maven Repository Manager which will have a pluggable mechanism for performing any sort of analysis on the repository you wish. There is a mechanism now for walking around the repository which we are currently using for indexing the contents of a repository. Regards, Raphaël 2006/2/7, Steve Loughran [EMAIL PROTECTED]: I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses junit, or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bringing plugins to Apache Maven
Brett Porter wrote: This is not a vote. +1's here are just I've read and think it's all good, but generally I'm just looking for feedback on specific plugins and decision points before taking this any further forward. Some of the plugins that wound up in mojo seem better suited to the main Apache project due to a) originally coming from there b) having the core libraries located there c) being essential to the day to day use of the project. These are the ones I'm thinking of: - jxr report (relates to jxr) +1 They should be together really. - surefire report (relates to surefire) +1 The current plugin plus the report should probably go into surefire proper. Might as well keep it all together. - changes/jira/announcement report (relates to issue stuff in sandbox) - changelog report (relates to scm) - dependency-maven-plugin (sounds generally handy in eliminating a lot of small antrunning). +1 As a community we need to decide where we are going to develop individual plugins. As I understand it, mojo.codehaus.org was established to: - develop things that can't be entirely under the ASL. - avoid developing plugins that rotted and tied due to lack of community in m1 - give a place for individual plugin developers to start out but still operate in the same way as the Maven community. In essence a very low barrier to entry for those wanting to participate in plugin development. As time passes plugins, like the ones listed above, that deem widely beneficial can be brought here. I think this process works fine. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
ClassCastException when moving from 2.5 to 3.0
--
Key: MPCHECKSTYLE-53
URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-53
Project: maven-checkstyle-plugin
Type: Bug
Versions: 3.0
Environment: Windows/Linux
Java 5.0
Maven 1.x
Reporter: Bernard Durfee
The error I get...
BUILD FAILED
File..
/home/cruisecontrol/.maven/cache/maven-checkstyle-plugin-3.0/plugin.jelly
Element... style
Line.. 238
Column 59
java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
...is usually caused when an application is specifically looking for Xerces
classes, instead of always going through JAXP interfaces and factories.
My application uses XSLT 2.0 features, which are not supported by Xerces/Xalan.
So I have a file in my JDK lib directory named jaxp.properties...
{code}
# JAXP Factories
javax.xml.parsers.SAXParserFactory = oracle.xml.jaxp.JXSAXParserFactory
javax.xml.parsers.DocumentBuilderFactory =
oracle.xml.jaxp.JXDocumentBuilderFactory
javax.xml.transform.TransformerFactory =
oracle.xml.jaxp.JXSAXTransformerFactory
{code}
...which causes the JDK to default to the Oracle parser, which supports XSLT
2.0.
My hunch is that somewhere in the code the JAXP TransformerFactory is called,
which returns the Oracle object, but someone is assuming that the Xerces object
will be returned and are casting the object to get at some Xerces specific
feature.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ${modules}
I know of one way that this can occure but only in non reactor envs (-N): if
your models do not explicitly declare a URL or name then the resulting
module will not be written into the final site (see
http://jira.codehaus.org/browse/MSITE-72)
- Original Message -
From: Brett Porter [EMAIL PROTECTED]
To: Maven Developers List dev@maven.apache.org
Sent: Tuesday, February 07, 2006 1:02 PM
Subject: Re: ${modules}
Hi Ersin,
I had a tough time reproducing this the other day. Please file a bug
under MSITE and I'll get to it before the release.
Thanks,
Brett
Ersin Er wrote:
I've installed the 2.0-SNAPSHOT version and what I get is only a menu
title as Modules. Here is the deployed site:
http://directory.apache.org/newsite/subprojects/apacheds/
Any suggestions ?
Thanks.
On 2/4/06, Brett Porter [EMAIL PROTECTED] wrote:
I think it's only available in 2.0-SNAPSHOT of the plugin from SVN.
- Brett
Ersin Er wrote:
Sorry but I've to ask it again. When I want to use it the site gets
corrupted. Can you confirm that it actually works ?
Thanks.
On 1/26/06, Brett Porter [EMAIL PROTECTED] wrote:
Yes.
Ersin Er wrote:
Hi,
Is ${modules} substitution supported in site.xml? I'm asking because
it's mentioned here:
http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence
Thanks.
--
Ersin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ersin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ersin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parent vs dependency aggregation, including sites and reports
Brett, I agree with most of what you said in this mail and in your POM-Problems email. I just have this comment: From the POM-problems email: 3) Separating inheritance of versioned and transient info A: Deprecate dependency inheritance (bare with me :) The problem of separation only seems to appear in generic pom inheritance, and then it is only the dependencies used that are of issue. For starters, in that case, we can just say its is best practice not to inherit the dependency, then the parent becomes completely project/build info which we are happy to have the auto versioning for. But that raises the question - is dependency inheritance worthwhile at all any more? I think the dependency or dependencyManagement inheritance is all about not having to duplicate versions etc all over the place. I have it setup so that I can control the versions from as few places as possible and thus most of my parents at least have the management sections. If this is removed, then I think it will be a nightmare for example to update from foo x-x to foo x-z. Now obviously this would happen with the auto version resolution if I set it in the final product (ie war). However, in this case, if I want my standalone builds or unit tests to be accurately using the intended version, then I need to update all my projects to have the correct version. This actually negates many benefits of the transitive dependency resolution you mentioned. I agree that the current method doesn't feel right, but this is currently the only way to control this that I can see. The other important part is the pluginManagement. In a corp environment, it's important to know all developers are using vetted versions of the plugins. Using a highlevel parent with pluginManagement allows me to verify new plugins make nessessary infrastructure changes before rolling it out. It means that this needs to be versioned because a new plugin rev might imply some other changes in the build or code. It's also nice that devs don't have to remember to use the -U command all the time. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 07, 2006 1:24 AM To: Maven Developers List Subject: Parent vs dependency aggregation, including sites and reports Hi folks, This is pretty important to start punting around as I need to lock in a best practice that works on Maven 2.0 and can be used in the site plug-in release. Please give this a review as soon as possible. I am battling the age old question where we have parent as inheritance and parent as a build aggregator. I'm still inclined to think that we should separate the functional from the informational (feedback on http://www.nabble.com/POM-Problems-and-Inheritence-t642303.html#a1708556 still welcome!), we're stuck with the current situation for right now. Recently, we've been talking about making the parents produce aggregated content - assemblies, ears, aggregated site reports. This results in a src/ directory under the root that sits with the parent. I'd alluded to this in http://www.nabble.com/-discuss-change-to-parent-hierachy-t898697.html#a2 329650 which I'll revise based on any decision here. Chatting with Jason, we've agreed it doesn't quite feel right, though for my part I'm not convinced it's a bad thing yet but rather just something I'm not used to. The main downside I see remains the inability to do anything with it in Eclipse :) The alternative is to make everything a module of the parent, using dependencies to represent the things to aggregate. This removes the need to make modules act like dependencies and keeps the parent clean as an inheritance and build entry point. All the outputs of the build end up in a module. Practical example: maven/components/trunk/ pom.xml maven-artifact/ maven-core/ ... maven-dist/ maven-user-guide/ maven-reference-guide/ The new stuff here: - maven-user-guide is a site that contains documentation for Maven. It would have a lot of the stuff from the site now under /guides/, but is here to be versioned and distributed. It would be of type assembly and produce an zip of the docs for individual download. - maven-dist is of packagingassembly/packaging and contains the assembly descriptors and binary files currently in maven-core. It would depend on maven-user-guide and bundle that in some binary distributions that include documentation (I generally prefer a separate bundle as above, but its an option as I'm thinking general practices here) - maven-reference-guide is a site that is deployed to include documentation for Maven developers. It depends on all the modules and while it doesn't produce a distribution, it provides the site that links in all the other modules and would produce any aggregate reports. The site plug-in would have to be able to include dependencies in a menu instead of modules, which might be a hassle as we are now reproducing a lot of information. This is the one I'm least comfortable about.
[jira] Updated: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
[ http://jira.codehaus.org/browse/MPCHECKSTYLE-53?page=all ]
Arnaud Heritier updated MPCHECKSTYLE-53:
Fix Version: 3.0.1
ClassCastException when moving from 2.5 to 3.0
--
Key: MPCHECKSTYLE-53
URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-53
Project: maven-checkstyle-plugin
Type: Bug
Versions: 3.0
Environment: Windows/Linux
Java 5.0
Maven 1.x
Reporter: Bernard Durfee
Fix For: 3.0.1
The error I get...
BUILD FAILED
File..
/home/cruisecontrol/.maven/cache/maven-checkstyle-plugin-3.0/plugin.jelly
Element... style
Line.. 238
Column 59
java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
...is usually caused when an application is specifically looking for Xerces
classes, instead of always going through JAXP interfaces and factories.
My application uses XSLT 2.0 features, which are not supported by
Xerces/Xalan. So I have a file in my JDK lib directory named
jaxp.properties...
{code}
# JAXP Factories
javax.xml.parsers.SAXParserFactory = oracle.xml.jaxp.JXSAXParserFactory
javax.xml.parsers.DocumentBuilderFactory =
oracle.xml.jaxp.JXDocumentBuilderFactory
javax.xml.transform.TransformerFactory =
oracle.xml.jaxp.JXSAXTransformerFactory
{code}
...which causes the JDK to default to the Oracle parser, which supports XSLT
2.0.
My hunch is that somewhere in the code the JAXP TransformerFactory is called,
which returns the Oracle object, but someone is assuming that the Xerces
object will be returned and are casting the object to get at some Xerces
specific feature.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MECLIPSE-37) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MECLIPSE-37?page=all ] Kenney Westerhof reopened MECLIPSE-37: -- The idea behind the eclipse plugin is that you can develop on a project. Right now, I checked out a new version of a project I'm working on. Somebody messed it up and now it doesn't compile. I want to edit the faulty classes in Eclipse but I don;t have any .project files. So I run mvn eclipse:eclipse. That fails because the project doesn't compile. Now I cannot fix the bugs because the plugin that should make metadata ABOUT the project tries to compile it first which makes no sense. I understand that test-resources should also be present in eclipse, but this solution limits the usage of eclipse on maven projects and is not backwards compatible in my opinion. I'd like to see this change reverted, and maybe add a comandline switch to include/exclude test resources when generating project resources. Currently I think only a new mojo can do the trick since the @execute phase is not runtime configurable. Maybe it's time to review the generate-test-resource phase. Is it per definition necessary to have compiled src/main sources present in this phase? If so, why? If not, shouldn't the generate-test-(re)sources be run right after the process-resources? I.e. move them before the compile phase? Another solution might be to make the @execute phase configurable somehow, and specify an option to the eclipse:eclipse plugin to NOT generate test resources and stick with the generate-resources phase. the process-resources eclipse:eclipse should execute in a later phase than generate-sources --- Key: MECLIPSE-37 URL: http://jira.codehaus.org/browse/MECLIPSE-37 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.0 Reporter: Mark Donszelmann Assignee: fabrizio giustina Fix For: 2.1 the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
[
http://jira.codehaus.org/browse/MPCHECKSTYLE-53?page=comments#action_58061 ]
Arnaud Heritier commented on MPCHECKSTYLE-53:
-
Can you give us the full stacktrace with the -e option. Thanks
ClassCastException when moving from 2.5 to 3.0
--
Key: MPCHECKSTYLE-53
URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-53
Project: maven-checkstyle-plugin
Type: Bug
Versions: 3.0
Environment: Windows/Linux
Java 5.0
Maven 1.x
Reporter: Bernard Durfee
Fix For: 3.0.1
The error I get...
BUILD FAILED
File..
/home/cruisecontrol/.maven/cache/maven-checkstyle-plugin-3.0/plugin.jelly
Element... style
Line.. 238
Column 59
java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
...is usually caused when an application is specifically looking for Xerces
classes, instead of always going through JAXP interfaces and factories.
My application uses XSLT 2.0 features, which are not supported by
Xerces/Xalan. So I have a file in my JDK lib directory named
jaxp.properties...
{code}
# JAXP Factories
javax.xml.parsers.SAXParserFactory = oracle.xml.jaxp.JXSAXParserFactory
javax.xml.parsers.DocumentBuilderFactory =
oracle.xml.jaxp.JXDocumentBuilderFactory
javax.xml.transform.TransformerFactory =
oracle.xml.jaxp.JXSAXTransformerFactory
{code}
...which causes the JDK to default to the Oracle parser, which supports XSLT
2.0.
My hunch is that somewhere in the code the JAXP TransformerFactory is called,
which returns the Oracle object, but someone is assuming that the Xerces
object will be returned and are casting the object to get at some Xerces
specific feature.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2047) doc. Philosophy of Maven: Typo
doc. Philosophy of Maven: Typo Key: MNG-2047 URL: http://jira.codehaus.org/browse/MNG-2047 Project: Maven 2 Type: Bug Components: Documentation: Guides Versions: 2.0.2 Reporter: Rainer Wasserfuhr Priority: Trivial http://svn.apache.org/viewcvs.cgi/maven/site/trunk/src/site/apt/background/?rev=375610 typo: resuability - reusability -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNGECLIPSE-72) performace
[ http://jira.codehaus.org/browse/MNGECLIPSE-72?page=comments#action_58063 ] Andrew Britz commented on MNGECLIPSE-72: My Bad ... sorry this is a duplicate. performace -- Key: MNGECLIPSE-72 URL: http://jira.codehaus.org/browse/MNGECLIPSE-72 Project: Maven 2.x Extension for Eclipse Type: Improvement Environment: XP, jsdk 1.5.x, eclipse 3.1.x Reporter: Andrew Britz Assignee: Eugene Kuleshov I have about six projects open in the ide and it takes about 25 minutes for the maven2 plug-in to get its lists of dependencies. (I have a local ibiblio mirror repository that is being hit) If I run the same builds on the command line it takes less then 10 seconds a build. Not sure if the problem it the plug-in or the embedded maven container. Has anyone else found this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNGECLIPSE-72) performace
[ http://jira.codehaus.org/browse/MNGECLIPSE-72?page=all ] Andrew Britz closed MNGECLIPSE-72: -- Resolution: Duplicate performace -- Key: MNGECLIPSE-72 URL: http://jira.codehaus.org/browse/MNGECLIPSE-72 Project: Maven 2.x Extension for Eclipse Type: Improvement Environment: XP, jsdk 1.5.x, eclipse 3.1.x Reporter: Andrew Britz Assignee: Eugene Kuleshov I have about six projects open in the ide and it takes about 25 minutes for the maven2 plug-in to get its lists of dependencies. (I have a local ibiblio mirror repository that is being hit) If I run the same builds on the command line it takes less then 10 seconds a build. Not sure if the problem it the plug-in or the embedded maven container. Has anyone else found this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
[
http://jira.codehaus.org/browse/MPCHECKSTYLE-53?page=comments#action_58064 ]
Bernard Durfee commented on MPCHECKSTYLE-53:
{code}
checkstyle:report-internal:
[mkdir] Created dir:
c:\eclipse-workspace\CAT\target\generated-xdocs\checkstyle
[style] Processing
c:\eclipse-workspace\CAT\target\checkstyle\checkstyle-raw-report.xml to
C:\eclipse-workspace\CAT\target\checkstyle\checkstyle-summary-report.xml
[style] Loading stylesheet c:\Documents and
Settings\home\.maven\cache\maven-checkstyle-plugin-3.0\plugin-resources\checkstyle-summary.xsl
[style] Failed to process
C:\eclipse-workspace\CAT\target\checkstyle\checkstyle-raw-report.xml
BUILD FAILED
java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
at
org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:534)
at
org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:239)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:185)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263)
at org.apache.maven.cli.App.doMain(App.java:488)
at org.apache.maven.cli.App.main(App.java:1239)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
Re: critique of maven 2.0.2
Piéroni Raphaël wrote: Hello, I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) I didnt know of that one. The one I know of is Jlog: http://jlogic.sourceforge.net/ . Our deployment runtime (smartfrog) can use this or other logic engines that can be dropped in to our constraint API, so that when you deploy things you can declare constraints in the logic language; let the system work out for itself what a good solution is to some of the constraints. We explicitly support other back ends so that we remain LGPL instead of GPL; I don't know what maven has in terms of a dependency API; what I'd do is -grab the pom files (well, be pointed at a repository and walk the tree) -extract the XML data -assert that all as facts in the prolog database -add extra rules resolve out interesting facts e.g m(junit,junit,3.8.1). m(log4j,log4j,1.2.8). depends(m(junit,junit,3.8.1),m(log4j,log4j,1.2.8)). Otherwise It is easy to declare transitive dependencies depends(X,Y) :- depends(X,Z),depends(Z,Y). Then you can get all solutions to a problem : depends(m(me,myapp,3.4)),X). exclusions complicate this model. Not having written proper prolog for a decade, it doesnt come to me off the top of my head. Something like X depends on m(G,A,V) if there isnt an excludes(X,m(G,A,_)), but prolog isnt great for specifying negative facts. Version rules are the other complexity. You can declare that a module is newer than something with the same group/artefact if its version tag is newer: newversion(m(Group,Artefact,Version),m(Group,Artifact,Version2)) :- Version Version2. Then add rules about only the newest version of anything being used. If you've never done Prolog, it is a different way of thinking. It should mesh very well with XML work. I've done RDBMS stuff with it in the past, and makes some things wonderfully easy (if desperately inefficient) -steve Regards, Raphaël 2006/2/7, Steve Loughran [EMAIL PROTECTED]: I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses junit, or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2048) Quote args in mvn script
Quote args in mvn script
Key: MNG-2048
URL: http://jira.codehaus.org/browse/MNG-2048
Project: Maven 2
Type: Bug
Components: Command Line
Versions: 2.0.2
Environment: Windows XP
Cygwin
Reporter: Dale Wyttenbach
Priority: Minor
The mvn script as distributed does not handle quoted args such as:
m2 -Dgreeting=huh bah hello:sayhi
You get the error:
Invalid task 'bah': you must specify a valid lifecycle phase, or a goal in the
format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal
Here is a fix for the mvn script:
*** mvn 2006/02/07 15:58:33 1.1
--- mvn 2006/02/07 15:58:38
***
*** 134,138
-classpath ${M2_HOME}/core/boot/classworlds-*.jar \
-Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
-Dmaven.home=${M2_HOME} \
! ${CLASSWORLDS_LAUNCHER} $@
--- 134,138
-classpath ${M2_HOME}/core/boot/classworlds-*.jar \
-Dclassworlds.conf=${M2_HOME}/bin/m2.conf \
-Dmaven.home=${M2_HOME} \
! ${CLASSWORLDS_LAUNCHER} $@
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-2047) doc. Philosophy of Maven: Typo
[ http://jira.codehaus.org/browse/MNG-2047?page=all ] John Casey updated MNG-2047: Assign To: Allan Ramirez Fix Version: documentation Allan, can you fix this and use it to test your commit privileges? I think they should be fixed now. doc. Philosophy of Maven: Typo Key: MNG-2047 URL: http://jira.codehaus.org/browse/MNG-2047 Project: Maven 2 Type: Bug Components: Documentation: Guides Versions: 2.0.2 Reporter: Rainer Wasserfuhr Assignee: Allan Ramirez Priority: Trivial Fix For: documentation http://svn.apache.org/viewcvs.cgi/maven/site/trunk/src/site/apt/background/?rev=375610 typo: resuability - reusability -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MECLIPSE-37) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MECLIPSE-37?page=comments#action_58066 ] John Casey commented on MECLIPSE-37: it might be good to define a sort of dry-run switch for plugins to follow, which would ask them not to modify anything, just to add the compile source roots, etc that they would have added, so that plugins like this can do their job more accurately. That's sort of a big design issue, though. :) eclipse:eclipse should execute in a later phase than generate-sources --- Key: MECLIPSE-37 URL: http://jira.codehaus.org/browse/MECLIPSE-37 Project: Maven 2.x Eclipse Plugin Type: Bug Versions: 2.0 Reporter: Mark Donszelmann Assignee: fabrizio giustina Fix For: 2.1 the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: critique of maven 2.0.2
I made some prolog at school, but never had since. but i remember well enough. Obviously the first thing to do is to create the facts by reading the poms. Which means reading all the poms at ibiblio (i remember there is a CVS/SVN of all the poms but where ?) I do not get the point about exclusion (as i never used exclusion in maven2). Will try to sent a better email of what i am understanding this nite after work. Raphaël 2006/2/7, Steve Loughran [EMAIL PROTECTED]: Piéroni Raphaël wrote: Hello, I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) I have not so much time, but i am volunteering on this if some one can point me to the 'dependency graph api'. And i needed some idea of code to work at home. this one is especially insterresting part (obviously the prolog one - Steve, if you can point me to the java-prolog library you know. the only one i know (and never used) is http://sourceforge.net/projects/amine-platform) I didnt know of that one. The one I know of is Jlog: http://jlogic.sourceforge.net/ . Our deployment runtime (smartfrog) can use this or other logic engines that can be dropped in to our constraint API, so that when you deploy things you can declare constraints in the logic language; let the system work out for itself what a good solution is to some of the constraints. We explicitly support other back ends so that we remain LGPL instead of GPL; I don't know what maven has in terms of a dependency API; what I'd do is -grab the pom files (well, be pointed at a repository and walk the tree) -extract the XML data -assert that all as facts in the prolog database -add extra rules resolve out interesting facts e.g m(junit,junit,3.8.1). m(log4j,log4j,1.2.8). depends(m(junit,junit,3.8.1),m(log4j,log4j,1.2.8)). Otherwise It is easy to declare transitive dependencies depends(X,Y) :- depends(X,Z),depends(Z,Y). Then you can get all solutions to a problem : depends(m(me,myapp,3.4)),X). exclusions complicate this model. Not having written proper prolog for a decade, it doesnt come to me off the top of my head. Something like X depends on m(G,A,V) if there isnt an excludes(X,m(G,A,_)), but prolog isnt great for specifying negative facts. Version rules are the other complexity. You can declare that a module is newer than something with the same group/artefact if its version tag is newer: newversion(m(Group,Artefact,Version),m(Group,Artifact,Version2)) :- Version Version2. Then add rules about only the newest version of anything being used. If you've never done Prolog, it is a different way of thinking. It should mesh very well with XML work. I've done RDBMS stuff with it in the past, and makes some things wonderfully easy (if desperately inefficient) -steve Regards, Raphaël 2006/2/7, Steve Loughran [EMAIL PROTECTED]: I personally think an interesting project for someone with time on their hands would be to write some code to walk the repository and derive useful facts from the dependency graph. I know this is on Brett's todo list, but it doesnt actually need repository/CVS access, and could be written by anyone. Things you could do with the right tool -reverse analysis, who uses junit, or junit-3.7 -cycle detection; who depends on a dependency -missing artifacts: what depends on things that arent there (split into sun, OSS, proprietary) -scale: who depends on the most stuff -stability: who is most bleeding edge, versus trailing output: generate fancy SVG graphs from it, or RDF triples for the fun of it. Having just been doing complex graph work in Java, I'd actually consider using Prolog for working with the dependency graph; the plugins for java are usually LGPL or GPL based though, especially the working ones (like JLog). -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCM-154) Bazaar tests should not assume bzr is installed
Bazaar tests should not assume bzr is installed --- Key: SCM-154 URL: http://jira.codehaus.org/browse/SCM-154 Project: Maven SCM Type: Bug Reporter: Mike Perham Priority: Critical Bazaar breaks my SCM build because it assumes it is installed. I do not think the user should be forced to install Bazaar just to compile the SCM codebase. See the StarTeam, Perforce and ClearCase providers for examples of providers which do not assume an installation. -- 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: (SCM-154) Bazaar tests should not assume bzr is installed
[ http://jira.codehaus.org/browse/SCM-154?page=all ] Mike Perham updated SCM-154: Version: 1.0-beta-3 Fix Version: 1.0-beta-3 Component: maven-scm-provider-bazaar Bazaar tests should not assume bzr is installed --- Key: SCM-154 URL: http://jira.codehaus.org/browse/SCM-154 Project: Maven SCM Type: Bug Components: maven-scm-provider-bazaar Versions: 1.0-beta-3 Reporter: Mike Perham Priority: Critical Fix For: 1.0-beta-3 Bazaar breaks my SCM build because it assumes it is installed. I do not think the user should be forced to install Bazaar just to compile the SCM codebase. See the StarTeam, Perforce and ClearCase providers for examples of providers which do not assume an installation. -- 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: (SCM-121) Intermittent CVS test failures
[ http://jira.codehaus.org/browse/SCM-121?page=comments#action_58067 ] Mike Perham commented on SCM-121: - I get the exact same error that Dan posted on 16/Jan. I will attach my cvs binary. Intermittent CVS test failures -- Key: SCM-121 URL: http://jira.codehaus.org/browse/SCM-121 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Versions: 1.0-beta-3 Reporter: Mike Perham Fix For: 1.0 Dan and I continue to have test failures when trying to compile the cvs plugin in our environment. I emailed these problems to the scm-dev list about a week ago. -- 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: (SCM-121) Intermittent CVS test failures
[ http://jira.codehaus.org/browse/SCM-121?page=all ] Mike Perham updated SCM-121: Attachment: cvs.exe Intermittent CVS test failures -- Key: SCM-121 URL: http://jira.codehaus.org/browse/SCM-121 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Versions: 1.0-beta-3 Reporter: Mike Perham Fix For: 1.0 Attachments: cvs.exe Dan and I continue to have test failures when trying to compile the cvs plugin in our environment. I emailed these problems to the scm-dev list about a week ago. -- 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
Re: Bringing plugins to Apache Maven
Brett Porter a écrit : This is not a vote. +1's here are just I've read and think it's all good, but generally I'm just looking for feedback on specific plugins and decision points before taking this any further forward. Some of the plugins that wound up in mojo seem better suited to the main Apache project due to a) originally coming from there b) having the core libraries located there c) being essential to the day to day use of the project. These are the ones I'm thinking of: - jxr report (relates to jxr) +1 - surefire report (relates to surefire) +1 - changes/jira/announcement report (relates to issue stuff in sandbox) +1 - changelog report (relates to scm) +1 It should probably go into maven-scm. - dependency-maven-plugin (sounds generally handy in eliminating a lot of small antrunning). +1 The other ones I'm tossing up: - taglist (generally useful report, originally came from m1) I put out a call for opinions and while the relevant mojo people were in favour, some of the Maven developers were either on the fence or against it. However, I didn't really receive an answer to my responses to those concerns. As a community we need to decide where we are going to develop individual plugins. As I understand it, mojo.codehaus.org was established to: - develop things that can't be entirely under the ASL. - avoid developing plugins that rotted and tied due to lack of community in m1 - give a place for individual plugin developers to start out but still operate in the same way as the Maven community. It's always been my thought that plugins at maven.apache.org should be those used by 80% of Maven users or essential to its operation, and those that relate to the Maven subprojects themselves. Also, plugins in like groups should be kept together. So, time to bring it here and get everyone's feedback again. If you already had objections, please voice them again if they are still a concern. What do others think? Note that this would imply bringing in a couple of new committers, but they are people that have been generally helpful. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r375474 - /maven/maven-1/plugins/trunk/plugins-site/project.xml
Sorry, I just thought this order was more logical (changelog, file/dev-activity together, license in the end,...). I'll check the sandbox as well. -Lukas Arnaud HERITIER wrote: I just use the alphabetical order. Why this order ? It's for the order in the menu ? Be careful to apply the same chages in the sandbox when you modify a commons part of the build (plugins-parent, plugins-site ...) Arnaud On 2/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: ltheussl Date: Mon Feb 6 20:21:03 2006 New Revision: 375474 URL: http://svn.apache.org/viewcvs?rev=375474view=rev Log: Re-order reports, add license report Modified: maven/maven-1/plugins/trunk/plugins-site/project.xml Modified: maven/maven-1/plugins/trunk/plugins-site/project.xml URL: http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/plugins-site/project.xml?rev=375474r1=375473r2=375474view=diff == --- maven/maven-1/plugins/trunk/plugins-site/project.xml (original) +++ maven/maven-1/plugins/trunk/plugins-site/project.xml Mon Feb 6 20:21:03 2006 @@ -176,15 +176,14 @@ defaultGoalplugins:site/defaultGoal /build reports -reportmaven-changelog-plugin/report -reportmaven-changes-plugin/report reportmaven-dashboard-plugin/report -reportmaven-developer-activity-plugin/report -reportmaven-faq-plugin/report +reportmaven-changelog-plugin/report reportmaven-file-activity-plugin/report -reportmaven-jdepend-plugin/report -reportmaven-linkcheck-plugin/report +reportmaven-developer-activity-plugin/report reportmaven-multichanges-plugin/report reportmaven-multiproject-plugin/report +reportmaven-faq-plugin/report +reportmaven-linkcheck-plugin/report +reportmaven-license-plugin/report /reports /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bringing plugins to Apache Maven
+1 (read and agree). Just make sure we have someone willing to keep them maintained to avoid the mess we have in m1 now. -Lukas Brett Porter wrote: This is not a vote. +1's here are just I've read and think it's all good, but generally I'm just looking for feedback on specific plugins and decision points before taking this any further forward. Some of the plugins that wound up in mojo seem better suited to the main Apache project due to a) originally coming from there b) having the core libraries located there c) being essential to the day to day use of the project. These are the ones I'm thinking of: - jxr report (relates to jxr) - surefire report (relates to surefire) - changes/jira/announcement report (relates to issue stuff in sandbox) - changelog report (relates to scm) - dependency-maven-plugin (sounds generally handy in eliminating a lot of small antrunning). The other ones I'm tossing up: - taglist (generally useful report, originally came from m1) I put out a call for opinions and while the relevant mojo people were in favour, some of the Maven developers were either on the fence or against it. However, I didn't really receive an answer to my responses to those concerns. As a community we need to decide where we are going to develop individual plugins. As I understand it, mojo.codehaus.org was established to: - develop things that can't be entirely under the ASL. - avoid developing plugins that rotted and tied due to lack of community in m1 - give a place for individual plugin developers to start out but still operate in the same way as the Maven community. It's always been my thought that plugins at maven.apache.org should be those used by 80% of Maven users or essential to its operation, and those that relate to the Maven subprojects themselves. Also, plugins in like groups should be kept together. So, time to bring it here and get everyone's feedback again. If you already had objections, please voice them again if they are still a concern. What do others think? Note that this would imply bringing in a couple of new committers, but they are people that have been generally helpful. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-121) Intermittent CVS test failures
[ http://jira.codehaus.org/browse/SCM-121?page=comments#action_58074 ] Mike Perham commented on SCM-121: - Weird. I wonder if it's a cygwin binary and your cygwin1.dll is different enough to not display the bad behavior we are seeing? Intermittent CVS test failures -- Key: SCM-121 URL: http://jira.codehaus.org/browse/SCM-121 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Versions: 1.0-beta-3 Reporter: Mike Perham Fix For: 1.0 Attachments: cvs.exe Dan and I continue to have test failures when trying to compile the cvs plugin in our environment. I emailed these problems to the scm-dev list about a week ago. -- 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
Re: svn commit: r375474 - /maven/maven-1/plugins/trunk/plugins-site/project.xml
you're right. No problem. Arnaud On 2/7/06, Lukas Theussl [EMAIL PROTECTED] wrote: Sorry, I just thought this order was more logical (changelog, file/dev-activity together, license in the end,...). I'll check the sandbox as well. -Lukas Arnaud HERITIER wrote: I just use the alphabetical order. Why this order ? It's for the order in the menu ? Be careful to apply the same chages in the sandbox when you modify a commons part of the build (plugins-parent, plugins-site ...) Arnaud On 2/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: ltheussl Date: Mon Feb 6 20:21:03 2006 New Revision: 375474 URL: http://svn.apache.org/viewcvs?rev=375474view=rev Log: Re-order reports, add license report Modified: maven/maven-1/plugins/trunk/plugins-site/project.xml Modified: maven/maven-1/plugins/trunk/plugins-site/project.xml URL: http://svn.apache.org/viewcvs/maven/maven-1/plugins/trunk/plugins-site/project.xml?rev=375474r1=375473r2=375474view=diff == --- maven/maven-1/plugins/trunk/plugins-site/project.xml (original) +++ maven/maven-1/plugins/trunk/plugins-site/project.xml Mon Feb 6 20:21:03 2006 @@ -176,15 +176,14 @@ defaultGoalplugins:site/defaultGoal /build reports -reportmaven-changelog-plugin/report -reportmaven-changes-plugin/report reportmaven-dashboard-plugin/report -reportmaven-developer-activity-plugin/report -reportmaven-faq-plugin/report +reportmaven-changelog-plugin/report reportmaven-file-activity-plugin/report -reportmaven-jdepend-plugin/report -reportmaven-linkcheck-plugin/report +reportmaven-developer-activity-plugin/report reportmaven-multichanges-plugin/report reportmaven-multiproject-plugin/report +reportmaven-faq-plugin/report +reportmaven-linkcheck-plugin/report +reportmaven-license-plugin/report /reports /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-121) Intermittent CVS test failures
[ http://jira.codehaus.org/browse/SCM-121?page=comments#action_58075 ] Emmanuel Venisse commented on SCM-121: -- Info about my cygwin1.dll: v ersion: 1005.19.0.0 Build date : 2006-01-20 13:28 Intermittent CVS test failures -- Key: SCM-121 URL: http://jira.codehaus.org/browse/SCM-121 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Versions: 1.0-beta-3 Reporter: Mike Perham Fix For: 1.0 Attachments: cvs.exe Dan and I continue to have test failures when trying to compile the cvs plugin in our environment. I emailed these problems to the scm-dev list about a week ago. -- 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: (MPDASHBOARD-28) Please sorth the report in alpha order
[ http://jira.codehaus.org/browse/MPDASHBOARD-28?page=comments#action_58076 ] Lukas Theussl commented on MPDASHBOARD-28: -- For the record: introduced maven.dashboard.sort and maven.dashboard.sort.property properties. Please sorth the report in alpha order -- Key: MPDASHBOARD-28 URL: http://jira.codehaus.org/browse/MPDASHBOARD-28 Project: maven-dashboard-plugin Type: Improvement Reporter: Jon Strayer Priority: Minor Fix For: 1.9 When you have a lot of projects on the dashbord report (and currently we have 34) the default sort makes it hard to find a specific 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCM-155) Perforce instance for maven-scm testing and continuum testing
Perforce instance for maven-scm testing and continuum testing - Key: SCM-155 URL: http://jira.codehaus.org/browse/SCM-155 Project: Maven SCM Type: Task Components: maven-scm-provider-perforce Reporter: Emmanuel Venisse - Install somewhere an instance of Perforce accessible for all of us - Add documentation about install/configuration - Add documentation about what we need on local machine for use it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (SCM-155) Perforce instance for maven-scm testing and continuum testing
[ http://jira.codehaus.org/browse/SCM-155?page=all ] Emmanuel Venisse reassigned SCM-155: Assign To: Mike Perham Perforce instance for maven-scm testing and continuum testing - Key: SCM-155 URL: http://jira.codehaus.org/browse/SCM-155 Project: Maven SCM Type: Task Components: maven-scm-provider-perforce Reporter: Emmanuel Venisse Assignee: Mike Perham - Install somewhere an instance of Perforce accessible for all of us - Add documentation about install/configuration - Add documentation about what we need on local machine for use it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
[
http://jira.codehaus.org/browse/MPCHECKSTYLE-53?page=comments#action_58077 ]
Lukas Theussl commented on MPCHECKSTYLE-53:
---
It's not a problem with checkstyle itself but with ant's style task that is
used to transform the results. Did you load the oracle dependency in the root
classloader? See http://maven.apache.org/maven-1.x/faq.html#BadXSLT
ClassCastException when moving from 2.5 to 3.0
--
Key: MPCHECKSTYLE-53
URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-53
Project: maven-checkstyle-plugin
Type: Bug
Versions: 3.0
Environment: Windows/Linux
Java 5.0
Maven 1.x
Reporter: Bernard Durfee
Fix For: 3.0.1
The error I get...
BUILD FAILED
File..
/home/cruisecontrol/.maven/cache/maven-checkstyle-plugin-3.0/plugin.jelly
Element... style
Line.. 238
Column 59
java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
...is usually caused when an application is specifically looking for Xerces
classes, instead of always going through JAXP interfaces and factories.
My application uses XSLT 2.0 features, which are not supported by
Xerces/Xalan. So I have a file in my JDK lib directory named
jaxp.properties...
{code}
# JAXP Factories
javax.xml.parsers.SAXParserFactory = oracle.xml.jaxp.JXSAXParserFactory
javax.xml.parsers.DocumentBuilderFactory =
oracle.xml.jaxp.JXDocumentBuilderFactory
javax.xml.transform.TransformerFactory =
oracle.xml.jaxp.JXSAXTransformerFactory
{code}
...which causes the JDK to default to the Oracle parser, which supports XSLT
2.0.
My hunch is that somewhere in the code the JAXP TransformerFactory is called,
which returns the Oracle object, but someone is assuming that the Xerces
object will be returned and are casting the object to get at some Xerces
specific feature.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCM-156) Add TCK tests for Perforce
Add TCK tests for Perforce -- Key: SCM-156 URL: http://jira.codehaus.org/browse/SCM-156 Project: Maven SCM Type: Task Components: maven-scm-provider-perforce Reporter: Emmanuel Venisse They'll be run only by developers that have Perforce installed -- 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] Assigned: (SCM-158) Add TCK tests for Starteam
[ http://jira.codehaus.org/browse/SCM-158?page=all ] Emmanuel Venisse reassigned SCM-158: Assign To: Dan Tran Add TCK tests for Starteam -- Key: SCM-158 URL: http://jira.codehaus.org/browse/SCM-158 Project: Maven SCM Type: Task Components: maven-scm-provider-starteam Reporter: Emmanuel Venisse Assignee: Dan Tran They'll be run only by developers that have Starteam installed -- 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-157) Add TCK tests for Clearcase
Add TCK tests for Clearcase --- Key: SCM-157 URL: http://jira.codehaus.org/browse/SCM-157 Project: Maven SCM Type: Task Components: maven-scm-provider-clearcase Reporter: Emmanuel Venisse They'll be run only by developers that have Clearcase installed. It will be great if we can have them for all type of Clearcase -- 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-158) Add TCK tests for Starteam
Add TCK tests for Starteam -- Key: SCM-158 URL: http://jira.codehaus.org/browse/SCM-158 Project: Maven SCM Type: Task Components: maven-scm-provider-starteam Reporter: Emmanuel Venisse They'll be run only by developers that have Starteam installed -- 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-1990) directoryPermissions is not repected when I deploy a POM
[ http://jira.codehaus.org/browse/MNG-1990?page=comments#action_58078 ] Erik van Zijst commented on MNG-1990: - I'm having the same problem and I'm afraid it's making it difficult cooperate on projects. directoryPermissions is not repected when I deploy a POM Key: MNG-1990 URL: http://jira.codehaus.org/browse/MNG-1990 Project: Maven 2 Type: Bug Environment: Debian Linux unstable, Sun JDK 1.5.0_06 Reporter: Trustin Lee Assignee: Brett Porter Fix For: 2.0.3 It seems like 'directoryPermissions' doesn't work at all though 'filePermissions' do. I tried both scp and scpexe. Nothing worked. I also changed my umask to 002, but it didn't help at all. If you have committership in the Apache Directory Project (Brett? :), then you can try it by yourself: svn co https://svn.apache.org/repos/asf/directory/trunks/ directory cd directory mvn --non-recursive deploy This is my ~/.m2/settings.xml ?xml version=1.0 encoding=UTF-8? settings servers server idapache.snapshots/id usernametrustin/username privateKey/home/trustin/.ssh/id_rsa/privateKey directoryPermissions0775/directoryPermissions filePermissions0664/filePermissions /server /servers /settings -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-29) test with CVS NT
[ http://jira.codehaus.org/browse/SCM-29?page=comments#action_58080 ] Dennis Lundberg commented on SCM-29: Running the command mentioned by Emmanuel in the previous comment works fine for me using CVSNT 2.0.51 on Windows XP. It produces the following results: U testCheckOutWithTag/src/java/org/apache/maven/MavenUtils.java test with CVS NT Key: SCM-29 URL: http://jira.codehaus.org/browse/SCM-29 Project: Maven SCM Type: Test Components: maven-scm-provider-cvs Reporter: Brett Porter Assignee: Emmanuel Venisse Fix For: 1.0-beta-3 Vincent reported test failures on CVS NT... test it and fix if required. -- 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-2049) Dependencies without POMs cause intermittent failures
Dependencies without POMs cause intermittent failures - Key: MNG-2049 URL: http://jira.codehaus.org/browse/MNG-2049 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0.2 Reporter: Matthew Beermann We have a number of jars in our repository that don't have POMs, e.g. third-party libraries, etc. Maven happily downloads the jar anyway, and issues a warning that there's no POM - except, sometimes, it just fails instead. See the build log below. If I were to rerun Maven again, it might fail on a different jar, or it might succeed. I can't seem to find any rhyme or reason to it... I agree that a missing POM merits a warning, but if the jar is there, it shouldn't be failing the build! Downloading: http://prdwebdev11/repository/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [WARNING] Unable to get resource from repository prdwebdev11 (http://prdwebdev11/repository) Downloading: http://repo1.maven.org/maven2/j2ee/j2ee/1.3.1/j2ee-1.3.1.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: j2ee:j2ee Reason: Error getting POM for 'j2ee:j2ee' from the repository: Error transferring file j2ee:j2ee:pom:1.3.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), prdwebdev11 (http://prdwebdev11/repository) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MRELEASE-79) Canoo webTest: please get latest version to facilitate downloading
Canoo webTest: please get latest version to facilitate downloading -- Key: MRELEASE-79 URL: http://jira.codehaus.org/browse/MRELEASE-79 Project: Maven 2.x Release Plugin Type: Improvement Reporter: Annette Cass webTest's most recent build is: Release class = 1.7, build number = R_1167 I would VERY MUCH appreciate it if you could get the most recent version to allow downloading from your site (http://maven-plugins.sourceforge.net). Thanks. Annette Cass -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-722) Update Tapestry 4.0 POM at ibiblio to reflect proper dependencies
[ http://jira.codehaus.org/browse/MAVENUPLOAD-722?page=comments#action_58081 ] Carlos Sanchez commented on MAVENUPLOAD-722: thanks for pointing that out. It'll be fxed in a few hours Update Tapestry 4.0 POM at ibiblio to reflect proper dependencies - Key: MAVENUPLOAD-722 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-722 Project: maven-upload-requests Type: Task Reporter: Matt Raible Assignee: Carlos Sanchez The current Tapestry 4.0 POM at ibiblio has no dependencies specifies. This upload bundle contains a pom.xml with the dependencies specified. This could be a duplicate of MEV-303, but that one doesn't seem to have taken effect yet (and it was marked fixed 2 weeks ago). http://issues.apache.org/jira/browse/TAPESTRY-857 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-29) test with CVS NT
[ http://jira.codehaus.org/browse/SCM-29?page=comments#action_58082 ] Emmanuel Venisse commented on SCM-29: - Hmm, doesn't work with CVSNT 2.5.03 (downloaded today). What is the correct version? what is the non bugged version? Your version get the same result than linux cvs. I'd be +1 to remove my test on cvsnt in checkout command and i'm not sure a numeric tag is used by users because it can checkout only one file. WDYT? test with CVS NT Key: SCM-29 URL: http://jira.codehaus.org/browse/SCM-29 Project: Maven SCM Type: Test Components: maven-scm-provider-cvs Reporter: Brett Porter Assignee: Emmanuel Venisse Fix For: 1.0-beta-3 Vincent reported test failures on CVS NT... test it and fix if required. -- 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: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
[
http://jira.codehaus.org/browse/MPCHECKSTYLE-53?page=comments#action_58083 ]
Bernard Durfee commented on MPCHECKSTYLE-53:
Actually, I think there is a change that should be made in the plugin.jelly
file, before executing the Ant 'style' task (line 235), there should be a line
line...
{code}
${systemScope.setProperty('javax.xml.transform.TransformerFactory','org.apache.xalan.processor.TransformerFactoryImpl')}
{code}
...which will change the system property to make sure JAXP returns the Xalan
transformer factory to Ant, because the style tag requires Xalan
specifically. I made the change locally and it works fine.
Also, maybe you'll need to add Xalan as a dependency for the plugin, since it
uses the Ant style tag, which requires Xalan. Really this is an Ant problem,
since it should use only standard JAXP methods. But since it requires Xalan,
now so does the CheckStyle Plugin.
ClassCastException when moving from 2.5 to 3.0
--
Key: MPCHECKSTYLE-53
URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-53
Project: maven-checkstyle-plugin
Type: Bug
Versions: 3.0
Environment: Windows/Linux
Java 5.0
Maven 1.x
Reporter: Bernard Durfee
Fix For: 3.0.1
The error I get...
BUILD FAILED
File..
/home/cruisecontrol/.maven/cache/maven-checkstyle-plugin-3.0/plugin.jelly
Element... style
Line.. 238
Column 59
java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
...is usually caused when an application is specifically looking for Xerces
classes, instead of always going through JAXP interfaces and factories.
My application uses XSLT 2.0 features, which are not supported by
Xerces/Xalan. So I have a file in my JDK lib directory named
jaxp.properties...
{code}
# JAXP Factories
javax.xml.parsers.SAXParserFactory = oracle.xml.jaxp.JXSAXParserFactory
javax.xml.parsers.DocumentBuilderFactory =
oracle.xml.jaxp.JXDocumentBuilderFactory
javax.xml.transform.TransformerFactory =
oracle.xml.jaxp.JXSAXTransformerFactory
{code}
...which causes the JDK to default to the Oracle parser, which supports XSLT
2.0.
My hunch is that somewhere in the code the JAXP TransformerFactory is called,
which returns the Oracle object, but someone is assuming that the Xerces
object will be returned and are casting the object to get at some Xerces
specific feature.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-724) new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.6.7
new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.6.7 -- Key: MAVENUPLOAD-724 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-724 Project: maven-upload-requests Type: Task Reporter: Michael Heuer The Tango Desktop Project exists to create a consistent user experience for free and Open Source software with graphical user interfaces. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCM-121) Intermittent CVS test failures
[ http://jira.codehaus.org/browse/SCM-121?page=comments#action_58084 ] Mike Perham commented on SCM-121: - I checked and it looks like that binary is static. So I have no idea why it's not working. I'm out of ideas. Intermittent CVS test failures -- Key: SCM-121 URL: http://jira.codehaus.org/browse/SCM-121 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Versions: 1.0-beta-3 Reporter: Mike Perham Fix For: 1.0 Attachments: cvs.exe Dan and I continue to have test failures when trying to compile the cvs plugin in our environment. I emailed these problems to the scm-dev list about a week ago. -- 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: (SCM-29) test with CVS NT
[ http://jira.codehaus.org/browse/SCM-29?page=comments#action_58085 ] Dennis Lundberg commented on SCM-29: Some reading in the Cederqvist http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_17.html#SEC157 http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_16.html#SEC117 http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48 My conclusion from the references above is that you are not allowed to use . character in the value for the -r option in a checkout command. test with CVS NT Key: SCM-29 URL: http://jira.codehaus.org/browse/SCM-29 Project: Maven SCM Type: Test Components: maven-scm-provider-cvs Reporter: Brett Porter Assignee: Emmanuel Venisse Fix For: 1.0-beta-3 Vincent reported test failures on CVS NT... test it and fix if required. -- 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: (MPIR-25) Text/caption for table in dependencies report should be left-justified like text in other reports
Text/caption for table in dependencies report should be left-justified like text in other reports - Key: MPIR-25 URL: http://jira.codehaus.org/browse/MPIR-25 Project: Maven 2.x Project Info Reports Plugin Type: Improvement Versions: 2.0-beta-3 Environment: Windows/XP, Maven 2.0.2, Maven Quick Start Archetype as sample project Reporter: Chris Markle Priority: Trivial Attachments: dependencies.html Nit but... In the dependencies report, the text (table caption?) under Project Dependencies which is The following is a list of dependencies for this project. These dependencies are required to compile and run the application: (right above the table of dependencies is centered as opposed to being left-justified. All other project info reports have siilar text left-justified so I would argue that this is an inconsistency (and just plain looks bad). I was able to reproduce this just using the Maven Quick Start Archetype and building the site goal. I will attach the resulting dependencies.html. I assume that you must have at least one dependency (yielding a table) before this is seen. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
[
http://jira.codehaus.org/browse/MPCHECKSTYLE-53?page=comments#action_58086 ]
Lukas Theussl commented on MPCHECKSTYLE-53:
---
I have deployed a new snapshot, please test:
maven plugin:download
-Dmaven.repo.remote=http://www.ibiblio.org/maven,http://cvs.apache.org/repository/
-DgroupId=maven -DartifactId=maven-checkstyle-plugin -Dversion=3.0.1-SNAPSHOT
Thanks!
ClassCastException when moving from 2.5 to 3.0
--
Key: MPCHECKSTYLE-53
URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-53
Project: maven-checkstyle-plugin
Type: Bug
Versions: 3.0
Environment: Windows/Linux
Java 5.0
Maven 1.x
Reporter: Bernard Durfee
Fix For: 3.0.1
The error I get...
BUILD FAILED
File..
/home/cruisecontrol/.maven/cache/maven-checkstyle-plugin-3.0/plugin.jelly
Element... style
Line.. 238
Column 59
java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
...is usually caused when an application is specifically looking for Xerces
classes, instead of always going through JAXP interfaces and factories.
My application uses XSLT 2.0 features, which are not supported by
Xerces/Xalan. So I have a file in my JDK lib directory named
jaxp.properties...
{code}
# JAXP Factories
javax.xml.parsers.SAXParserFactory = oracle.xml.jaxp.JXSAXParserFactory
javax.xml.parsers.DocumentBuilderFactory =
oracle.xml.jaxp.JXDocumentBuilderFactory
javax.xml.transform.TransformerFactory =
oracle.xml.jaxp.JXSAXTransformerFactory
{code}
...which causes the JDK to default to the Oracle parser, which supports XSLT
2.0.
My hunch is that somewhere in the code the JAXP TransformerFactory is called,
which returns the Oracle object, but someone is assuming that the Xerces
object will be returned and are casting the object to get at some Xerces
specific feature.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-2050) Classloader.getResource() doesn't encode blanks
Classloader.getResource() doesn't encode blanks --- Key: MNG-2050 URL: http://jira.codehaus.org/browse/MNG-2050 Project: Maven 2 Type: Bug Components: General Versions: 2.0.1 Environment: win xp Reporter: Roland Kofler When I'm executing an getClass().getClassLoader().getResource(s); it gives back an URL encoded string in eclipse while Maven2 gives me blanks in my URL: * eclipse file:/C:/Dokumente%20und%20Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg *maven2 file:/C:/Dokumente und Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg MY PROBLEM WITH THIS: Because of this behaviour a new URI(file:/C:/Dokumente und Einstellungen/roland.kofler/systemone/core/target/test-classes/fsm.jpg) throws a URISyntaxException. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-724) new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.6.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-724?page=all ] Carlos Sanchez closed MAVENUPLOAD-724: -- Assign To: Carlos Sanchez Resolution: Fixed new version to upload, groupId=org.tango-project artifactId=tango-icon-theme version=0.6.7 -- Key: MAVENUPLOAD-724 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-724 Project: maven-upload-requests Type: Task Reporter: Michael Heuer Assignee: Carlos Sanchez The Tango Desktop Project exists to create a consistent user experience for free and Open Source software with graphical user interfaces. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-707) Glazedlists 1.5.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-707?page=all ] Carlos Sanchez closed MAVENUPLOAD-707: -- Assign To: Carlos Sanchez Resolution: Fixed Glazedlists 1.5.0 - Key: MAVENUPLOAD-707 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-707 Project: maven-upload-requests Type: Task Reporter: Geoffrey De Smet Assignee: Carlos Sanchez Attachments: pom.xml JTable with sorting filtering, used in spring-rich and many Swing applications. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-717) Databinder 0.2 with sources
[ http://jira.codehaus.org/browse/MAVENUPLOAD-717?page=all ] Carlos Sanchez closed MAVENUPLOAD-717: -- Resolution: Fixed Databinder 0.2 with sources --- Key: MAVENUPLOAD-717 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-717 Project: maven-upload-requests Type: Task Reporter: Nathan Hamblen Assignee: Carlos Sanchez Please upload databinder-0.2 with sources, and also this archetype update: http://databinder.net/releases/data-app-0.2-bundle.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bringing plugins to Apache Maven
+1, especially for changes/jira and announcement stuff. On 2/7/06, Brett Porter [EMAIL PROTECTED] wrote: This is not a vote. +1's here are just I've read and think it's all good, but generally I'm just looking for feedback on specific plugins and decision points before taking this any further forward. Some of the plugins that wound up in mojo seem better suited to the main Apache project due to a) originally coming from there b) having the core libraries located there c) being essential to the day to day use of the project. These are the ones I'm thinking of: - jxr report (relates to jxr) - surefire report (relates to surefire) - changes/jira/announcement report (relates to issue stuff in sandbox) - changelog report (relates to scm) - dependency-maven-plugin (sounds generally handy in eliminating a lot of small antrunning). The other ones I'm tossing up: - taglist (generally useful report, originally came from m1) I put out a call for opinions and while the relevant mojo people were in favour, some of the Maven developers were either on the fence or against it. However, I didn't really receive an answer to my responses to those concerns. As a community we need to decide where we are going to develop individual plugins. As I understand it, mojo.codehaus.org was established to: - develop things that can't be entirely under the ASL. - avoid developing plugins that rotted and tied due to lack of community in m1 - give a place for individual plugin developers to start out but still operate in the same way as the Maven community. It's always been my thought that plugins at maven.apache.org should be those used by 80% of Maven users or essential to its operation, and those that relate to the Maven subprojects themselves. Also, plugins in like groups should be kept together. So, time to bring it here and get everyone's feedback again. If you already had objections, please voice them again if they are still a concern. What do others think? Note that this would imply bringing in a couple of new committers, but they are people that have been generally helpful. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-721) Upload Javassist 3.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-721?page=all ] Carlos Sanchez closed MAVENUPLOAD-721: -- Assign To: Carlos Sanchez Resolution: Fixed Moved javassist versions from javassist group to jboss group, please use jboss group Upload Javassist 3.0 Key: MAVENUPLOAD-721 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-721 Project: maven-upload-requests Type: Task Reporter: Matt Raible Assignee: Carlos Sanchez Please upload javassist 3.0 to ibiblio - Tapestry 4.0 depends on this JAR being available. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-723) Upload JOTM 2.0.10 with pom specifying dependencies, as well as new groupId (org.objectweb)
[ http://jira.codehaus.org/browse/MAVENUPLOAD-723?page=comments#action_58091 ] Carlos Sanchez commented on MAVENUPLOAD-723: Several comments: - groupid for carol should be org.objectweb.carol. Fixed and uploaded. - howl is already in groupId howl, so we'll keep it there until we have resources to relocate it. - not uploading howl 1.0 as pom is empty, while pom for previous version has more info. - jotm already in jotm groupid, so keeping there, I'll take a look to use your poms Upload JOTM 2.0.10 with pom specifying dependencies, as well as new groupId (org.objectweb) --- Key: MAVENUPLOAD-723 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-723 Project: maven-upload-requests Type: Task Reporter: Matt Raible In addition, this bundle requires a number of other bundles be uploaded. Carol and Howl are both ObjectWeb projects that I renamed the groupId for (to org.objectweb). http://static.raibledesigns.com/downloads/carol-2.0.5-bundle.jar http://static.raibledesigns.com/downloads/howl-0.1.11-bundle.jar Since Howl 1.0 has been released, I created a bundle for that as well: http://static.raibledesigns.com/downloads/howl-1.0-bundle.jar I don't know if this is the correct way to package the IIOP and JRMP Stubs - but it seemed logical. Maybe their groupId should be org.objectweb.jotm instead? http://static.raibledesigns.com/downloads/jotm-iiop-stubs-2.0.10-bundle.jar http://static.raibledesigns.com/downloads/jotm-jrmp-stubs-2.0.10-bundle.jar In order to use JOTM in my pom.xml - I'm using the following. The Geronimo JARs allows users to have a seemless downloading experience: dependency groupIdorg.objectweb/groupId artifactIdjotm/artifactId version2.0.10/version exclusions exclusion groupIdjavax.resource/groupId artifactIdconnector/artifactId /exclusion exclusion groupIdjavax.transaction/groupId artifactIdjta/artifactId /exclusion /exclusions /dependency dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-jta/artifactId version1.0.1B-rc4/version /dependency dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-j2ee-connector/artifactId version1.5-rc4/version /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Tue Feb 7 19:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060207.193001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060207.193001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPCHECKSTYLE-53) ClassCastException when moving from 2.5 to 3.0
[
http://jira.codehaus.org/browse/MPCHECKSTYLE-53?page=comments#action_58092 ]
Bernard Durfee commented on MPCHECKSTYLE-53:
Yep, that worked. Although my personal preference is to use the latest version
of stuff like Xalan, which is 2.7.0. I don't know if it matters much though.
ClassCastException when moving from 2.5 to 3.0
--
Key: MPCHECKSTYLE-53
URL: http://jira.codehaus.org/browse/MPCHECKSTYLE-53
Project: maven-checkstyle-plugin
Type: Bug
Versions: 3.0
Environment: Windows/Linux
Java 5.0
Maven 1.x
Reporter: Bernard Durfee
Fix For: 3.0.1
The error I get...
BUILD FAILED
File..
/home/cruisecontrol/.maven/cache/maven-checkstyle-plugin-3.0/plugin.jelly
Element... style
Line.. 238
Column 59
java.lang.ClassCastException:
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
...is usually caused when an application is specifically looking for Xerces
classes, instead of always going through JAXP interfaces and factories.
My application uses XSLT 2.0 features, which are not supported by
Xerces/Xalan. So I have a file in my JDK lib directory named
jaxp.properties...
{code}
# JAXP Factories
javax.xml.parsers.SAXParserFactory = oracle.xml.jaxp.JXSAXParserFactory
javax.xml.parsers.DocumentBuilderFactory =
oracle.xml.jaxp.JXDocumentBuilderFactory
javax.xml.transform.TransformerFactory =
oracle.xml.jaxp.JXSAXTransformerFactory
{code}
...which causes the JDK to default to the Oracle parser, which supports XSLT
2.0.
My hunch is that somewhere in the code the JAXP TransformerFactory is called,
which returns the Oracle object, but someone is assuming that the Xerces
object will be returned and are casting the object to get at some Xerces
specific feature.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M1] Status of 1.1 release
Arnaud, I'm trying to produce a failing test for MAVEN-1549 using maven 1.0.2. Unfortunately, like Bretts comment to MAVEN-1321 (which 1549 duplicates), I'm unable to reproduce the problem. I'll poke at it some more, but if I can't reproduce it, I'll have nothing to add to the touchstone tests. Doug Arnaud HERITIER wrote: Hi Doug, Thanks a lot for your help. Your testcases are very useful for us to close the issues. Can you try (when possible) to create your tests in the touchstone-build : http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/src/test/touchstone-build/src/reactor-build/ It will help us to ensure that these issues never come back. For example for the issue MAVEN-1691 I created a testcase : http://svn.apache.org/viewcvs.cgi/maven/maven-1/core/trunk/src/test/touchstone-build/src/reactor-build/overlappedCalls/ When this issue will be fix, I'll activate it. What you need to do it's to automate your test to fail if the issue exists. Can you try to do it for example for MAVEN-1549 ? Thanks Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
