I have a task I wrote and I am trying to get it built into my ant setup. I
would like to run it like this...
ant -f executor.xml xml.beautify -Dxml.include=**\test.xml
Ant should resolve **\test.xml to a full path.
My target looks like this:
All,
Do any of you have experience using the FixCRLF class in the ant API?
I'm doing a concat using the Concat class and that works fine, but then I go
to set the setEol property of Concat and it doesn't seem to be doing
anything.
Concat concat..
concat.setDestfile(new File
Hi,
I notice that the Concat class constructor called a reset method which reads
a system property called line.separator, like this:
public Concat () {
reset ();
}
/**
* Reset state to default.
*/
public void reset () {
append = false;
forceOverwrite =
Hi,
I'm using the replaceRegexp ant task and I want to replace whatever matches
my pattern with 2 line breaks.
Right now I'm doing this:
however, it replace the file with the \n\n as literal text. How can I
replace these w/ 2 line breaks?
fano Marsili
> http://www.efanomars.net/pf
>
>
> --- Alex Egg <[EMAIL PROTECTED]> wrote:
>
>
>> Hi,
>>
>> I'm using the replaceRegexp ant task and I want to
>> replace whatever matches
>> my pattern with 2 line breaks.
>>
>> Right
e \n (0x0A) to a property and
> > use it. Anyway, if you want your build to be platform
> > indipendent, I think ${line.separator} is still the
> > best choice.
> >
> > Stefano Marsili
> > PFunctions: http://www.efanomars.net/pf
> >
> > --- Alex Egg <[
I need help with this task:
I have an HTML file with this snippet:
I would like to get each the src attribute value of each script tag, e.g.
"scripts/script1.js, scripts/script2.js, scripts/script3.js "
After I extract the scripts I would like to be able to pass them another ant
task in my
cludes attribute, providing the proper dir to look for
the files. --DD
On 7/19/07, Alex Egg <[EMAIL PROTECTED]> wrote:
> I need help with this task:
> I have an HTML file with this snippet:
>
>
>
>
>
>
>
> I would like to get each the src attribute value of
By default it looks like the LineContainsRegExp filter uses the
java.util.regex package by default. However, apparently
this particular regex implementation doesn't support * metacharacters
in look-behinds, e.g.: (?<=\