{5} Assigned, Active Tickets by Owner (Full Description) (11 matches)

Make inclusion of multiple custom tasks easier by extending the taskdef task to accept a "file" attribute to read task names and classes from a property file much like the defaults.properties file.

As reported by Raphael Scott on mailing list:

While running some old build files developed prior to the current 2.3.0 release(no svn, just stable PEAR package) I encountered some weird replace tokens behaviour. Even tried to pull them out of a bigger build file with not even more success to track it down. Even ran this build fie on a win32 box and a mac osx box and didn't work on both.

Sorry maybe I'm just to waisted due to the later hour and thereby not getting it, but otherwise I also could have been stumbled into a (already reported?) bug.

Shouldn' t the following test target produce the text 'Some text with two tokens: 1st Token followed by a 2nd Token' when applied to the move task context and get written into the file moved to?

<?xml version="1.0" encoding="utf-8" ?>
<project name="test" basedir="." default="test">

  <property name="one" value="1st Token" />
  <property name="two" value="2nd Token" />

  <property name="text">Some text with two tokens: @@TOKEN_ONE@@ followed by a @@TOKEN_TWO@@</property>

  <target name="test">
    <echo msg="${one}" />
    <echo msg="${two}" />
    <echo msg="${text}" />

    <echo file="template.txt">${text}</echo>

    <move file="template.txt" tofile="text-with-tokens-replaced.txt">
      <filterchain>
        <replacetokens begintoken="@@" endtoken="@@">
          <token key="TOKEN_ONE" value="${one}" />
          <token key="TOKEN_TWO" value="${two}" />
        </replacetokens>
      </filterchain>
    </move>
  </target>

</project>

I'm creating specific tasks which are put in our own code repository, e.g. MyRepos. All our classes follow the prominent naming convention of class name matches directory to filename, e.g. MyRepos/Some/File.php requires the class MyRepos_Some_File being in File.php .

Now <taskdef> supports providing a classname but only has one rule to instantiate the class, namely by it right-most name before the first dot. So when I provide

<taskdef name="mytask" classname="MyRepos.Phing.OurOwnTask">

only OurOwnTask is tried to be instantiated. With the attached patch, when this resolution fails, the classname dots are converted to underscores and then the class is tried to instantiate, in this example MyRepos_Phing_OurOwnTask .

Since the naming convention I'm using is quite common, it shouldn't be seen as too specific and maybe of interest for phing in general. I hope :)

Patch is against 2.3 branch. I'm aware of #188 but still think this could be integrated already.

Phing does not fail when a Phpdoc child task itself fails, and I can't tell from the manual that there is any way to tell Phing to fail when the PhpDoc task fails.

I've tested this several ways:

• put bad values in phpdoc's args, to force an "ERROR" message from phpdoc itself;
• kill the php process while phpdoc was running;
• phpdoc threw an malloc() failure due to low memory;

In all cases, Phing just keeps going like the phpdoc task finished successfully. I even put two phpdoc tasks in the same phing target, thinking perhaps the target would fail after the first phpdoc task failed, but no, it went right on to the second phpdoc task.

Shouldn't it be reporting a build failure when the phpdoc task failed, or is this an enhancement that needs to be added to Phing? Or, worse, is Phing already supposed to fail but Phpdoc is returning a success exit code even when it itself fails?

I'm setting this ticket type initially to "enhancement" because I feel it may have been deliberate to have the "passthru" attribute behave the way it does in phing 2.3.0.

However, it was a bit misleading to me for when I searched for some way to have ExecTask allow the shell command it was executing to stream the command output to stdout. The "passthru" attribute seems to only change the output of the shell command after all of it has been collected in a buffer because it makes use of the PHP function "exec":

http://us2.php.net/manual/en/function.exec.php

I'd like to propose that the "passthru" attribute when set to "true" make use of the PHP function "passthru":

http://us2.php.net/manual/en/function.passthru.php

Because there are many situations where the command that is executed by ExecTask may prompt the user for input and because of the behaviour of "exec", the user sees no prompt until the buffer has been flushed to stdout.

Let me know if you need a patch to the ExecTask code or if you need more details on the request for enhancement.

Cheers, Andrew

Our particular build strategy is as follows:
* build depends upon clean, lint
* build assembles files for web-visibility
* build calls smoketest
* build is called after each update

So, a developer makes a change, runs "phing build", which does a clean, a lint, then builds the files in the right web directory, and finally runs some smoke tests. The source code often contains third party libraries that we usually don't touch. Sometimes these libraries have hundreds of files.

Linting all of these third-party source files each and every time seriously hurts our cycle time: sometimes 20-30 seconds are added. It would be very nice for the PHPLintTask to remember which files it's already linted and only lint those that have been modified. Even build cycles that aren't as frequent as ours could benefit from caching (why work if you don't have to).

I suppose the cache directory should be a part of the lint element. Like this:

<phplint haltonfailure="true" cachefile="/tmp/phplintcache"> ... </phplint>

When cachefile is absent, phplint behaves as it does currently. When present, phplint checks to see if the file has been modified since last cache and lints if so, then stores file name and modification time into cache file after a successful lint.

If this is a reasonable approach, and an approved ticket, we can implement. Just give us the green light.