Re: Maven parsing pom.xml incorrectly
This mailing list is used only for automated responses from our issue tracker. Please use us...@maven.apache.org instead. On Tue, Sep 17, 2013 at 6:55 PM, Andrew Pennebaker apenneba...@42six.com wrote: I'm using Thrift in my Maven project, compiling my .thrift code to .java as part of the generate-sources step. To do this, I use the maven antrun plugin in my pom.xml, which executes a command line call to the thrift executable, and sends it the appropriate argument flags, such as -out and --gen. However, when I comment out this plugin with the standard XML comment syntax !-- ... --, Maven fails to parse the pom file. It doesn't like the fact that the comment contains --gen, expecting the comment to end right there. Can we please improve Maven's comment syntax parsing for pom.xml? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven parsing pom.xml incorrectly
Hi Andrew: Unfortunately, that's in the XML spec, not Maven. '--' is not permitted in comments. I'm not aware of any workaround, though I'd be interested to hear one. Putting the line that contains the offending '--' does not work. Sorry, Greg. On Wed, 2013-09-18 at 04:59, Dennis Lundberg wrote: This mailing list is used only for automated responses from our issue tracker. Please use us...@maven.apache.org instead. On Tue, Sep 17, 2013 at 6:55 PM, Andrew Pennebaker apenneba...@42six.com wrote: I'm using Thrift in my Maven project, compiling my .thrift code to .java as part of the generate-sources step. To do this, I use the maven antrun plugin in my pom.xml, which executes a command line call to the thrift executable, and sends it the appropriate argument flags, such as -out and --gen. However, when I comment out this plugin with the standard XML comment syntax !-- ... --, Maven fails to parse the pom file. It doesn't like the fact that the comment contains --gen, expecting the comment to end right there. Can we please improve Maven's comment syntax parsing for pom.xml? -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
+1 (non-binding), installed this as default Maven 3 on a Jenkins installation and after upping maven-site-plugin from 3.0 to 3.3 in some projects, around 20 projects (Mostly maven and Jenkins plugin) were successfully running mvn clean install site (@Stephen: even with Jenkins' Maven job type!) I also checked the SHA1 of the src.zip at the staging repository is 2251357aa47129674df578e787504b72cd57ed4d, the SHA1 from the binary (mvn -v) reports 0728685237757ffbf44136acec0402957f723d9a which is the prepare commit of the release-plugin. Regards Mirko Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Tue, Sep 17, 2013 at 5:39 PM, Jason van Zyl ja...@tesla.io wrote: Hi, Maven Core ITs are good, and the license/notice issue has been resolved so I'm rolling 3.1.1 again. Here is a link to Jira with 6 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968 Staging repo: https://repository.apache.org/content/repositories/maven-065/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz Source release checksum(s): apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d Staging site: http://people.apache.org/~jvanzyl/maven-3.1.1/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, The Maven Team Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-wagon pull request: Wagon HTTP upgraded to HttpClient 4.3
GitHub user ok2c opened a pull request: https://github.com/apache/maven-wagon/pull/3 Wagon HTTP upgraded to HttpClient 4.3 Upgrades Apache HttpClient used by HTTP wagon to version 4.3 http://jira.codehaus.org/browse/WAGON-402 You can merge this pull request into a Git repository by running: $ git pull https://github.com/ok2c/maven-wagon httpclient-4.3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-wagon/pull/3.patch - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Remote Resources Plugin issue
I noticed while building on the plane today that I get this issue with the remote-resources-plugin: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (default) on project apache-maven: Error rendering velocity resource. Invocation of method 'getResourceAsFile' in class org.codehaus.plexus.resource.DefaultResourceManager threw exception org.codehaus.plexus.resource.loader.ResourceNotFoundException: Could not find resource 'https://glassfish.java.net/public/CDDLv1.0.html'. at remote-resources[line 40, column 26] - [Help 1] This is not an issue with version 1.4. Anyone know what might be causing this and how to fix it before I go looking. This is a bad regression as it prevents builds from completing where you are not connected to the internet even if you have a local repository manager running. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
RE: bug in parsing file ... comments
Hi Brian, From the XML specification, specifically the section dealing with comments (http://www.w3.org/TR/REC-xml/#sec-comments), what you have below is not a viable XML file: - 2.5 Comments [Definition: Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar. They are not part of the document's character data; an XML processor may, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string -- (double-hyphen) must not occur within comments.] Parameter entity references must not be recognized within comments. - So I doubt there is any way that maven can provide a fix that will suit your needs as any changes they make would cause their XML parser to be non-conformant to the XML specification. Given the specific case you were targeting with your request, perhaps change --gen to ==gen with note at the start of the comment along the lines of all instances of == within this comment must be changed to -- when uncommenting. Hope this helps, Dan -Original Message- From: Brian Withnell [mailto:bwithn...@42six.com] Sent: Tuesday, September 17, 2013 2:46 PM To: iss...@maven.apache.org Subject: bug in parsing file ... comments We ran into a parsing bug that prevents commenting out an option with a command line for maven. We tried commenting out (for testing purposes) the following plugin, which contains the thrift --gen command. The --gen caused a parse error in the file (looks like it thinks it needs to have -- because it is in a comment rather than -- as the only thing that matters. It would be *great* if it allowed nesting of comments, but I'll take that it just doesn't barf on valid command structures. Because the following is a comment, you *should* be able to paste it into any pom file and have maven process the file properly. !-- plugin artifactIdmaven-compiler-plugin/artifactId version3.1/version configuration source1.6/source target1.6/target /configuration /plugin -- !-- plugin artifactIdmaven-antrun-plugin/artifactId executions execution idgenerate-sources/id phasegenerate-sources/phase configuration tasks mkdir dir=target/generated-sources/ / apply executable=/usr/local/bin/thrift parallel=false the line below in a comment causes problems: arg value=--gen / arg value=java / arg value=-out / arg value=target/generated-sources/ / fileset dir=src/ include name=*.thrift / /fileset /apply /tasks /configuration goals goalrun/goal /goals /execution /executions /plugin -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven parsing pom.xml incorrectly
Thanks. Makes sense. On Sep 18, 2013 12:08 PM, Dan Taylor dan.tay...@merge.com wrote: Hi Andrew, From the XML specification, specifically the section dealing with comments (http://www.w3.org/TR/REC-xml/#sec-comments), what you have below is not a viable XML file: - 2.5 Comments [Definition: Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar. They are not part of the document's character data; an XML processor may, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string -- (double-hyphen) must not occur within comments.] Parameter entity references must not be recognized within comments. - So I doubt there is any way that maven can provide a fix that will suit your needs as any changes they make would cause their XML parser to be non-conformant to the XML specification. Given the specific case you were targeting with your request, perhaps change --gen to ==gen with note at the start of the comment along the lines of all instances of == within this comment must be changed to -- when uncommenting. Hope this helps, Dan -Original Message- From: Andrew Pennebaker [mailto:apenneba...@42six.com] Sent: Tuesday, September 17, 2013 12:55 PM To: Maven Issues Subject: Maven parsing pom.xml incorrectly I'm using Thrift in my Maven project, compiling my .thrift code to .java as part of the generate-sources step. To do this, I use the maven antrun plugin in my pom.xml, which executes a command line call to the thrift executable, and sends it the appropriate argument flags, such as -out and --gen. However, when I comment out this plugin with the standard XML comment syntax !-- ... --, Maven fails to parse the pom file. It doesn't like the fact that the comment contains --gen, expecting the comment to end right there. Can we please improve Maven's comment syntax parsing for pom.xml?
RE: Maven parsing pom.xml incorrectly
Hi Andrew, From the XML specification, specifically the section dealing with comments (http://www.w3.org/TR/REC-xml/#sec-comments), what you have below is not a viable XML file: - 2.5 Comments [Definition: Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document type declaration at places allowed by the grammar. They are not part of the document's character data; an XML processor may, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string -- (double-hyphen) must not occur within comments.] Parameter entity references must not be recognized within comments. - So I doubt there is any way that maven can provide a fix that will suit your needs as any changes they make would cause their XML parser to be non-conformant to the XML specification. Given the specific case you were targeting with your request, perhaps change --gen to ==gen with note at the start of the comment along the lines of all instances of == within this comment must be changed to -- when uncommenting. Hope this helps, Dan -Original Message- From: Andrew Pennebaker [mailto:apenneba...@42six.com] Sent: Tuesday, September 17, 2013 12:55 PM To: Maven Issues Subject: Maven parsing pom.xml incorrectly I'm using Thrift in my Maven project, compiling my .thrift code to .java as part of the generate-sources step. To do this, I use the maven antrun plugin in my pom.xml, which executes a command line call to the thrift executable, and sends it the appropriate argument flags, such as -out and --gen. However, when I comment out this plugin with the standard XML comment syntax !-- ... --, Maven fails to parse the pom file. It doesn't like the fact that the comment contains --gen, expecting the comment to end right there. Can we please improve Maven's comment syntax parsing for pom.xml? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Remote Resources Plugin issue
On Sep 18, 2013, at 2:04 PM, Jason van Zyl ja...@tesla.io wrote: I noticed while building on the plane today that I get this issue with the remote-resources-plugin: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (default) on project apache-maven: Error rendering velocity resource. Invocation of method 'getResourceAsFile' in class org.codehaus.plexus.resource.DefaultResourceManager threw exception org.codehaus.plexus.resource.loader.ResourceNotFoundException: Could not find resource 'https://glassfish.java.net/public/CDDLv1.0.html'. at remote-resources[line 40, column 26] - [Help 1] This is not an issue with version 1.4. Anyone know what might be causing this and how to fix it before I go looking. This is a bad regression as it prevents builds from completing where you are not connected to the internet even if you have a local repository manager running. This would only be with the main Maven build. We HAVE to have the full text for all the licenses available in the binary distribution. Thus, in apache-maven/src/main/appended-resources/META-INF/LICENSE.vm you will see it uses the URL's from the dependent poms to download the various licenses. Eventually, I wanted to get it updated to store the licenses in the .m2/repository someplace, but didn't have the time to pursue that. Feel free to tackle it. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven 3.1.1
If you can reproduce it in a stand-alone example I can track it down. Or if it's an OSS project I'll take a look. On Sep 18, 2013, at 5:45 PM, Mark Derricutt m...@talios.com wrote: Maybe a -1 here, not sure. I was about to +1 this from basic builds/releases, but then needed to run some integration tests locally and hit the following issue, strangely - this also occurs using 3.1.0 AND 3.0.5, but only on my machine. So I'm suspecting something strange in my .m2 maybe… I'm seeing Aether fall into an endless loop that: On our integration tests I'm seeing this lock solid: main prio=5 tid=0x7fc1dc801800 nid=0x1903 runnable [0x00010b458000] java.lang.Thread.State: RUNNABLE at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329) at
Re: [VOTE] Release Maven 3.1.1
On 19/09/2013, at 1:09 PM, Jason van Zyl ja...@tesla.io wrote: If you can reproduce it in a stand-alone example I can track it down. Or if it's an OSS project I'll take a look. Sadly not unfortunately - 3.1.1 seems to work flawlessly fine for our main artefacts and any OSS projects I have, but something in our integration tests is tripping it up, -X doesn't give me anything useful either. Since I'm seeing this on 3.0.5/3.0.1 as well as 3.1.1 I don't think this should prevent a release assuming nothing else crops up. I'll see if I can nail it down a bit and step thru the code and try figure it out. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [VOTE] Release Maven 3.1.1
I didn't have time to test this release for the moment but I updated a few days ago Maven core release instructions [1] to stage core reference documentation: http://maven.apache.org/ref/3-LATEST/ Actual state is the staging from previous release vote: it should be updated from actual tag, but I don't have time for the moment Please take a few minutes to run the commands from your release directory. Regards, Hervé [1] http://maven.apache.org/developers/release/maven-core-release.html#Stage_the_Latest_Documentation Le mardi 17 septembre 2013 11:39:17 Jason van Zyl a écrit : Hi, Maven Core ITs are good, and the license/notice issue has been resolved so I'm rolling 3.1.1 again. Here is a link to Jira with 6 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18 968 Staging repo: https://repository.apache.org/content/repositories/maven-065/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-065/org/apache/mave n/apache-maven/3.1.1/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-065/org/apache/mave n/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip https://repository.apache.org/content/repositories/maven-065/org/apache/mav en/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz https://repository.apache.org/content/repositories/maven-065/org/apache/mav en/apache-maven/3.1.1/apache-maven-3.1.1-src.zip https://repository.apache.org/content/repositories/maven-065/org/apache/mav en/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz Source release checksum(s): apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d Staging site: http://people.apache.org/~jvanzyl/maven-3.1.1/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, The Maven Team Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
