This may overlap with other Windows parameterization bugs but I did not see it described exactly.

Steps to reproduce:
1. Create a build with a simple ant file to just echo "Hello World" or whatever.
2. Add a string parameter to the job called TEST_PARAM.
3. Build with nothing in the parameter (empty string) - build succeeds (but note that -DTEST_PARAM="" is being passed to the ant cmd
4. Build again typing "foo" as the parameter - succeeds (but note that -DTEST_PARAM=foo is being passed to the ant cmd)
5. (THE BUG) Build again setting "foo=bar" as the parameter value. You might want to do this, for example, to have a parameter that lets you override arbitrary ant properties. But now the build fails, because windows ant invocation can't handle -DTEST_PARAM=foo=bar - it somehow treats that 2nd '=' as a separator and then treats "bar" as a target name:

BUILD FAILED
Target "bar" does not exist in the project "env-test".

Note that this all works fine on Mac OS X (and presumably Linux).

However note also - what I think is the real bug - nowhere is a build parameter documented as being automatically injected as an ant property via -D. The parameters are supposed to become environment variables. We can turn env vars into ant targets, or properties, or whatever we want (and also keep properties we don't want out of ant that way) - why is Jenkins always trying to turn them into -D[param]=[value] ant properties?

We encountered this because we want to have a parameterized job let us set arbitrary properties for ant invokation, e.g. a CUSTOM_PROPERTIES text param where the user can type "prop1=value", etc., and $CUSTOM_PROPERTIES is then put in the Ant task configuration's Properties area. There's no way to do this on Windows due to this bug.

Suggested fix: stop treating every parameter as an ant property, let the user decide. Alternately: fix the Windows ant task invocation to tolerate key=value text as property values.