Re: [ant] branch master updated: support default value for scriptdef attribute

[Matt Benson]

I fully planned to do so once I know what next version number we'd be
targeting. Minor or point?

Matt

On Sun, Mar 6, 2022, 7:43 AM Stefan Bodewig  wrote:

> On 2022-03-06, Stefan Bodewig wrote:
>
> > On 2022-02-25,  wrote:
>
> >>>  
> >>>default
> >>>the default value of the attribute
> >>>No
> >>>  
>
> > please add "since ..." somewhere here and a small note in WHATSNEW.
>
> and please do the same for the other attributes an elements you've
> added.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Jenkins build became unstable: Ant » Ant-Build-Matrix-master-Linux » ubuntu,jdk_1.8_latest #128

[Matt Benson]

Interesting, I'll have to have another look. Thanks Stefan!

Matt

On Sun, Mar 6, 2022, 6:38 AM Stefan Bodewig  wrote:

> On 2022-02-15, Matt Benson wrote:
>
> > So my tests for scriptcondition return values were using beanshell
> > because I couldn't figure out any way to get rhino to return a value
> > from the script. I can't understand which optional dependencies are
> > present during the build, where they are, nor how they get there. Are
> > they in the lib of the actual Ant installation used by Jenkins? Who
> > can help me with this?
>
> Sorry, I'm pretty ,uch restricted to weekends right now - or even less.
>
> AFAIK there the Ant installation does not come with any optional
> dependencies, but I may be wrong.
>
> This is what the build job definition for building master on Linux
> currently says:
>
> java -version && ./build.sh -f fetch.xml -Ddest=optional && ./bootstrap.sh
> && ./build.sh clean jars javadocs test
>
> so dependencies should be in lib/optional
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: New Antlib

[Matt Benson]

For the information of dev@, the new repo discussed has been created at
https://gitbox.apache.org/repos/asf/ant-antlibs-s3.git . Additionally I
committed the current state of my work before realizing that its
notifications were set up improperly; this has now been fixed and future
commits should be reported to Ant's notification list.

Matt

On Mon, Feb 21, 2022, 1:31 PM Matt Benson  wrote:

> Thanks, Stefan. Will do.
>
> Matt
>
> On Mon, Feb 21, 2022, 12:50 PM Stefan Bodewig  wrote:
>
>> On 2022-02-20, Matt Benson wrote:
>>
>> > The plan from this thread is two years old, so I want to revisit. As
>> > of now the extant antlibs seem to have their own repos. If I am
>> > creating a new one, do I want to create its own repo now, or would we
>> > rather create a sandbox repo and promote its children as they
>> > "graduate" to their own repos?
>>
>> I believe there hasn't been any change to the list of antlibs in this
>> two years. Neither of them is really active. And to be honest I don't
>> expect any of the existing sandbox antilibs to ever leave that state.
>>
>> If you plan to bring the Antlib from sandox to proper anyway, I'd
>> recommend starting with a new targetted repository reight from the
>> start. This is not an incredibly strong preference, though.
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>

Re: New Antlib

[Matt Benson]

Thanks, Stefan. Will do.

Matt

On Mon, Feb 21, 2022, 12:50 PM Stefan Bodewig  wrote:

> On 2022-02-20, Matt Benson wrote:
>
> > The plan from this thread is two years old, so I want to revisit. As
> > of now the extant antlibs seem to have their own repos. If I am
> > creating a new one, do I want to create its own repo now, or would we
> > rather create a sandbox repo and promote its children as they
> > "graduate" to their own repos?
>
> I believe there hasn't been any change to the list of antlibs in this
> two years. Neither of them is really active. And to be honest I don't
> expect any of the existing sandbox antilibs to ever leave that state.
>
> If you plan to bring the Antlib from sandox to proper anyway, I'd
> recommend starting with a new targetted repository reight from the
> start. This is not an incredibly strong preference, though.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: New Antlib

[Matt Benson]

The plan from this thread is two years old, so I want to revisit. As of now
the extant antlibs seem to have their own repos. If I am creating a new
one, do I want to create its own repo now, or would we rather create a
sandbox repo and promote its children as they "graduate" to their own repos?

Matt

On Sat, Mar 7, 2020, 4:33 PM Matt Benson  wrote:

> Thanks, Stefan! Sounds like a good plan.
>
> Matt
>
> On Sat, Mar 7, 2020, 9:52 AM Stefan Bodewig  wrote:
>
>> On 2020-03-05, Matt Benson wrote:
>>
>> > What is our current protocol for creating a new Antlib?
>>
>> Do we have one? :-)
>>
>> > I have written some types for working with Amazon S3 objects as Ant
>> > resources and think they could be generally useful to the community.
>>
>> Sounds good.
>>
>> You could start with a sandbox immediately if you wanted to, but after
>> the move to git there really isn't any big difference. IMHO you should
>> just create a new antlibs git repository and add something under
>> "sandbox" and we talk about "graduating" the sandbox once it is ready
>> for a release (candidate).
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>

Re: Jenkins build became unstable: Ant » Ant-Build-Matrix-master-Linux » ubuntu,jdk_1.8_latest #128

[Matt Benson]

So my tests for scriptcondition return values were using beanshell because
I couldn't figure out any way to get rhino to return a value from the
script. I can't understand which optional dependencies are present during
the build, where they are, nor how they get there. Are they in the lib of
the actual Ant installation used by Jenkins? Who can help me with this?

Matt

On Mon, Feb 14, 2022, 4:14 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-Matrix-master-Linux/OS=ubuntu,jdk=jdk_1.8_latest/128/display/redirect?page=changes
> >
>
>

Re: Antlib test classpath

[Matt Benson]

On Sat, Feb 5, 2022, 1:19 AM Stefan Bodewig  wrote:

> On 2022-02-04, Matt Benson wrote:
>
> > I am working on a new antlib (discussed a couple of years ago on list),
> and
> > trying to figure out how to get antunit to run tests using Ivy's created
> > classpath.test from the common build framework. I have tried combinations
> > of the (hidden) classloader task with antunit references, etc., so far to
> > no avail. Does anyone (Stefan?) have any basic suggestions I can try?
>
> I must admit that I never tried to use things with Ivy at all. When I
> run tests I do so with several -lib arguments (and always need to figure
> out what is required as I don't do it often enough).
>
> If you figured things out it would probably be a good idea to update the
> common build structure as needed.
>
>
>
>
> Well
>

The changes I have made today to Ant core and Antunit will allow us, after
the next release of each, to boilerplate the classpath setup for running
Antunit tests in antlibs using [future modifications to] the common build
structure.

Matt

Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Java 8 for AntUnit

[Matt Benson]

Okay to stick with Java 5 for now, for the 1.9.x reason.

Thanks,
Matt

On Thu, Feb 10, 2022, 9:09 AM Stefan Bodewig  wrote:

> On 2022-02-09, Matt Benson wrote:
>
> > Similarly to the question on Ivy, is there any compelling reason we
> should
> > continue to constrain this antlib to its current level of Java (1.)5?
>
> We still create Ant 1.9.x releases from time to time and 1.9.x would not
> be able to use newer releases. Having said that, it is not as if we had
> much active development of AntUnit, so it wouldn't miss out much.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Build failed in Jenkins: Ant » Ant-Build-from-POMs #120

[Matt Benson]

I saw the Windows related failure and will fix it today.

Thanks,
Matt

On Wed, Feb 9, 2022, 11:16 PM Jaikiran Pai  wrote:

> Hello Matt,
>
> That job keeps failing every other time. I haven't had a chance to
> understand why it fails nor do I know what that job is for. I think you
> can ignore that specific job failure since it's not your commits which
> is causing it.
>
> The only failure that looks related to the recent commits is in a
> different job (on Windows) -
>
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-Matrix-master-Windows/OS=Windows,jdk=jdk_1.8_latest/120/testReport/src.tests.antunit.taskdefs/pathconvert-test_xml/testDirsep/
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Build failed in Jenkins: Ant » Ant-Build-from-POMs #120

[Matt Benson]

These failures don't seem to be related to my changes. Does anybody have
any idea about them?

Matt

On Wed, Feb 9, 2022, 1:37 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/120/display/redirect
> >
>
> Changes:
>
>
> --
> [...truncated 453.39 KB...]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> ant-jdepend ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/target/ant-jdepend/classes
> >
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources
> (default-testResources) @ ant-jdepend ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/src/etc/poms/ant-jdepend/src/test/resources
> >
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> ant-jdepend ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 3 source files to <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/target/ant-jdepend/testcases
> >
> [INFO] <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/src/tests/junit/org/apache/tools/ant/taskdefs/optional/jdepend/JDependTest.java>:
> <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/src/tests/junit/org/apache/tools/ant/taskdefs/optional/jdepend/JDependTest.java>
> uses or overrides a deprecated API.
> [INFO] <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/src/tests/junit/org/apache/tools/ant/taskdefs/optional/jdepend/JDependTest.java>:
> Recompile with -Xlint:deprecation for details.
> [INFO]
> [INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ ant-jdepend
> ---
> [INFO]
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running
> org.apache.tools.ant.util.facade.ImplementationSpecificArgumentTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.078 s - in
> org.apache.tools.ant.util.facade.ImplementationSpecificArgumentTest
> [INFO] Running org.apache.tools.ant.util.facade.FacadeTaskHelperTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.001 s - in org.apache.tools.ant.util.facade.FacadeTaskHelperTest
> [INFO] Running org.apache.tools.ant.taskdefs.optional.jdepend.JDependTest
> [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 1.295 s - in org.apache.tools.ant.taskdefs.optional.jdepend.JDependTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
> [INFO] --- maven-jar-plugin:3.1.0:jar (default-jar) @ ant-jdepend ---
> [INFO] Building jar: <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/target/ant-jdepend/ant-jdepend-1.10.13-SNAPSHOT.jar
> >
> [INFO]
> [INFO] ---< org.apache.ant:ant-jmf
> >---
> [INFO] Building Apache Ant + JMF 1.10.13-SNAPSHOT
>  [19/27]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ant-jmf ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> ant-jmf ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources to META-INF
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ ant-jmf
> ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/target/ant-jmf/classes
> >
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources
> (default-testResources) @ ant-jmf ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/src/etc/poms/ant-jmf/src/test/resources
> >
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> ant-jmf ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ ant-jmf ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:3.1.0:jar (default-jar) @ ant-jmf ---
> [INFO] Building jar: <
> https://ci-builds.apache.org/job/Ant/job/Ant-Build-from-POMs/ws/target/ant-jmf/ant-jmf-1.10.13-SNAPSHOT.jar
> >
> [INFO]
> [INFO] --< org.apache.ant:ant-jsch
> >---
> [INFO] Building Apache Ant + JSch 1.10.13-SNAPSHOT
> [20/27]
> [INFO] [ jar
> ]-
> Downloading from central:
> 

Java 8 for AntUnit

[Matt Benson]

Similarly to the question on Ivy, is there any compelling reason we should
continue to constrain this antlib to its current level of Java (1.)5?

Matt

Java 8 for Apache Ivy

[Matt Benson]

Java 7 public updates have ended nearly 7 years ago. Looking over the Ivy
codebase, there appear to be many opportunities for modernization using
Java 8 features (new APIs, interface default methods, etc.). Does anyone
object to, or have other thoughts on this upgrade?

Matt

Re: Antlib test classpath

[Matt Benson]

Looks like I got it sorted by passing a path reference to Antunit and
executing typedef there.

Matt

On Fri, Feb 4, 2022, 12:07 PM Matt Benson  wrote:

> I am working on a new antlib (discussed a couple of years ago on list),
> and trying to figure out how to get antunit to run tests using Ivy's
> created classpath.test from the common build framework. I have tried
> combinations of the (hidden) classloader task with antunit references,
> etc., so far to no avail. Does anyone (Stefan?) have any basic suggestions
> I can try?
>
> Matt
>

Antlib test classpath

[Matt Benson]

I am working on a new antlib (discussed a couple of years ago on list), and
trying to figure out how to get antunit to run tests using Ivy's created
classpath.test from the common build framework. I have tried combinations
of the (hidden) classloader task with antunit references, etc., so far to
no avail. Does anyone (Stefan?) have any basic suggestions I can try?

Matt

Re: New Antlib

[Matt Benson]

Thanks, Stefan! Sounds like a good plan.

Matt

On Sat, Mar 7, 2020, 9:52 AM Stefan Bodewig  wrote:

> On 2020-03-05, Matt Benson wrote:
>
> > What is our current protocol for creating a new Antlib?
>
> Do we have one? :-)
>
> > I have written some types for working with Amazon S3 objects as Ant
> > resources and think they could be generally useful to the community.
>
> Sounds good.
>
> You could start with a sandbox immediately if you wanted to, but after
> the move to git there really isn't any big difference. IMHO you should
> just create a new antlibs git repository and add something under
> "sandbox" and we talk about "graduating" the sandbox once it is ready
> for a release (candidate).
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

New Antlib

[Matt Benson]

Hello all,
What is our current protocol for creating a new Antlib? I have written some
types for working with Amazon S3 objects as Ant resources and think they
could be generally useful to the community.

Matt

Re: Mass changes to various projects under Ant umbrella - should we be doing it?

[Matt Benson]

On Wed, Apr 11, 2018, 8:25 AM Stefan Bodewig <bode...@apache.org> wrote:

> On 2018-04-11, Matt Benson wrote:
>
> > On Sun, Apr 8, 2018, 11:03 AM Stefan Bodewig <bode...@apache.org> wrote:
>
> >> We did have one big "cleanup" commit which has been the one that brought
> >> us the regressions in 1.10.2 and I deeply regret not taking the time
> >> reviewing the change back then.
>
> > I'm pretty sure I was the perpetrator of said commit and wanted to offer
> my
> > apologies.
>
> I didn't mean to single you out.


I took no offense, only wanted to express regret for having been involved
in the project in such a limited capacity these past several years and then
dropping a couple of large commits without really helping to address the
fallout.

Matt

It is incredibly hard to review diffs
> with several thousand lines (or multiple diffs with several hundred) and
> this is not only true for the reviewer but also for the person who
> created the change. It is way to easy to miss the dropped exclamation
> mark or the stripped null guard in this situtation.
>
> Personally I prefer cleanups in smaller doses by now, i.e. fix code when
> I'm making changes close by anyway, and leave it alone otherwise.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Mass changes to various projects under Ant umbrella - should we be doing it?

[Matt Benson]

On Sun, Apr 8, 2018, 11:03 AM Stefan Bodewig  wrote:

> On 2018-04-07, Jaikiran Pai wrote:
>
> > I don't mean to appear authoritative but I feel that these mass,
> > never-ending changes to various projects under the Ant umbrella,
> > related to formatting, coding style, whitespaces, syntax changes and
> > such aren't really worth it.
>
> We've done some systematic changes in the past, usually when a certain
> pattern has lead to bugs and we wanted to ensure the pattern was
> eliminated systematically. There are some precendents around
> try-with-resources or the introduction of generics that were similar to
> Gintas' series of commits, but there've only been a few.
>
> We did have one big "cleanup" commit which has been the one that brought
> us the regressions in 1.10.2 and I deeply regret not taking the time
> reviewing the change back then.
>
>
I'm pretty sure I was the perpetrator of said commit and wanted to offer my
apologies.

Matt


>
> > Especially when a lot of those changes are merely, IMO, personal
> > preferences, to code that has been around for a long time now.
>
> > It's extremely hard to do any kind of review for such changes and IMO
> > they really don't add any value.
>
> Some of them certainly are personal preferences. I tend to agree that
> many of the latest changes are not really improving the code base.
>
> I'm about twenty commits behind on reviewing the changes.
>
> > I haven't been long around in the project, to have any kind of
> > authority on this matter, but having been involved in some other open
> > source projects, changes like these aren't really good nor are
> > typically considered required or accepted.
>
> You've got as much authority as anybody else of us to state you don't
> like the changes or as Gintas has stating they make to code base
> cleaner.
>
> Honestly, I would prefer to not make this type of change at the scale
> they have happened. Mostly because I feel I'm spending a lot of time
> reviewing changes that transform working code into equivalent working
> code. Not reviewig the changes is not an option.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: ant git commit: Tidy up the code

[Matt Benson]

By and large I approve of these changes, but I felt compelled to express
the opinion that I do not believe adding else after if/continue does
anything to simplify the code. IMO it does the opposite.

Matt

On Thu, Apr 5, 2018, 1:15 AM  wrote:

> Repository: ant
> Updated Branches:
>   refs/heads/master 845c2c5b3 -> 66d7986c3
>
>
> Tidy up the code
>
> Project: http://git-wip-us.apache.org/repos/asf/ant/repo
> Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/66d7986c
> Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/66d7986c
> Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/66d7986c
>
> Branch: refs/heads/master
> Commit: 66d7986c3ad41040528a118052c4ef5b2e65ef89
> Parents: 845c2c5
> Author: Gintas Grigelionis 
> Authored: Thu Apr 5 08:15:07 2018 +0200
> Committer: Gintas Grigelionis 
> Committed: Thu Apr 5 08:15:07 2018 +0200
>
> --
>  src/main/org/apache/tools/ant/DirectoryScanner.java   |  1 +
>  src/main/org/apache/tools/ant/filters/ConcatFilter.java   |  8 +++-
>  src/main/org/apache/tools/ant/filters/HeadFilter.java |  8 +++-
>  src/main/org/apache/tools/ant/filters/SortFilter.java |  5 +
>  src/main/org/apache/tools/ant/filters/TailFilter.java |  8 +++-
>  .../apache/tools/ant/filters/util/JavaClassHelper.java|  1 -
>  src/main/org/apache/tools/ant/launch/Locator.java |  9 ++---
>  src/main/org/apache/tools/ant/taskdefs/Expand.java|  1 -
>  src/main/org/apache/tools/ant/taskdefs/Get.java   | 10 +++---
>  src/main/org/apache/tools/ant/taskdefs/UpToDate.java  |  1 -
>  .../tools/ant/taskdefs/optional/RenameExtensions.java |  1 +
>  .../tools/ant/taskdefs/optional/jdepend/JDependTask.java  |  2 ++
>  .../junitlauncher/AbstractJUnitResultFormatter.java   |  2 --
>  .../optional/junitlauncher/JUnitLauncherTask.java |  2 --
>  .../junitlauncher/LegacyPlainResultFormatter.java |  1 -
>  .../optional/junitlauncher/LegacyXmlResultFormatter.java  |  1 -
>  src/main/org/apache/tools/ant/types/Commandline.java  |  1 -
>  src/main/org/apache/tools/ant/types/CommandlineJava.java  |  1 -
>  src/main/org/apache/tools/ant/util/JavaEnvUtils.java  |  1 +
>  .../junit/org/apache/tools/ant/util/JavaEnvUtilsTest.java |  2 ++
>  20 files changed, 26 insertions(+), 40 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/ant/blob/66d7986c/src/main/org/apache/tools/ant/DirectoryScanner.java
> --
> diff --git a/src/main/org/apache/tools/ant/DirectoryScanner.java
> b/src/main/org/apache/tools/ant/DirectoryScanner.java
> index 1a7a7e0..967c9ca 100644
> --- a/src/main/org/apache/tools/ant/DirectoryScanner.java
> +++ b/src/main/org/apache/tools/ant/DirectoryScanner.java
> @@ -613,6 +613,7 @@ public class DirectoryScanner
>   *
>   * @since Ant 1.6
>   */
> +@SuppressWarnings("deprecated")
>  public static void resetDefaultExcludes() {
>  synchronized (defaultExcludes) {
>  defaultExcludes.clear();
>
>
> http://git-wip-us.apache.org/repos/asf/ant/blob/66d7986c/src/main/org/apache/tools/ant/filters/ConcatFilter.java
> --
> diff --git a/src/main/org/apache/tools/ant/filters/ConcatFilter.java
> b/src/main/org/apache/tools/ant/filters/ConcatFilter.java
> index 817572f..72b68f8 100644
> --- a/src/main/org/apache/tools/ant/filters/ConcatFilter.java
> +++ b/src/main/org/apache/tools/ant/filters/ConcatFilter.java
> @@ -192,13 +192,11 @@ public final class ConcatFilter extends
> BaseParamFilterReader
>  final Parameter[] params = getParameters();
>  if (params != null) {
>  for (Parameter param : params) {
> -if ("prepend".equals(param.getName())) {
> +final String paramName = param.getName();
> +if ("prepend".equals(paramName)) {
>  setPrepend(new File(param.getValue()));
> -continue;
> -}
> -if ("append".equals(param.getName())) {
> +} else if ("append".equals(paramName)) {
>  setAppend(new File(param.getValue()));
> -continue;
>  }
>  }
>  }
>
>
> http://git-wip-us.apache.org/repos/asf/ant/blob/66d7986c/src/main/org/apache/tools/ant/filters/HeadFilter.java
> --
> diff --git a/src/main/org/apache/tools/ant/filters/HeadFilter.java
> b/src/main/org/apache/tools/ant/filters/HeadFilter.java
> index 29806b3..24e2403 100644
> --- a/src/main/org/apache/tools/ant/filters/HeadFilter.java
> +++ b/src/main/org/apache/tools/ant/filters/HeadFilter.java

Re: [32/34] ant git commit: java 5-8

[Matt Benson]

On Thu, Apr 20, 2017 at 2:48 AM, Stefan Bodewig <bode...@apache.org> wrote:

> On 2017-04-19, Matt Benson wrote:
>
> > I had forgotten about this. When testing my other changes I noted that no
> > InputStream was returned here, due to the requested entry name including
> > the leading slash from the jar resource URL; the jar entries encountered
> > during testing, at least, lacked the leading slash.
>
> So this has never worked and nobody has noticed so far, strange.
>
> > Due to this the actual reading of the resource was deferred to the XML
> > parser. Skipping the slash fixed this issue for me and seemed
> > anecdotally to decrease the amount of time needed to run the
> > tests.
>
> Wouldn't we end up with a null InputStream and an exception being thrown
> later on?
>
> In my debugging the XML parser allowed the null InputStream and took it
upon itself to go find the named resource. This caused a weird exception
that somehow coincided with the changes to Path and Union to use the Java 8
Stream APIs, prompting me to find and fix this bug.


> > You of course know much more about the file format than I; I have been
> > unable to find a definitive resource that confirms that jar file
> > entries should always lack a leading separator.
>
> A leading slash would violate the ZIP spec
>
> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
>
>4.4.17.1 The name of the file, with optional relative path.
>The path stored MUST not contain a drive or
>device letter, or a leading slash. ...
>
> so the current code is certainly wrong. I'll try to dig deeper into this
> the coming days unless anybody else beats me to it.
>
> By "current" do you mean the code that increments past the ':' but not the
'/', i.e. until I fixed said bug?


> Many thanks
>
> Not at all, thank you!

Matt


> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [32/34] ant git commit: java 5-8

[Matt Benson]

Hi Stefan,
  I had forgotten about this. When testing my other changes I noted that no
InputStream was returned here, due to the requested entry name including
the leading slash from the jar resource URL; the jar entries encountered
during testing, at least, lacked the leading slash. Due to this the actual
reading of the resource was deferred to the XML parser. Skipping the slash
fixed this issue for me and seemed anecdotally to decrease the amount of
time needed to run the tests. You of course know much more about the file
format than I; I have been unable to find a definitive resource that
confirms that jar file entries should always lack a leading separator.

Matt

On Wed, Apr 19, 2017 at 7:58 AM, Stefan Bodewig  wrote:

> Matt,
>
> something I overlooked on my first pass
>
> On 2017-04-13,  wrote:
>
> > http://git-wip-us.apache.org/repos/asf/ant/blob/b7d1e9bd/
> src/main/org/apache/tools/ant/helper/ProjectHelper2.java
> > @@ -256,7 +259,7 @@ public class ProjectHelper2 extends ProjectHelper {
> >  zf = new ZipFile(org.apache.tools.ant.
> launch.Locator
> >   .fromJarURI(uri), "UTF-8");
> >  inputStream =
> > -zf.getInputStream(zf.getEntry(uri.substring(pling
> + 1)));
> > +zf.getInputStream(zf.getEntry(uri.substring(pling
> + 2)));
>
> why did you change the offset from 1 to 2? Doesn't look right to me but
> if it is we should probably change it for 1.9.x as well.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [28/34] ant git commit: java 5-8

[Matt Benson]

Thanks for taking the time to look them over!

Matt

On Apr 18, 2017 2:25 AM, "Stefan Bodewig" <bode...@apache.org> wrote:

> On 2017-04-14, Stefan Bodewig wrote:
>
> > On 2017-04-13, Matt Benson wrote:
>
> >> Sorry for the giant pile of changes. Tests pass for me; does anyone
> object
> >> to my merging these to master?
>
> > Most likely I won't have any reason to object, but please allow me some
> > time to digest it :-)
>
> +1 for merging
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [28/34] ant git commit: java 5-8

[Matt Benson]

Sorry for the giant pile of changes. Tests pass for me; does anyone object
to my merging these to master?

Matt

On Thu, Apr 13, 2017 at 10:16 AM,  wrote:

> http://git-wip-us.apache.org/repos/asf/ant/blob/b7d1e9bd/
> src/main/org/apache/tools/ant/taskdefs/Java.java
> --
> diff --git a/src/main/org/apache/tools/ant/taskdefs/Java.java
> b/src/main/org/apache/tools/ant/taskdefs/Java.java
> index ed9f906..b4b5a7e 100644
> --- a/src/main/org/apache/tools/ant/taskdefs/Java.java
> +++ b/src/main/org/apache/tools/ant/taskdefs/Java.java
> @@ -20,8 +20,6 @@ package org.apache.tools.ant.taskdefs;
>
>  import java.io.File;
>  import java.io.IOException;
> -import java.io.PrintWriter;
> -import java.io.StringWriter;
>  import java.util.Vector;
>
>  import org.apache.tools.ant.BuildException;
> @@ -52,6 +50,8 @@ import org.apache.tools.ant.util.StringUtils;
>   * @ant.task category="java"
>   */
>  public class Java extends Task {
> +private static final String TIMEOUT_MESSAGE =
> +"Timeout: killed the sub-process";
>
>  private CommandlineJava cmdl = new CommandlineJava();
>  private Environment env = new Environment();
> @@ -78,9 +78,6 @@ public class Java extends Task {
>  private boolean spawn = false;
>  private boolean incompatibleWithSpawn = false;
>
> -private static final String TIMEOUT_MESSAGE =
> -"Timeout: killed the sub-process";
> -
>  /**
>   * Normal constructor
>   */
> @@ -100,6 +97,7 @@ public class Java extends Task {
>   * @throws BuildException if failOnError is set to true and the
> application
>   * returns a nonzero result code.
>   */
> +@Override
>  public void execute() throws BuildException {
>  File savedDir = dir;
>  Permissions savedPermissions = perm;
> @@ -148,30 +146,32 @@ public class Java extends Task {
>  throw new BuildException("Classname must not be null.");
>  }
>  if (!fork && getCommandLine().getJar() != null) {
> -throw new BuildException("Cannot execute a jar in non-forked
> mode."
> - + " Please set fork='true'. ");
> +throw new BuildException(
> +"Cannot execute a jar in non-forked mode. Please set
> fork='true'. ");
>  }
>  if (!fork && getCommandLine().getModule() != null) {
> -throw new BuildException("Cannot execute a module in
> non-forked mode."
> - + " Please set fork='true'. ");
> +throw new BuildException(
> +"Cannot execute a module in non-forked mode. Please set
> fork='true'. ");
>  }
>  if (spawn && !fork) {
> -throw new BuildException("Cannot spawn a java process in
> non-forked mode."
> - + " Please set fork='true'. ");
> +throw new BuildException(
> +"Cannot spawn a java process in non-forked mode. Please
> set fork='true'. ");
>  }
>  if (getCommandLine().getClasspath() != null
>  && getCommandLine().getJar() != null) {
> -log("When using 'jar' attribute classpath-settings are
> ignored. "
> -+ "See the manual for more information.",
> Project.MSG_VERBOSE);
> +log("When using 'jar' attribute classpath-settings are
> ignored. See the manual for more information.",
> +Project.MSG_VERBOSE);
>  }
>  if (spawn && incompatibleWithSpawn) {
> -getProject().log("spawn does not allow attributes related to
> input, "
> -+ "output, error, result", Project.MSG_ERR);
> +getProject().log(
> +"spawn does not allow attributes related to input,
> output, error, result",
> +Project.MSG_ERR);
>  getProject().log("spawn also does not allow timeout",
> Project.MSG_ERR);
> -getProject().log("finally, spawn is not compatible "
> -+ "with a nested I/O ", Project.MSG_ERR);
> -throw new BuildException("You have used an attribute "
> -+ "or nested element which is not compatible with spawn");
> +getProject().log(
> +"finally, spawn is not compatible with a nested I/O
> ",
> +Project.MSG_ERR);
> +throw new BuildException(
> +"You have used an attribute or nested element which is
> not compatible with spawn");
>  }
>  if (getCommandLine().getAssertions() != null && !fork) {
>  log("Assertion statements are currently ignored in non-forked
> mode");
> @@ -191,8 +191,8 @@ public class Java extends Task {
>  Project.MSG_WARN);
>  }
>  if (newEnvironment || null != env.getVariables()) {
> -log("Changes to environment variables are ignored 

Re: [VOTE] migration to git

[Matt Benson]

On Apr 27, 2014 10:03 PM, Antoine Levy Lambert anto...@gmx.de wrote:

 Hi,

 Let's vote about migrating to git :

 -  Ant

 - Ivy

 - easyant

 - Ivyde

 - the antlibs

 I am not including the sandbox in the thread intentionally.

 The web sites will remain in svn in any event because svnpubsub is the
only supported mechanism to maintain web sites AFAIK.

 [] Yes
 [] No


+0 for all

Matt


 Let me start with my +1

 Antoine



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant Version

[Matt Benson]

Are you looking for compatibility with the version?  I.e., this task will
work on versions = n?  A commonly taken approach there is to use the
presence of some particular class introduced in the target version, rather
than fiddling with version numbers per se.

HTH,
Matt


On Mon, Dec 9, 2013 at 1:08 PM, Andre-John Mas andrejohn@gmail.comwrote:

 Hi,

 I recently made a code contribution and had the task get the version from
 the Main class. I appreciate this probably want the best approach and I am
 trying to consider options going forward. I had looked at the ant.version
 property, but the is only available in the project scope and also limited
 to the 'long' version.

 Some possibilities I am thinking of going forward:
  - Version class
  - AntRuntime class

 Does anyone else have suggestions or preferences as to the best way going
 forward?

 André-John

 Sent from my phone. Envoyé depuis mon téléphone.
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant Version

[Matt Benson]

Looks like Main.getAntVersion() is your friend.

Matt


On Mon, Dec 9, 2013 at 2:50 PM, Andre-John Mas andrejohn@gmail.comwrote:

 Hi,

 This was the Get Task, whereby I was getting the ant version for use in
 the user-agent response. I am using the value uninterpreted.

 André-John

 Sent from my phone. Envoyé depuis mon téléphone.

  On Dec 9, 2013, at 14:23, Matt Benson gudnabr...@gmail.com wrote:
 
  Are you looking for compatibility with the version?  I.e., this task will
  work on versions = n?  A commonly taken approach there is to use the
  presence of some particular class introduced in the target version,
 rather
  than fiddling with version numbers per se.
 
  HTH,
  Matt
 
 
  On Mon, Dec 9, 2013 at 1:08 PM, Andre-John Mas andrejohn@gmail.com
 wrote:
 
  Hi,
 
  I recently made a code contribution and had the task get the version
 from
  the Main class. I appreciate this probably want the best approach and I
 am
  trying to consider options going forward. I had looked at the
 ant.version
  property, but the is only available in the project scope and also
 limited
  to the 'long' version.
 
  Some possibilities I am thinking of going forward:
  - Version class
  - AntRuntime class
 
  Does anyone else have suggestions or preferences as to the best way
 going
  forward?
 
  André-John
 
  Sent from my phone. Envoyé depuis mon téléphone.
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant Version

[Matt Benson]

Do you have a link to that discussion?  I'd be interested to catch up the
context here.

Thanks,
Matt


On Mon, Dec 9, 2013 at 3:01 PM, Andre-John Mas andrejohn@gmail.comwrote:

 It is what I used and how the patch was accepted, but since I was told it
 wasn't ideal I wanted to see if there were ways to deal with this going
 forward.

 André-John

 Sent from my phone. Envoyé depuis mon téléphone.

  On Dec 9, 2013, at 15:56, Matt Benson gudnabr...@gmail.com wrote:
 
  Looks like Main.getAntVersion() is your friend.
 
  Matt
 
 
  On Mon, Dec 9, 2013 at 2:50 PM, Andre-John Mas andrejohn@gmail.com
 wrote:
 
  Hi,
 
  This was the Get Task, whereby I was getting the ant version for use in
  the user-agent response. I am using the value uninterpreted.
 
  André-John
 
  Sent from my phone. Envoyé depuis mon téléphone.
 
  On Dec 9, 2013, at 14:23, Matt Benson gudnabr...@gmail.com wrote:
 
  Are you looking for compatibility with the version?  I.e., this task
 will
  work on versions = n?  A commonly taken approach there is to use the
  presence of some particular class introduced in the target version,
  rather
  than fiddling with version numbers per se.
 
  HTH,
  Matt
 
 
  On Mon, Dec 9, 2013 at 1:08 PM, Andre-John Mas 
 andrejohn@gmail.com
  wrote:
 
  Hi,
 
  I recently made a code contribution and had the task get the version
  from
  the Main class. I appreciate this probably want the best approach and
 I
  am
  trying to consider options going forward. I had looked at the
  ant.version
  property, but the is only available in the project scope and also
  limited
  to the 'long' version.
 
  Some possibilities I am thinking of going forward:
  - Version class
  - AntRuntime class
 
  Does anyone else have suggestions or preferences as to the best way
  going
  forward?
 
  André-John
 
  Sent from my phone. Envoyé depuis mon téléphone.
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: new Windows Color Logger for Ant - how do I upload to ant opensource ?

[Matt Benson]

The easiest way would be to set up an open source project--even a github
project would be fine--and announce to the list that you would like it
included in the list at [1]. Thanks for your interest!

Matt
[1] https://ant.apache.org/projects.html


On Fri, Dec 6, 2013 at 1:54 PM, Dennis Lang dl...@wsi.com wrote:

 I created a Windows Color Logger for Ant which I would like to upload to
 the ant project.

 What are the steps/procedure to share my work with the Ant open source
 project ?


 *Dennis **Lang  *
 * w:* 978 983 6626  *e:* dennis.l...@weather.com

Re: Antlibs - Compress and Props in Particular

[Matt Benson]

On Oct 31, 2013 7:08 AM, Stefan Bodewig bode...@apache.org wrote:

 Hi all,

 it looks as if we needed to d something about Antlibs.

 Looking at the commit activities it is pretty clear none of them has a
 developer community - some of them have an occasional single committer.

 In general this doesn't mean there is a problem, we could just go on and
 move them to the Attic, mark them dormant or whatever.

 Compress and Props are a bit different:

 * Compress I care about myself and like to create releases when Commons
   Compress moves forward.  The current vote that would add some new
   formats fails to attract a single vote.

Like Nicolas, I will try to make time to review.


   Is there anything I can do to get more people involved?  Should I fork
   the codebase and cut my release anywhere else (maybe bringing it back
   here if people get interested, but I doubt it)?

   I don't want people to just give a +1 because I've invested time.  If
   I need to create release outside of Apache so be it, no harm done.

 * Props is useful and it seems to have users even though we've never cut
   a release.  See Bugzilla Issue 55716.

   Do we want to cut a release?  If so, I'd be happy to act as a release
   manager.  Will there people around to address issues if anything comes
   up?

I had intended to bring this up after the request came in. I am most
responsible for the props antlib and will support it as long as I am able
(i.e. breathing). I would also be okay to act as RM, perhaps with some
real-time guidance?

Matt


 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Online manual

[Matt Benson]

On Sep 12, 2013 2:37 AM, Stefan Bodewig bode...@apache.org wrote:

 On 2013-09-12, Stefan Bodewig wrote:

  On 2013-09-11, Matt Benson wrote:

  Last release was 1.9.2. https://ant.apache.org/manual/index.html says
  1.9.3.  What's going on here?

  I merged the jar/signjar doc changes from trunk, maybe I've merged too
  much - will look into it later today.

 Nah, even simple than that.  When I updated the site to reflect the
 1.9.2 I merged the trunk version of manual (which already said 1.9.3)
 rather than the one of the 1.9.2. tag.

 I've updated the cover page.

 Good catch


I assure you, it was completely accidental. ;-)

Matt

  Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant status

[Matt Benson]

Thanks for the update, Stefan!

Matt


On Sun, Sep 8, 2013 at 6:19 AM, Stefan Bodewig bode...@apache.org wrote:

 On 2013-09-05, Matt Benson wrote:

  So for a long time (starting after I had made a bunch of Java 5
  upgrades--at least I think they were upgrades) Ant builds were failing in
  Gump.

 The builds don't fail.  There is a single test in test-ant that fails
 every second or third run.

  I haven't seen those notices for quite some time now, so are they
  cleared up or simply turned off?

 Notices have been turned off for Ant.  A while back I asked all projects
 built by Gump whether they'd still be interested in it.  Some projects
 responded, others didn't.  I've removed all Gump builds of uninterested
 projects that were not needed by the remaining builds - and turned off
 nags for uniterested projects that still were needed.  Ant is in the no
 longer intersted but still needed by other projects camp - in fact all
 remaining projects are built with Ant.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Ant status

[Matt Benson]

So for a long time (starting after I had made a bunch of Java 5
upgrades--at least I think they were upgrades) Ant builds were failing in
Gump.  I haven't seen those notices for quite some time now, so are they
cleared up or simply turned off?

Matt

Re: [PATCH] fixing unit tests related to URLResolver

[Matt Benson]

Actually the right way is to submit a report through Ivy's issue tracker.

Thanks,
Matt
On Aug 27, 2013 8:35 PM, Jerry Maloney gpjerrymalo...@gmail.com wrote:

 Hi, I was doing some work on
 https://issues.apache.org/jira/browse/IVY-1436 and I think I found some
 unit tests that are broken due to some changed URLs and structure at
 http://repo1.maven.org/

 I haven't submitted to this code base before; could someone in the know
 please let me know if this is still the right way?

 Thanks,
 Jerry Maloney


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Cutting a Release because of the Javadoc Vulnerability?

[Matt Benson]

Sounds like a good idea. Thanks Stefan!

Matt
On Jul 5, 2013 9:36 AM, Stefan Bodewig bode...@apache.org wrote:

 Hi all,

 as you most probably know Oracle's javadoc tool prior to Java 7u25
 creates javadocs with a frame injection vulnerability - see
 CVE-2013-1571, VU#225657 for details.

 The javadoc task in trunk contains a patch based on code by Uwe
 Schindler of the Lucene community that postprocesses javadoc's output,
 identifies vulnerable pages and fixes them.

 This is similar to the patch applied to Maven's javadoc plugin which led
 to their version 2.9.1.

 Do we want to cut an Ant release to help Ant users to get around the
 vulnerability or is the macrodef I've added to the online manual enough
 in our view?

 If enough people think we should cut a release then I guess I'm
 volunteering to be the RM.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant 1.9.0

[Matt Benson]

I don't think I've affected any APIs as yet.  This would be acceptable.

Matt


On Fri, Feb 1, 2013 at 9:19 AM, Stefan Bodewig bode...@apache.org wrote:

 Hi

 On 2013-01-31, Antoine Levy Lambert wrote:

  I would be interested to prepare soon an Ant 1.9.0 release.

 Obviously I've not been very active here lately, and to be honest, I
 don't expect this to change anytime soon.  Thank you for taking this
 forward.

 Matt, do you expect the Java5ification to break existing public APIs?
 If not, we could as well create a release now with the rather
 incompletely migration and tak additional steps in later point releases.

 Cheers

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant 1.9.0

[Matt Benson]

Hi Antoine,
  I had made a start towards upgrading to Java 5 syntax in the Ant codebase
some months back.  At some point we started getting odd failures in Gump
which I wasn't able to understand.  It might be nice to figure this out and
finish the Java 5-ization for 1.9.0.

br,
Matt


On Wed, Jan 30, 2013 at 9:09 PM, Antoine Levy Lambert anto...@gmx.dewrote:

 Hi,

 I would be interested to prepare soon an Ant 1.9.0 release.

 In WHATSNEW I see we already have 17 fixed bugs.

 Are there other bugs - ideally with patches - that the community needs ?

 Also, Jan Matèrne had proposed previously [1] to remove the Perforce Ant
 tasks from Ant due to the availability of better tasks supplied by Perforce.

 Now would be a good time to remove them.

 Do we need a vote for that ?

 Best regards,

 Antoine

 [1]
 http://mail-archives.apache.org/mod_mbox/ant-dev/201012.mbox/%3C000601cb97a0$970bde10$c5239a30$@de%3E

Re: Request - Native Java Script Support

[Matt Benson]

Some years ago Stefan Bodewig and Jan Materne worked on this:

http://svn.apache.org/repos/asf/ant/sandbox/javafront/

YMMV

Matt

On Thu, Sep 20, 2012 at 11:45 AM, Jeffrey E Care ca...@us.ibm.com wrote:
 Anders Rundgren anders.rundg...@telia.com wrote on 09/20/2012 09:27:10
 AM:

 I guess I knew that this idea wouldn't get a big hooray...

 If you had tried NAnt you would probably agree that in-line Java
 is cooler than custom tasks because you (can) have the entire script
 in one file.

 The proposal wasn't to satisfy my own needs but to serve a large base
 of Ant users who are considering jumping the ship for Maven and other
 tools.

 I doubt I would agree.

 In my experience anything sufficiently complicated that it can't be
 handled by the standard tasks is going to require non-trivial custom code.
 No matter what technology I'm using to implement that custom code (e.g.
 javascript, java, groovy) I'm not going to want to clutter up my build.xml
 with it. I'm going to want to use my regular development tools to write
 that code.

 Having operated in both the Ant  Maven worlds my answer is the same: if I
 need to do something custom in Ant I'm going to want to write a
 full-fledged custom task instead of trying to inline it in my build.xml;
 if I need to do something custom in Maven I'm going to want to write a
 full-fledged mojo instead of trying to inline it in my POM.

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

[Matt Benson]

Hi DD,
  I had looked at PropertySet in this context, but ISTR there may have
been problems due to its desire to work with properties that already
exist rather than properties that *might* be set.

Matt

On Mon, Sep 17, 2012 at 3:36 AM, Dominique Devienne ddevie...@gmail.com wrote:
 On Sun, Sep 16, 2012 at 5:24 PM, Matt Benson gudnabr...@gmail.com wrote:
 [...] only I had intended to support regex matching.

 Can't propertyset's selection logic be reused? --DD

 PS: Didn't look at the patch, so maybe it is.

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task

[Matt Benson]

Hi,
FWIW, I approve generally of this feature and was soon going to start
working on something similar, only I had intended to support regex
matching.  I'm not quite sure when I will be able to get back to work
on Ant, but I need the feature so rest assured it will get in there at
some point.

Matt

On Sun, Sep 16, 2012 at 7:04 AM, Vimil Saju vimils...@yahoo.com wrote:
 I like this feature. I have been using the local task multiple times in my 
 targets to name properties, this enhancement will make my build scripts much 
 more cleaner.


 
  From: Ralf rks-...@gmx.de
 To: dev@ant.apache.org
 Sent: Sunday, September 16, 2012 1:59 AM
 Subject: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all 
 local, New: global task

 Hello,

 about a month ago I added an enhancement request with patch to ant bugzilla.
 As there were no feedback on bugzilla, I thought I start a little promotion.

 The patch adds some functionality to the local task:

  !-- foo is a local property - like today --
  local name=foo /

  !-- All properties with the prefix local. are local --
  local prefix=local /

  !-- all properties are local --
  local/


 Additionally the new task global was added to be able to export a
 property from a scope if all other properties are defined local.

  !-- all properties are local ... --
  local/
  !-- ... except the property gFoo --
  global name=gFoo /


 Most important for me (and hopfully others) are the addition to the
 local task (local-by-prefiy and all-local). The global tasks seems
 like a logical implication to me.

 Please have a look at the description for Bugzilla 53723 and the patch.
 It would be great if this enhancement would be included into ant.

 Regards,
 Ralf

 PS: https://issues.apache.org/bugzilla/show_bug.cgi?id=53723

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [GUMP@vmgump]: Project test-ant-no-xerces (in module ant) failed

[Matt Benson]

Any idea (Stefan?) how or why ${ant.home} shows up in the middle of
the messages for the tests in
src/tests/antunit/types/resources/archives-test.xml ?

Matt

On Tue, Sep 4, 2012 at 3:12 AM, Gump Integration Build
bode...@apache.org wrote:
 To whom it may engage...

 This is an automated request, but not an unsolicited one. For
 more information please visit http://gump.apache.org/nagged.html,
 and/or contact the folk at gene...@gump.apache.org.

 Project test-ant-no-xerces has an issue affecting its community integration.
 This issue affects 1 projects,
  and has been outstanding for 58 runs.
 The current state of this project is 'Failed', with reason 'Build Failed'.
 For reference only, the following projects are affected by this:
 - test-ant-no-xerces :  Java based build tool


 Full details are available at:
 http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/index.html

 That said, some information snippets are provided here.

 The following annotations (debug/informational/warning/error messages) were 
 provided:
  -INFO- Optional dependency rhino prerequisite failed with reason build failed
  -INFO- Optional dependency jakarta-tomcat-4.0 prerequisite failed with 
 reason build failed
  -INFO- Failed with reason build failed



 The following work was performed:
 http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/gump_work/build_ant_test-ant-no-xerces.html
 Work Name: build_ant_test-ant-no-xerces (Type: Build)
 Work ended in a state of : Failed
 Elapsed: 16 mins 52 secs
 Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
 -Dbuild.sysclasspath=only org.apache.tools.ant.Main 
 -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dtest.haltonfailure=false 
 -Dant.home=/srv/gump/public/workspace/ant/dist run-tests
 [Working Directory: /srv/gump/public/workspace/ant]
 CLASSPATH: 
 /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/build/testcases:/srv/gump/public/workspace/ant/src/tests/junit:/srv/gump/public/workspace/ant/src/etc/testcases:/srv/gump/public/workspace/ant/src/etc/testcases/taskdefs/optional/out:/srv/gump/public/workspace/ant/src/tests/antunit/filters:/srv/gump/public/workspace/ant/src/tests/antunit/taskdefs/importtests:/srv/gump/public/workspace/ant/src/tests/antunit/filters/foo:/srv/gump/public/workspace/ant/src/tests/antunit/taskdefs/foo:/srv/gump/public/workspace/ant/build/antunit/tmp/testinput/build:/srv/gump/public/workspace/ant/build/antunit/tmp/testoutput:/srv/gump/public/workspace/ant/build/antunit/tmp/test.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test1.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test2.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test3.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test4.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test5.
  
 jar:/srv/gump/public/workspace/ant/build/antunit/tmp/resources:/srv/gump/public/workspace/ant/build/lib/ant.jar:/srv/gump/public/workspace/ant/build/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/build/lib/ant-antlr.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/srv/gump/public/workspace/ant/build/lib/ant-jai.jar:/srv/gump/public/workspace/ant/build/lib/ant-javamail.jar:/srv/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/srv/gump/public/workspace/ant/build
  
 /lib/ant-jmf.jar:/srv/gump/public/workspace/ant/build/lib/ant-jsch.jar:/srv/gump/public/workspace/ant/build/lib/ant-junit.jar:/srv/gump/public/workspace/ant/build/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/build/lib/ant-swing.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/bcel/target/bcel-6.0-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-04092012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-04092012.jar:/srv/gump/public/workspace/apache-commons/net/target/commons-net-3.2-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/net/target/commons-net-ftp-3.2-SNAPSHOT.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/public/workspace/jakarta-bsf/build/lib/bsf.jar:/srv/gump/packages/apache-attic/jakarta-regexp-1.5.jar:/srv/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.
  
 

Re: Argument Processor plugin

[Matt Benson]

Comments:

- ArgumentProcessor#readArgument() should return a negative number for
unsupported args, otherwise a separate boolean #supports(arg) method
and a declared IllegalArgumentException from #readArgument()
- Prefer e.g. Appendable to StringBuffer in
ArgumentProcessor#printUsage() signature, or unless there is a good
reason for the configurable line separator, PrintStream or PrintWriter

I am generally in favor of the idea, so as long as the APIs are as
nice as they can be all the internals are negotiable.

Thanks,
Matt

On Wed, Aug 29, 2012 at 8:35 AM, Nicolas Lalevée
nicolas.lale...@hibnet.org wrote:
 I would like to add to Ant the possibility to define custom command line 
 options.

 This is motivated by the experiment I am doing with the AntDSL and the import 
 model I am trying to revisit (if anybody is interested, at some point I will 
 probably discuss it on easyant-dev, but we can also discuss here). I want 
 things to happen before the build file is being parsed and I want it to 
 happen only if the end user has requested it.

 I have not committed it because it is a kind of important door opening in 
 Ant's API. And it is only required by an experiment. EasyAnt has some custom 
 arguments too, it could benefit from it, but for now it has it own main 
 implementation and so has a full control of argument parsing. So there is no 
 real use case. yet :)

 So I would like some feed back before proceeding. The suggested patch is here:
 https://svn.apache.org/repos/asf/ant/sandbox/antdsl/branches/import-experiment/argument-processor.patch

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Argument Processor plugin

[Matt Benson]

On Wed, Aug 29, 2012 at 10:42 AM, Nicolas Lalevée
nicolas.lale...@hibnet.org wrote:

 Le 29 août 2012 à 16:41, Matt Benson a écrit :

 Comments:

 - ArgumentProcessor#readArgument() should return a negative number for
 unsupported args, otherwise a separate boolean #supports(arg) method
 and a declared IllegalArgumentException from #readArgument()

 Reviewing this, maybe a better method would be:
 int readArgument(String[] args, int pos);
 which returns the new position, the same as the one provided is not supported.
 That way we can have a variable number of custom arguments.

Sounds good.  Reminds me of ParsePosition etc.


 - Prefer e.g. Appendable to StringBuffer in
 ArgumentProcessor#printUsage() signature, or unless there is a good
 reason for the configurable line separator, PrintStream or PrintWriter

 Actually, in the current implementation, any reason all the message is 
 buffered before being put to System.out ?
 Any reason not to do System.out.println rather than StringBuffer.append( + 
 line.separator) ?

Not sure, but using PrintStream would allow Ant Main to have the
ArgumentProcessor write directly to System.out or not.  :D

Matt


 I am generally in favor of the idea, so as long as the APIs are as
 nice as they can be all the internals are negotiable.

 Thanks for the review,
 Nicolas


 Thanks,
 Matt

 On Wed, Aug 29, 2012 at 8:35 AM, Nicolas Lalevée
 nicolas.lale...@hibnet.org wrote:
 I would like to add to Ant the possibility to define custom command line 
 options.

 This is motivated by the experiment I am doing with the AntDSL and the 
 import model I am trying to revisit (if anybody is interested, at some 
 point I will probably discuss it on easyant-dev, but we can also discuss 
 here). I want things to happen before the build file is being parsed and I 
 want it to happen only if the end user has requested it.

 I have not committed it because it is a kind of important door opening in 
 Ant's API. And it is only required by an experiment. EasyAnt has some 
 custom arguments too, it could benefit from it, but for now it has it own 
 main implementation and so has a full control of argument parsing. So 
 there is no real use case. yet :)

 So I would like some feed back before proceeding. The suggested patch is 
 here:
 https://svn.apache.org/repos/asf/ant/sandbox/antdsl/branches/import-experiment/argument-processor.patch

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [GUMP@vmgump]: Project test-ant (in module ant) failed

[Matt Benson]

Looks like one problem here is that ${ant.home} isn't set during the
tests' run.  :/

Matt

On Sat, Aug 25, 2012 at 2:45 AM, Gump Integration Build
bode...@apache.org wrote:
 To whom it may engage...

 This is an automated request, but not an unsolicited one. For
 more information please visit http://gump.apache.org/nagged.html,
 and/or contact the folk at gene...@gump.apache.org.

 Project test-ant has an issue affecting its community integration.
 This issue affects 1 projects,
  and has been outstanding for 38 runs.
 The current state of this project is 'Failed', with reason 'Build Failed'.
 For reference only, the following projects are affected by this:
 - test-ant :  Java based build tool


 Full details are available at:
 http://vmgump.apache.org/gump/public/ant/test-ant/index.html

 That said, some information snippets are provided here.

 The following annotations (debug/informational/warning/error messages) were 
 provided:
  -INFO- Optional dependency rhino prerequisite failed with reason build failed
  -INFO- Optional dependency jakarta-tomcat-4.0 prerequisite failed with 
 reason build failed
  -INFO- Failed with reason build failed



 The following work was performed:
 http://vmgump.apache.org/gump/public/ant/test-ant/gump_work/build_ant_test-ant.html
 Work Name: build_ant_test-ant (Type: Build)
 Work ended in a state of : Failed
 Elapsed: 17 mins 22 secs
 Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
 -Dbuild.sysclasspath=only 
 -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar
  org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
 -Dtest.haltonfailure=false -Dant.home=/srv/gump/public/workspace/ant/dist 
 run-tests
 [Working Directory: /srv/gump/public/workspace/ant]
 CLASSPATH: 
 /usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/build/testcases:/srv/gump/public/workspace/ant/src/tests/junit:/srv/gump/public/workspace/ant/src/etc/testcases:/srv/gump/public/workspace/ant/src/etc/testcases/taskdefs/optional/out:/srv/gump/public/workspace/ant/src/tests/antunit/filters:/srv/gump/public/workspace/ant/src/tests/antunit/taskdefs/importtests:/srv/gump/public/workspace/ant/src/tests/antunit/filters/foo:/srv/gump/public/workspace/ant/src/tests/antunit/taskdefs/foo:/srv/gump/public/workspace/ant/build/antunit/tmp/testinput/build:/srv/gump/public/workspace/ant/build/antunit/tmp/testoutput:/srv/gump/public/workspace/ant/build/antunit/tmp/test.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test1.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test2.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test3.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test4.jar:/srv/gump/public/workspace/ant/build/antunit/tmp/test5.
  
 jar:/srv/gump/public/workspace/ant/build/antunit/tmp/resources:/srv/gump/public/workspace/ant/build/lib/ant.jar:/srv/gump/public/workspace/ant/build/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/build/lib/ant-antlr.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/srv/gump/public/workspace/ant/build/lib/ant-jai.jar:/srv/gump/public/workspace/ant/build/lib/ant-javamail.jar:/srv/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/srv/gump/public/workspace/ant/build
  
 /lib/ant-jmf.jar:/srv/gump/public/workspace/ant/build/lib/ant-jsch.jar:/srv/gump/public/workspace/ant/build/lib/ant-junit.jar:/srv/gump/public/workspace/ant/build/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/build/lib/ant-swing.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/bcel/target/bcel-6.0-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-25082012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-25082012.jar:/srv/gump/public/workspace/apache-commons/net/target/commons-net-3.2-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/net/target/commons-net-ftp-3.2-SNAPSHOT.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/public/workspace/jakarta-bsf/build/lib/bsf.jar:/srv/gump/packages/apache-attic/jakarta-regexp-1.5.jar:/srv/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.
  
 

Re: deprecations

[Matt Benson]

Hi Peter,
  So does that mean you would be opposed to removing these deprecated items?

Matt

On Tue, Aug 21, 2012 at 6:07 PM, Peter Reilly
peter.kitt.rei...@gmail.com wrote:
 The only problem is the there are a lot
 of tasks out there in the wild that have not
 been compiled in a very long time. (I know
 I have uses a number), These
 will most likely use the deprecated methods,
 especially in regard to handling of properties
 and references.

 Peter

 2012/8/20 Martin Gainty mgai...@hotmail.com:

 Hi Matt

  as long as there is a new method (or new class) to replace the deprecated 
 method (or deprectaed class)

 Many Thanks for your diligence!
 Martin
 __
 Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

 Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene 
 Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte 
 Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht 
 dient lediglich dem Austausch von Informationen und entfaltet keine 
 rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von 
 E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
 Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
 destinataire prévu, nous te demandons avec bonté que pour satisfaire 
 informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie 
 de ceci est interdite. Ce message sert à l'information seulement et n'aura 
 pas n'importe quel effet légalement obligatoire. Étant donné que les email 
 peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
 aucune responsabilité pour le contenu fourni.


 Date: Mon, 20 Aug 2012 12:52:19 -0500
 Subject: deprecations
 From: gudnabr...@gmail.com
 To: dev@ant.apache.org

 Hi gang,
   There are lots of methods in Ant's source that have been deprecated
 since e.g. v1.6.  Does anyone object to removing deprecated methods
 for Ant 1.9?

 Matt

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

deprecations

[Matt Benson]

Hi gang,
  There are lots of methods in Ant's source that have been deprecated
since e.g. v1.6.  Does anyone object to removing deprecated methods
for Ant 1.9?

Matt

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: svn commit: r1367306 - /ant/core/trunk/src/main/org/apache/tools/ant/Target.java

[Matt Benson]

Can't this be done more cleanly by internally wrapping all if/unless
to a Condition instance?

Matt

On Mon, Jul 30, 2012 at 4:13 PM,  hi...@apache.org wrote:
 Author: hibou
 Date: Mon Jul 30 21:13:02 2012
 New Revision: 1367306

 URL: http://svn.apache.org/viewvc?rev=1367306view=rev
 Log:
 Allow Condition as if and unless attributes of targets and extension points 
 (Java API only)

 Modified:
 ant/core/trunk/src/main/org/apache/tools/ant/Target.java

 Modified: ant/core/trunk/src/main/org/apache/tools/ant/Target.java
 URL: 
 http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/Target.java?rev=1367306r1=1367305r2=1367306view=diff
 ==
 --- ant/core/trunk/src/main/org/apache/tools/ant/Target.java (original)
 +++ ant/core/trunk/src/main/org/apache/tools/ant/Target.java Mon Jul 30 
 21:13:02 2012
 @@ -26,6 +26,7 @@ import java.util.List;
  import java.util.StringTokenizer;

  import org.apache.tools.ant.property.LocalProperties;
 +import org.apache.tools.ant.taskdefs.condition.Condition;

  /**
   * Class to implement a target object with required parameters.
 @@ -45,6 +46,10 @@ public class Target implements TaskConta
  /** The unless condition to test on execution. */
  private String unlessCondition = ;

 +private Condition if_;
 +
 +private Condition unless;
 +
  /** List of targets this target is dependent on. */
  private List/*String*/ dependencies = null;

 @@ -73,6 +78,8 @@ public class Target implements TaskConta
  this.name = other.name;
  this.ifCondition = other.ifCondition;
  this.unlessCondition = other.unlessCondition;
 +this.if_ = other.if_;
 +this.unless = other.unless;
  this.dependencies = other.dependencies;
  this.location = other.location;
  this.project = other.project;
 @@ -293,6 +300,15 @@ public class Target implements TaskConta
  }

  /**
 + * Same as {@link #setIf(String)} but requires a {@link Condition} 
 instance
 + *
 + * @since 1.9
 + */
 +public void setIf(Condition if_) {
 +this.if_ = if_;
 +}
 +
 +/**
   * Sets the unless condition to test on execution. This is the
   * name of a property to test for existence - if the property
   * is set, the task will not execute. The property goes
 @@ -321,6 +337,15 @@ public class Target implements TaskConta
  }

  /**
 + * Same as {@link #setUnless(String)} but requires a {@link Condition} 
 instance
 + *
 + * @since 1.9
 + */
 +public void setUnless(Condition unless) {
 +this.unless = unless;
 +}
 +
 +/**
   * Sets the description of this target.
   *
   * @param description The description for this target.
 @@ -450,32 +475,48 @@ public class Target implements TaskConta
  }

  /**
 - * Tests whether or not the if condition allows the execution of this 
 target.
 + * Tests whether or not the if conditions (via String AND Condition)
 + * allows the execution of this target.
   *
 - * @return whether or not the if condition is satisfied. If no
 + * @return whether or not both if conditions are satisfied. If no
   * condition (or an empty condition) has been set,
   * codetrue/code is returned.
   *
   * @see #setIf(String)
 + * @see #setIf(Condition)
   */
  private boolean testIfAllows() {
  PropertyHelper propertyHelper = 
 PropertyHelper.getPropertyHelper(getProject());
  Object o = propertyHelper.parseProperties(ifCondition);
 -return propertyHelper.testIfCondition(o);
 +if (!propertyHelper.testIfCondition(o)) {
 +return false;
 +}
 +if (if_ != null  !if_.eval()) {
 +return false;
 +}
 +return true;
  }

  /**
 - * Tests whether or not the unless condition allows the execution of 
 this target.
 + * Tests whether or not the unless conditions (via String AND 
 Condition)
 + * allows the execution of this target.
   *
 - * @return whether or not the unless condition is satisfied. If no
 + * @return whether or not both unless condition are satisfied. If no
   * condition (or an empty condition) has been set,
   * codetrue/code is returned.
   *
   * @see #setUnless(String)
 + * @see #setUnless(Condition)
   */
  private boolean testUnlessAllows() {
  PropertyHelper propertyHelper = 
 PropertyHelper.getPropertyHelper(getProject());
  Object o = propertyHelper.parseProperties(unlessCondition);
 -return propertyHelper.testUnlessCondition(o);
 +if (!propertyHelper.testUnlessCondition(o)) {
 +return false;
 +}
 +if (unless != null  unless.eval()) {
 +return false;
 +}
 +return true;
  }
  }

Re: Merging to the 1.8.x branch

[Matt Benson]

On Thu, Mar 15, 2012 at 11:58 PM, Stefan Bodewig bode...@apache.org wrote:
 Hi,

 WRT merging to the branch we basically have two options: (1) merge when
 we commit to trunk or (2) merge when we know we want to create another
 1.8.x release.

 I'm leaning towards (2) since I personally don't expect a 1.8.4
 release.  But just in case I've created a wiki page at
 http://wiki.apache.org/ant/MergeCandidates18xBranch listing the
 changesets that could be merged easily and would be important enough to
 go into the next release.  I haven't found the time to review Jesse's
 commits of the past two weeks, yet.

 Is this a dumb idea?  Should we merge stuff right away?

Option 2 sounds fine to me.

Matt


 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: fileset not iterable

[Matt Benson]

On Sat, Mar 3, 2012 at 7:10 AM, Jarek Czekalski
jarekc...@poczta.onet.pl wrote:
 Hi all

 When I was scripting in ant, I could write

 for (f: fs)

 where fs is a FileSet. But after switching to ant tasks in java, it is no
 longer available. I get a compile error:

 foreach not applicable to expression type

 I guess it's pretty easy to just write FileSet implements Iterable, but have
 not tried it in the source. If it is really easy, then I suggest adding it
 to all methods returning iterator().


Hi, Jarek.  Ant has only just recently voted to adopt Java 5 in its
trunk development (being a build tool it has tried to remain as
accessible as possible even to those stuck on what are by today's
standards thought of as archaic Java platforms).  In the future the
Iterable interface could be implemented as you suggest.

Thanks,
Matt

 Regards
 Jarek


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

[Matt Benson]

On Tue, Feb 14, 2012 at 8:13 AM, Stefan Bodewig bode...@apache.org wrote:
 On 2012-02-13, Bruce Atherton wrote:

 I spent some time starting to implement a very simple (only a few
 tasks) new version of Ant that started from Java 7. Personal issues
 have taken me out of the game for a while, but I've still been
 wondering, could Java 7 and NIO 2.0 be a good reason to create Ant
 2.0?

 There are things in NIO2 that can be added via FileUtils one way or the
 other, but it could also make us rethink our concept of Resources
 (although nio2's Path looks too limited for that).

 If we really want to take the burden of redesigning Ant on us then it
 certainly wouldn't only be NIO2 but also revolutionary things like
 generics.  OTOH there will always be a reason to wait longer (lambdas,
 modules).

 I fully understand that throwing away the existing cruft can set free
 new energy.  Personally I enjoy working on the Commons Antlib way more
 than working on the built-in Zip/Tar tasks because I could design them
 from a fresh start while the later have accumulated features with big
 care for API backwards compatibility.

 To me the strength of Ant (as it is) is in its tasks.  The tasks are
 proven pieces of code that have been tested by an incredibly big amount
 of people.  And even if we have about 200 bug reports open, most tasks
 do what they are supposed to do and do so very well.  Any rewritten Ant
 would have a long way to reach the same level of stability.  The same is
 true for the Compress Antlib vs the core tasks, of course.

 It could be a way to sweep away the kind of cruft that is holding up
 the release and to redesign Ant to reflect all the lessons learned
 about how to build software in the last 10 years.

 This will lead us to the discussion of what Ant2 would be.  A rewritten
 Ant that remains compatible (or mostly so) on the build file level or
 something quite different?


It would be very beneficial to have Ant 2 remain compatible at the
build file level if for no other reason than to facilitate testing of
v2 tasks:  AntUnit-based tests should continue to pass, and as we've
seen, the vast majority of Ant's unit tests are expressible in the
AntUnit style.

Agreed that a v2 could allow us to cast off accumulated baggage.  The
core of the redesign would be the most important thing to get right.
I suspect that the concept of a Resource would be closer to the core
(hindsight and all that) and would be interface-based.  TBH, I've
never looked closely at nio1, let alone 2, until just now, but after a
quick look at java.nio.file.Path I confess that I don't immediately
see what it lacks that we would need.

Matt

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Possible bug in ResourceUtils and/or FileResource?

[Matt Benson]

Hi, Jeff.  It does look like it would be nice for FileResource's (File)
constructors to set basedir.  I'm looking into this.

Matt

On Thu, Feb 9, 2012 at 4:19 PM, Jeffrey E Care ca...@us.ibm.com wrote:

 I was trying to track down some strange behavior in one of our custom
 resource collections and I think that I might have stumbled across a
 potential but in ResourceUtils. Specifically, in the asFileResource
 method:

 /**
  * Convenience method to turn any fileProvider into a basic
  * FileResource with the file's immediate parent as the basedir,
  * for tasks that need one.
  * @param fileProvider input
  * @return fileProvider if it is a FileResource instance, or a new
  * FileResource with fileProvider's file.
  * @since Ant 1.8
  */
 public static FileResource asFileResource(FileProvider fileProvider) {
 if (fileProvider instanceof FileResource || fileProvider == null) {
 return (FileResource) fileProvider;
 }
 FileResource result = new FileResource(fileProvider.getFile());
 result.setProject(Project.getProject(fileProvider));
 return result;
 }

 This method purports to return a FileResource whose baseDir will be the
 parent of the file returned by the passed FileProvider. The only problem is
 that setBaseDir is never called on the new'ed up FileResource from this
 code path. Also, in the instanceof case there's no promise that the
 FileProvider cast to FileResource has a non-null basedir either.

 The fix for my collection was simply to set the basedir on all of its
 resources. I think the real fix here might be that the FileResource(File)
 constructor should also set the basedir on the FileResource to the passed
 File's parent? I'm not sure the best way to fix this but I think that
 something is clearly not right.
   
 
  Jeffrey E. (Jeff) Care
 *ca...@us.ibm.com* ca...@us.ibm.com
  IBM WebSphere Application Server
 WAS Release Engineering

  [image: WebSphere Mosiac]
 [image: WebSphere Brandmark]

Re: 1.8.3?

[Matt Benson]

On Fri, Jan 20, 2012 at 9:06 AM, Tushar Kapila tgkp...@gmail.com wrote:
 I got java 1.4 from Oracle/ old sun java site for windows and got it
 running for a test app.
 Can you share the command to get the latest ant code?

 I tried
 svn co https://fisheye6.atlassian.com/browse/ant/core/trunk ant


 svn co http://svn.apache.org/repos/asf/ant/ant/trunk ant
 (svn: Repository moved permanently to '/viewvc/ant/core/trunk/'; please
 relocate)

 svn co http://svn.apache.org/viewvc/ant/core/trunk/

Hi, this should be:

http://svn.apache.org/repos/asf/ant/core/trunk/

Matt


 Or give me a snap shot locaiton?

 On Fri, Jan 20, 2012 at 10:55, Stefan Bodewig bode...@apache.org wrote:

 On 2012-01-19, Jesse Glick wrote:

  On 01/16/2012 12:27 AM, Stefan Bodewig wrote:

  what do you think about putting out a new release?

  +1; looks like around forty issues fixed so far in 1.8.3 - not a lot,
  but enough time has passed.

  A few issues are still open but marked as TM=1.8.3.

 OK, I'll try to look through them during the weekend to see which ones I
 want to tackle myself.

 As for building the release: I don't have Java 1.4 around anymore and
 wouldn't really know where to obtain one.  Any other volunteers?  Or are
 we willing to build Ant on a more recent JDK and hope its going to work
 on 1.4?

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




 --
 Regards
 Tushar Kapila

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ZIP64 Support

[Matt Benson]

Ant has historically catered to the lowest common denominator.  I
agree that that level has progressed to at least Java 5, but all
things considered I don't think we'd gain that much from a bump all
the way up to 6.

Matt

On Fri, Jul 29, 2011 at 8:31 AM, Jess Holle je...@ptc.com wrote:
 At least.

 If there are any compelling API which weren't introduced until 1.6 (there
 are in concurrency areas, but I'm not sure about anything Ant would use),
 then I'd say require 1.6.

 1.5 is actually quite ancient at this point.  If you're not on at least 1.6,
 then I have to assume you're fine using old versions of Ant too.

 On 7/29/2011 3:30 AM, Peter Reilly wrote:

 Personally I think that ant should move to java 1.5 for ant 1.9.

 Peter

 On Fri, Jul 29, 2011 at 5:16 AM, Stefan Bodewigbode...@apache.org
  wrote:

 Hi all,

 ZIP64 is the nickname for the changes to the ZIP archive format that are
 necessary to support files  4GB (both individual entries and complete
 archives) or archives with more than 64k entries.  Ant's ZIP package
 does not support this and neither does java.util.zip prior to Java7[1].

 Over in Commons land I've started to implement ZIP64 support in Commons
 Compress.  Once the code is released the Compress Antlib will
 transparently support ZIP64 without any changes required there.  All
 you'd need to do is upgrading Commons Compress.

 In order to implement it, Commons Compress must switch to Java5 as the
 few parts of java.util.zip that are used in CC (Inflater/Deflater) have
 an issuficient API for big entries (getTotalIn returns an int which is
 too small, getBytesRead which returns a long has been added in Java5).

 Since Ant is stuck with Java 1.4 for now I do not plan to backport the
 changes from Commons Compress over to Ant's ZIP package.  The reflection
 needed will be too much and I've started to embrace generics and other
 Java5 features in the modified code base, so porting is just too
 painful.

 Users that need ZIP64 can be pointed to the Compress Antlib IMHO.

 Stefan

 [1] Java7 claims to support it but from what I've seen the OpenJDK
 implementation is likely wrong.  I'll dig into OpenJDK's code at one
 point in time and open a bug report if my suspicion remains true.

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: svn commit: r1151473 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/AugmentReference.java

[Matt Benson]

Removing my figurative hat!  The bit of time I had spent looking at
this didn't bear fruit; can't believe it was this simple.  Thanks
Stefan!

Matt

On Wed, Jul 27, 2011 at 9:08 AM,  bode...@apache.org wrote:
 Author: bodewig
 Date: Wed Jul 27 14:08:00 2011
 New Revision: 1151473

 URL: http://svn.apache.org/viewvc?rev=1151473view=rev
 Log:
 restore RCW id once augment has performed its job so it can be reused by 
 other targets.  PR 50894

 Modified:
    ant/core/trunk/WHATSNEW
    ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AugmentReference.java

 Modified: ant/core/trunk/WHATSNEW
 URL: 
 http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=1151473r1=1151472r2=1151473view=diff
 ==
 --- ant/core/trunk/WHATSNEW (original)
 +++ ant/core/trunk/WHATSNEW Wed Jul 27 14:08:00 2011
 @@ -73,6 +73,10 @@ Fixed bugs:
  * sync didn't work properly when working on resource collections.
    Bugzilla Report 51462.

 + * augment cause a NullPointerException if it was used in a target
 +   that was invoked by multiple targets from the command line.
 +   Bugzilla Report 50894.
 +
  Other changes:
  --


 Modified: 
 ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AugmentReference.java
 URL: 
 http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AugmentReference.java?rev=1151473r1=1151472r2=1151473view=diff
 ==
 --- 
 ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AugmentReference.java 
 (original)
 +++ 
 ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/AugmentReference.java 
 Wed Jul 27 14:08:00 2011
 @@ -70,4 +70,26 @@ public class AugmentReference extends Ta
             wrapper.setElementTag(augmented reference \ + id + \);
         }
     }
 +
 +    /**
 +     * Overridden to restore the wrapper once it is no longer needed.
 +     * @since Ant 1.8.3
 +     */
 +    public void execute() {
 +        restoreWrapperId();
 +    }
 +
 +    /**
 +     * Needed if two different targets reuse the same instance.
 +     * @see https://issues.apache.org/bugzilla/show_bug.cgi?id=50894
 +     */
 +    private synchronized void restoreWrapperId() {
 +        if (id != null) {
 +            log(restoring augment wrapper  + id, Project.MSG_DEBUG);
 +            RuntimeConfigurable wrapper = getWrapper();
 +            wrapper.setAttribute(id, id);
 +            wrapper.setElementTag(getTaskName());
 +        }
 +    }
 +
  }




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Limit PropertyHelper delegates to a certain scope?

[Matt Benson]

Hi, Jeff!  Seems like it's been awhile.  :)

  Off the top of my head the only thing that occurs to me are
ant/antcall/subant:  the tasks that create a new project.  :/

Matt

On Wed, Jul 27, 2011 at 1:39 PM, Jeffrey E Care ca...@us.ibm.com wrote:

 I have a situation where I'm retrofitting some old code to use the
 PropertyHelper delegates that where added in Ant 1.8; in particular I need
 to limit that scope to which a certain delegate is active.

 I know how to add a delegate but there doesn't seem to be any way of
 removing a delegate once it's no longer needed: they seem to persist
 forever. As a stop-gap I've added a way to deactivate my delegate such
 that it will always return the proper values so that the next delegate will
 be invoked, but that seems like a poor work around.

 Is there a better way to do this?
   
 
  Jeffrey E. (Jeff) Care
 *ca...@us.ibm.com* ca...@us.ibm.com
  IBM WebSphere Application Server
 WAS Release Engineering

  [image: WebSphere Mosiac]
 [image: WebSphere Brandmark]

Re: Limit PropertyHelper delegates to a certain scope?

[Matt Benson]

Seems like scoped delegates would be handy, perhaps more so than straight-up
delegate removal.  It might be possible to use the existing notion of
property scopes to support this.

Matt

On Wed, Jul 27, 2011 at 2:25 PM, Jeffrey E Care ca...@us.ibm.com wrote:

 Yeah, I've been working on other projects for quite a while but recently I
 got thrown back into low-level build stuff. I'm still trying to push some
 Ant patches through IBM's legal approval process so if/when that ever
 happens you're likely to see some more of me.

 Anyway, I figured that there was no way to remove delegates, so my hacky
 work around will have to do for now I guess. I'm curious to get the
 community's thoughts on this: would delegate removal be a valuable thing to
 have? If there's a consensus that delegate removal is a good thing then I'm
 willing to work on it and submit it with the other patches that I have in
 the pipe.
  
 
  Jeffrey E. (Jeff) Care
 *ca...@us.ibm.com* ca...@us.ibm.com
  IBM WebSphere Application Server
 WAS Release Engineering

  [image: WebSphere Mosiac]
 [image: WebSphere Brandmark]





 From:Matt Benson gudnabr...@gmail.com
 To:Ant Developers List dev@ant.apache.org
 Date:07/27/2011 02:48 PM
 Subject:Re: Limit PropertyHelper delegates to a certain scope?
 --



 Hi, Jeff!  Seems like it's been awhile.  :)

  Off the top of my head the only thing that occurs to me are
 ant/antcall/subant:  the tasks that create a new project.  :/

 Matt

 On Wed, Jul 27, 2011 at 1:39 PM, Jeffrey E Care ca...@us.ibm.com wrote:

  I have a situation where I'm retrofitting some old code to use the
  PropertyHelper delegates that where added in Ant 1.8; in particular I
 need
  to limit that scope to which a certain delegate is active.
 
  I know how to add a delegate but there doesn't seem to be any way of
  removing a delegate once it's no longer needed: they seem to persist
  forever. As a stop-gap I've added a way to deactivate my delegate such
  that it will always return the proper values so that the next delegate
 will
  be invoked, but that seems like a poor work around.
 
  Is there a better way to do this?
 
 
   Jeffrey E. (Jeff) Care
  *ca...@us.ibm.com* ca...@us.ibm.com

   IBM WebSphere Application Server
  WAS Release Engineering
 
   [image: WebSphere Mosiac]
  [image: WebSphere Brandmark]
 
 

Re: xor condition

[Matt Benson]

On Wed, Jul 20, 2011 at 5:44 AM, Jesse Glick jesse.gl...@oracle.com wrote:
 On 07/16/2011 08:59 PM, Matt Benson wrote:

 xor(true, false) == true
 xor(true, false, true) == false
 xor(true, false, true, false) == false

 Is this correct?

 Follows the usual semantics; cf.:
 http://en.wikipedia.org/wiki/Exclusive_or#Associativity_and_commutativity

 It would seem that semantically an xor over multiple
 nested conditions should mean that exactly one value should evaluate
 true in order for the xor operation to yield truth.

 Which is in fact the case in the examples you mentioned, but probably you
 are thinking of

 xor(true, true, true) == true

 which is consistent with the algebraic definition, and the behavior of
 Java's ^ operator for that matter. If you wanted a condition with the
 semantics you describe, it should be named something else.


Thanks, Jesse--I think you cleared it up in my head:

and(x, y, z) = x  y  z
or(x, y, z) = x | y | z
xor(x, y, z) = x ^ y ^ z

Thanks!

Matt


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

xor condition

[Matt Benson]

Currently each nested condition is xor'd against the cumulative result, thus:

xor(true, false) == true
xor(true, false, true) == false
xor(true, false, true, false) == false

Is this correct?  It would seem that semantically an xor over multiple
nested conditions should mean that exactly one value should evaluate
true in order for the xor operation to yield truth.

Matt

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: xor condition

[Matt Benson]

On Sat, Jul 16, 2011 at 10:21 PM, Stefan Bodewig bode...@apache.org wrote:
 On 2011-07-17, Matt Benson wrote:

 Currently each nested condition is xor'd against the cumulative result, thus:

 xor(true, false) == true
 xor(true, false, true) == false
 xor(true, false, true, false) == false

 Is this correct?  It would seem that semantically an xor over multiple
 nested conditions should mean that exactly one value should evaluate
 true in order for the xor operation to yield truth.

 While my gut feeling agrees with what you describe the documentation of
 the xor description actually says

 ,
 | It only evaluates to true if an odd number of nested conditions are true.
 `


So is this an accepted kind of xor?

 If you need the other kind of xor then a new container would be
 required.  exactlyOneOf or something similar?

I don't need it, personally, yet.  Was working in Commons Lang,
noticed the discrepancy between oacl.BooleanUtils.xor() and Ant's xor
condition, and wanted to follow up.

br,
Matt


 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Fwd: Reminder: TAC Assistance to ApacheCon NA 2011 closes July 8th

[Matt Benson]

-- Forwarded message --
From: Gavin McDonald ga...@16degrees.com.au
Date: Sat, Jul 2, 2011 at 7:16 PM
Subject: Reminder: TAC Assistance to ApacheCon NA 2011 closes July 8th
To: p...@apache.org


PMCs, please re-post this reminder to your user and dev lists and anywhere
else you see fit.

-


Hi All,

Just a friendly (and final)  reminder that applications for financial help
to attend
ApacheCon NA 2011 in Vancouver close this coming Friday 8th July (2200 BST :
UTC+1)

Financial assistance is available for Travel (planes, trains, whatever) ,
Accomodation (at
the conference venue hotel) and Conference entrance fees. Dependant on your
circumstances will decide how much of that you would be given.

Please visit http://apache.org/travel for more information and a link to the
application
form.

Remember: We DO help people get to ApacheCon and other Apache events every
year,
we DO want to help people get there who otherwise could not, that is why we
exist.

Spread the word, you are welcome to tweet, blog, email, post, phone or smoke
signal
to anyone who you think might benefit from attending ApacheCon this year.

Kind Regards,

The Travel Assistance Committee.


-
To unsubscribe, e-mail: private-unsubscr...@commons.apache.org
For additional commands, e-mail: private-h...@commons.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant Plugins - ant version compatibility

[Matt Benson]

On Mon, Jun 20, 2011 at 10:02 AM, Michael Nellis mrnel...@us.ibm.com wrote:
 Jesse Glick jesse.glick at oracle.com writes:

 On 06/20/2011 09:40 AM, Michael Nellis wrote:
  I am investigating how to determine whether an Ant plugin,
  built with Ant 1.8.1, will work with Ant 1.8.2.

 Do you mean an Ant task? Generally it should work this (not the reverse of
 course), though specific
 incompatibilities ought to be mentioned in the changelog.



 I should have qualified my question a bit better.
 I have a set of Ant listeners that I need to make sure works from version to
 version.


These should always work with later versions.  The Ant developers take
backward compatibility very seriously, in preference to probably any
other concern.

Matt






 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ant Task Documentation

[Matt Benson]

2011/6/16 Grüner Heinrich gruener.heinr...@googlemail.com:

     Hi,

     I've written a couple of own tasks for which I want to generate
     help files via javadoc.
     This documentation should look like the original ant documentation.
     Can anyone provide a javadoc set up or doclet?

     Are there any efforts to generate the documentation of the core
     tasks out of the source code?
     Some source files seem to be prepared for taglet use.

     Regards,
     Stefan.



At one time there were some experiments in that direction; search for
gendoc at http://ant.apache.org/antlibs/sandbox.html .  However, this
never took off.  In my experience the manual page of a given Ant task
is cloned from some other such page.

Matt

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Command Line Debugging

[Matt Benson]

On Thu, Jun 16, 2011 at 12:37 PM, Siddhartha Purkayastha
kpsiddha...@gmail.com wrote:
 Hi Matt,

 I am not sure I understand the whole of what you said (probably I lack
 sufficient context here), so I am trying to rephrase here -

 What you are suggesting is we defer the creation of the PropertyDebugHelper
 (our custom helper) till the execution of the  target (which I assume is
 the implicit target) is complete. The assumption being that we may expect a
 custom propertyhelper, if available at all, to have been instantiated by
 then. If there is such a propertyhelper it will be wrapped by the
 PropertyDebugHelper instance and all that the latter would do is to do its
 own stuff and then delegate the call to the actual wrapped helper. Is this
 correct?


Correct.

 If so, I see two problems with this:

 (a) It seems it is also possible to create propertyhelpers inside
 user-defined targets - in which case we will not be able to track such
 property helpers? May be that is why you brought up the question of
 listeners for the project references table.

Correct again.

 (b) If the creation of the PropertyDebugHelper is deferred till later we
 will not be able to define watch points on property creations that are
 happening in the  target.

I hadn't considered this.


 I think another way of attaining it could be to 'indirectly listen' for
 calls to set a PropertyHelper instance in the taskFinished method of the
 listener itself. As soon as we detect a call to the propertyhelper task has
 finished, we can retrieve the new PropertyHelper, replace the existing
 wrapped instance in PropertyDebugHelper with the new one, and set this
 PropertyDebugHelper instance back as the PropertyHelper reference for the
 project.

 How does this sound?

Strictly speaking, it isn't 100% necessary to use the
PropertyHelperTask to replace the PropertyHelper.  However, in my
experience it's not something you can do with stock Ant tasks, instead
requiring Java (or, I suppose, script) code to do.  So why would
anyone *not* use the provided task to do it?  Therefore this seems
reasonable.

Matt


 Thanks,
 Siddhartha

 On 15 June 2011 23:48, Matt Benson gudnabr...@gmail.com wrote:

 On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha
 kpsiddha...@gmail.com wrote:
  Hello All -
 
  I spent some more time on this and have enhanced the POC to include the
  following (in addition to moving to a listener based model as suggested
 by
  Nicolas):
 
  (a) Added Property Watchpoints: You could specify a property which will
 be
  monitored for attempted changes, and when such a change is detected, the
  execution is paused, and the user is presented the debug prompt.
  (b) Added provision to add multiple break points and watch points at
 runtime
  through the debug prompt itself instead of command line arguments. When
 you
  launch ant using the debug tool, you get a prompt on BuildStarted event
  where you can add all breakpoints.
  (c) Added an Auditor that monitors and collects all changes attempted on
  select properties and lists the 'attempted change' audit records on
 request.
  Such a property must have been earlier added as a watchpoint.
 
  The implementation may be found here:
 
 https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/command-line-debuggeralong
  with Ant and EasyAnt build files.
 
  There is a README file checked in this location: please refer this for
 usage
  - trying it is very easy - it should take just two steps.
 
  If you will take a look at the code, I have substituted the regular
  PropertyHelper with a debugger version to implement watchpoints. It
 appears
  on second thoughts that a PropertyHelper Delegate may be a better choice
 to
  attain this but, I am not sure. Can someone help on this?
 

 Actually, since delegates can be added at will and are consulted in
 LIFO order, a delegate wouldn't ensure that the debug delegate always
 preempts every other.  I think the custom PropertyHelper is the way to
 go.  To be completely bullet-proof I would think eventually we need to
 finish the TODO in oata.Project of making the reference table
 listenable/interceptable; this way the PropertyDebugHelper can always
 delegate back to another instance and you can always wrap any incoming
 PropertyHelper.  For now I would recommend you go ahead and set the
 PropertyHelper up for delegation as I have said, then do your setup
 after the  target completes rather than when the build starts; this
 way you can attempt to work with users' custom PropertyHelpers.  If
 you really wanted to get fancy you could dynamically generate proxies
 for their custom PropertyHelper types so that their casts, if any,
 would still succeed, but at some point you have to draw the line, I
 suppose.  :)

 I notice the Ant patches in svn; are those still necessary?  I would
 imagine that if done correctly, most of what you need does not require
 debug awareness in Ant core--even the change I mentioned above isn't
 about debugging per

Re: Command Line Debugging

[Matt Benson]

On Wed, Jun 15, 2011 at 12:53 PM, Siddhartha Purkayastha
kpsiddha...@gmail.com wrote:
 Hello All -

 I spent some more time on this and have enhanced the POC to include the
 following (in addition to moving to a listener based model as suggested by
 Nicolas):

 (a) Added Property Watchpoints: You could specify a property which will be
 monitored for attempted changes, and when such a change is detected, the
 execution is paused, and the user is presented the debug prompt.
 (b) Added provision to add multiple break points and watch points at runtime
 through the debug prompt itself instead of command line arguments. When you
 launch ant using the debug tool, you get a prompt on BuildStarted event
 where you can add all breakpoints.
 (c) Added an Auditor that monitors and collects all changes attempted on
 select properties and lists the 'attempted change' audit records on request.
 Such a property must have been earlier added as a watchpoint.

 The implementation may be found here:
 https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/command-line-debuggeralong
 with Ant and EasyAnt build files.

 There is a README file checked in this location: please refer this for usage
 - trying it is very easy - it should take just two steps.

 If you will take a look at the code, I have substituted the regular
 PropertyHelper with a debugger version to implement watchpoints. It appears
 on second thoughts that a PropertyHelper Delegate may be a better choice to
 attain this but, I am not sure. Can someone help on this?


Actually, since delegates can be added at will and are consulted in
LIFO order, a delegate wouldn't ensure that the debug delegate always
preempts every other.  I think the custom PropertyHelper is the way to
go.  To be completely bullet-proof I would think eventually we need to
finish the TODO in oata.Project of making the reference table
listenable/interceptable; this way the PropertyDebugHelper can always
delegate back to another instance and you can always wrap any incoming
PropertyHelper.  For now I would recommend you go ahead and set the
PropertyHelper up for delegation as I have said, then do your setup
after the  target completes rather than when the build starts; this
way you can attempt to work with users' custom PropertyHelpers.  If
you really wanted to get fancy you could dynamically generate proxies
for their custom PropertyHelper types so that their casts, if any,
would still succeed, but at some point you have to draw the line, I
suppose.  :)

I notice the Ant patches in svn; are those still necessary?  I would
imagine that if done correctly, most of what you need does not require
debug awareness in Ant core--even the change I mentioned above isn't
about debugging per se, just reference tracking.

Regards,
Matt

 I am imagining the following additions to this tool:
 (a) Adding Exception Breakpoints: If a task throws an exception of interest,
 then the debug mode takes over.
 (b) Allowing Properties to be set/unset, and probably paths to be edited.

 Can you share thoughts on this? Can we include other things to make this
 more useful?

 Thanks,
 Siddhartha

 On 10 June 2011 16:17, Siddhartha Purkayastha kpsiddha...@gmail.com wrote:

 Hi Nicolas - BuildListener is a better idea than my current implementation.
 It looks cleaner and perhaps the same listener can also be attached at
 individual task level to step through targets one by one, pausing at each
 one. I will try to incorporate your comments and share the outcome with the
 group.

 Hi Jan / Jesse - If you would have noticed, the PoC allows detecting
 current values of properties, and paths, and also the location of individual
 properties inside build files. I think it should also be possible to locate
 individual tasks. Do you have any suggestions on what else can be included
 into this to make it more helpful?

 A further thought - It could also be possible to expose the listener itself
 (or any such debugging interface) as a hook from within Ant, that IDEs can
 use to implement any debuggers. If the developers of any debuggers are
 present here and can help, then they could share their approach - or any
 debug-APIs from Ant would be of use to them.

 Any thoughts?

 Thanks,
 Siddhartha


 On 10 June 2011 10:55, Jan Matèrne apa...@materne.de wrote:

 Eclipse (tested with Helios) has a built in Ant debugger too.
 Quick test:
 - write a buildfile
 - set a breakpoint (line 9)
 - Debug as  Ant build

 == Eclipse changed to the debug perspective (or wants to)
 In the variables view you can see the properties, but not change values or
 set new props.


 Jan

  -Ursprüngliche Nachricht-
  Von: Jesse Glick [mailto:jesse.gl...@oracle.com]
  Gesendet: Donnerstag, 9. Juni 2011 21:42
  An: dev@ant.apache.org
  Betreff: Re: Command Line Debugging
 
  On 06/09/2011 05:42 AM, Nicolas Lalevée wrote:
   At some point we may imagine a debugger in an IDE like Eclipse too.
 
  By the way there has long been an Ant debugger in 

[ivy] m2 compatibility WAS Re: svn commit: r1133126 - in /ant/ivy/core/trunk: src/java/org/apache/ivy/plugins/parser/m2/ test/java/org/apache/ivy/core/resolve/ test/java/org/apache/ivy/plugins/parser/

[Matt Benson]

Hi Ivy devs,
  You may have noticed over the past several days that I have
committed some m2-related fixes, specifically:

https://issues.apache.org/jira/browse/IVY-1299
https://issues.apache.org/jira/browse/IVY-1301

Both of these issues related to overriding parent properties that
specified dependency versions, and I had to do some strange gymnastics
to make this work.  A code review by more experienced eyes would
probably be best.

Thanks,
Matt

On Tue, Jun 7, 2011 at 1:34 PM,  mben...@apache.org wrote:
 Author: mbenson
 Date: Tue Jun  7 18:34:01 2011
 New Revision: 1133126

 URL: http://svn.apache.org/viewvc?rev=1133126view=rev
 Log:
 [IVY-1301] Ivy does not apply overridden properties to parent dependency 
 versions specified using dependencyManagement properties

 Added:
    
 ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/m2/test-overrideParentVersionPropertyDependencyMgt.pom
    
 ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/m2/test-versionPropertyDependencyMgt.pom
 Modified:
    
 ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorBuilder.java
    
 ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorParser.java
    ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/m2/PomReader.java
    ant/ivy/core/trunk/test/java/org/apache/ivy/core/resolve/ResolveTest.java
    
 ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorParserTest.java

 Modified: 
 ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorBuilder.java
 URL: 
 http://svn.apache.org/viewvc/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorBuilder.java?rev=1133126r1=1133125r2=1133126view=diff
 ==
 --- 
 ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorBuilder.java
  (original)
 +++ 
 ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorBuilder.java
  Tue Jun  7 18:34:01 2011
 @@ -184,7 +184,7 @@ public class PomModuleDescriptorBuilder



 -    private final DefaultModuleDescriptor ivyModuleDescriptor;
 +    private final PomModuleDescriptor ivyModuleDescriptor;


     private ModuleRevisionId mrid;
 @@ -199,7 +199,7 @@ public class PomModuleDescriptorBuilder

     public PomModuleDescriptorBuilder(
             ModuleDescriptorParser parser, Resource res, ParserSettings 
 ivySettings) {
 -        ivyModuleDescriptor = new DefaultModuleDescriptor(parser, res);
 +        ivyModuleDescriptor = new PomModuleDescriptor(parser, res);
         ivyModuleDescriptor.setResolvedPublicationDate(new 
 Date(res.getLastModified()));
         for (int i = 0; i  MAVEN2_CONFIGURATIONS.length; i++) {
             ivyModuleDescriptor.addConfiguration(MAVEN2_CONFIGURATIONS[i]);
 @@ -365,6 +365,8 @@ public class PomModuleDescriptorBuilder


     public void addDependencyMgt(PomDependencyMgt dep) {
 +        ivyModuleDescriptor.addDependencyManagement(dep);
 +
         String key = getDependencyMgtExtraInfoKeyForVersion(dep.getGroupId(), 
 dep.getArtifactId());
         ivyModuleDescriptor.addExtraInfo(key, dep.getVersion());
         if (dep.getScope() != null) {
 @@ -450,13 +452,25 @@ public class PomModuleDescriptorBuilder
     }

     private String getDefaultVersion(PomDependencyData dep) {
 +        ModuleId moduleId = ModuleId.newInstance(dep.getGroupId(), 
 dep.getArtifactId());
 +        if 
 (ivyModuleDescriptor.getDependencyManagementMap().containsKey(moduleId)) {
 +            return ((PomDependencyMgt) 
 ivyModuleDescriptor.getDependencyManagementMap().get(
 +                moduleId)).getVersion();
 +        }
         String key = getDependencyMgtExtraInfoKeyForVersion(dep.getGroupId(), 
 dep.getArtifactId());
         return (String) ivyModuleDescriptor.getExtraInfo().get(key);
     }

     private String getDefaultScope(PomDependencyData dep) {
 -        String key = getDependencyMgtExtraInfoKeyForScope(dep.getGroupId(), 
 dep.getArtifactId());
 -        String result = (String) ivyModuleDescriptor.getExtraInfo().get(key);
 +        String result;
 +        ModuleId moduleId = ModuleId.newInstance(dep.getGroupId(), 
 dep.getArtifactId());
 +        if 
 (ivyModuleDescriptor.getDependencyManagementMap().containsKey(moduleId)) {
 +            result = ((PomDependencyMgt) 
 ivyModuleDescriptor.getDependencyManagementMap().get(
 +                moduleId)).getScope();
 +        } else {
 +            String key = 
 getDependencyMgtExtraInfoKeyForScope(dep.getGroupId(), dep.getArtifactId());
 +            result = (String) ivyModuleDescriptor.getExtraInfo().get(key);
 +        }
         if ((result == null) || !MAVEN2_CONF_MAPPING.containsKey(result)) {
             result = compile;
         }
 @@ -488,6 +502,13 @@ public class PomModuleDescriptorBuilder
                                 ModuleDescriptor descriptor,
                              

[ivy] jenkins builds on Ubuntu slave only?

[Matt Benson]

What was the reason for restricting the Ivy builds to this slave?

Matt

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Build failed in Jenkins: Ivy-tests #49

[Matt Benson]

;) Me learning why builds are restricted to Ubuntu slaves; seemingly
they're the ones that are properly configured!

Matt

On Tue, Jun 7, 2011 at 2:42 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 See https://builds.apache.org/job/Ivy-tests/49/changes

 Changes:

 [mbenson] [IVY-1301] Ivy does not apply overridden properties to parent 
 dependency versions specified using dependencyManagement properties

 --
 [...truncated 2560 lines...]
 AU        doc/tutorial/dependence.html
 AU        doc/tutorial/multiple.html
 AU        doc/moreexamples.html
 A         doc/images
 AU        doc/images/ivy-forum.png
 AU        doc/images/searched.gif
 AU        doc/images/grippie.png
 AU        doc/images/ivy-book.png
 AU        doc/images/logo.png
 AU        doc/images/ivy-publish-fc.png
 AU        doc/images/downloaded.gif
 AU        doc/images/apache-incubator-logo.png
 AU        doc/images/ivy-dl-1.4.1.png
 AU        doc/images/yed-step1.jpg
 AU        doc/images/main-tasks.png
 AU        doc/images/yed-step2.jpg
 AU        doc/images/yed-step3-2.jpg
 AU        doc/images/yed-step3.jpg
 AU        doc/images/error.gif
 AU        doc/images/yed-step4.jpg
 AU        doc/images/yed-step5.jpg
 AU        doc/images/yed-step6.jpg
 AU        doc/images/yed-step7.jpg
 AU        doc/images/ivy-dl-2.0.0-alpha-1.png
 AU        doc/images/report-small.png
 AU        doc/images/ivy-lierre.png
 AU        doc/images/discovery.gif
 AU        doc/images/xooki-toolbar.png
 AU        doc/images/closed.gif
 AU        doc/images/ivy-dl.xcf
 AU        doc/images/ivy-terminology.odg
 AU        doc/images/evicted.gif
 AU        doc/images/bullet.gif
 AU        doc/images/xooki-edit.png
 AU        doc/images/ivy-terminology.png
 AU        doc/images/ivyfile-small.png
 AU        doc/images/xooki-edit-small.png
 AU        doc/images/open.gif
 AU        doc/images/hibgraph.png
 AU        doc/images/ivy-publish-fc.odg
 AU        doc/images/ivy-demo.png
 AU        doc/images/hibgraph-small.png
 AU        doc/images/ant-group-logo.gif
 AU        doc/tutorial.html
 A         doc/configuration
 A         doc/configuration/macrodef
 AU        doc/configuration/macrodef/attribute.html
 AU        doc/configuration/parsers.html
 AU        doc/configuration/namespaces.html
 AU        doc/configuration/macrodef.html
 AU        doc/configuration/classpath.html
 AU        doc/configuration/status.html
 A         doc/configuration/caches
 AU        doc/configuration/caches/cache.html
 AU        doc/configuration/caches/ttl.html
 AU        doc/configuration/include.html
 AU        doc/configuration/resolvers.html
 AU        doc/configuration/property.html
 AU        doc/configuration/conf.html
 AU        doc/configuration/module.html
 AU        doc/configuration/triggers.html
 AU        doc/configuration/caches.html
 AU        doc/configuration/version-matchers.html
 A         doc/configuration/namespace
 AU        doc/configuration/namespace/dest.html
 AU        doc/configuration/namespace/rule.html
 AU        doc/configuration/namespace/src.html
 AU        doc/configuration/namespace/fromtosystem.html
 AU        doc/configuration/namespace.html
 AU        doc/configuration/conflict-managers.html
 AU        doc/configuration/properties.html
 AU        doc/configuration/outputters.html
 AU        doc/configuration/lock-strategies.html
 AU        doc/configuration/typedef.html
 AU        doc/configuration/latest-strategies.html
 AU        doc/configuration/modules.html
 AU        doc/configuration/statuses.html
 AU        doc/install.html
 AU        doc/configuration.html
 A         doc/js
 AU        doc/js/jquery.treeview.js
 AU        doc/js/jquery.pack.js
 A         doc/dev
 AU        doc/dev/makerelease.html
 AU        doc/dev/updatesite.html
 AU        doc/yed.html
 AU        doc/ant.html
 AU        doc/principle.html
 AU        doc/textual.html
 AU        doc/extend.html
 AU        doc/printTemplate.html
 A         doc/use
 AU        doc/use/resolve.html
 AU        doc/use/cachefileset.html
 AU        doc/use/cachepath.html
 AU        doc/use/configure.html
 AU        doc/use/repreport.html
 AU        doc/use/retrieve.html
 AU        doc/use/var.html
 AU        doc/use/makepom.html
 AU        doc/use/artifactreport.html
 AU        doc/use/deliver.html
 AU        doc/use/buildlist.html
 AU        doc/use/info.html
 AU        doc/use/convertpom.html
 AU        doc/use/findrevision.html
 AU        doc/use/settings.html
 AU        doc/use/buildobr.html
 AU        doc/use/artifactproperty.html
 AU        doc/use/listmodules.html
 AU        doc/use/install.html
 AU        doc/use/cleancache.html
 AU        doc/use/publish.html
 AU        doc/use/convertmanifest.html
 AU        doc/use/buildnumber.html
 AU        doc/use/postresolvetask.html
 AU        doc/use/resources.html
 AU        doc/use/report.html
 AU        doc/apache-proposal.txt
 AU        doc/toc.json
 AU        doc/concept.html
 AU        

Travel Assistance applications open for ApacheCon North America 2011

[Matt Benson]

The Apache Software Foundation (ASF)'s Travel Assistance Committee (TAC) is
now accepting applications for ApacheCon North America 2011, 7-11 November
in Vancouver BC, Canada.

The TAC is seeking individuals from the Apache community at-large --users,
developers, educators, students, Committers, and Members-- who would like to
attend ApacheCon, but need some financial support in order to be able to get
there. There are limited places available, and all applicants will be scored
on their individual merit.

Financial assistance is available to cover flights/trains, accommodation and
entrance fees either in part or in full, depending on circumstances.
However, the support available for those attending only the BarCamp (7-8
November) is less than that for those attending the entire event (Conference
+ BarCamp 7-11 November). The Travel Assistance Committee aims to support
all official ASF events, including cross-project activities; as such, it may
be prudent for those in Asia and Europe to wait for an event geographically
closer to them.

More information can be found at http://www.apache.org/travel/index.html
including a link to the online application and detailed instructions for
submitting.

Applications will close on 8 July 2011 at 22:00 BST (UTC/GMT +1).

We wish good luck to all those who will apply, and thank you in advance for
tweeting, blogging, and otherwise spreading the word.

Regards,
The Travel Assistance Committee

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Ivy Jenkins build

[Matt Benson]

Why do we only do a 'clean jar'?  Shouldn't we be running unit tests
at least?  Isn't that kind of the point of CI?  Perhaps 'clean
coverage-report'?

Matt

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy Jenkins build

[Matt Benson]

FYI I experimented with running these targets; build completed
successfully in 3.x minutes.  I'm not going to revert my change unless
someone presents a good reason to do so.

Matt

On Mon, Jun 6, 2011 at 10:18 AM, Matt Benson gudnabr...@gmail.com wrote:
 Why do we only do a 'clean jar'?  Shouldn't we be running unit tests
 at least?  Isn't that kind of the point of CI?  Perhaps 'clean
 coverage-report'?

 Matt


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [GUMP@vmgump]: Project test-ant-no-xerces (in module ant) failed

[Matt Benson]

2011/4/29 Nicolas Lalevée nicolas.lale...@hibnet.org:

 Le 28 avr. 2011 à 21:39, Nicolas Lalevée a écrit :


 Le 28 avr. 2011 à 00:39, Matt Benson a écrit :

 2011/4/27 Nicolas Lalevée nicolas.lale...@hibnet.org:
 I could only reproduce the apply-test failing locally (on a mac).
 The following command line got me more info about what's happening:
 ant -lib lib/optional/ant-antunit-1.1.jar antunit-report 
 -Dantunit.testcase=taskdefs/exec/apply-test.xml -Dantunit.loglevel=info

 In the output I can see these lines:
 [au:antunit] error at LeadPipeInputStream.read():  Pipe broken
 [au:antunit] z after y after blah
 [au:antunit] error at LeadPipeInputStream.read():  Pipe broken
 [au:antunit] x after y after blah

 Not sure what to conclude from that since I'm not yet familiar with what 
 LeadPipeInputStream does. At a first glance I would say that we could 
 interpret that if the pipe is broken, then the writing Thread is no 
 longer alive, which would be basically be a nominal case and not an error 
 one ?


 If it helps, LeadPipeInputStream (a poor pun) is intended to replace
 the java.io.PipedInputStream to recover from writing thread is no
 longer alive errors, because often there is data remaining to be read
 when the writer has already sent all he had to send, then terminated.

 ok I see. Then I think it will make sense to handle the Pipe broken just 
 like the Write end dead. The read method in PipedInputStream start to 
 check the thread status, and can fail with a IOE with Write end dead as a 
 message the write thread is dead. If the write thread are still alive but no 
 content is yet available, a loop begins to wait for content. Then if at some 
 point there's still no content to read but the write thread has stopped, 
 there is an IOE with Pipe broken as a message. So having either Pipe 
 broken or Write end dead is just a matter of timing.

 I'll commit a fix. Tested locally the ant unit tests then works (tested 
 several times). And I think it will fix the bug #48789 [1].
 If gump shows us it now works I'll update the what's new and close #48789. 
 If not I'll revert my commit.

 gump seems happier, bug closed as resolved.

Thanks for your attention to this, Nicolas.

Matt


 One test still failing, I haven't looked at it:

 [au:antunit] Target: 
 test-redirector-input-output-inputencoding-outputencoding  FAILED
 [au:antunit]    at line 552, column 24
 [au:antunit]    Message: Assertion failed
 [au:antunit]    took 1.424 sec


 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [GUMP@vmgump]: Project test-ant-no-xerces (in module ant) failed

[Matt Benson]

2011/4/27 Nicolas Lalevée nicolas.lale...@hibnet.org:
 I could only reproduce the apply-test failing locally (on a mac).
 The following command line got me more info about what's happening:
 ant -lib lib/optional/ant-antunit-1.1.jar antunit-report 
 -Dantunit.testcase=taskdefs/exec/apply-test.xml -Dantunit.loglevel=info

 In the output I can see these lines:
 [au:antunit] error at LeadPipeInputStream.read():  Pipe broken
 [au:antunit] z after y after blah
 [au:antunit] error at LeadPipeInputStream.read():  Pipe broken
 [au:antunit] x after y after blah

 Not sure what to conclude from that since I'm not yet familiar with what 
 LeadPipeInputStream does. At a first glance I would say that we could 
 interpret that if the pipe is broken, then the writing Thread is no longer 
 alive, which would be basically be a nominal case and not an error one ?


If it helps, LeadPipeInputStream (a poor pun) is intended to replace
the java.io.PipedInputStream to recover from writing thread is no
longer alive errors, because often there is data remaining to be read
when the writer has already sent all he had to send, then terminated.

Matt

 Nicolas

 Le 23 avr. 2011 à 22:48, Antoine Levy Lambert a écrit :

 We currently have two antunit tests failing in gump.
 I am looking into this, I am trying my luck at installing virtualbox on my 
 MacBook.

 Regards,

 Antoine

 [au:antunit] Build File: 
 /srv/gump/public/workspace/ant/src/tests/antunit/taskdefs/exec/exec-test.xml
 [au:antunit] Tests run: 30, Failures: 1, Errors: 0, Time elapsed: 32.748 sec
 [au:antunit] Target: 
 test-redirector-input-output-inputencoding-outputencoding  FAILED
 [au:antunit]     at line 552, column 24
 [au:antunit]     Message: Assertion failed
 [au:antunit]     took 1.428 sec
 [au:antunit] Build File: 
 /srv/gump/public/workspace/ant/src/tests/antunit/taskdefs/exec/apply-test.xml
 [au:antunit] Tests run: 30, Failures: 1, Errors: 0, Time elapsed: 98.754 sec
 [au:antunit] Target: testRedirector14  FAILED
 [au:antunit]     at line 611, column 76
 [au:antunit]     Message: Expected log to contain 'z after y after blahx 
 after y after blah' at level info
 [au:antunit]     took 3.269 sec


 On 4/23/11 8:27 AM, Gump Integration Build wrote:

 Full details are available at:
     http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/index.html



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ResourceExists condition (was Re: svn commit: r1063181 - in /ant/antlibs/antunit/trunk: ./ docs/ src/etc/testcases/ src/main/org/apache/ant/antunit/ src/tests/junit/org/apache/ant/antunit/)

[Matt Benson]

On Jan 25, 2011, at 4:25 AM, Stefan Bodewig wrote:

 On 2011-01-25, bode...@apache.org wrote:
 
 Added:

 ant/antlibs/antunit/trunk/src/main/org/apache/ant/antunit/ResourceExists.java
(with props)
 
 This is a plain ant condition with no dependency on AntUnit that might
 be useful in core Ant as well.
 

Shorthand for

resourcecount count=1
  restrict
exists
  resource refid=myresource /
/exists
  /restrict
/resourcecount

?  ;)

-Matt

 I added it to AntUnit rather than Ant's trunk so that we can release
 AntUnit (if we ever want to) without having to release Ant first.
 
 Stefan
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: svn commit: r1032922 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/BindTargets.java

[Matt Benson]

On Nov 9, 2010, at 9:12 AM, Dominique Devienne wrote:

 2010/11/9 Nicolas Lalevée nicolas.lale...@hibnet.org:
 Note: I'll commit the unit test and doc I have wrote about this task. I 
 don't want to enforce anything, just share the work I have done. It is still 
 up to debate and can still be reverted.
 
 Well, process-wise we tend to discuss things out on the ML before
 committing, or go thru the sandbox.

I wouldn't say that we are always RTC.  For changes with potentially large 
impact, I personally have always gone ahead and opened up discussion beforehand 
because I didn't want a large changeset to come as a complete surprise.  But a 
particular expert level task being added to Ant, I don't really have much 
problem with.  I don't 100% see a use for it myself, and am pretty sure that if 
I did want it, it wouldn't be for simple build composition, but for some kind 
of parameterized situation.  I guess I'm +0 to this task's inclusion.


 As Stefan, I still don't quite see
 the use case, or more precisely why the use case you describe can't be
 achieved some other way. --DD
 
 PS: There's no enum-like type for onMissingExtensionPoint? Taking it
 as a string allow passing anithing.

+1 here.

-Matt

 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: svn commit: r1032931 - /ant/core/trunk/src/main/org/apache/tools/ant/Main.java

[Matt Benson]

On Nov 9, 2010, at 9:16 AM, Dominique Devienne wrote:

 On Tue, Nov 9, 2010 at 5:35 AM,  hi...@apache.org wrote:
 +msg.append(   depends of: );
 
 That doesn't sound correct somehow.  depends on ?  dependent of/on ?
 
 Could native speakers chime in please? Thanks, --DD

I agree:  depends on:.

-Matt

 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: svn commit: r1032922 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/BindTargets.java

[Matt Benson]

On Nov 9, 2010, at 9:12 AM, Dominique Devienne wrote:

 2010/11/9 Nicolas Lalevée nicolas.lale...@hibnet.org:
 Note: I'll commit the unit test and doc I have wrote about this task. I 
 don't want to enforce anything, just share the work I have done. It is still 
 up to debate and can still be reverted.
 
 Well, process-wise we tend to discuss things out on the ML before
 committing, or go thru the sandbox.

I wouldn't say that we are always RTC.  For changes with potentially large 
impact, I personally have always gone ahead and opened up discussion beforehand 
because I didn't want a large changeset to come as a complete surprise.  But a 
particular expert level task being added to Ant, I don't really have much 
problem with.  I don't 100% see a use for it myself, and am pretty sure that if 
I did want it, it wouldn't be for simple build composition, but for some kind 
of parameterized situation.  I guess I'm +0 to this task's inclusion.


 As Stefan, I still don't quite see
 the use case, or more precisely why the use case you describe can't be
 achieved some other way. --DD
 
 PS: There's no enum-like type for onMissingExtensionPoint? Taking it
 as a string allow passing anithing.

+1 here.

-Matt

 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Accept Bushel Donation

[Matt Benson]

On Nov 5, 2010, at 9:45 AM, Stefan Bodewig wrote:

 Hi,
 
 the people behind Bushel[1] want to donate their code to Ivy[2] and
 before I can start the formal IP clearance process we can and should
 vote whether we want to accept the donation at all.
 
 So, do we want to accept the Bushel donation?
 

+1

Matt

 Stefan
 
 [1] Original: http://code.google.com/p/bushel/
Donated Code: https://issues.apache.org/jira/browse/IVY-1241 
 
 [2] 
 http://mail-archives.apache.org/mod_mbox/ant-dev/201010.mbox/%3cb53d948c-5da9-48d8-b81d-2f8c44dba...@hibnet.org%3e
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ApacheCon Atlanta

[Matt Benson]

On Oct 18, 2010, at 3:51 PM, Antoine Levy-Lambert wrote:

 Hi,
 
 I will be attending ApacheCon US in Atlanta. Anyone else from the Ant 
 community coming too ?
 

I am hoping my employer will agree to send me, but I was a little late getting 
them the specifics, so at this point I don't yet have an answer from them.  :o

-Matt

 Regards,
 
 Antoine
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: warning: 'includeantruntime' was not set

[Matt Benson]

On Aug 18, 2010, at 11:15 AM, Jesse Glick wrote:

 On 08/18/2010 10:14 AM, kwut...@web.de wrote:
 Why doesn't Ant just default to false and just omit warning me about this 
 for every Ant build?
 
 That would be an incompatible change. Some old build scripts may be 
 intentionally compiling sources against ant.jar (typically because they 
 define Ant tasks), tools.jar (who knows why), etc. They also ought to set 
 includeantruntime=false but then explicitly add the desired classpath, e.g. 
 pathelement location=${ant.core.lib}/. (The warning will also go away if 
 you set includeantruntime=true, but this will make your script be less 
 portable.)
 
 I agree that it is irritating to issue this warning so often, but the 
 alternative of breaking compatibility even for a minority of existing scripts 
 seems worse. There are similar places in Ant where an old default was a bad 
 choice but cannot now be changed compatibly.
 
 (You could also define ANT_OPTS=-Dbuild.sysclasspath=ignore for yourself but 
 this will not help other people running your script.)
 

Personally, I would vote that we break backward-compatibility on this issue, 
and require those running such ancient buildfiles to declare build.sysclasspath 
if they DO want the system classpath appended.

-Matt

 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: warning: 'includeantruntime' was not set

[Matt Benson]

On Aug 18, 2010, at 12:56 PM, Jesse Glick wrote:

 On 08/18/2010 12:31 PM, Matt Benson wrote:
 require those running such ancient buildfiles
 
 Unfortunately they need not be so ancient. I have come across more than one 
 build.xml from an actively developed project which just assumed that sources 
 could be compiled against org.apache.tools.ant.** without doing anything. Of 
 course fixing such a script is easy if you know what is wrong, but the 
 authors (or new maintainers) may not know what to do when a new Ant release 
 breaks their build.
 

Okay, maybe ancient was a poor choice of words, but I would still guess that 
more builds than not DON'T need to compile against Ant itself.

-Matt

 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Import and project helpers

[Matt Benson]

On Jul 19, 2010, at 4:12 AM, Nicolas Lalevée wrote:


On Friday 16 July 2010 18:07:57 Matt Benson wrote:

On Jul 16, 2010, at 8:25 AM, Nicolas Lalevée wrote:

Hi,

I did some other experiment with the groovy frontend to ant
recently. And I
would like to be able to make a groovy build file import an xml
build file
and vice versa.

As far as I can tell, in order to do this, a simple change would be
needed in
ImportTask. Rather than doing this in importResource:

helper.parse(getProject(), importedResource);

we would do something like:

ProjectHelper subHelper =
ProjectHelperRepository.getInstance().getProjectHelperForBuildFile(
importedResource);

// push current stacks into the sub helper
subHelper.getImportStack().addAll(helper.getImportStack());
subHelper.getExtensionStack().addAll(helper.getExtensionStack());
getProject().addReference(ProjectHelper.PROJECTHELPER_REFERENCE,
subHelper);

subHelper.parse(getProject(), importedResource);

// push back the stacks from the sub helper to the main one
getProject().addReference(ProjectHelper.PROJECTHELPER_REFERENCE,
helper);
helper.getImportStack().clear();
helper.getImportStack().addAll(subHelper.getImportStack());
helper.getExtensionStack().clear();
helper.getExtensionStack().addAll(subHelper.getExtensionStack());


For the little tests I have done with the groovy frontend, it seems
to work
quite well.

Actually it seems so simple that I am wondering if I might have
missed some
side effect. Did I ?


I suppose it's possible you missed something, but it seems okay.  If
it were me, I might work out a way to make the subHelper send its
imports/extensions directly back to the top-level ProjectHelper
rather than so much clearing and replacing, but I'll admit to being
somewhat paranoid.


I think I got paranoid too but the other way: I didn't want to  
change the API

of ProjectHelper that might be implemented around the world and bring
backward compatibility issues.



I didn't actually pick up on where there was an actual API change?   
Being backward-compatibility-obsessed as a project, we should expand  
rather than change our APIs...


-Matt

Thanks for the review, I will commit that probably with some  
additionnal unit

tests.

Nicolas



-Matt


At least the unit tests showed me that I did nothing that wrong.

Nicolas

 
-

To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Import and project helpers

[Matt Benson]

On Jul 16, 2010, at 8:25 AM, Nicolas Lalevée wrote:


Hi,

I did some other experiment with the groovy frontend to ant  
recently. And I
would like to be able to make a groovy build file import an xml  
build file

and vice versa.

As far as I can tell, in order to do this, a simple change would be  
needed in

ImportTask. Rather than doing this in importResource:

helper.parse(getProject(), importedResource);

we would do something like:

ProjectHelper subHelper =
ProjectHelperRepository.getInstance().getProjectHelperForBuildFile(
importedResource);

// push current stacks into the sub helper
subHelper.getImportStack().addAll(helper.getImportStack());
subHelper.getExtensionStack().addAll(helper.getExtensionStack());
getProject().addReference(ProjectHelper.PROJECTHELPER_REFERENCE,  
subHelper);


subHelper.parse(getProject(), importedResource);

// push back the stacks from the sub helper to the main one
getProject().addReference(ProjectHelper.PROJECTHELPER_REFERENCE,  
helper);

helper.getImportStack().clear();
helper.getImportStack().addAll(subHelper.getImportStack());
helper.getExtensionStack().clear();
helper.getExtensionStack().addAll(subHelper.getExtensionStack());


For the little tests I have done with the groovy frontend, it seems  
to work

quite well.

Actually it seems so simple that I am wondering if I might have  
missed some

side effect. Did I ?



I suppose it's possible you missed something, but it seems okay.  If  
it were me, I might work out a way to make the subHelper send its  
imports/extensions directly back to the top-level ProjectHelper  
rather than so much clearing and replacing, but I'll admit to being  
somewhat paranoid.


-Matt


At least the unit tests showed me that I did nothing that wrong.

Nicolas

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [Proposal] Capture attributes in unknown namespaces

[Matt Benson]

Like org.apache.tools.ant.Dynamic*NS?

-Matt

On Jun 24, 2010, at 2:50 PM, Danny Yates wrote:

 Hi guys,
 
 Me again!
 
 I have some more functionality that I'm interested in, but I fear it may be
 quite specific to my requirements, so I thought I'd run it past you all
 before getting to work on it.
 
 I'm developing a custom executor which can execute targets in parallel, and
 as an extension of that, it would be kind of cool to be able to mark
 individual targets as CPU-bound or IO-bound so that the executor can be a
 bit smarter about scheduling them. However, I can't find any sensible way to
 communicate this information to the executor.
 
 What would be kind of cool would be that if the parser encounters attributes
 in a namespace that it doesn't recognise, then instead of ignoring them (as
 it does now), it records them and makes them available through an API on the
 Project and Target objects. This would allow the executor to inspect them.
 
 I realise this is very specific to my parallel executor project, but I think
 adding it would be a non-breaking change that wouldn't have any impact on
 existing consumers of the API.
 
 What do you folks think?
 
 Cheers,
 
 Danny.


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [Proposal] Capture attributes in unknown namespaces

[Matt Benson]

On Jun 24, 2010, at 3:04 PM, Danny Yates wrote:

 Hmm... that's interesting. I hadn't discovered that before. It's not clear
 to me what that does - it appears to manipulate the DOM somehow.
 
 Could you explain what it's for and how to use it and then I can see if it
 will help me solve my current problem.
 

Admittedly, I didn't read the entire message to see _what_ you wanted 
namespaced attributes for.  :)  The Dynamic* interfaces are more for custom 
tasks, etc.  I could swear we've had a similar discussion about putting 
attributes on Targets before; at the very least you could create a custom 
ProjectHelper that instantiated a particular Target subclass.  One of our 
committers, Alexey Solofnenko, was once working on a parallel executor, but I 
don't know whether he ever completed it.

-Matt

 Many thanks,
 
 Danny.
 
 
 On 24 June 2010 20:58, Matt Benson gudnabr...@gmail.com wrote:
 
 Like org.apache.tools.ant.Dynamic*NS?
 
 -Matt
 
 On Jun 24, 2010, at 2:50 PM, Danny Yates wrote:
 
 Hi guys,
 
 Me again!
 
 I have some more functionality that I'm interested in, but I fear it may
 be
 quite specific to my requirements, so I thought I'd run it past you all
 before getting to work on it.
 
 I'm developing a custom executor which can execute targets in parallel,
 and
 as an extension of that, it would be kind of cool to be able to mark
 individual targets as CPU-bound or IO-bound so that the executor can be a
 bit smarter about scheduling them. However, I can't find any sensible way
 to
 communicate this information to the executor.
 
 What would be kind of cool would be that if the parser encounters
 attributes
 in a namespace that it doesn't recognise, then instead of ignoring them
 (as
 it does now), it records them and makes them available through an API on
 the
 Project and Target objects. This would allow the executor to inspect
 them.
 
 I realise this is very specific to my parallel executor project, but I
 think
 adding it would be a non-breaking change that wouldn't have any impact on
 existing consumers of the API.
 
 What do you folks think?
 
 Cheers,
 
 Danny.
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Remove commercial tasks from Ant

[Matt Benson]

On Jun 19, 2010, at 1:38 PM, Bruce Atherton wrote:

 Ant supplies several tasks that require commercial software in order to run. 
 This is a problem because the Ant developers do not typically have access to 
 the commercial products required to test, maintain, and enhance the tasks. It 
 also means that users downloading the binary edition of Ant end up with a lot 
 of tasks that they cannot use.
 
 In order to rectify this situation, I'm calling a vote on how to deal with 
 these unsupportable tasks. The vote is composed of two parts: should we drop 
 support for each of these tasks from the Ant release, and should we establish 
 the commercial tasks that have been dropped as Antlibs in the sandbox.
 
 1. Should the following commercial tasks be dropped from being distributed 
 with the Ant release?
 
 [  ]  Continuous/Synergy tasks:  CCMCheckin, CCMCheckout, CCMCheckinTask, 
 CCMReconfigure, CCMCreateTask
 [  ]  Clearcase tasks: CCCheckin, CCCheckout, CCUnCheckout, CCUpdate, 
 CCMklbtype, CCMklabel, CCRmtype, CCLock, CCUnlock, CCMkbl, CCMkattr, CCMkdir, 
 CCMkelem
 [  ]  Perforce Tasks: P4Sync, P4Change, P4Edit, P4Submit, P4Have, P4Label, 
 P4Labelsync, P4Counter, P4Reopen, P4Revert, P4Add, P4Delete, P4Integrate, 
 P4Resolve, P4Fstat
 [  ]  PVCS
 [  ]  ServerDeploy, but only for the jonas and weblogic nested elements, 
 generic can stay where it is.
 [  ]  Source Offsite: sosget, soslabel, soscheckin, soscheckout
 [  ]  Microsoft Visual SourceSafe (already an Antlib)
 

+1 to all

 2. Should the commercial tasks that are voted for dropping from Ant core 
 above be established in their own Antlibs in the sandbox?
 
 [  ]  +1 = Yes, establish one new Antlib in the sandbox for each task dropped
  -1 = No, just drop the commercial tasks altogether from Ant
 

+0

-Matt

 Note that question 1 is a  vote for code modification, so any -1 vote on 
 question 1 is considered a veto. Question 2 is just for guidance from the 
 community about whether there is a desire to keep the commercial tasks around 
 in Antlibs. Since any committer can create a sandbox Antlib at any time, the 
 vote is non-binding and any -1 vote just indicates that the voter does not 
 think that this is a good idea rather than being a veto.
 
 Three or more +1 votes with no -1 votes are required for dropping any of the 
 commercial tasks. The vote will end in one week.
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: A performance issue in 'restrict'

[Matt Benson]

On 6/15/10, Nicolas Lalevée nicolas.lale...@hibnet.org wrote:
 On Monday 14 June 2010 20:01:08 Matt Benson wrote:
 Hi, Nicolas:

 [SNIP]

  I looked into the code, it seems
  org.apache.tools.ant.types.resources.Restrict is the culprit. It uses
  BaseResourceCollectionWrapper which loads the entire underlying resource
  collection.
  I searched for the use of BaseResourceCollectionWrapper in Ant and I
  think that this performance issue may also affect
  org.apache.tools.ant.types.resources.SizeLimitCollection and
  org.apache.tools.ant.types.resources.Tokens.
 
  I started to think about a fix but it seems non trivial. If I'm not
  mistaken we would have to implement an iterator which should deal with
  an
  optionnal cache and concurrency.

 While it would be possible to reimplement Restrict's internal wrapper
 such that it would dynamically calculate the included resources while
 iterating, I don't see any way to do the same when the *size* of the
 collection is requested...

 Yep if size is called then the whole collection has to be fetched.
 I just hope that in my use case where I just want the first element of the
 restrict, the whole resource collection won't be fetched. And as I keep
 looking into the code, it seems that the implementation of
 org.apache.tools.ant.types.resources.First does that. So size() shouldn't be
 an issue here.

  I am also worried about the isFilesystemOnly implementation in Restrict.
  Should it return true if actually selected resources are files, or
  return
  true if the entire set of candidates are files ? In the first case it
  would make the iterator useless.

 Typically the implementation of #isFilesystemOnly() in
 BaseResourceCollectionWrapper and BaseResourceCollectionContainer is a
 quick check whether the underlying collection/s is/are known to be
 entirely filesystem-based.  If not, each resource is checked in turn
 until one is found that is *not* filesystem-based.  The reason for the
 distinction is to provide a means of recognizing whether it should be
 possible to handle a given resourcecollection using a task that can
 only work with files.

 So I am suggesting a little change on the implementation: removing the check
 isFilesystemOnly on the underlying resource collection; just keep the
 iteration on the actual resources of the underlying collection.
 I don't think it will change the semantic of the function, right?
 About performance, in my use case it should behave better as the first
 will
 only load one resource in the collection.
 I think there could be a performance impact where a resource collection is
 known to be file system only, and it is used with a task that cannot support
 that. The resources will be loaded but not actually used as the build will
 fail.
 So it seems a choice between:
  * useless iteration on some resources which can have high latency
  * useless iteration on some resources which should be on a filsytem and
 trigger a failed build.

 I prefer the second choice. I might not be impartial though ;)


I feel like if we get stuck on #isFilesystemOnly(), we're going to
lose sight of the important issue here.  This kind of diagnostic
method must, by definition, ultimately survey each resource, but
checking against the nested collection/s is a valuable optimization.
Consider the case where you may wrap a first in a sort in a
restrict of some other resourcecollection.  If each of these has to
fully iterate, that amounts to greater latency than attempting to
delegate that call all the way back to the innermost nested
collection, does it not?

The bigger issue is whether we can figure out a way to increase
throughput by delegating iterator calls.  The problem is that
BaseResourceCollectionWrapper and BaseResourceCollectionContainer both
implement the cache attribute by caching a collection of resources.
We could explore making the implementation of the cached collection
more efficient.  Once again, my understanding of your wider purpose
here is, given:

first
  restrict
someotherresourcecollection /
  /restrict
/first

You would like for the innermost collection to iterate only until
restrict accepts one of its resources.  Perhaps the original
implementation is naive in its simplicity.  It has been several years
now since the bulk of that code was added to Ant; if we can figure out
how to optimize it now I would be perfectly happy with that, but I
don't think #isFilesystemOnly() is germane to that efficiency
discussion.

-Matt

 Nicolas



 -Matt

  Side note: I didn't checked that piece of script in as our Hudson
  instance doesn't have Ant 1.8 installed. Not yet. I'll ask for it.
 
  Nicolas
 
  [1] http://ant.apache.org/manual/Types/resources.html#resourcelist
 
  PS: I started recently to intensively use loadresource and all the
  resource related stuff in my build scripts, it is amazingly porwerful !
  It reminds me when I was 'pipelining' in cocoon

Re: A performance issue in 'restrict'

[Matt Benson]

Hi, Nicolas:

[SNIP]
 I looked into the code, it seems
 org.apache.tools.ant.types.resources.Restrict is the culprit. It uses
 BaseResourceCollectionWrapper which loads the entire underlying resource
 collection.
 I searched for the use of BaseResourceCollectionWrapper in Ant and I think
 that this performance issue may also affect
 org.apache.tools.ant.types.resources.SizeLimitCollection and
 org.apache.tools.ant.types.resources.Tokens.

 I started to think about a fix but it seems non trivial. If I'm not mistaken
 we would have to implement an iterator which should deal with an optionnal
 cache and concurrency.

While it would be possible to reimplement Restrict's internal wrapper
such that it would dynamically calculate the included resources while
iterating, I don't see any way to do the same when the *size* of the
collection is requested...

 I am also worried about the isFilesystemOnly implementation in Restrict.
 Should it return true if actually selected resources are files, or return
 true if the entire set of candidates are files ? In the first case it would
 make the iterator useless.


Typically the implementation of #isFilesystemOnly() in
BaseResourceCollectionWrapper and BaseResourceCollectionContainer is a
quick check whether the underlying collection/s is/are known to be
entirely filesystem-based.  If not, each resource is checked in turn
until one is found that is *not* filesystem-based.  The reason for the
distinction is to provide a means of recognizing whether it should be
possible to handle a given resourcecollection using a task that can
only work with files.

-Matt

 Side note: I didn't checked that piece of script in as our Hudson instance
 doesn't have Ant 1.8 installed. Not yet. I'll ask for it.

 Nicolas

 [1] http://ant.apache.org/manual/Types/resources.html#resourcelist

 PS: I started recently to intensively use loadresource and all the resource
 related stuff in my build scripts, it is amazingly porwerful ! It reminds me
 when I was 'pipelining' in cocoon ;)


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Extending path

[Matt Benson]

I'm not sure what filelist has that you need to begin with...
sequence?  You might be better off creating a resource type that
decorates another resource to add the attributes you need, i.e. adding
'scope' to some file-based resource.  Then you could create those
directly, or implement a resource collection to transform the
resources of some other resource collection to your new resource type.
 This approach is probably your best best because then your resources
should be usable by whatever other tasks know how to deal with
filesystem-based resources.

HTH,
Matt

On 6/7/10, Jon Stevens latch...@gmail.com wrote:
 Anyone? Stefan?

 On Fri, Jun 4, 2010 at 11:52 AM, Jon Stevens latch...@gmail.com wrote:
 Hi all,

 Been a long long time since I've been around these parts, so apologies
 if this has been covered before.

 What I'd like to do is be able to add a couple of attributes to the
 file element that lives in a filelist and then get access to those
 attributes in my Task. I've mucked around for the last couple hours on
 seeing how I could extend the existing ant code to make this happen
 and it really doesn't seem easily possible.

 For example:

    path id=filelist.classpath
        myfilelist dir=${lib.dir}
            file name=${ant.jar} src=thesrc scope=run /
            file name=svntask.jar src=svntasksrc scope=compile /
        /myfilelist
    /path

 myTask
    classpath refid=foo /
 /myTask

 Thus, in MyTask.java, I have:

    private ListPath classpaths = new ArrayListPath();

    public void addClasspath(Path classpath) {
        classpaths.add(classpath);
    }

 This works fine.

 However, since there is no way to access the Union within a Path, I'm
 kind of stuck cause I can't access the actual myfilelist objects to
 get out my additional attributes. I could implement my own Path
 object, but that is kind of a pain as I've already had to copy/paste
 the source code for FileList.

 I guess, ideally, Ant would be a lot more extensible if all of the
 private fields had getter/setters and internally those getter/setters
 were used instead of direct access. This would allow me to more easily
 extend the existing Ant objects.

 What I'm trying to accomplish is the ability to define a path within
 Ant and then be able to pass that to a Task that I wrote that can
 generate the Eclipse .classpath and .launch files. The task will be
 smart about looking at the scope (run/compile) as well as pointing to
 the source for the jar file.

 Thoughts?

 jon


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE-RESULTS] use nexus for maven upload of ant release

[Matt Benson]

Antoine:  I'm not sure about this, but it may be that the
maven-metadata shows that 1.8.1 is the only version managed through
the Apache Nexus install, but when 1.8.1 propagates out to maven
central, the earlier versions as well as 1.8.1 will be represented in
that metadata.

-Matt

On 5/24/10, Antoine Levy-Lambert anto...@gmx.de wrote:
 Hi,

 I have succeeded to upload ant 1.8.1 using nexus. [1]

 Thanks Maarten for your help.

 There is an issue though that the maven-metadata.xml files such as [2] now
 are mentioning only the 1.8.1 version of ant. Brian Fox says that this does
 not affect the usability of these versions (1.7.0, 1.7.1, 1.8.0). I remember
 something different though. I remember Stefan wanted me to get the maven
 team to also show 1.7.1 in the maven-metadata.xml files. These
 maven-metatada.xml are managed by the maven infrastructure, not
 created/uploaded by us.


 Regards,

 Antoine

 [1] https://issues.apache.org/jira/browse/INFRA-2706
 [2] http://repo1.maven.org/maven2/org/apache/ant/ant/maven-metadata.xml
  Original-Nachricht 
 Datum: Wed, 19 May 2010 14:36:47 -0700 (PDT)
 Von: Maarten Coene maarten_co...@yahoo.com
 An: Ant Developers List dev@ant.apache.org
 Betreff: Re: [VOTE-RESULTS] use nexus for maven upload of ant release


 Let's hope you succeed, I'll probably have to do the same exercise soon
 when uploading the next Ivy release...

 Maarten




 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE-RESULTS] use nexus for maven upload of ant release

[Matt Benson]

--hence my declaration of being less than sure.  You are correct.  I
have no idea then!  :)

-Matt

On 5/24/10, Antoine Levy-Lambert anto...@gmx.de wrote:
 Hello Matt,


  Original-Nachricht 
 Datum: Mon, 24 May 2010 15:58:06 -0500
 Von: Matt Benson gudnabr...@gmail.com
 An: Ant Developers List dev@ant.apache.org
 Betreff: Re: [VOTE-RESULTS] use nexus for maven upload of ant release

 Antoine:  I'm not sure about this, but it may be that the
 maven-metadata shows that 1.8.1 is the only version managed through
 the Apache Nexus install, but when 1.8.1 propagates out to maven
 central, the earlier versions as well as 1.8.1 will be represented in
 that metadata.

 http://repo1.maven.org/maven2/org/apache/ant/ant/maven-metadata.xml lists
 only 1.8.1. Is this URL not on central ?


 -Matt

 Regards,

 Antoine

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] use nexus for maven upload of ant release

[Matt Benson]

On May 13, 2010, at 3:19 PM, Antoine Levy-Lambert wrote:


Hi,

Brian Fox on the repository list has advised me to upload the ant  
artefacts to the maven repository using nexus. [1]


I have entered a sub-task of INFRA-1996 Track projects that want  
to use the Nexus repository infrastructure for snapshots/releases  
deployment [2]


I realize now that a vote is required to actually do this upload



I wondered when you would.  ;D


Do we want to use nexus to upload our ant release to nexus

[X] Yes

[ ] No

Do we want to use nexus to upload the antlibs

[X] Yes

[ ] No

Do we want to use nexus to upload ivy

[X] Yes

[ ] No



Nexus does work well with Ivy, FWIW.  We should be able to eat our  
own dogfood to deploy our artifacts to Nexus.


-Matt



Regards,

Antoine

[1] http://mail-archives.apache.org/mod_mbox/www-repository/ 
201005.mbox/%3c2010051210.14...@gmx.net%3e

[2] https://issues.apache.org/jira/browse/INFRA-1896


 Original-Nachricht 

Datum: Tue, 11 May 2010 20:23:21 +0200
Von: Antoine Levy-Lambert anto...@gmx.de
An: dev@ant.apache.org
Betreff: Upload of ant 1.8.1 in maven2 repository



Hi,

I have just seen that there is some inconsistency in the upload of  
ant
1.8.1 in the maven2 repository, the jars have been uploaded to new  
directories

[1] but the maven-metadata.xml files have not been updated [2].

I have reported this to the repository team on a parallel email  
and will

keep you posted.

Regards,

Antoine
[1] http://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.8.1/
[2]
http://repo1.maven.org/maven2/org/apache/ant/ant-parent/maven- 
metadata.xml


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: move-test fails on Windows7

[Matt Benson]

I'm not sure.  We probably need to do a little more testing but I'm on
OSX right now and don't have any Win7 system at my disposal.  Later
today I can verify what was returned on XP for new
File(abc).equals(new File(ABC)) .

On 4/25/10, Stefan Bodewig bode...@apache.org wrote:
 On 2010-04-23, Matt Benson gudnabr...@gmail.com wrote:

 On Apr 23, 2010, at 3:08 AM, Stefan Bodewig wrote:

 The problem is this code in Move#renameFile


 sourceFile = getFileUtils().normalize
 (sourceFile.getAbsolutePath()).getCanonicalFile();
 destFile = getFileUtils().normalize
 (destFile.getAbsolutePath());
 if (destFile.equals(sourceFile)) {
 //no point in renaming a file to its own canonical
 version...
 log(Rename of  + sourceFile +  to  + destFile
 +  is a no-op., Project.MSG_VERBOSE);
 return true;
 }

 Using Win7 destFile.equals(sourceFile) returns true so no attempt is
 even made to rename abc to aBc.  Using WinXP it must have returned
 false (can't test it anymore).

 IIRC the purpose is to detect the attempted rename of a file to its
 own canonical name, e.g. when the original name case-insensitively
 equals the target name on a case-insensitive filesystem.

 OK, you mean in a situation where the file is called abc on the disk
 and we reach it via new File(ABC) then we don't want to rename it to
 abc (because that already is the name on disk).

 Given that new File(abc).equals(new File(ABC)) on Win7 now we
 probably better modify the test to compare the file names directly
 rather than the File objects.

 Am I getting this right?

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: move-test fails on Windows7

[Matt Benson]

On Apr 23, 2010, at 3:08 AM, Stefan Bodewig wrote:


On 2010-04-22, Stefan Bodewig bode...@apache.org wrote:


On 2010-04-21, Steve Loughran ste...@apache.org wrote:



So perhaps the check for windows (and special handling) is failing



I'll try to fix it.


There is no Windows specific code, I've reopened bug 41948 because its
fix doesn't seem to work reliably on Windows7 anymore.

The problem is this code in Move#renameFile


sourceFile = getFileUtils().normalize 
(sourceFile.getAbsolutePath()).getCanonicalFile();
destFile = getFileUtils().normalize 
(destFile.getAbsolutePath());

if (destFile.equals(sourceFile)) {
//no point in renaming a file to its own canonical  
version...

log(Rename of  + sourceFile +  to  + destFile
+  is a no-op., Project.MSG_VERBOSE);
return true;
}

Using Win7 destFile.equals(sourceFile) returns true so no attempt is
even made to rename abc to aBc.  Using WinXP it must have returned
false (can't test it anymore).

I would understand why we wanted to skip the rename operation if  
the old

and new absolute and normalized file names were the same, but I don't
understand how and why we are comparing one canonical file to a
non-canonical one and then decide we don't need a rename if they  
are the

same.

Matt, Martijn or Antoine, you've been involved in fixing the bug many
moons ago - do you still remember why the condition has been written
that way?



IIRC the purpose is to detect the attempted rename of a file to its  
own canonical name, e.g. when the original name case-insensitively  
equals the target name on a case-insensitive filesystem.


-Matt


Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [POLL] Bug 48804

[Matt Benson]

On Apr 23, 2010, at 4:29 AM, Stefan Bodewig wrote:


Hi all,

currently extension-point and import don't play together like they are
supposed to.  You can't extend an imported extension point with a  
target

from the importing build file (which is the primary use-case, really).

Attached to this bug is a patch that fixes the problem (including an
AntUnit test that fails in 1.8.0).

The same patch breaks a different AntUnit test, namely
testExtensionPointMustBeKnown in extension-point-test.xml.  This test
asserts that you can't extend an extension point from the same build
file before that extension point has been defined.  I.e. you can't do

  target name=bar extensionOf=foo/
  extension-point name=foo/

Personally I think the changed behavior isn't a bad thing, the old
behavior isn't documented and we shouldn't even try to keep it.

What do you think?



I don't see any harm in allowing an extensionOf foo to be declared in  
the same buildfile as extension-point foo.  In contrast, I have been  
frustrated by the primary issue from the referenced bugrep.  Which  
all translates to my being in general agreement with your opinion.


-Matt


Stefan

PS: I'd love to see this fixed with Ant 1.8.1.

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [Result][Vote] Augment feature

[Matt Benson]

Thanks for conducting the vote, Bruce.  The task has been added.

-Matt

On Apr 20, 2010, at 3:46 PM, Bruce Atherton wrote:

I lost my email server for a few days, so I can only now close the  
vote and post the results. I believe that between my returned email  
feed and the record of posts on MarkMail[1] I have all the results.  
If you feel your vote was missed, let me know.


On question 1, whether to adopt the augment feature code, we had:

7 votes for +1 from Jean Louis, Matt, Bruce, Stefan, Jan, Dominque,  
Antoine

1 vote for -0.5 from Martijn

With more than 3 +1 binding votes and no -1 vetos, the motion passes.

On question 2, whether to have a final attribute, the vote was:

1 votes for +1 from Jean Louis
3 votes for +0 from Jan, Dominique, Antoine
3 votes for -0 from Matt, Bruce, Stefan

Without the 3 +1 binding votes required, the motion fails.

The failure of the second question makes the third moot, but for  
the sake of history, the result of making the final attribute  
defualt to false was:


6 votes for +1 from Jean Louis, Matt, Bruce, Jan, Dominique, Antoine
1 vote for +0 from Stefan

So the augmentation feature is voted in with +7 positive votes and  
-0.5 negative ones. The final attribute fails, and the default  
value of the final attribute is rendered moot.


Thanks everyone for voting.

[1] http://ant.markmail.org/search/?q=#query:%20list% 
3Aorg.apache.ant.dev+page:1+mid:o7hllwxqvkvru4hx+state:results



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [Vote] Augment feature

[Matt Benson]

Martijn,
  augment can change properties that are coded as attributes, but
only interacts with nested elements by adding new children to a given
reference.  The task as it stands is extremely, extremely simple.  Any
restrictions we care to impose would complicate it immensely--I would
again urge that we consider addressing this universally for all
attack vectors by creating a task to armor a reference.  In my
copious spare time (ha) I may start a sandbox antlib for that purpose.
 Thanks for not wanting to be a blocker.  :)

-Matt

On 4/18/10, Martijn Kruithof j...@famkruithof.net wrote:
 Hello

 I have quite some difficulties with the discrepancy of the name of the
 task and that what the task is about to do.
 Therefore, using the current name and functionality I would cast a -0,5
 vote, as i do not want to be blocking.
 I can see the desire for a task that changes predeclared id's.

 My objection against the current name comes from the fact that the task
 not only augments (basically adds, increases, stretches, enlarges etc.)
 things but it is used to change the path at will.

 On the other hand I think free modification of references seems like a
 giant pitfall in the following situations:
   - when used in combination with parrallel
   - when related tasks in a script expect the same elements present on
 the path

 If the augment task was used to do only what its name implies (extend)
 and not to reduce less problems could be expected.
 Therefore I would be in favour of an augment feature if it can only be
 used to augment (and not change at will).


 On 14-4-2010 0:34, Bruce Atherton wrote:
 Ok, so this didn't start out as a vote thread, just my suggestion for
 what questions should appear in the vote. But since it has morphed
 into that I've changed the subject line to make it easier for people
 to find. So the questions are:

 1. Are you in favor of adding the augment feature to Ant?

 -0,5 : Non blocking negative look. +1 if augment is only used to augment
 (increase, extend, combine, add to the existing)

 2. Are you in favor of an attribute that allows references to be
 marked as final, to avoid augmentation?

 3. If a final attribute is decided upon, do you think it should
 default to false?

 If you have already voted, no need to recast your vote.


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: svn commit: r933177 - /ant/antlibs/props/trunk/src/main/org/apache/ant/props/NestedPropertyExpander.java

[Matt Benson]

Good catch; I was afraid there might be similar issues lurking  
there.  ;)


-Matt

On Apr 12, 2010, at 5:25 AM, bode...@apache.org wrote:


Author: bodewig
Date: Mon Apr 12 10:25:46 2010
New Revision: 933177

URL: http://svn.apache.org/viewvc?rev=933177view=rev
Log:
remove costly indexOf - see revision 932588 of core's PropertyHelper

Modified:
ant/antlibs/props/trunk/src/main/org/apache/ant/props/ 
NestedPropertyExpander.java


Modified: ant/antlibs/props/trunk/src/main/org/apache/ant/props/ 
NestedPropertyExpander.java
URL: http://svn.apache.org/viewvc/ant/antlibs/props/trunk/src/main/ 
org/apache/ant/props/NestedPropertyExpander.java? 
rev=933177r1=933176r2=933177view=diff
== 

--- ant/antlibs/props/trunk/src/main/org/apache/ant/props/ 
NestedPropertyExpander.java (original)
+++ ant/antlibs/props/trunk/src/main/org/apache/ant/props/ 
NestedPropertyExpander.java Mon Apr 12 10:25:46 2010

@@ -39,7 +39,8 @@ public class NestedPropertyExpander impl
 public String parsePropertyName(String value, ParsePosition pos,
 ParseNextProperty parseNextProperty) {
 int start = pos.getIndex();
-if (value.indexOf(${, start) == start) {
+if (value.length() - start = 3
+ '$' == value.charAt(start)  '{' == value.charAt 
(start + 1)) {
 parseNextProperty.getProject().log(Attempting nested  
property processing,

 Project.MSG_DEBUG);
 pos.setIndex(start + 2);





-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: svn commit: r932456 - /ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java

[Matt Benson]

On Apr 9, 2010, at 10:34 AM, Stefan Bodewig wrote:


On 2010-04-09, mben...@apache.org wrote:


Address indexOf inefficiency in PropertyHelper embedded
skip-double-dollar propertyexpander implementation.


Maybe we should also modify the code in DEFAULT_EXPANDER since it will
call indexOf repeatedly as well.


Let me check that.


I've started to write a test for this but even with a couple MB of
random text and property references I fail to see any big performance
differences between 1.8.0 and 1.7.1 on my machine.


I wondered about that.  :|  Do what we can for now I guess?

-Matt



Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: task that allows augmentation of previously declared references

[Matt Benson]

On Mar 22, 2010, at 5:42 AM, Jean-Louis Boudart wrote:


Sorry for the delay.

I really like the idea of being able to augment previously declared
reference. There is many uses cases where it can be useful.
For example, if ant can provides such feature it would simplify a  
lot the

job in easyant for projects using many directories as source folder.
They will just need to augment the fileset used for source folder.

It makes also senses for other dataType.

I'm also +1 for the final=false attribute.

By the way i think the only use case that is discutable is for  
path. Most
of the time we want to append something to an existing classpath,  
so here
augment make sense. But how will the augment feature will help us  
if we want
to prepend things in the classpath (for example if we use coverage  
tools,

instrumented classes must be put before the compiled classes in the
classpath)?
In EasyAnt we've defined our own path task that handle this use  
cases

(allowing prepend / append / overwrite).
Considering that this problem cannot be solved just by using augment
feature, should we improve the behavior of path task? or let each  
projects

defined their own task to do this?

Is the augment feature already commited on trunk (i've not checked  
the trunk

for a while)? Is it targeted to be in the 1.8.1?



It depends on the timeframe for 1.8.1.  I haven't been able to  
clearly gauge the general direction of majority opinion on the  
final issue.


-Matt


My 2 cents




2010/2/25 Dominique Devienne ddevie...@gmail.com


On Thu, Feb 25, 2010 at 10:00 AM, Gilles Scokart gscok...@gmail.com
wrote:

Did you have any example to demonstrates the benefits of such task ?


The benefits with conjunction with import could be important, in
that you can mix-in specialized pre-defined builds dealing with
specific concerns (like JAXB pre-compilation for example) and have
those builds implicitly augment the classpath or Javac source path
appropriately for example (as documented in those builds, and you do
explicitly import those, so are kinda in control). Sure, it does open
the door for some complexity, and Ant would enter some un-chartered
waters indeed, but when trying to design reusable builds in the
(distant now) past, I've often felt the need for such a feature. Yet
it doesn't necessarily mean that would have been the right solution
either. I'd be interesting to have the input of the EasyAnt people on
the matter in fact. Maybe an opt-in approach, explicitly adding
final=false on those datatype ids *designed* for extension,  
would be

a more conservative introduction of this feature, although that does
force to have perfect hindsight into what will be necessary to
extend/augment or not. --DD

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org





--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: IvyDE 2.1.0 Release

[Matt Benson]

I have now tested the RC and can offer my +1.

-Matt

On Mar 19, 2010, at 8:10 AM, Jon Schneider wrote:

Just a reminder on this vote... Any other binding voters other than  
Maarten

care to offer an up or down vote ;) ?

Thanks,
Jon


On Sun, Mar 14, 2010 at 5:24 PM, Maarten Coene  
maarten_co...@yahoo.comwrote:



Do you vote for the release of these binaries?
[X] Yes
[ ] No

I was able to install it now and didn't notice any problem so far,  
although

I must admit I'm not using any of the more advanced features...

Maarten




- Original Message 
From: Jon Schneider jschnei...@apache.org
To: Ant Developers List dev@ant.apache.org
Sent: Thu, March 11, 2010 8:58:58 PM
Subject: IvyDE 2.1.0 Release

The final IvyDe 2.1.0 release has been re-built.  This build  
includes the
optional XML editor manifest.  Also, the jars I signed previously  
that had
the short PGP key have been resigned with my new longer key and  
the new key

has been added to the ant keystore.

You can download the distribution from this URL:
http://people.apache.org/~jschneider/ivyde-2.1.0/

And a staging update site has been setup here:
http://people.apache.org/~jschneider/staging/updatesite/

Do you vote for the release of these binaries?

[ ] Yes
[ ] No

Thanks,

Jon





-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: task that allows augmentation of previously declared references

[Matt Benson]

Okay, let's reason this out... since tasks and types are Java objects  
can we assume that a Java property final is unlikely enough to be  
used that we can use it as a configuration attribute?  Now, any  
id'd item would declare final=false if it wanted to be augmentable.   
This would require changes in the way we handle references, but   
would seem doable.


On Mar 1, 2010, at 11:22 PM, Stefan Bodewig wrote:


On 2010-02-25, Matt Benson gudnabr...@gmail.com wrote:


I'd like to direct the Ant developers' attention to https://
issues.apache.org/bugzilla/show_bug.cgi?id=48798 for discussion.


I'm with the other people in this thread who'd prefer to make this an
option that reference have to opt-in to so that not all references can
be augmented.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org