Re: [VOTE] Release Apache Ant 1.10.14 based on RC1

[Paul King]

+1 (non-binding)

I did a casual inspection of the zip artifact including checking for
LICENSE & NOTICE files, and confirming its hash & signature.
I ran the Apache Groovy test suite against the candidate maven artifacts
for JDK 17 and 19.

Cheers, Paul.


On Wed, Aug 16, 2023 at 10:35 PM Jaikiran Pai  wrote:

> Hello everyone,
>
> I've created RC1 release candidate for Ant 1.10.14 release:
>
> git tag: ANT_1.10.14_RC1
>
>  on commit: 53f19eccf49acf526415997046dca5a5135b0e8f
>
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>
>  revision: 63474
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapacheant-1057
>
>
> Apart from regular bug fixes, this 1.10.14 release has crucial changes
> around Ant's usage of Java SecurityManager. Many of you will be aware
> that Java 17 deprecated (for removal) the use of SecurityManager. Java
> 18 then disallowed setting SecurityManager at runtime, by default. Ant
> internally sets a SecurityManager at runtime to prevent System.exit()
> calls from within tasks, from killing the JVM in which Ant process is
> running. In Ant 1.10.13, we tried to keep using the SecurityManager
> internally for a few more releases in Ant, to facilitate projects to use
> Ant without requiring (major) changes to their build. The workarounds we
> put in place in Ant 1.10.13 were brittle and complex and although we had
> hoped they won't break user builds, they did end up breaking several
> builds. Ultimately, these workarounds for usage of SecurityManager are
> no longer feasible or adding value.
>
> As such, this 1.10.14 release of Ant will no longer use (or set) Java
> SecurityManager when running on Java versions 18 and higher. This has
> implications for projects using Ant. Specifically, if any of the build
> tasks (for example the "", "" or "" tasks)
> or libraries used in those tasks are calling System.exit() or
> Runtime.exit() and aren't forking a new JVM, then when running on Java
> 18 and higher, they may notice that the Ant JVM process gets killed.
> Such builds are recommended to either not call
> System.exit()/Runtime.exit() or use the "fork=true" option in relevant
> tasks (wherever appropriate).
>
> Furthermore, the usage of "" type when running on Java 18
> and higher is no longer supported. More details are available in the
> manual of that type https://dist.apache.org/repos/dist/dev/ant/manual/.
>
> The complete set of changes in this release are noted in
> https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.14.html.
>
> Please do give this proposed release version a try against whichever
> Java runtime versions you plan to use it against (this version requires
> a minimum of Java 8 runtime, like any other Ant 1.10.x versions). Even
> if you don't vote, if you do run into issues, please report back - it
> takes time to create Ant releases, so catching any blocker issues (like
> some of which we saw after Ant 1.10.13 was released) early will help fix
> them sooner.
>
> This vote will be open for at least 72 hours and close no earlier than
> 19th August 2023 12 PM.
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Release Ant 1.10.13?

[Paul King]

Thanks for the update. We have some workarounds in the Groovy codebase too.
I'll try to tidy them up too once this has settled.

Thanks again, Paul.

On Mon, May 15, 2023 at 10:08 PM Jaikiran Pai  wrote:

> Hello Paul,
>
> On 12/12/22 5:30 am, Paul King wrote:
> > Do you know if there is an issue with the "allow" class approach if
> > multiple projects adopt that technique? E.g. if Netbeans or Groovy
> > also have an allow class, will that cause a split package violation or
> > since it isn't really referenced except for those early JDKs, that we
> > should be okay? I will eventually try this out myself if searching
> > doesn't help, but just wondering if someone has already checked this.
>
> The use of a "allow" class as a workaround to older versions of JDK
> considering this value as a classname for -Djava.security.manager system
> property, was always a brittle one. As such, Oracle JDK in its upcoming
> October CPU release is going to introduce a change which will treat the
> values "allow" and "disallow" specially (by ignoring them and not
> considering them as a classname) for the java.security.manager system
> property. This will be available in Oracle's 11, 8 and 7 releases and is
> being tracked in https://bugs.openjdk.org/browse/JDK-8301118. Hopefully
> other vendors too will bring in this change in their releases.
>
> What that will then mean is that, applications/users will no longer have
> to first detect the version of Java before deciding whether or not they
> can set the value "allow" for the java.security.manager system property
> (if at all they want to set that value).
>
> As a related note, after Ant 1.10.13 was released we have received
> reports that the "allow" workaround we introduced, has its own set of
> issues. It was always a temporary change in Ant to allow for this
> version of Ant to work against recent releases of Java. I'm in the
> process of undoing this "allow" workaround and then completing skipping
> setting of SecurityManager against recent versions of Java, in Ant.
>
> -Jaikiran
>
>
>

Re: Release Ant 1.10.13?

[Paul King]

Do you know if there is an issue with the "allow" class approach if
multiple projects adopt that technique? E.g. if Netbeans or Groovy
also have an allow class, will that cause a split package violation or
since it isn't really referenced except for those early JDKs, that we
should be okay? I will eventually try this out myself if searching
doesn't help, but just wondering if someone has already checked this.

On Sun, Dec 11, 2022 at 11:38 PM Jaikiran Pai  wrote:
>
> Hello Stefan,
>
> On 18/11/22 2:40 pm, Stefan Bodewig wrote:
> > On 2022-11-16, Jaikiran Pai wrote:
> >
> >> Users can still use the current released Ant version against these
> >> recent Java versions, but they additionally have to set a system
> >> property while launching Ant to allow setting the security
> >> manager. Ant's mainline code has changes where it does the necessary
> >> work (to the extent possible) to set this property internally without
> >> forcing the users to do that. So releasing this version of Ant should
> >> help projects building against these recent versions.
> > I guess you've seen Earl Hood's response, I haven't looked into it
> > myself, yet.
>
> Yes, that response helped me decide which way to go. Before that, I was
> still inclined to try and get this working by doing necessary changes to
> the launcher scripts - but that was going nowhere and it introduced the
> unnecessary dual launch of Java (once to identify the version and then
> the real launch). ewh's response gave me the confidence that using
> "allow" as a class (on Java versions where it isn't recognized as a
> predefined value) would be the better of the 2 approaches.
>
> I found some time this weekend to get this implemented in Ant and have
> now committed
> https://github.com/apache/ant/commit/82c70f3202d5aec4d99fa3b6314ba4a6c338cd94.
> Tests against JDK 8, 11, 17, 19 and latest 20 EA all came back fine
> against Linux and Windows.
>
> -Jaikiran
>
>
>
> -
> 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] Release Apache Ant 1.10.12 based on RC1

[Paul King]

+0 (non-binding)

I checked:
* LICENSE & NOTICE seem okay
* HASH & SIG seem okay
* I ran against the Groovy test suite which has 100+ ant-related tests and
all continue to pass (using JDK16 and the upcoming Groovy 4)

I was surprised to see binary jars in the src archives under lib/optional.
I don't know the history, so perhaps it is fine.

Cheers, Paul.



On Thu, Sep 30, 2021 at 12:58 PM Jaikiran Pai  wrote:

> I've created a release candidate for 1.10.12:
>
> git tag: ANT_1.10.12_RC1
>   on commit: cb7f242aa099c069bd75e6ee4d6e50b56fd73b71
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>revision: 50166
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapacheant-1051/
> Snapcraft Build
>Revision 21 in latest/candidate
>
> This release is mainly a bug fix release and the exact changes are noted
> in
> https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.12.html.
> Of particular interest is the relatively minor bug fix in the javadoc
> task which is necessary for it to work properly in the recently released
> Java 17 version.
>
> This vote will be open at least for 72 hours and close no earlier than
> 4th October 2021 03:00 AM UTC (given that it's a weekend in the next
> couple of days, I decided to extend the voting period till Monday)
>
>
> -Jaikiran
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [VOTE] Release Apache Ant 1.10.10 based on RC1

[Paul King]

+1 (non-binding)

* Checked signatures and hashes for zip and tar.gz src distributions.
* I also ran the Apache Groovy build against the new artifacts. The Groovy
test suite has >100 tests exercising various aspects of Ant functionality
for Groovy's AntBuilder and Groovy's various Ant tasks. There were no
failures.

Cheers, Paul.


On Mon, Apr 12, 2021 at 2:31 PM Jaikiran Pai  wrote:

> I've created a release candidate for 1.10.10:
>
> git tag: ANT_1.10.10_RC1
>   on commit: eccd0a2ceb4fa854ee9f2a95cfea10d55a485dda
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>revision: 46988
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapacheant-1047/org/apache/ant/
> Snapcraft Build
>Revision 18 in latest/candidate
>
> This vote will be open at least for 72 hours and close no earlier than
> 15th April 2021 04:30 AM UTC.
>
>
> -Jaikiran
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [VOTE] Release Apache Ant 1.10.8 based on RC1

[Paul King]

+1 (non-binding)

I checked 1.10.8 with AdoptOpenJDK 11.0.6:
+ checksums and signatures for src and bin zips
+ cursory glance at LICENSE/NOTICE files seemed okay
+ ran against Groovy's test suite (GROOVY_3_0_X branch) which invokes
several hundred related tests for Groovy's Ant tasks, AntBuilder and
various usages of ant, ant-testutil, ant-junit, ant-launcher and ant-antlr
artifacts

Cheers, Paul.


On Mon, May 11, 2020 at 12:59 AM Stefan Bodewig  wrote:

> Hi all
>
> I've created a release candidate for 1.10.8:
>
> git tag: ANT_1.10.8_RC1
>  on commit: e04bc3455
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>   revision: 39345
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapacheant-1045/org/apache/ant/
> Snapcraft Build
>   Revision 15 in latest/candidate
>
> This Vote will be open at least for 72 hours and close no earlier than
> 2020-05-13 15:00UTC.
>
> Cheers
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [ant] branch master updated: Clarify the snapcraft release command

[Paul King]

For Groovy we use a single command but as part of push with multiple
--release options, something like:

snapcraft push --release=3.0/beta --release=beta groovy_3.0.0-beta-3_all.snap


On Thu, Sep 5, 2019 at 5:08 PM Stefan Bodewig  wrote:

> On 2019-09-05,  wrote:
>
> > -$ snapcraft release ant REVISION latest/stable 1.10/stable
> > +$ snapcraft release ant REVISION latest/stable
> > +$ snapcraft release ant REVISION 1.10/stable
>
> I'm pretty sure I've done it with the single command when I published
> 1.10.6, but I may be wrong. Also the snapcraft CLI may have changed in
> between.
>
> Thank you for improving the instructions.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: [VOTE] Release Ant 1.10.5 based on RC1

[Paul King]

+1 (non-binding)

I ran the Groovy test suite against the candidate jars and everything
passed.
There are over 100 tests related to AntBuilder and the groovy, groovyc,
groovydoc ant tasks.

Cheers, Paul.


On Tue, Jul 10, 2018 at 7:55 PM Stefan Bodewig  wrote:

> Hi all
>
> I've created a new release candidate for 1.10.5 with a few bug fixes and
> and the "single source executable" feature for Java11.
>
> git tag: ANT_1.10.5_RC1
>  on commit: c0848d2c6
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>  revision: 28015
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapacheant-1035/org/apache/ant/
>
> This Vote will be open at least for 72 hours and close no earlier than
> 2018-07-13 10:00UTC.
>
> Cheers
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Ant Contrib

[Paul King]

On Sun, Jun 4, 2017 at 7:47 PM, Gintautas Grigelionis <
g.grigelio...@gmail.com> wrote:

> [...]
> P.S. While we're at it, in the light of the latest ASM debacle, I'm
> interested in improving Ant classloader task

[...]


Which ASM issue(s) are you referring to? Is there a link to some
discussions?

Cheers, Paul.

Re: Minimum Java runtime version for proposed upcoming Ivy release

[Paul King]

The current version of Groovy has 1.6 as the minimum but is our maintenance
stream.
The upcoming next version will require 1.7 and versions with 1.8 as the
minimum are not too far away.

Ant 1.9.x is still on Java5 but Ant 1.10.x requires Java 8.

I don't think Gradle uses any Ivy classes any more.

I'd recommend 1.7 since most active projects will be releasing on 1.7/1.8
and then after a release, if all goes well activity-wise, I'd then bump the
Ivy version and target 8.

Cheers, Paul.


On Thu, May 18, 2017 at 7:14 PM, Nicolas Lalevée  wrote:

> I think that upgrading the requirement on the JDK is a good idea, because
> at least us, the maintainers, need at some point to be able to test it if
> there is an issue with that minimum JDK.
>
> One thing to consider is which JDK is being required in the environment
> Ivy is being used: Ant, Gradle, SBT, Eclipse, Intellij… We shouldn’t
> require too high.
>
> Nicolas
>
> > Le 18 mai 2017 à 10:58, J Pai  a écrit :
> >
> > Now that the plan seems to be to release 2.5.x of Ivy, would it be fine
> if we mandate the _minimum_ Java runtime version to be something higher
> than Java 5 that’s currently supported for 2.4.x
> http://ant.apache.org/ivy/history/latest-milestone/compatibility.html.
> >
> > Given that Java 6 itself has long been EOLed, I’m not sure whether we
> should consider that as minimum supported version or something higher. Any
> thoughts?
> >
> > Things will be a bit more easy to develop and test once we finalize on
> the Java version.
> >
> > -Jaikiran
> > -
> > 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: 1.9.8 vs 1.10.0 (was Re: [VOTE] Release Ant 1.10.0 based on RC1)

[Paul King]

Yep, that makes things clearer. Nice.

Cheers, Paul.

On Sat, Dec 31, 2016 at 2:50 AM, Stefan Bodewig  wrote:
> On 2016-12-30, Stefan Bodewig wrote:
>
>> The README.html isn't really part of the release and we can simply
>> modify it at will at any time. Let me try to improve on what we have
>> right now.
>
> I've modified the introduction of
> https://dist.apache.org/repos/dist/dev/ant/README.html - is this clearer
> now?
>
> 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: [VOTE] Release Ant 1.10.0 based on RC1

[Paul King]

+1 (non-binding)
I checked the checksums and signature of the source zip.
I ran Groovy's master branch against this version including its
groovy-ant test suite.
I must admit to not having followed much recent discussion on the dev
mailing list. Just as an aside for future reference, I thought perhaps
more discussion of the difference between versions would be useful in
the release notes or manual. I initially assumed that 1.10.0 followed
1.9.8 but the split is really at 1.9.7 IIUC. In particular, I found
having the 1.9.8 section above the 1.10.0 section a little confusing
in the README file:
https://dist.apache.org/repos/dist/dev/ant/README.html
It's certainly not worth redoing the release for and I assume the
build process just prepends - it was just a little strange having them
out of order.

Cheers, Paul.

On Tue, Dec 27, 2016 at 5:07 PM, Stefan Bodewig  wrote:
> Hi all
>
> I've created a release candidate for 1.10.0:
>
> git tag: ANT_1.10.0_RC1
>  on commit: ffcbcd7
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>   revision: 17588
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapacheant-1011/org/apache/ant/
>
> This Vote will be open at least for 72 hours and close no earlier than
> 2016-12-30 7:00UTC.
>
> Cheers
>
> 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: [VOTE] Release Ant 1.9.5 based on RC1

[Paul King]

+1 non-binding (based on running against the groovy-ant test suite)

Cheers, Paul.

On 1/06/2015 12:46 AM, Stefan Bodewig wrote:

Hi all

I've created a release candidate for 1.9.5:

git tag: ANT_195_RC1
  hash: 54ac2fedd
  on commit: ea7bf28
tarballs: https://dist.apache.org/repos/dist/dev/ant/
   revision: 9181
Maven artifacts:
   
https://repository.apache.org/content/repositories/orgapacheant-1007/org/apache/ant/

Vote will be open at least for 72 hours and close no earlier than Wed
3rd June 2015.

Cheers

 Stefan

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





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [VOTE] Apache Ivy 2.3.0 release

[Paul King]

I tried out the proposed artifacts with the Groovy build and test suite
(which has a bunch of ivy-related tests for downloading groovy grapes)  and
also did some additional manual testing - all seemed to work as expected.

So non-binding informal +1 from me.

Cheers, Paul.

On 14/01/2013 8:40 AM, Maarten Coene wrote:

Hi all,

I've created the binaries containing the Apache Ivy 2.3.0 release.

These binaries can be found here:
https://dist.apache.org/repos/dist/dev/ant/ivy/2.3.0/

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapacheant-125/

Eclipse Update site is located here:
https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.3.0.final_20130110142753/

They are based on the following tag:
https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.3.0/

Do you vote for the release of these binaries?

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

kind regards,
Maarten Coene




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

Re: [VOTE] release of ant 1.8.2

[Paul King]

After a little more testing, one thing I did notice was an
apparent stricter treatment of property expansion.
With 1.8.1, having an arg to a forked java task like this:

arg value=-DskipFetch=${skipFetch}/

was happily ignored if skipFetch wasn't defined.
With 1.8.2, we now get a failed build with reason:

Property skipFetch was circularly defined.

The fix was to add a default property defn but it seems
like such a behavior change in a minor update release
should warrant an entry in the WHATSNEW at least?

Cheers, Paul.

On 15/12/2010 1:48 PM, Paul King wrote:


No official vote for me but just as feedback, Ant 1.8.2 built
the latest Groovy with no problems and the (albeit humble)
AntBuilder tests all ran fine.

Cheers, Paul.

On 14/12/2010 6:59 AM, Antoine Levy-Lambert wrote:

Hi,

as announced I have built a release candidate for Ant 1.8.2.

This is available for download from http://people.apache.org/~antoine/dist/

Do you want to release these artefacts as Apache Ant 1.8.2 ?

Yes []

No []

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





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

Re: [VOTE] release of ant 1.8.2

[Paul King]

This is probably enough to reproduce it:

project
  target name=foo
java classname=org.apache.tools.ant.launch.Launcher fork=true
  classpath path=${java.class.path}/
  arg value=-Dbar=${bar}/
/java
  /target
/project

Cheers, Paul.

On 15/12/2010 7:55 PM, Stefan Bodewig wrote:

On 2010-12-15, Paul King wrote:


After a little more testing, one thing I did notice was an
apparent stricter treatment of property expansion.
With 1.8.1, having an arg to a forked java task like this:



arg value=-DskipFetch=${skipFetch}/



was happily ignored if skipFetch wasn't defined.
With 1.8.2, we now get a failed build with reason:



Property skipFetch was circularly defined.



The fix was to add a default property defn but it seems
like such a behavior change in a minor update release
should warrant an entry in the WHATSNEW at least?


I don't think this a conscious change but rather a side effect of a
change somewhere else.  But it must be more complex than that, I don't
get a warning like yours with

project
 target name=foo
   echo${x}/echo
 /target
/project

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: [VOTE] release of ant 1.8.2

[Paul King]

On 15/12/2010 10:55 PM, Stefan Bodewig wrote:

On 2010-12-15, Paul King wrote:


This is probably enough to reproduce it:


Yes, it is, thank you Paul.


project
   target name=foo
 java classname=org.apache.tools.ant.launch.Launcher fork=true
   classpath path=${java.class.path}/
   arg value=-Dbar=${bar}/
 /java
   /target
/project


The error message is created by the forked Ant process, not the one
executing the build file.  You would see the same if you used

ant -Dbar=${bar}

(with proper shell escaping in place, that is).  Properties specified on
the command line via -D and -propertyfile can now use other properties
in their values.  Prior to Ant 1.8.2 they were not expanded.

What you see really is a border case that only happens because you use
the same property name in your build file and the property use pass to
the forked Ant process.

I'm not even sure how to document the situation 8-)


Yes, I guess it is a bit unusual. We were running into memory problems so
our build calls back to itself for just one target with a cut down set of
properties. In any case, it sounds like the change isn't too wide spread.
So maybe not release-note worthy after all.

Thanks for the new release.

Cheers, Paul.

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

Re: [VOTE] release of ant 1.8.2

[Paul King]

No official vote for me but just as feedback, Ant 1.8.2 built
the latest Groovy with no problems and the (albeit humble)
AntBuilder tests all ran fine.

Cheers, Paul.

On 14/12/2010 6:59 AM, Antoine Levy-Lambert wrote:

Hi,

as announced I have built a release candidate for Ant 1.8.2.

This is available for download from http://people.apache.org/~antoine/dist/

Do you want to release these artefacts as Apache Ant 1.8.2 ?

Yes []

No []

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: ant+soap+ssl

[Paul King]

Don't know if this helps or not:

?xml version=1.0 encoding=UTF-8?
project name=SOAP example basedir=.
property environment=env/
taskdef name=groovy classname=org.codehaus.groovy.ant.Groovy
classpath
fileset dir=${env.GROOVY_HOME} 
includes=embeddable/groovy-all-*.jar,lib/ivy*.jar/
/classpath
/taskdef
groovy
@Grab(group='org.codehaus.groovy.modules', module='groovyws', 
version='0.5.1')
import groovyx.net.ws.WSClient
def url = 'http://www.w3schools.com/webservices/tempconvert.asmx?WSDL'
def proxy = new WSClient(url, this.class.classLoader)
proxy.initialize()
result = proxy.CelsiusToFahrenheit(0)
new AntBuilder().echo Help, I'm freezing at ${result} degrees 
Fahrenheit
/groovy
/project

I was using Groovy 1.7.0.

Cheers, Paul.

On 16/03/2010 8:01 AM, Gilbert Rebhan wrote:

 Original Message  
Subject: Re: ant+soap+ssl
From: Paul Kingpa...@asert.com.au
To: Ant Developers Listdev@ant.apache.org
Date: 15.03.2010 22:29



I'd probably use Groovy or whatever your favorite JVM scripting language
is.
Groovy-WS is the library you would need. It uses Apache CXF under the
covers.
If you have trouble getting started I can try to find one of my existing
examples that does something similar.

Cheers, Paul.


Hi, Paul

Thanks for your quick reponse.
Thought of groovy already, because i'm a great fan of (j)ruby and both
have similarities, but have never tried groovy seriously before.
Also i have no further experience with webservices, i know the theory
and some basics, but have not really dealt with it.
Groovy is on my list for years, so maybe now is the time, any examples
are appreciated !


Regards, Gilbert


-
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+soap+ssl

[Paul King]

Here's another version showing setting properties:

?xml version=1.0 encoding=UTF-8?
project name=SOAP example default=main basedir=.
property environment=env/
property name=celsius value=0/
target name=main
taskdef name=groovy classname=org.codehaus.groovy.ant.Groovy
classpath
fileset dir=${env.GROOVY_HOME} 
includes=embeddable/groovy-all-*.jar,lib/ivy*.jar/
/classpath
/taskdef
groovy
@Grab(group='org.codehaus.groovy.modules', module='groovyws', 
version='0.5.1')
import groovyx.net.ws.WSClient
def url = 
'http://www.w3schools.com/webservices/tempconvert.asmx?WSDL'
def proxy = new WSClient(url, this.class.classLoader)
proxy.initialize()
ant.echo I'm freezing at ${properties.celsius} degrees Celsius
properties.result = proxy.CelsiusToFahrenheit(properties.celsius)
/groovy
antcall target=results/
/target
target name=results
echo message=I'm freezing at ${result} degrees Fahrenheit/
/target
/project

Happy to answer more questions but they probably belong on some other list.

Cheers, Paul.

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

Re: ant+soap+ssl

[Paul King]

I'd probably use Groovy or whatever your favorite JVM scripting language is.
Groovy-WS is the library you would need. It uses Apache CXF under the covers.
If you have trouble getting started I can try to find one of my existing
examples that does something similar.

Cheers, Paul.

On 16/03/2010 7:07 AM, Gilbert Rebhan wrote:

Hi,

i want to access a IBM DataPower xml management interface
from within ant to send status and configuration requests
via soap messages.
Has anyone experience with such a setting ?

@IBM site only has an article that uses curl and openssl
as external commands called with exec from ant =
http://www.ibm.com/developerworks/websphere/library/techarticles/0904_rasmussen/0904_rasmussen.html
But i prefer a solution, where all tasks are running in jvm,
there are java apis for soap, f.e. JAX-WS 2.0 or Apache Axis

Are there any ant tasks in the wild for that purpose ?
Need to know which tools will do the job.
Some keywords =
http post, base64 encoding, soap, ssl, basic authentication

Any hints on that ?


Regards, Gilbert



-
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: Java Packaging Tool - one for development and using. The best wish of many developers

[Paul King]

Not 100% the same as what you suggest but Groovy's Grape system does some
of what you are asking for. Normally Grapes are used from within scripts,
e.g.:

@Grab('org.apache.ant:ant:1.7.1')
import org.apache.tools.ant.Main
Main.main(['-version'] as String[])

but it also has a commandline interface. Excerpt from doco shown below:

doco
Command Line Tools

grape install groupId artifactId [version]

This installs the specified groovy module or maven artifact. If a version is 
specified that specific version will be installed, otherwise the most recent 
version will be used (as if '*' we passed in).

grape list

Lists locally installed modules (with their full maven name in the case of 
groovy modules) and versions.

grape resolve (groupId artifactId version)+

This returns the file locations of the jars representing the artifcats for the 
specified module(s) and the respective transitive dependencies.
/doco

This may not be what you want but might be a useful starting point.


Cheers, Paul.



Alexey Lunacharsky wrote:

Hello!

Does anybody think about imlementation a Debian APT-like tool on the top
of an Ivy dependency manager. It can manage all java binaries and source
installation in the system on user level,
through home directory located workspace, or on admin level through FHS on
Unix systems.

For the give what I mean I write some high level usage examples, which can
be used in unit tests):

$ jpt install apache-ant-1.7.0

by this command ant and all of its dependencies (jars and maybe other
resources such jpt run configurations) are get downloaded and become
available in ivy cache and it can be run by:

$ jpt run apache-ant

This execution will find and organize classpath through ivy depencies
review, and than
run spesified class (which is specified through jpt run configuation XML
file)

$ jpt wrap apache-ant ant

Creates system dependent warapper script for running application through
'jpt run'.

$ ant

will now execute $ jpt run apache-ant

$ jpt unwrap ant

now wrapper no more exist

$ ant

no such command

$ jpt uninstall apache-ant-1.7.0

deletes a softfare binaries if there is no dependencies remain

And so on.

In future it can manage also the libraries source code. And be used for
development environment buildings based on ant or gant scripts.
So many software can be integrated on the top of spring framework etc.

This is the system of my dream!

So I will be very glad if you tell me, if such the system have already exist
or
why to not imlement such as a thin wrapper across the Ivy?




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

Re: Java Packaging Tool - one for development and using. The best wish of many developers

[Paul King]

Paul King wrote:


Not 100% the same as what you suggest but Groovy's Grape system does some
of what you are asking for. Normally Grapes are used from within scripts,
e.g.:

@Grab('org.apache.ant:ant:1.7.1')
import org.apache.tools.ant.Main
Main.main(['-version'] as String[])

but it also has a commandline interface. Excerpt from doco shown below:

doco
Command Line Tools

grape install groupId artifactId [version]

This installs the specified groovy module or maven artifact. If a 
version is specified that specific version will be installed, otherwise 
the most recent version will be used (as if '*' we passed in).


Even though the doco says maven artifact, it is Ivy under the covers
so it is strictly speaking an Ivy artifact which can be and often is
a maven artifact.

Paul.


grape list

Lists locally installed modules (with their full maven name in the case 
of groovy modules) and versions.


grape resolve (groupId artifactId version)+

This returns the file locations of the jars representing the artifcats 
for the specified module(s) and the respective transitive dependencies.

/doco

This may not be what you want but might be a useful starting point.


Cheers, Paul.



Alexey Lunacharsky wrote:

Hello!

Does anybody think about imlementation a Debian APT-like tool on the 
top

of an Ivy dependency manager. It can manage all java binaries and source
installation in the system on user level,
through home directory located workspace, or on admin level through 
FHS on

Unix systems.

For the give what I mean I write some high level usage examples, which 
can

be used in unit tests):

$ jpt install apache-ant-1.7.0

by this command ant and all of its dependencies (jars and maybe other
resources such jpt run configurations) are get downloaded and become
available in ivy cache and it can be run by:

$ jpt run apache-ant

This execution will find and organize classpath through ivy depencies
review, and than
run spesified class (which is specified through jpt run configuation XML
file)

$ jpt wrap apache-ant ant

Creates system dependent warapper script for running application through
'jpt run'.

$ ant

will now execute $ jpt run apache-ant

$ jpt unwrap ant

now wrapper no more exist

$ ant

no such command

$ jpt uninstall apache-ant-1.7.0

deletes a softfare binaries if there is no dependencies remain

And so on.

In future it can manage also the libraries source code. And be used for
development environment buildings based on ant or gant scripts.
So many software can be integrated on the top of spring framework etc.

This is the system of my dream!

So I will be very glad if you tell me, if such the system have already 
exist

or
why to not imlement such as a thin wrapper across the Ivy?




-
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: Java Packaging Tool - one for development and using. The best wish of many developers

[Paul King]

Yes, startup speed can be a factor though I am not sure it is as bad
as 10 times slower these days. Some potentially useful info for you:

* if you grab 1.7.1 snapshot or 1.8 snapshot from one of the 
CI servers then it avoids one of the big startup delays due to DGM

class loading by loading that info in one go as serialised data.

* targeted for 1.8 but not yet finished is some lazy loading logic
which should speed that up even further

* also targeted for 1.8 is a modularisation of the libraries so you
could package up a streamlined Groovy system that would load quicker
if you didn't need all of the library functionality

* there is a still experimental static groovy project which performs
on par with Java which might allow you to gain some further speed.

So, while Groovy isn't the only game in town these days in terms of
innovative languages on the JVM, it should only improve in the areas
that are of concern to you.

Cheers, Paul.

Alexey Lunacharsky wrote:

Thanks you a lot.

I've heard about grape. But didn't know it is almost what I need.
It is very good point to start... But
The biggest problem with groovy it is very slow at startup.
The pure java solution such Ivy or thin wrapped with ant scripting can be
about 10 times faster for
using from command shell.

2010/1/18 Paul King pa...@asert.com.au


Paul King wrote:


Not 100% the same as what you suggest but Groovy's Grape system does some
of what you are asking for. Normally Grapes are used from within scripts,
e.g.:

@Grab('org.apache.ant:ant:1.7.1')
import org.apache.tools.ant.Main
Main.main(['-version'] as String[])

but it also has a commandline interface. Excerpt from doco shown below:

doco
Command Line Tools

grape install groupId artifactId [version]

This installs the specified groovy module or maven artifact. If a version
is specified that specific version will be installed, otherwise the most
recent version will be used (as if '*' we passed in).


Even though the doco says maven artifact, it is Ivy under the covers
so it is strictly speaking an Ivy artifact which can be and often is
a maven artifact.

Paul.


 grape list

Lists locally installed modules (with their full maven name in the case of
groovy modules) and versions.

grape resolve (groupId artifactId version)+

This returns the file locations of the jars representing the artifcats for
the specified module(s) and the respective transitive dependencies.
/doco

This may not be what you want but might be a useful starting point.


Cheers, Paul.



Alexey Lunacharsky wrote:


Hello!

Does anybody think about imlementation a Debian APT-like tool on the
top
of an Ivy dependency manager. It can manage all java binaries and source
installation in the system on user level,
through home directory located workspace, or on admin level through FHS
on
Unix systems.

For the give what I mean I write some high level usage examples, which
can
be used in unit tests):

$ jpt install apache-ant-1.7.0

by this command ant and all of its dependencies (jars and maybe other
resources such jpt run configurations) are get downloaded and become
available in ivy cache and it can be run by:

$ jpt run apache-ant

This execution will find and organize classpath through ivy depencies
review, and than
run spesified class (which is specified through jpt run configuation XML
file)

$ jpt wrap apache-ant ant

Creates system dependent warapper script for running application through
'jpt run'.

$ ant

will now execute $ jpt run apache-ant

$ jpt unwrap ant

now wrapper no more exist

$ ant

no such command

$ jpt uninstall apache-ant-1.7.0

deletes a softfare binaries if there is no dependencies remain

And so on.

In future it can manage also the libraries source code. And be used for
development environment buildings based on ant or gant scripts.
So many software can be integrated on the top of spring framework etc.

This is the system of my dream!

So I will be very glad if you tell me, if such the system have already
exist
or
why to not imlement such as a thin wrapper across the Ivy?



-
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: [VOTE] Accept Groovy-Front Donation

[Paul King]

I don't have a vote but happy to give a non-binding +1.

The one thing that might need changing (shouldn't affect
an acceptance decision) is the rename of import to
include - this might need to be looked at given the
recent introduction in trunk of include.

Cheers, Paul.

Stefan Bodewig wrote:

Hi,

Nicolas wants to donate his ProjectHelper implementation that allows
build files to be written in Groovy.  It can be found attached to 


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

It would start life at Ant inside the sandbox.

Since this is more than just a small patch, following the IP-Clearance
process[1] which involves the incubator seems in order.  I volunteer to
see this through the Incubator process.

But before I start doing this: do we want to accept the donation?

Stefan

[1] http://incubator.apache.org/ip-clearance/index.html
http://incubator.apache.org/ip-clearance/ip-clearance-template.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

Re: How to automize Ant

[Paul King]

If you really want to get fully up to speed quickly, I would
recommend finding yourself a book or two to read. They will
help you absorb things at a faster pace than the individual
project websites.

To cover off the Ant side of things why not try:

http://www.amazon.com/Ant-Action-Manning-Steve-Loughran/dp/193239480X/

To cover off the CI side of things, try:

http://www.amazon.com/Continuous-Integration-Improving-Addison-Wesley-Signature/dp/0321336380/

There are plenty of other good ones out there too but with
these two you will go a long way.

Cheers, Paul.

Jan K wrote:

Hi,
I have downloaded the cruisecontrol.I have cvs.Can you let me know what
should i do next or can you give me any documentation on it.Please guide me.
 


Thorsten Scherler-3 wrote:

On Mon, 2008-09-01 at 02:40 -0700, Jan K wrote:

Hi,

I am new to apache ant.I just know for what purpose we use ant.Now i need
to 
automize my project with ant.My requirement is Whenever i checkin my

code,the build and deploy  should be done automatically.

Well there are a couple of our of the box tools for that
http://en.wikipedia.org/wiki/Continuous_Integration

Here on apache there are http://continuum.apache.org/ and
http://gump.apache.org/ but the list is long as you may see from the
websites above.

Basically what you need to do (the poor men approach) is create a
post-commit hook in your svn server that triggers the build. 


The rest is done by your build script.

HTH

salu2


Also a notification
should be send to QA team.Also the build and deploy should be carried out
automatically in my onsite server also.This should be done for all the
java
projects running in our company.How can i do this,Please help
me.Please.Thanks in advance.

--
Thorsten Scherler thorsten.at.apache.org
Open Source Java  consulting, training and solutions


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] 1.7.1 Release now available for final testing

[Paul King]

Not a formal vote, but just some positive feedback.
I built Groovy with 1.7.1 with no problems. Also, all
of the AntBuilder tests within the build passed fine
using 1.7.1 as did my manual testing. Looking good!

Cheers,
Paul.

Kevin Jackson wrote:

Hi all,

There is an additional folder at http://people.apache.org/dist/ant/v1.7.1/

This is the src/bin that will become the final 1.7.1 release unless
there are any vetos

I've done the download + check signature test and it seems fine to me

Vote


The distribution files on http://people.apache.org/dist/ant/v1.7.1/
are good to move to /www/www.apache.org/dist/ant/[source|binaries].
(step 18 of ReleaseInstruction) and can be considered Apache Ant 1.7.1

yes [x] (+1)
no [ ]

(My vote included above)

Thanks,
Kev

PS please vote asap if you can as I have very little time to finalize
the release (basically 1 week where I still have a PC! :).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] migrate Ivy's wiki to Confluence

[Paul King]

If you can move straight in to Confluence 2.8, that will let you
do page ordering which helps a lot if you want to export your
site to PDF as a User Guide/PDF manual. It also seems to do
a slightly better job formatting code examples.

Cheers, Paul.

Archie Cobbs wrote:

Not sure if my vote counts, but +1 from me in any case :-)

-Archie

On Wed, Apr 23, 2008 at 2:41 AM, Xavier Hanin [EMAIL PROTECTED]
wrote:


Hi,

There's been a discussion recently about Ivy's documentation, which end up
discussing user contributed documentation and especially the wiki.

It seems 2 Ivy committers would prefer to use Confluence for Ivy wiki:
http://markmail.org/message/n4mvsmowb3ujlyeg

Moreover, some users expressed their opinion about this preference too:
http://markmail.org/message/kjbzcqukzhqrowwt

I already expressed the reasons why I'd like to migrate:
First, in JIRA we have activated the wiki syntax, which is the same as
confluence one. So using confluence it would be only one wiki syntax to
learn for both the wiki and issues. Secondly, I think with confluence you
have a rich text editor, which can be useful for people who don't want to
learn the syntax, or for tables which are cumbersome to write and maintain
in wiki syntax. Lastly, I much prefer the look of confluence pages over *
MoinMoin*.

So I'd like to start a vote to see if migrating Ivy's wiki to confluence
is
possible.

Xavier
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Should ScriptRunner call terminate() on the BSFManager?

[Paul King]

[EMAIL PROTECTED] wrote:

Hi,
 
We've recently integrated Jepp (http://jepp.sourceforge.net/) into our

use of Ant via the BSF engine. This is very useful because we use Python
for scripting quite a lot and it allows Python code to be used in full
while also allowing access to Java objects.
 
This has resulted in a Java OOM error, which I suspect is due to this

integration change. There is a comment in the Jepp usage instructions
that close() must be called on the Jep objects. This is done inside the
terminate() method of the BSFJepEngine, which is called by the
BSFManager on all engines. However I cannot see anywhere where
BSFManager.terminate() is called inside ScriptRunner or elsewhere inside
Ant. Should terminate() be called by ScriptRunner(), perhaps in the
finally section in the executeScript method?


Others will be more familiar with the ScriptRunnerXXX classes than me
but in WebTest, its Script task has a keep flag. This might be a useful
concept to have here. Basically the flag allows you to distinguish between
scenarios where you want the binding retained across tasks (and hence
in the scenario above I suspect you don't want terminate() called) and
the case where you want a fresh manager/runner for each run. Again, I
haven't done a complete analysis of what gets called where in Ant at the
moment. Just noting an important use case for WebTest which I know is
in use in the field in many places.

Paul.
P.S. For those that aren't aware, WebTest is an Ant extension for
testing web applications.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Should ScriptRunner call terminate() on the BSFManager?

[Paul King]

Peter Reilly wrote:

On Tue, Mar 25, 2008 at 8:59 PM, Paul King [EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] wrote:
  Hi,
 
  We've recently integrated Jepp (http://jepp.sourceforge.net/) into our
  use of Ant via the BSF engine. This is very useful because we use Python
  for scripting quite a lot and it allows Python code to be used in full
  while also allowing access to Java objects.
 
  This has resulted in a Java OOM error, which I suspect is due to this
  integration change. There is a comment in the Jepp usage instructions
  that close() must be called on the Jep objects. This is done inside the
  terminate() method of the BSFJepEngine, which is called by the
  BSFManager on all engines. However I cannot see anywhere where
  BSFManager.terminate() is called inside ScriptRunner or elsewhere inside
  Ant. Should terminate() be called by ScriptRunner(), perhaps in the
  finally section in the executeScript method?


Just had a quick look,
  we should call the terminate method - it is part of the life cycle that
  we missed.

Looking at some of the languages:
  beanshell does not use the  terminate method
  jruby does
  rhino does not
  groovy does not
  jython does not
  netrexx does not
  jacl does not

so it is not surprising that we missed this.

The odd thing is that javax.scripting does not seem to have
a corresponding method and the jruby javax.script engine
calls the terminate for each invoke method.



 Others will be more familiar with the ScriptRunnerXXX classes than me
 but in WebTest, its Script task has a keep flag. This might be a useful
 concept to have here. Basically the flag allows you to distinguish between
 scenarios where you want the binding retained across tasks (and hence
 in the scenario above I suspect you don't want terminate() called) and
 the case where you want a fresh manager/runner for each run. Again, I
 haven't done a complete analysis of what gets called where in Ant at the
 moment. Just noting an important use case for WebTest which I know is
 in use in the field in many places.


It should be possible to modify the scripting code in such a way that
will not affect people that use the code.


OK, that is good to know. Here is a sample of what WebTest does:

scriptStep keep=true language=javascript
   var foo = bar;
/scriptStep
!-- other tasks here ... --
storeProperty name=upperfoo value=#{script:foo.toUpperCase()}/
verifyProperty name=upperfoo text=BAR/

The storeProperty task relies on the same BSFManager being used
with all of its variables intack. Under the covers it is calling
the eval() method in BSFManager. If you get around to making this
change, I'll test out that this stuff still works.

Cheers,
Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Functional testing with AntUnit

[Paul King]

Chris Connelly wrote:

Hello,

I apologize in advance if this is the wrong forum for this question. 


My organization is looking to replace some home-grown, in-house test automation 
tools with open source tools where possible. I've prototyped some solutions 
using Ant and AntUnit, and was impressed by how easy it was to replace custom 
tools with Ant tasks; display results through CruiseControl; and integrate 
tests and results into our existing test management systems (also home grown). 
I think Ant and AntUnit could provide the basis for an incremental path for 
migrating off our custom tools.

My questions: the AntUnit home page says: AntUnit could also be used for 
functional and integration tests
  outside of the scope of Ant tasks ...  This is an area that will need more 
research. Is anyone currently looking into this, and is this still considered 
a reasonable use of AntUnit? We do a lot of different types of testing -- from 
drivers and distros to middleware integration -- and I'm interested in any opinions 
on this possibility.

Thanks in advance,
Chris Connelly
 


You might want to consider WebTest (http://webtest.canoo.com).
I have about 10 customers using it quite happily. It is ant extensions
just like AntUnit. 5 of those customers now use it almost exclusively
with Groovy. 2 arbitrarily mix AntUnit and WebTest (via Groovy).

Cheers, Paul.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Paul King]

Peter Reilly wrote:

On 7/17/07, Matt Benson [EMAIL PROTECTED] wrote:

The refactoring is much bigger than the formatting
here, FYI... wanted to reassure you that I am taking
your comments to heart, Peter.

Cool!
I think perhaps we should push to remove all
checkstyle errors for ant1.8. At work, I have
implemented a zero checkstyle error policy -
with an checkconfig based on ant's (removing some
of the sillier checks) - this is run as part of CI and
reports are seen by the project manager.
(within a couple of weeks all checkstyle errors
disappeared!).


Yes, I am a fan of breaking the build if a checkstyle
violation is found. And then you make your IDE know about
the exact same set of checkstyle rules, so any breakage
won't come as a surprise.

Paul.


Peter


-Matt

--- [EMAIL PROTECTED] wrote:

 Author: mbenson
 Date: Tue Jul 17 14:35:26 2007
 New Revision: 557062

 URL:
 http://svn.apache.org/viewvc?view=revrev=557062
 Log:
 fmt/refac

 Modified:


ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java

 Modified:

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java
 URL:

http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java?view=diffrev=557062r1=557061r2=557062 



== 


 ---

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java
 (original)
 +++

ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java
 Tue Jul 17 14:35:26 2007
 @@ -76,8 +76,7 @@
   * @param resource resource on classpath
   */
  public void setResource(String resource) {
 -assertSrcIsJavaResource();
 -((JavaResource) src).setName(resource);
 +
 getRequiredJavaResource().setName(resource);
  }

  /**
 @@ -100,8 +99,7 @@
   * @param classpath to add to any existing
 classpath
   */
  public void setClasspath(Path classpath) {
 -assertSrcIsJavaResource();
 -((JavaResource)
 src).setClasspath(classpath);
 +
 getRequiredJavaResource().setClasspath(classpath);
  }

  /**
 @@ -109,8 +107,7 @@
   * @return The classpath to be configured
   */
  public Path createClasspath() {
 -assertSrcIsJavaResource();
 -return ((JavaResource)
 src).createClasspath();
 +return
 getRequiredJavaResource().createClasspath();
  }

  /**
 @@ -119,8 +116,7 @@
   * @param r The reference value
   */
  public void setClasspathRef(Reference r) {
 -assertSrcIsJavaResource();
 -((JavaResource) src).setClasspathRef(r);
 +
 getRequiredJavaResource().setClasspathRef(r);
  }

  /**
 @@ -128,8 +124,7 @@
   * @return The classpath
   */
  public Path getClasspath() {
 -assertSrcIsJavaResource();
 -return ((JavaResource) src).getClasspath();
 +return
 getRequiredJavaResource().getClasspath();
  }

  /**
 @@ -150,7 +145,6 @@
  }
  throw new BuildException(Source
 resource does not exist:  + src);
  }
 -
  BufferedInputStream bis = null;
  Reader instream = null;
  ByteArrayInputStream tis = null;
 @@ -162,7 +156,6 @@
  } else {
  instream = new
 InputStreamReader(bis, encoding);
  }
 -
  ChainReaderHelper crh = new
 ChainReaderHelper();
  crh.setPrimaryReader(instream);
  crh.setFilterChains(filterChains);
 @@ -175,7 +168,6 @@
  if (!text.endsWith(\n)) {
  text = text + \n;
  }
 -
  if (encoding == null) {
  tis = new
 ByteArrayInputStream(text.getBytes());
  } else {
 @@ -188,10 +180,8 @@
  propertyTask.bindToOwner(this);
  propertyTask.addProperties(props);
  }
 -
  } catch (final IOException ioe) {
 -final String message = Unable to load
 file:  + ioe.toString();
 -throw new BuildException(message, ioe,
 getLocation());
 +throw new BuildException(Unable to
 load file:  + ioe, ioe, getLocation());
  } finally {
  FileUtils.close(bis);
  FileUtils.close(tis);
 @@ -211,23 +201,24 @@
   * @param a the resource to load as a single
 element Resource collection.
   * @since Ant 1.7
   */
 -public void addConfigured(ResourceCollection a)
 {
 +public synchronized void
 addConfigured(ResourceCollection a) {
  if (src != null) {
  throw new BuildException(only a single
 source is supported);
  }
  if (a.size() != 1) {
 -throw new BuildException(only single
 argument resource collections
 - +  are
 supported);
 +throw new BuildException(
 +only single-element resource
 collections are supported);
  

Re: Retry task container

[Paul King]

There is one of these in WebTest:

 http://webtest.canoo.com/webtest/manual/retry.html

But it might be nice to have one outside WebTest as well.

You might want to guard against NoRetries being equal to 0
or change the code to skip the perform in that case. It
wouldn't be the usual case but might be useful to allow it.

Cheers, Paul.

Kevin Jackson wrote:

Hi all,

Looking through the bugzilla I came across, #28736 requesting a retry
attribute for the ftp task.

I thought instead that a generic Retry task container may be useful.
I've quickly thrown this together and first tests (using get) seem to
be fine, does anyone have an objection to adding this?

Use case:
- network operations may fail and cause a build to fail when all is
needed is another attempt

retry noRetries=3
 get src= dest=/
/retry

src:

/*
*  Licensed to the Apache Software Foundation (ASF) under one or more
*  contributor license agreements.  See the NOTICE file distributed with
*  this work for additional information regarding copyright ownership.
*  The ASF licenses this file to You under the Apache License, Version 2.0
*  (the License); you may not use this file except in compliance with
*  the License.  You may obtain a copy of the License at
*
*  http://www.apache.org/licenses/LICENSE-2.0
*
*  Unless required by applicable law or agreed to in writing, software
*  distributed under the License is distributed on an AS IS BASIS,
*  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
*  See the License for the specific language governing permissions and
*  limitations under the License.
*
*/
package org.apache.tools.ant.taskdefs;

import java.util.Enumeration;
import java.util.Vector;

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.TaskContainer;

/**
* Retries the nested task a set number of times
*/
public class Retry extends Task implements TaskContainer {

   private Vector nestedTasks = new Vector();

   private int noRetries;

   public void addTask(Task t) {
   nestedTasks.addElement(t);
   }

   public void setNoRetries(int n) {
   noRetries = n;
   }

   public void execute() throws BuildException {
   for(Enumeration e = nestedTasks.elements(); e.hasMoreElements();) {
   Task t = (Task)e.nextElement();
   for(int i=0; inoRetries; i++) {
   try {
   t.perform();
   } catch (Exception ex) {
   log(Attempt [+i+] error occured, retrying... ,
ex, Project.MSG_INFO);
   }
   }
   try {
   t.perform();
   } catch(Exception ex) {
   throw new BuildException(Failed after [+noRetries+]
attempts, giving up);
   }
   }
   }

}

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FW: antunit branch for 1.6.x compatibility

[Paul King]

Stefan Bodewig wrote:

If there is enough interest we could certainly still create a 1.6
compatible branch.

From this posting I got a reply from Paul King, who explained that
similar asserts are being used in WebTest project and that he would
be interested to learn the outcome of this discussion.


Paul is subscribed here as well, haven't seen him chime in, yet.

It is mostly a question of how much ongoing work it would take when we
add new features to AntUnit.  Which parts of AntUnit would you use?
Only the assertions or the tasks and listeners as well?


I am listening but still pondering what the best path is before
making further suggestions. WebTest has a focus on Acceptance
Testing and has more extensive reporting than e.g. JUnit.
AntUnit currently has sufficient listener capability and
infrastructure to align it closely with JUnit-style tests.

WebTest's steps are just Ant Tasks with a context. So it would
not be impossible to make WebTest's verification steps AntUnit
assertions with a context. It would be an interesting way to
move forward but maybe it isn't critical at the moment.

See the thread 'Property expansion notification interesting?'
over the last few weeks to see one of the things we would need
to solve first.

I'll keep pondering,

Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ideas on support of javax.script'ing

[Paul King]

Peter Reilly wrote:

[...] however, having bsf.jar and js.jar in
the $ANT_HOME/lib, is a user's choice, so if they are there it is
a good assumption that the user wants to use them.


I think that Groovy has native jsr support but jruby didn't last
time I checked (though that may soon or may have already changed)
so I might want to go with native jsr when using Groovy even
though I have bsf.jar in my classpath for when I want to
use jruby. So, the 'bsf:', 'jsr:' switch sounds good to me.

Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ideas on support of javax.script'ing

[Paul King]

Peter Reilly wrote:

On 10/27/06, Paul King [EMAIL PROTECTED] wrote:

Peter Reilly wrote:
 [...] however, having bsf.jar and js.jar in
 the $ANT_HOME/lib, is a user's choice, so if they are there it is
 a good assumption that the user wants to use them.

I think that Groovy has native jsr support but jruby didn't last
time I checked (though that may soon or may have already changed)


Support for jruby is provided via the
java scripting project:
https://scripting.dev.java.net/
They have a number of engines for various languages
that do not have native implementations.
(provided as language engine jar files).

Peter


Cool. I didn't remember the list being so complete last time
I looked. I guess the question still remains. If I needed BSF
for e.g. NetRexx would I want BSF or JSR for everything else?
I suspect I would be going JSR if I could.

Paul.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r466627 - in /ant/core/trunk/src/etc/poms: ./ ant-antlr/ ant-apache-bcel/ ant-apache-bsf/ ant-apache-log4j/ ant-apache-oro/ ant-apache-regexp/ ant-apache-resolver/ ant-commons-logging/

[Paul King]

Thanks for the pointers. The mentioned files provide some good ideas
but still look like they will download optional dependencies as well.
I also realised that my questions were a bit off topic but you have
given me some useful things to think about anyway. Thanks. If I think
of any way to improve things further I'll write back to the list.

Cheers, Paul.

Antoine Levy-Lambert wrote:

 Original-Nachricht 
Datum: Thu, 26 Oct 2006 06:06:18 +1000
Von: Paul King [EMAIL PROTECTED]
An: Ant Developers List dev@ant.apache.org
Betreff: Re: svn commit: r466627 - in /ant/core/trunk/src/etc/poms: ./ 
ant-antlr/ ant-apache-bcel/ ant-apache-bsf/ ant-apache-log4j/ ant-apache-oro/ 
ant-apache-regexp/ ant-apache-resolver/ ant-commons-logging/ ant-commons-net/ 
ant-jai/ ant-javamail/ ant-jdepend/ an...


Thanks. I will submit a request and see what they say.

Two questions though which you may or may not be able to help with.

(1) BSF provides the engines for Xalan, Jython, etc. but the engine
comes externally with the language for Groovy, JRuby, Beanshell, etc.
Do you believe this distinction is irrelevant as far as the
dependency list is concerned?


The only nuances that I know of in a maven dependency list are the element 
optional (true or false) and the element scope 
(compile,runtime,provided,system). So for me both the languages for which bsf 
provides the engine and the languages which provide their own bsf engine are 
optional runtime dependencies.

I do not know what maven does with optional runtime dependencies. I imagine in 
the end they are only a hint for the readers of your POMs about where to find 
the optional dependencies in ibiblio and which version numbers you endorse 
together with bsf 2.4.0.

You could have a look at two files written mainly by Steve Loughran, fetch.xml 
and libraries.properties.
http://svn.apache.org/viewvc/ant/core/trunk/fetch.xml
http://svn.apache.org/viewvc/ant/core/trunk/lib/libraries.properties
these work with the maven ant tasks to download the libs.
Maybe you could inspire yourself from these files to add similar files to bsf 
for users to download select lists of files.


(2) Do you know if there is a way using Ant Maven tasks to not get
optional jars without explicitly excluding each one? I guess this
is where Ivy's configurations really shine but Ivy doesn't seem
to have the concept of scope without explicitly mimicking it
using configurations. The most common scenario with BSF is someone
is trying to integrate their favorite scripting language with
Java. They wouldn't normally want every known scripting language
to be supported. Under these circumstances is it reasonable to
leave off the optional dependencies in the POM? Any thoughts?



you would have to ask the maven user list. I do not know, I am not a big user 
of the maven ant tasks. Sounds like only Ivy can do what you want. You would 
like for instance to say : get bsf + groovy + jython but not beanshell for 
instance.
 

Thanks, Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r466627 - in /ant/core/trunk/src/etc/poms: ./ ant-antlr/ ant-apache-bcel/ ant-apache-bsf/ ant-apache-log4j/ ant-apache-oro/ ant-apache-regexp/ ant-apache-resolver/ ant-commons-logging/

[Paul King]

Antoine Levy-Lambert wrote:

[...] You would like for instance to say : get bsf + groovy + jython but not 
beanshell for instance.


Forgot to say: yes, this is what I would like to do.


You could have a look at two files written mainly by Steve Loughran, fetch.xml 
and libraries.properties.
http://svn.apache.org/viewvc/ant/core/trunk/fetch.xml
http://svn.apache.org/viewvc/ant/core/trunk/lib/libraries.properties


A consequence I just realised that would be relevant to this list. If I put all 
the dependencies in the BSF POM, then I guess you could remove all of the 
language-related info in fetch.xml and library.properties. These would come 
down automatically along with Groovy just by downloading the BSF artifact.


Cheers, Paul.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r466627 - in /ant/core/trunk/src/etc/poms: ./ ant-antlr/ ant-apache-bcel/ ant-apache-bsf/ ant-apache-log4j/ ant-apache-oro/ ant-apache-regexp/ ant-apache-resolver/ ant-commons-logging/

[Paul King]

Thanks. I will submit a request and see what they say.

Two questions though which you may or may not be able to help with.

(1) BSF provides the engines for Xalan, Jython, etc. but the engine
comes externally with the language for Groovy, JRuby, Beanshell, etc.
Do you believe this distinction is irrelevant as far as the
dependency list is concerned?

(2) Do you know if there is a way using Ant Maven tasks to not get
optional jars without explicitly excluding each one? I guess this
is where Ivy's configurations really shine but Ivy doesn't seem
to have the concept of scope without explicitly mimicking it
using configurations. The most common scenario with BSF is someone
is trying to integrate their favorite scripting language with
Java. They wouldn't normally want every known scripting language
to be supported. Under these circumstances is it reasonable to
leave off the optional dependencies in the POM? Any thoughts?

Thanks, Paul.

Antoine Levy-Lambert wrote:

Hello Paul,


Here is what you could add to your POM :

22a23,25

!--
NetRexx is not available on ibiblio
--

34a38,86

dependency
  groupIdorg.jruby/groupId
  artifactIdjruby/artifactId
  version0.8.3/version
  optionaltrue/optional
  scoperuntime/scope
/dependency
dependency
  groupIdorg.beanshell/groupId
  artifactIdbsh/artifactId
  version2.0b4/version
  optionaltrue/optional
  scoperuntime/scope
/dependency
dependency
  groupIdorg.beanshell/groupId
  artifactIdbsh-core/artifactId
  version2.0b4/version
  optionaltrue/optional
  scoperuntime/scope
/dependency
dependency
  groupIdjython/groupId
  artifactIdjython/artifactId
  version2.1/version
  optionaltrue/optional
  scoperuntime/scope
/dependency
dependency
  groupIdrhino/groupId
  artifactIdjs/artifactId
  version1.6R3/version
  optionaltrue/optional
  scoperuntime/scope
/dependency
dependency
  groupIdgroovy/groupId
  artifactIdgroovy/artifactId
  version1.0-jsr-06/version
  optionaltrue/optional
  scoperuntime/scope
/dependency
dependency
  groupIdxalan/groupId
  artifactIdxalan/artifactId
  version2.7.0/version
  optionaltrue/optional
  scoperuntime/scope
/dependency


Check with the maven team or by emailing repository@apache.org whether
it is possible to overwrite the existing POM for 2.4.0 or whether these
additions would have to wait until the next release of bsf.

Regards,
Antoine

Paul King wrote:

Antoine Levy-Lambert wrote:

[...] I hope that for instance the pom of commons-bsf should itself
contain js, groovy, and the other supported languages as optional
runtime dependencies. 

BSF doesn't contain optional jars at the moment. The project team
members are fairly new to Maven and didn't have a POM originally.
I put in a request to have a minimal POM put in place but didn't
include optional jars. I am sure they won't mind if you put in a
request to add these to the POM. I will do so myself if I get some
time but not in the next few days.

Cheers, Paul.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r466627 - in /ant/core/trunk/src/etc/poms: ./ ant-antlr/ ant-apache-bcel/ ant-apache-bsf/ ant-apache-log4j/ ant-apache-oro/ ant-apache-regexp/ ant-apache-resolver/ ant-commons-logging/

[Paul King]

Antoine Levy-Lambert wrote:
[...] I hope that for instance the pom of commons-bsf should itself contain js, groovy, and the other supported languages as optional runtime dependencies. 


BSF doesn't contain optional jars at the moment. The project team
members are fairly new to Maven and didn't have a POM originally.
I put in a request to have a minimal POM put in place but didn't
include optional jars. I am sure they won't mind if you put in a
request to add these to the POM. I will do so myself if I get some
time but not in the next few days.

Cheers, Paul.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: Hi I need some help

[Paul King]

Groovy lets you run AntUnit tests (in Groovy AntBuilder syntax) and see
the results using the normal Green bar if you use Groovy's AllTestSuite.

Otherwise, just run as - ant... and point to your ant 1.7 jar files
so you don't get the built-in ant jars and you can expect output as per below:

Buildfile: C:\Documents and Settings\Paul\workspaceAU\AntUnitProj\build.xml
all:
[au:antunit] Build File: C:\Documents and 
Settings\Paul\workspaceAU\AntUnitProj\build.xml
[au:antunit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.047 sec
[au:antunit] Target: test1 took 0.032 sec
BUILD SUCCESSFUL
Total time: 406 milliseconds

Cheers, Paul.

[EMAIL PROTECTED] wrote:

I would not use Eclipse for that - use Ant itself.
So from inside Eclipse use Ants own buildfile for starting the testcases.

Oh yes - another reason: Eclipse cant run AntUnit-Tests AFAIK ;-)


Jan 


-Ursprüngliche Nachricht-
Von: zheng yiyu [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 27. September 2006 08:31

An: dev@ant.apache.org
Betreff: Hi I need some help

Could anyone tell me how to run the testcases of ant in 
eclipse ? I just mean the testcases in the trunk I checked out 
from the svn.

Thanks.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] Apache AntUnit 1.0 Beta 1 Released

[Paul King]

Thanks Stefan, comments and a question below.

Stefan Bodewig wrote:

On Sun, 24 Sep 2006, Paul King [EMAIL PROTECTED] wrote:
[...]


Does the Antlib.createAntlib part look like a violation of what I
should be doing from an Ant perspective?


You rely on an internal API - granted, technically it is public - so
you are in danger.  We try not to break our API, but we are more
willing to do so than to break the XML level API.


From the Groovy user side of view, I'd expect this to be hidden by

AntBuilder.  Something like

ant.registerAntlib('antlib:org.apache.ant.antunit')


Yes, I'll work on getting that added.


Also, I was expecting to have to muck around with namespaces but
they just dissappeared from the example at the moment. (Not sure
this is a good thing or not.)


I don't think it is, since Antlibs are also a way to solve naming
conflicts and you loose that abiblity IIUC.


So are you saying it is probably a bad thing that namespaces have
dissappeared? I think so too. From the internal Java API perspective
can anyone point me to what I need to do to register an Antlib dynamically
and retain the namespace? I.e. an alternative to:

Url url = this.getClass().getResource(org/apache/ant/antunit/antlib.xml);
Antlib.createAntlib(getProject(), url, 
antlib:org.apache.ant.antunit).execute();

Thanks, Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] Apache AntUnit 1.0 Beta 1 Released

[Paul King]

The Ant Team is proud to announce the first Beta release of
Apache AntUnit 1.0.


Sorry I have a question that is half Groovy and half AntUnit related.
It is also half user/half dev related. I am wanting to know the best
way to use the API (and potentially some normally internal pieces).

I was trying to create an AntUnit example with Groovy - mainly just
to check out some namespace support which has just been added to
Groovy's AntBuilder and currently have the following example working:

 import org.apache.tools.ant.taskdefs.Antlib
 def ant = new AntBuilder()
 def url = this.class.getResource('org/apache/ant/antunit/antlib.xml')
 Antlib.createAntlib(ant.project, url,
   'antlib:org.apache.ant.antunit').execute()
 ant.assertFileDoesntExist(file:'copytest1.tmp')
 ant.copy(file:'antunit.groovy', tofile:'copytest1.tmp')
 ant.assertFileExists(file:'copytest1.tmp')
 ant.delete(file:'copytest1.tmp')

Groovy includes an AntBuilder class which allows Ant build files to
be expressed as Groovy notation. It also has its own lifecycle which
I guess is bootstrapped slightly differently to the normal launcher.
I am not asking this group about the Groovy side of things but I
am interested in an opinion on what is the best way to do this
from an Ant perspective.

Does the Antlib.createAntlib part look like a violation of what
I should be doing from an Ant perspective? AntBuilder doesn't normally
involve explicitly creating anything equivalent to the project or
target - these are done under the covers.

Also, I was expecting to have to muck around with namespaces but they
just dissappeared from the example at the moment. (Not sure this is a
good thing or not.)

Cheers, Paul.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANN] Apache AntUnit 1.0 Beta 1 Released

[Paul King]

The Ant Team is proud to announce the first Beta release of
Apache AntUnit 1.0.


I added a patch to bug 28883 (regex condition for Ant):

http://issues.apache.org/bugzilla/show_bug.cgi?id=28883

Which would allow AntUnit to have an additional assertion:

target name=testTstampFormat
  tstamp
format property=today pattern=dd-MM-/
  /tstamp
  au:assertMatches string=${today}
pattern=[0123]\d-[01]\d-[12]\d{3}/
/target

Useful for checking dates, urls, pathnames, passwords,
email addresses, globbing etc. I guess typically more for
an acceptance flavour of test than a strict unit test but
useful none the less.

It requires an extra condition in core Ant but if there
is no interest in that change I guess the condition could
be packaged up as part of AntUnit. I guess an assertDoesntMatch
would also be an easy extension.

Cheers, Paul. 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: suggestion : Ant 1.8 full dist to include a 'scripting lang'

[Paul King]

Kevin Jackson wrote:

On 9/16/06, Jesse Glick [EMAIL PROTECTED] wrote:

[...]

(I'd steer away from groovy before anyone suggests it ;))


Kevin, anything in particular you don't like about Groovy?

In my experience Groovy is an excellent scripting language
and has excellent Ant support but as coauthor of the upcoming
Groovy in Action book I guess I am a little biased. :-)

Ant integration with Groovy crops up several times throughout
the book. Here is just one example (using Groovy in a
traditional build file - as distinct from using a Groovy
file as the build file - which would just involve leaving
off the outer tags in this example):

groovy
def scanner = ant.fileScanner {
  fileset(dir: properties['src.dir']) {
   include(name: '**/*.xml')
  }
}
def nameCheck = scanner.every{
  file - file.name.contains('build')
}
def totalSize = 0
def fileCount = 0
def maxSize   = 0
for(file in scanner){
  fileCount++
  if (file.size()  maxSize) maxSize = file.size()
  totalSize += file.size()
}
if (nameCheck || totalSize / fileCount  50 ||
  maxSize  100 || fileCount  10)
  properties.shouldCompress = true
/groovy

This just sets a property ready for a subsequent
'if' or 'unless' attribute based on some conditions
which would be somewhat cumbersome to do declaratively.

I have also been playing around with AntUnit and I certainly
find Groovy to be a natural fit when you outgrow AntUnit.


Cheers, Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: suggestion : Ant 1.8 full dist to include a 'scripting lang'

[Paul King]

Kevin Jackson wrote:

On 9/16/06, Jesse Glick [EMAIL PROTECTED] wrote:

[...]

(I'd steer away from groovy before anyone suggests it ;))


Kevin, anything in particular you don't like about Groovy?

In my experience it is an excellent scripting language and
has excellent Ant support but as coauthor of the upcoming
Groovy in Action book I guess I am a little biased. :-)

Ant integration with Groovy crops up many times throughout
the book. Here is just one example (using Groovy in a
traditional build file - as distinct from using a Groovy
file as the build file - which would just involve leaving
off the outer tags in this example):

groovy
def scanner = ant.fileScanner {
   fileset(dir: properties['src.dir']) { 
   include(name: '**/*.xml') 
   } 
} 
def nameCheck = scanner.every{

   file - file.name.contains('build')
} 
def totalSize = 0 
def fileCount = 0 
def maxSize   = 0 
for(file in scanner){
   fileCount++ 
   if (file.size()  maxSize) maxSize = file.size() 
   totalSize += file.size() 
} 
if (nameCheck || totalSize / fileCount  50 ||

   maxSize  100 || fileCount  10)
   properties.shouldCompress = true
/groovy

This just sets a property ready for a subsequent
'if' or 'unless' attribute based on some conditions
which would be rather hard to set up declaratively.


Cheers, Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: suggestion : Ant 1.8 full dist to include a 'scripting lang'

[Paul King]

Kevin Jackson wrote:

Kevin, anything in particular you don't like about Groovy?


Hi Paul,

Nice to 'chat' to you :)

My major problem with groovy was it's instability - every time I
looked at it previously, something was mentioned as still being
unstable etc.


Yes, it has had an interesting history with a few road bumps.


groovy
def scanner = ant.fileScanner {
   fileset(dir: properties['src.dir']) {
include(name: '**/*.xml')
   }
}


ok, so we have a chance to make a 'new' language and we can already
see what 'works' or doesn't work - we are making it for the JVM and we
want this to be adopted by non-Java programmers as well as Java people
- why carry all those braces?  Perl had them for no particular reason,
and practically every new dynamic language has dropped them (for good
reason) - so why did groovy choose to keep them?  I'd actually be
interested to know if it's simply because Java programmers are used to
braces?


Well, I wasn't involved at the time when many of these things were
set in concrete. One of the goals though was to be a scripting language
friendly to Java developers.


also def is being used here to define a new procedure or is it
assigning a block of code to a varaible?


def is being used to declare an untyped variable. You can either have
your compile-time checked typing as in Java or leave out the type and
replace it with def to indicate dynamic typing.
(It can also be used to define methods but that is not what is being
used here. The perhaps unusual feature being used here is builder
capability which lets you define your own DSLs. In this case, each
set of braces indicates another level of nesting as you would have
in XML in your ant build file.)


Having just checked out the groovy site for the first time in years (I
admit I've not bothered keeping up with it as it seemed to be taking a
long time to get to a release), I notice this:\

def map = [name:Gromit, likes:cheese, id:1234]

Ouch!  map is a functional term, in groovy though map means
associative array/plist/dictionary/HashMap.

When I read groovy has native support for maps, I though cool!

list = [1,2,3].map( i : i*2) (or similar)


Maps are the same as in Java with some syntactic sugar.
You can use closures with lists:

list = [1,2,3].collect{ i - i * 2 }
assert list == [2,4,6]

And similar things with maps, e.g.:

daylengths = [:] // empty map 'daylengths'
['Tuesday', 'Wednesday', 'Thursday'].each{
   day - daylengths[day] = day.length()
} // fill 3 day, daylength entries into map
println daylengths.findAll{ key - key =~ 'T.*y' }

Will print the map entries with keys matching the
regex 'T.*y', i.e.:

{Tuesday=7, Thursday=8}


Well anyway, that's just a couple of reasons why I'm not as keen on
groovy as other people are - that said, I'll have to download the
latest version and play with it to re-evaluate it - after all if
Manning are publishing a book, perhaps it's now ready for prime-time
:)


I certainly think it is getting close. There are still plenty of
things to do and still things under minor change and still heaps
of marketing to be done if Groovy is to approach the success of Ruby
let alone Java but it isn't too bad.


Thanks for the feedback (I'm an old curmudgeon too and groovy just
sounds wrong as a name ;)


Well, when we come up with the Groovy replacement, we can call it Crusty! ;)


Kev




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: using multiple properties in the 'if' and 'unless' conditions

[Paul King]

[EMAIL PROTECTED] wrote:

Hello,

Has the possibility of adding multiple conditions to the target 'if' and
'unless' attributes ever been considered? Are there any reasons why this
change would be a bad idea?


I have found Groovy (and to a lesser degree other scripting
languages) to be very useful for complex builds.
You can use Groovy from normal ant build files using the
script or external groovy tasks:

 http://groovy.codehaus.org/Groovy+Ant+Task

Or you can start from Groovy and use the ant builder syntax
to have full programming capabilities if you wish:

 http://groovy.codehaus.org/Ant+Scripting

As an example (not optimal) which combines both techniques:

 groovy
 def ant = new AntBuilder()
 def scanner = ant.fileScanner {
 fileset(dir:properties['basedir']) {
 include(name:**/*.xml)
 }
 }
 def nameCheck = scanner.every{ file - file.name.contains('build') }
 def totalSize = 0
 def fileCount = 0
 def maxSize = 0
 for(file in scanner){
 fileCount++
 if (file.length()  maxSize) maxSize = file.length()
 totalSize += file.length()
 }
 if (nameCheck || totalSize / fileCount  50 ||
 maxSize  100 || fileCount  10) properties.put('shouldCompress', 'true')
 /groovy

This sets up a property for subsequent use in an if or unless attribute
called 'shouldCompress' which is set based on the properties of xml
files in the directory in which the script is run. The property will
be set if every file in the selected fileset has the characters 'build'
in its name or if there are more than 10 files or if the average file
size is greater than 50 or if the maximum file size is more than 100.

This would be difficult trying to use alternative notations and
probably would be harder to understand. (Not that I am advocating
complex build logic just for the sake of it!)


Cheers, Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: using multiple properties in the 'if' and 'unless' conditions

[Paul King]

[EMAIL PROTECTED] wrote:

Hello,

Has the possibility of adding multiple conditions to the target 'if' and
'unless' attributes ever been considered? Are there any reasons why this
change would be a bad idea?


I have found Groovy (and to a lesser degree other scripting
languages) to be very useful for complex builds.
You can use Groovy from normal ant build files using the
script or external groovy tasks:

 http://groovy.codehaus.org/Groovy+Ant+Task

Or you can start from Groovy and use the ant builder syntax
to have full programming capabilities if you wish:

 http://groovy.codehaus.org/Ant+Scripting

As an example (not optimal) which combines both techniques:

 groovy
 def ant = new AntBuilder()
 def scanner = ant.fileScanner {
 fileset(dir:properties['basedir']) {
 include(name:**/*.xml)
 }
 }
 def nameCheck = scanner.every{ file - file.name.contains('build') }
 def totalSize = 0
 def fileCount = 0
 def maxSize = 0
 for(file in scanner){
 fileCount++
 if (file.length()  maxSize) maxSize = file.length()
 totalSize += file.length()
 }
 if (nameCheck || totalSize / fileCount  50 ||
 maxSize  100 || fileCount  10) properties.put('shouldCompress', 'true')
 /groovy

This sets up a property for subsequent use in an if or unless attribute
called 'shouldCompress' which is set based on the properties of xml
files in the directory in which the script is run. The property will
be set if every file in the selected fileset has the characters 'build'
in its name or if there are more than 10 files or if the average file
size is greater than 50 or if the maximum file size is more than 100.

This would be difficult trying to use alternative notations and
probably would be harder to understand. (Not that I am advocating
complex build logic just for the sake of it!)


Cheers, Paul.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT - want to join other projects, any recommendations?

[Paul King]

Peter Reilly wrote:

Ruby my friend ruby

look at [rake]


Yes, Ruby is OK but if you want to contribute to the project
in a meaningful way, Groovy/Ant/Grails/WebTest is a more fun
place to be (at least in my experience) at the moment. There
is still scope for fixing things which annoy you.

Cheers, Paul.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT - want to join other projects, any recommendations?

[Paul King]

Kev Jackson wrote:

Hi all,

This is totally off-topic, apart from in a meta-sense of Ant being an 
open source project...


My favourites at the moment are:
WebTest - an Ant extension with many extension for acceptance testing (mainly) 
web applications.
Groovy - a neat scripting language (which can be used from Ant and also has an 
ant builder so that you can have script-oriented ant build files)

Cheers, Paul.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: http tasks

[Paul King]

You might want to consider WebTest (webtest.canoo.com).
WebTest test scripts are like ant build scripts.
You can mix and match whatever ant tasks you want with
webtest tasks (called steps because they are actually
extend ant's Task and provide a reference to a context
which contains the state associated with a series of
http requests). It can do all of the things you are
after below (and quite a bit more too). It doesn't have
XML post yet but should do within a few weeks.

Have a look at WebTest's build file for an example
of how it brings it's own site up in Jetty and tests it.

Cheers, Paul.

Steve Loughran wrote:

James Fuller wrote:


what they really need is a functional test harness. I had some .pl
code up on iseran.com that tested a bit of it, but we should really
create a WAR and bring it up in Jetty or something.



why not jmeter ?



All the test harness really is is some things that are served up on a site

-text file   files/something.txt
-binary file files/something.bin
-error codes   errors/404/
-lie about content length (send more/less than asked)
-basic auth section
-digest auth section
-stuff to test POST

Nothing too complex, a few jsp pages really.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Introducing AntUnit

[Paul King]

I would mostly encourage this. It would seem reasonable
to be able to write tests productively use ant build files.
I am not sure how directly tied to ant (vs testing any java
program) you would need to make it to be worthwhile. I would
hope that it could be more generic.
You might want to have a look at webtest (webtest.canoo.com).
It is designed for testing web applications but might be
a fruitful source of ideas. Webtest uses webtest tests
(along with java unit tests) for its self-tests.
Paul.
Stefan Bodewig wrote:
Hi,
inspired by the creative use of macrodef and fail others (mainly
Matt and Steve) have shown in our tests, the idea of AntUnit we had a
long time ago surfaced in my mind again.
I've just dumped a little macrodef antlib (and one real task,
assertTrue) into our proposal area.  This is only a temporary place
until my JIRA request for a subversion space for Ant[1] has been
answered.
I simply lost patience and didn't want to have the code on my disk
until the next head-crash.  And I also don't know when I'll find time
to continue work on it, so I wanted to give others a chance to play
with it.
The idea is to create a unit test Ant library that uses Ant build
files to test Ant.  Having assert tasks is only one part of it and it
pretty much works the way that I've already shown (a very incomplete
list of asserts we'll need is in antlib.xml).  Things like
assertLogContaining will be more difficult to do.
The other part will be an antunit task, which will take a build file
and for each target whose name starts with test will
(1) create an Ant task
(2) run the target named setUp if present
(3) run the target
(4) run the target named tearDown if present
It will support result formatters much like the JUnit task.  There
will be passing and failing tests as well as tests that cause errors.
To tell failures from errors, assert* throws a subclass of
BuildException named AssertionFailedException.
It may be better to fork a new VM, I'm not sure.  Reusing the Ant task
would certainly be easier.
What do you think?  Is this worth the effort?
I came accross some issues that I'm going to raise in separete
threads.
Stefan
Footnotes: 
[1]  http://issues.apache.org/jira/browse/INFRA-263

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
Managing Director  Principal Consultant, ASERT Consulting Pty Ltd
Specialists in Java/J2EE, XML, Internet, Integration, Content Management
Level 3, Suite 10/53 Tribune Street, South Brisbane Qld Australia 4101
tel: 07 3844 1344, fax: 07 3844 1099, mob: 0404 012 062
web: http://www.asert.com.au, email: [EMAIL PROTECTED]
--
This message is intended solely for the named addressee and may contain
privileged  confidential information. Copying or distribution of this
transmission or any information it contains, by anyone other than the
addressee, is prohibited. If you receive this  message in error please
reply to the sender, delete the message and destroy any printed copies.
Any views expressed in this message are those of the individual sender.
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] macrodef - do attributes as properties or substitution s

[Paul King]

[EMAIL PROTECTED] wrote:
If macrodef attribute are to be implements as substitutions, what
should be the notation? (where x is the attribute name)
  [ ] as ${x} (look like ant properties)  confusion with 'real'
properties
  [ ] as $(x) to close to A
  [ ] as @x   I miss the brackets
  [ ] as ${attribute:x}   too long
  [X] as @{x} ok, close to A but seeable
different
  [ ] some thing else nothing in my mind to that
Has someone ruled out $${x}? Or does that conflict with
using $$ as some kind of escape sequence for $?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: override

[Paul King]

Costin Manolache wrote:
IMHO ant should try to be a bit easier to use than XSLT.
I was playing with some examples to capture the use cases
which have been discussed for include and import with a view
to getting a/some simple models straight in my head.
I am attempting in part to explain the use cases and capture
how parts of it are currently working/proposed and in part
to try to come up with a suggestion for an improved way to
handle the various cases.
I don't think I have quite got it yet (there are some big
gaps in my knowledge of some 1.6 aspects of ant!) but the
examples have got me further than where I was before.
Perhaps some of the gurus can point me in the right
direction and help me understand if I am on the right track.
In particular, I am unsure about how to deal with top-level
tasks. I have been thinking about properties, path references
and fileset references etc. and normal targets. I haven't
thought about antlib namespaces either.
First off, two small sample files to be reused later.
Each one has a couple of properties, a couple of path
references (I assume filesets and other types would
be similar) and a couple of targets.
common1.xml:
?xml version=1.0?
project name=common1 default=all basedir=.
property name=prop1 value=prop1/
property name=propX value=propX/
path id=path1
pathelement location=path1/
/path
path id=pathX
pathelement location=pathX/
/path
target name=target1
echo message=target1/
/target
target name=targetX depends=target1
echo message=targetX/
/target
/project
common2.xml:
?xml version=1.0?
project name=common2 default=all basedir=.
property name=prop2 value=prop2/
property name=propX value=propX/
path id=path2
pathelement location=path2/
/path
path id=pathX
pathelement location=pathX/
/path
target name=target2
echo message=target2/
/target
target name=targetX depends=target2
echo message=targetX/
/target
/project
Now for examples of attempts to reuse.
main1.xml:
?xml version=1.0?
project name=main1 default=all basedir=.
include url=common1.xml/
include url=common2.xml/
property name=prop3 value=${prop2} and ${propX}/
path id=path3
pathelement location=path3/
path refid=path2/
path refid=pathX/
/path
target name=target3 depends=targetX
echo message=target3/
/target
/project
For include the conceptual model is one of textual inclusion
(or XML entity inclusion if you are that way inclined).
The ant way states (at least for properties) that whoever sets
things first wins.  I would argue that would be the simplest
model for everything else too (but there has been some talk of
failing the build if nameclashes occur). I would suggest that
whoever is first wins could apply to path references, targets etc.
Depending on my settings I will get a warning and arguably ant
could be run in a strict mode which could fail if a property,
path, target was adjusted later.  The implication of this is
that even within the one file you could (though never recommended)
have two targets with the same name - the second would be ignored.
So, for main1 above, running target3 will indirectly cause the
dependency for target1 to be checked - and target2 would be checked
if I reversed the order of the includes.
main2.xml
?xml version=1.0?
project name=main2 default=all basedir=.
antref id=prefix1 url=common1.xml/
antref id=prefix2 url=common2.xml/
property name=prop3a refid=prefix1.propX/
property name=prop3b refid=prefix2.propX/
path id=path3
path refid=prefix1.pathX/
path refid=prefix2.pathX/
/path
target name=targetX depends=pre1.target1,pre2.target2
echo message=prestep/
targetref id=prefix1.targetX/
echo message=middle/
targetref id=prefix2.targetX/
echo message=post/
/target
target name=target3 depends=targetX
echo message=target3/
/target
/project
I have seen some of the import, super, override discussions
but can't see an easy conceptual model following ant's
similar but not exactly equivalent notion of inheritance.
So, what I want to achieve is the equivalent of Java's
delegation trick/pattern used to mimic multiple inheritance.
In Java I wouldn't use inheritance at all but would instead
have two instance variables (the delegates) and I would
pass any method calls on to the appropriate delegate.
This is where things aren't clear to me. In the example
I have used two antref tags.  I am trying to avoid the
nameclash issue altogether - conceptually I either have
some new targets but only full qualified and perhaps not
visible or I may need target references to some targets.
Now I can declare my own targets and refer to the original
targets in some fashion either by their fully-qualified names
or using the target reference. I have used a pseudo task
called targetref - kind of like super which 

JBuilder Gel IDE Integration

[Paul King]

In the IDE and Editor Integration section of the
External Tools and Tasks page it lists an older ant
plugin for JBuilder but it doesn't list Borland
JBuilder 8 Enterprise which now supports ANT natively.
Also, GEL from www.gexperts.com also supports ANT and
isn't listed.
I didn't submit a bug on this 'cause I wasn't sure if this
should normally come from the vendor themselves.
But here are the details if anyone wants to make the update.

Borland JBuilder Enterprise
Java IDE with support for Ant.
Compatibility:  JBuilder 8 comes with Ant 1.5.1
URL:http://www.borland.com/jbuilder/index.html
Contact:[EMAIL PROTECTED]
License:Commercial

GEL IDE for Windows
Java IDE with support for Ant.
Compatibility:  Ant 1.4 and above
URL:http://www.gexperts.com/gel.html
Contact:[EMAIL PROTECTED]
License:Freeware