[
http://jira.codehaus.org/browse/MNG-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98073
]
Alan D. Salewski commented on MNG-2399:
---------------------------------------
Well, one reason for reading the pom from a named pipe is that it facilitates
using '{{mvn}}' from within shell scripts for performing tasks that leverage
built\-in maven capabilities. For example, the attached '{{mvn\-get\-plugin}}'
script retrieves and installs one or more maven plugins using a shell "here"
document for the POM:
{noformat}
...
mvn --file /dev/stdin validate <<EOF
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>foo.bar.baz</groupId>
<artifactId>fooshizzle</artifactId>
<name>Dummy Project for Retrieving and Installing ${plugin_name}</name>
<version>does-not-matter</version>
<build>
<plugins>
<plugin>
<groupId>${plugin_group_id}</groupId>
<artifactId>${plugin_name}</artifactId>
${plugin_version_elem}
</plugin>
</plugins>
</build>
</project>
EOF
...
{noformat}
It does this without creating any temporary files, which simplifies the program
(there are no temporary file security bugs to worry about; there is no
temporary directory to clean up when the program ends or when a signal is
received, etc).
More generally, though, not fixing the issue leaves an arbitrary limitation in
the program, and violates the principle of least surprise (encountering an
error when attempting to specify '{{/dev/stdin}}' as an argument to the
'{{\-\-file}}' option is what lead me to investigate the issue in the first
place). One of the strengths of unix command line tools is that they are of
general use and expected to be used in combination with other tools, even in
ways that their original authors did not foresee. There is no benefit of
leaving this easily addressed issue in maven, only an arbitrary limitation.
Some examples:
{noformat}
$ make -f /dev/stdin <<EOF
> all:
> @echo "hello from stdin"
> EOF
hello from stdin
$ ant -buildfile /dev/stdin <<EOF
> <project><echo>hello from stdin</echo></project>
> EOF
Buildfile: /dev/stdin
[echo] hello from stdin
BUILD SUCCESSFUL
Total time: 0 seconds
{noformat}
And in case it gives anyone a warm and fuzzy, over the past year I've run maven
2.0.4, 2.0.5, and now 2.0.6 with the originally attached (simple) patch without
any problems.
> file size check on pom.xml (or thing specified by --file opt) should only
> apply to regular files (patch attached)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: MNG-2399
> URL: http://jira.codehaus.org/browse/MNG-2399
> Project: Maven 2
> Issue Type: Bug
> Components: Command Line, General
> Affects Versions: 2.0.4
> Reporter: Alan D. Salewski
> Priority: Minor
> Fix For: 2.0.x
>
> Attachments: MNG-2399-maven-core-2.0.4.patch,
> MNG-2399-maven-core-trunk.patch, mvn-get-plugin
>
>
> The file size check in {{maven-core/.../org/apache/maven/DefaultMaven.java}}
> is applied too aggressively. In particular, it should only be applied to
> regular files; when reading from a unix named pipe (probably other
> platform-specific devices, too) we may not be able to determine the file size
> prior to reading the data.
> The real-world motiviation from this is the attached '{{mvn-get-plugin}}'
> {{bash}} script, which wants to pipe a dummy {{pom.xml}} file to {{mvn}} on
> {{stdin}} (by specifying {{/dev/stdin}} as the argument to the {{mvn}}
> {{\-\-file}} command line option).
> Once I submit this issue and have the issue number, I'll attach two patches,
> one against the maven svn trunk, and one against the {{maven-2.0.4}} tag.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
