Ant

lp:~kendfinger-deactivatedaccount/ant/trunk

Created by Kenneth Endfinger and last modified
Get this branch:
bzr branch lp:~kendfinger-deactivatedaccount/ant/trunk

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Kenneth Endfinger
Project:
Ant
Status:
Development

Import details

Import Status: Failed

This branch is an import of the HEAD branch of the Git repository at git://git.apache.org/ant.git.

The import has been suspended because it failed 5 or more times in succession.

Last successful import was .

Import started on russkaya and finished taking 40 seconds — see the log
Import started on russkaya and finished taking 40 seconds — see the log
Import started on pear and finished taking 30 seconds — see the log
Import started on pear and finished taking 30 seconds — see the log

Recent revisions

13078. By Jan Matèrne <email address hidden>

Test with @-sign like discussed on the user list.

13077. By Stefan Bodewig <email address hidden>

fix version number

13076. By Stefan Bodewig <email address hidden>

make sure AggregateTransformer knows its task when running the test

13075. By Stefan Bodewig <email address hidden>

fix for Bugzilla 47002 by Martin van Gagern - closes #3

13074. By Martin von Gagern

junitreport: Expose classpath and factory of internal XSLTProcess task.

This patch creates the nested XSLTProcess at creation of the
AggregateTransformer, not upon execution of the transformation. This way it
is much easier to simply wrap parts of the interface I'd like to expose,
like the new <classpath> and <factory> nested elements, but also the
existing <param> elements.

I haven't called XSLTProcess.init(), as the previous code didn't do that
either. I don't fully understand the difference between init() and a
constructor, but it might be a good thing to init the task somewhere.

The approach I chose is something like a whitelist delegation: the
XSLTProcess is a private member, and only selected methods of its interface
are wrapped and thus exposed to be configured. As an alternative, one could
do something like a blacklist delegation by deriving a class from
XSLTProcess and forbidding access to certain settings by ovverriding the
corresponding methods and throwing exceptions therein. In that case, one
might even turn the class derived from XSLTProcess into a nested <xslt>
element, which would be probably much clearer, as it would be configured in
the same way that a top-level <xslt> task is. I didn't choose this approach
in my patch for now.

13073. By Stefan Bodewig <email address hidden>

ignore a few GNU global files

13072. By Stefan Bodewig <email address hidden>

add a github "contributing guide" based on the great work Benedikt
Ritter has done for Commons.

13071. By Stefan Bodewig <email address hidden>

add @vit1251 's full name to contributor list

13070. By Vitold S

patch by Vitold S: make runant.py deal with spaces in java's path.
fixes #1

13069. By Stefan Bodewig <email address hidden>

after all these years we still have some author tags left

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers

No subscribers.