I agree with Robert. I'm not necessarily totally opposed to adding this to the plugin, but I would only support it if it was turned on via a configuration and the default of that config would need to be FALSE.
Otherwise we'd just as quickly have people running here complaining about the exec-m-p changing their text in ways they didn't want and didn't specify. Wayne On 12/7/11, Robert Scholte <[email protected]> wrote: > > Which IDE are you using?What does your config look like?At least create a > jira-issue with a patch, but right now I don't think we should add it, just > because IDE thinks to be smart. -Robert > > ---------------------------------------- >> From: [email protected] >> Date: Wed, 7 Dec 2011 06:56:21 +0000 >> To: [email protected] >> Subject: [mojo-dev] exec-maven-plugin: Un-wanted line endings in >> environmentVariables >> >> Hi, >> >> I'm using exec-maven-plugin to run an external script which needs >> environment variables setting (specifically a path). >> >> Everything works fine until my IDE decides (not un-reasonably) that the >> length path I've specified ought to be wrapped at 80 chars and indented >> nicely. >> >> At this point; the environment variable that I've defined has newlines >> added to it and hence the path is corrupt. >> >> I have checked out the source for 1.2.1 and added some code to >> ExecMojo.java which will remove the newlines (and extra whitespace) that's >> added and it now works correctly. >> >> However; I realise that it's possible that there may be use-cases where >> whitespace is wanted. Everyone seems comfortable that XML shouldn't care >> about line-breaks / formatting within a body of text, but adherence to >> that means that these use-cases won't be supported. >> >> I've tried using a CDATA block for the value of a multi-line environment >> variable; this is passed through but is a java.lang.String with >> line-endings in exactly the same way as the non-multi-line, wrapped >> use-case so this can't be used to differentiate. >> >> Before I go further into thinking about how this use case might be catered >> for, it would be good to know if there really is a multi-line use case - >> or whether I'm just imagining it! >> >> I'll go ahead and commit my change to remove the extraneous line-endings >> and I'll be interested to hear opinions on the multi-line use case. >> >> Zuhayr Khan >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
