Re: SonarQube

[Michael Clarke]

It looks like the Windows slaves use Java 8 so you could try tying the job to 
then. The config in the SonarQube plugin sets which JVM the plugin launched for 
running the Sonar checks, but the plugin itself needs at least Java 8 to run.

Thanks,
Michael


> On 19 Dec 2016, at 16:11, Stefan Bodewig  wrote:
> 
> Hmm, strange. The configuration section of the plugin contains an option
> for the JDK to use, so I had expected it to do anything :-)
> 
> I'm afraid all Jenkins slaves run Java7, so we are out of luck using the
> existing plugin. Executing the runner from within an Ant build file
> would be an option, I'll try to carve out some time for that.
> 
> Stefan
> 
>> On 2016-12-19, Michael Clarke wrote:
>> 
>> Stefan,
> 
>> It's failing as the slave is running on Java 7 so can't read the SonarQube 
>> plugin's Java 8 classes. You'll need to find a slave running on Java 8 (not 
>> just with Java 8 installed), although I couldn't find one from the quick 
>> selection I checked.
> 
>> Thanks
>> Michael
> 
>>> On 19 Dec 2016, at 14:46, Stefan Bodewig  wrote:
> 
>>> Hi all
> 
>>> I've tried to set up a SonarQube build for Ant with
>>> <https://builds.apache.org/job/Ant-Master%20SonarQube/> but right now it
>>> doesn't work (doesn't use the JDK8 I've configured). I'll try to get it
>>> working on and off but if anybody is familiar with the Jenkins plugin we
>>> seem to use, any help will be appreciated.
> 
>>> 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
> 
> -
> 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: SonarQube

[Michael Clarke]

Stefan,

It's failing as the slave is running on Java 7 so can't read the SonarQube 
plugin's Java 8 classes. You'll need to find a slave running on Java 8 (not 
just with Java 8 installed), although I couldn't find one from the quick 
selection I checked.

Thanks
Michael

> On 19 Dec 2016, at 14:46, Stefan Bodewig  wrote:
> 
> Hi all
> 
> I've tried to set up a SonarQube build for Ant with
>  but right now it
> doesn't work (doesn't use the JDK8 I've configured). I'll try to get it
> working on and off but if anybody is familiar with the Jenkins plugin we
> seem to use, any help will be appreciated.
> 
> 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: IntelliJ Idea licenses

[Michael Clarke]

I'm interested in this.

On 7 March 2016 at 02:53, Antoine Levy Lambert  wrote:

> Hi,
>
> I would like to request open source licenses for Intellij in the name of
> the Apache Ant project.
>
> Who is interested ?
>
> Best regards,
>
> Antoine
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Drop Support for Java5, Move on to Ant 1.10.0?

[Michael Clarke]

I personally don't think we should constrain ourselves to supporting End of
Life'd versions of Java: anyone wanting to use an older version of Java can
download an older version of Ant. That being said, Ant doesn't introduce
major new features particularly often so we may not be losing too much by
not using the latest Java APIs available to us.

My preference would be to move our mainline development to compile against
the current versions of Java with public support - so currently Java 1.8
and 1.9 - with an increment in minor version number of Ant to reflect this
change that may break some peoples' environments. I also think we should
consider creating a "Long Term Support" style branch for the previous
version where we back-port fixes where possible - i.e. where any changed
dependencies don't require a new version of Java, and the changed code
hasn't used a new Java API and isn't specifically introducing new features.
This may increase the work required to perform a release, but the back-port
of fixes is manageable given our use of Git, and can be pretty thoroughly
checked with our automated Unit and Integration tests. We may also have to
perform some work on our Bugzilla to make it clear which issues need ported
between versions, or only affect a specific release branch of Ant.

Thanks,
Michael

On 6 March 2016 at 17:09, Andre-John mas  wrote:

> Consider Enterprise is often 2 versions (maybe 3 versions) behind latest
> JDK, at lease based on my own experience, so 7 should still be included?
>
> Sent from my tablet
>
> > On Mar 6, 2016, at 10:31, Fernando Cassia  wrote:
> >
> >> On 3/6/16, Stefan Bodewig  wrote:
> >> I think it's time to drop support for Java5 and - as we've done in the
> >> past - bump the second part of Ant's version number to reflect the
> >> change.
> >
> > +1
> >
> >> I'm not sure whether moving to Java6 is worth the effort since it has
> >> been EOLed as well, even Java7 is no longer officially supported by
> >> Oracle
> >
> > Isn't Java 6 the baseline API for Android development? Do Android IDEs
> use ant?
> > Just thinking aloud...
> >
> >> but personally I wouldn't want to require Java8 right now.
> >
> > Why? OpenJDK 8 is included in most Linux distros.
> >
> >> So do we want to move on and if so, what should become our new baseline?
> >
> > That's a timely and relevant discussion, as just an ant user, and a
> > lurker on this list, I'm all ears. :)
> >
> > FC
> >
> > -
> > 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-Matrix-Job

[Michael Clarke]

I've applied a fix to the Jenkins Matrix Plugin for the issue that Olivier
raised, and jglick has kindly merged it and released the plugin. We'll need
one of the Jenkins admins to update the matrix plugin (or downgrade
Jenkins) to hopefully bring our matrix job back.


On 6 May 2014 12:27, Antoine Levy Lambert  wrote:

> I got the following information from Olivier Lamy :
>
> > From: Olivier Lamy 
> > Subject: Re: Ant-Build-Matrix Jenkins job
> > Date: May 6, 2014 at 12:20:03 AM EDT
> > To: Antoine Levy Lambert 
> >
> > I have investigated in logs and as I was not able to find any
> > workaround I created an issue
> > https://issues.jenkins-ci.org/browse/JENKINS-22879.
> > I will have a look later if I can find someone on jenkins irc.
>
>
> Olivier, thanks again for your investigation.
>
> From the issue which you entered, it looks like there is a field in the
> job’s xml definition whose content is “hudson” and is supposed to be a
> groovy script.
> I wonder whether I did no enter something invalid by mistake in a
> configuration field in attempt to prevent Ant from building with Open JDK 8
> on Windows - since this is a combination which is not supported.
>
> Is it possible by any chance to find the offending XML tag or attribute in
> the Ant Build Matrix XML definition and remove it to see if then Jenkins
> becomes able to reload the job ?
>
> Regards,
>
> Antoine
> On May 5, 2014, at 8:51 AM, Antoine Levy Lambert  wrote:
>
> > I remember accessing the configuration option of Ant-Build-Matrix a few
> days ago, and then recently when Jan informed me that we had
> > already a Jenkins job to build Ant using its maven POMs, I wanted to
> look at the Ant-Build-Matrix configuration to see how the notifications are
> configured
> > and I could not find it.This was on 30/4/2014. The last notification
> from the job was on 11/4/2014 on notificati...@ant.apache.org.
> >
> > Let me ask infra if there is a way to recover the job.
> >
> >
> >
> > Regards,
> >
> > Antoine
> > On May 5, 2014, at 8:07 AM, Nicolas Lalevée 
> wrote:
> >
> >> Yesterday I was wondering why it didn't appeared in my "Personal View",
> but I didn't looked into it, merly though it was a UI bug.
> >> But it seems indeed gone…
> >>
> >> Nicolas
> >>
> >> Le 5 mai 2014 à 12:35, Jan Matèrne (jhm)  a écrit :
> >>
> >>> Does anyone know where (and why) the matrix build is gone?
> >>>
> >>> https://builds.apache.org/job/Ant-Build-Matrix/
> >>>
> >>>
> >>>
> >>> Jan
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> -
> >> 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] migration to git

[Michael Clarke]

+1 from me for Ant, +0 for the other associated projects.

I'm happy to help with any migration or post migration cleanup of
docs/processes, but am only properly familiar with the Ant core so may
not be much help with the likes of Ivy but can give it a shot if
needed.

> On 28 Apr 2014, at 13:32, "Nicolas Lalevée"  
> wrote:
>
>
>> Le 28 avr. 2014 à 05:02, Antoine Levy Lambert  a écrit :
>>
>> Hi,
>>
>> Let's vote about migrating to git :
>>
>> -  Ant
>>
>> - Ivy
>>
>> - easyant
>>
>> - Ivyde
>>
>> - the antlibs
>>
>> I am not including the sandbox in the thread intentionally.
>>
>> The web sites will remain in svn in any event because svnpubsub is the only 
>> supported mechanism to maintain web sites AFAIK.
>>
>> [] Yes
>> [] No
>
> +0 for all.
>
> It's not a +1 because even if I like git more than svn, I am not sure of the 
> amount of work required afterwards (documentation update, CI, release 
> scripts, etc…), so I don't want my vote to be counted as important as the 
> vote of someone who doesn't want to make the transition.
>
> But it's a positive 0 as I would gladly follow any decision taken by the PMC, 
> especially on IvyDE.
>
> Nicolas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>

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

Re: AW: Migrating to Git

[Michael Clarke]

I think a move to Git is a good idea.

I personally don't have a huge issue with using Subversion, but Git would
make it easier to allow potentially high impact changes to be made outside
of the mainline repository. These changes could then be opened up for
review by others before any decision about whether they get accepted into
master (I know that SVN had branches for doing this, but this was only
available to people who already had commit status). I think that moving to
Git would make it easier to submit features and patches given the
prevalence of the likes of Github.

Thanks,
Michael


On 14 April 2014 15:15, Martin Gainty  wrote:

> Jan/Stefan
>
> This is the license.txt which sits in every apache project
> Maven currently contains license in  $M2_HOME/license.txt
>
>
>  Apache License
>Version 2.0, January 2004
> http://www.apache.org/licenses/
>
>TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
>
>1. Definitions.
>
>   "License" shall mean the terms and conditions for use, reproduction,
>   and distribution as defined by Sections 1 through 9 of this document.
>
>   "Licensor" shall mean the copyright owner or entity authorized by
>   the copyright owner that is granting the License.
>
>   "Legal Entity" shall mean the union of the acting entity and all
>   other entities that control, are controlled by, or are under common
>   control with that entity. For the purposes of this definition,
>   "control" means (i) the power, direct or indirect, to cause the
>   direction or management of such entity, whether by contract or
>   otherwise, or (ii) ownership of fifty percent (50%) or more of the
>   outstanding shares, or (iii) beneficial ownership of such entity.
>
>   "You" (or "Your") shall mean an individual or Legal Entity
>   exercising permissions granted by this License.
>
>   "Source" form shall mean the preferred form for making modifications,
>   including but not limited to software source code, documentation
>   source, and configuration files.
>
>   "Object" form shall mean any form resulting from mechanical
>   transformation or translation of a Source form, including but
>   not limited to compiled object code, generated documentation,
>   and conversions to other media types.
>
>   "Work" shall mean the work of authorship, whether in Source or
>   Object form, made available under the License, as indicated by a
>   copyright notice that is included in or attached to the work
>   (an example is provided in the Appendix below).
>
>   "Derivative Works" shall mean any work, whether in Source or Object
>   form, that is based on (or derived from) the Work and for which the
>   editorial revisions, annotations, elaborations, or other
> modifications
>   represent, as a whole, an original work of authorship. For the
> purposes
>   of this License, Derivative Works shall not include works that remain
>   separable from, or merely link (or bind by name) to the interfaces
> of,
>   the Work and Derivative Works thereof.
>
>   "Contribution" shall mean any work of authorship, including
>   the original version of the Work and any modifications or additions
>   to that Work or Derivative Works thereof, that is intentionally
>   submitted to Licensor for inclusion in the Work by the copyright
> owner
>   or by an individual or Legal Entity authorized to submit on behalf of
>   the copyright owner. For the purposes of this definition, "submitted"
>   means any form of electronic, verbal, or written communication sent
>   to the Licensor or its representatives, including but not limited to
>   communication on electronic mailing lists, source code control
> systems,
>   and issue tracking systems that are managed by, or on behalf of, the
>   Licensor for the purpose of discussing and improving the Work, but
>   excluding communication that is conspicuously marked or otherwise
>   designated in writing by the copyright owner as "Not a Contribution."
>
>   "Contributor" shall mean Licensor and any individual or Legal Entity
>   on behalf of whom a Contribution has been received by Licensor and
>   subsequently incorporated within the Work.
>
>2. Grant of Copyright License. Subject to the terms and conditions of
>   this License, each Contributor hereby grants to You a perpetual,
>   worldwide, non-exclusive, no-charge, royalty-free, irrevocable
>   copyright license to reproduce, prepare Derivative Works of,
>   publicly display, publicly perform, sublicense, and distribute the
>   Work and such Derivative Works in Source or Object form.
>
>3. Grant of Patent License. Subject to the terms and conditions of
>   this License, each Contributor hereby grants to You a perpetual,
>   wo

Re: Build failed in Jenkins: Ant-Build-Matrix » JDK 1.6 (latest),Windows #697

[Michael Clarke]

The Jenkins master got rebooted shortly after this failure so I don't know
if the Ops were already up to something. Neither Windows slave is currently
active so I can't see if the reboot has recovered the build or not.

Our Windows builds just generally don't seem right:

JDK 1.8 on Windows gives the following (I suspect this requires Ops input
to fix):

java.io.IOException
:
Cannot run program
"f:\hudson\hudson-slave\tools\hudson.model.JDK\jdk-1.8.0\jdk.exe" (in
directory "f:\hudson\hudson-slave\tools\hudson.model.JDK\jdk-1.8.0"):
CreateProcess error=740, The requested operation requires elevation


Open JDK also tried to run on Windows, despite is only being available
on Ubuntu nodes (can one of our project with the appropriate Karama
tweak our matrix?)


Thanks,

Michael



On 19 April 2014 22:01, Antoine Levy Lambert  wrote:

> Our build is successful but Jenkins is running out of memory processing
> JUnit results if I understand correctly.
>
> I wonder whether we should ask Infra to run Jenkins with a larger PermGen
> space as the error message suggests or whether there is something else to
> do on our end ?
>
> Regards,
>
> Antoine
>
>
> On Apr 19, 2014, at 9:40 AM, Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> >
> >
> > BUILD SUCCESSFUL
> > Total time: 26 minutes 57 seconds
> > Recording test results
> > ERROR: Failed to archive test reports
> > java.io.IOException: remote file operation failed: <
> https://builds.apache.org/job/Ant-Build-Matrix/jdk=JDK%201.6%20(latest),label=Windows/ws/>
> at hudson.remoting.Channel@4629d59e:windows1
> >   at hudson.FilePath.act(FilePath.java:910)
> >   at hudson.FilePath.act(FilePath.java:887)
> >   at hudson.tasks.junit.JUnitParser.parse(JUnitParser.java:87)
> >   at
> hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:121)
> >   at
> hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:133)
> >   at
> hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
> >   at
> hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
> >   at
> hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:714)
> >   at hudson.model.Build$BuildExecution.post2(Build.java:182)
> >   at
> hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:663)
> >   at hudson.model.Run.execute(Run.java:1714)
> >   at hudson.matrix.MatrixRun.run(MatrixRun.java:146)
> >   at
> hudson.model.ResourceController.execute(ResourceController.java:88)
> >   at hudson.model.Executor.run(Executor.java:231)
> > Caused by: java.io.IOException: Remote call on windows1 failed
> >   at hudson.remoting.Channel.call(Channel.java:731)
> >   at hudson.FilePath.act(FilePath.java:903)
> >   ... 13 more
> > Caused by: java.lang.OutOfMemoryError: PermGen space
> >   at java.lang.ClassLoader.defineClass1(Native Method)
> >   at java.lang.ClassLoader.defineClass(Unknown Source)
> >   at java.lang.ClassLoader.defineClass(Unknown Source)
> >   at
> hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:322)
> >   at
> hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:236)
> >   at java.lang.ClassLoader.loadClass(Unknown Source)
> >   at java.lang.ClassLoader.loadClass(Unknown Source)
> >   at hudson.tasks.junit.SuiteResult.parse(SuiteResult.java:120)
> >   at hudson.tasks.junit.TestResult.parse(TestResult.java:273)
> >   at
> hudson.tasks.junit.TestResult.parsePossiblyEmpty(TestResult.java:229)
> >   at hudson.tasks.junit.TestResult.parse(TestResult.java:164)
> >   at hudson.tasks.junit.TestResult.parse(TestResult.java:147)
> >   at hudson.tasks.junit.TestResult.(TestResult.java:123)
> >   at
> hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:117)
> >   at
> hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:90)
> >   at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2462)
> >   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> >   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> >   at hudson.remoting.Request$2.run(Request.java:328)
> >   at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> >   at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
> >   at java.util.concurrent.FutureTask.run(Unknown Source)
> >   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> >   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> >   at hudson.remoting.Engine$1$1.run(Engine.java:63)
> >   at java.lang.Thread.run(Unknown Source)
> > Build step 'Publish JUnit test result report' changed build result to
> FAILURE
>
>
> -

Re: svn commit: r1588563 [4/16] - in /ant/core/trunk: ./ manual/ manual/Types/ src/etc/testcases/taskdefs/ src/etc/testcases/taskdefs/optional/ src/etc/testcases/taskdefs/optional/antlr/ src/etc/testc

[Michael Clarke]

>
> buildRule.executeTarget("test1");
> ==> could the BuildFileRule use a default (test name) for executeTarget?
> buildRule.executeTarget();
>

I'm not sure it can - the same build file is often used for multiple tests,
each calling a different target, so how would we know which target was
intending to be called? If we were to change the general testing practice
to have an individual build XML for each test then this would be fine,
although I'm not sure this would be the right way to go. Alternatively we
could have an executeTarget() method that executes a default target (e.g.
"test") or incrementally executes targets for that class ("test1" on first
call, "test2" on the second call"), but this seems like it would just be
introducing complexity into BuildFileRule to force a specific convention.
I'd be interested in other's opinions on this though.


> //TODO assert exception message
> Here the rule ExpectedException would help
>

Agreed, although the problem still remains that we're not asserting we have
the right exception: how do we know Ant hasn't thrown a build exception
about a missing attribute when the test is expecting it to throw a
BuildException about now being able to create a temporary file? Working out
the exception messages and moving to ExpectedException is currently planned
to be part of my second phase of migration. There are some tests where we
have multiple exception asserts grouped into a single method so I need to
spit these into individual methods to allow the ExpectedException rule to
be used, but I plan on doing this as part of the exception testing cleanup.

Thanks,
Michael

Migration of Ant test to JUnit4

[Michael Clarke]

Hi,

I've now completed the migration of Ant's test cases to JUnit4 and would
like to give other developers a chance to review/comment on these changes
before I merge them back into SVN. My changes can be found on Github at
https://github.com/mc1arke/ant/tree/JUnit4Conversion (
https://github.com/mc1arke/ant/compare/JUnit4Conversion.patch for anyone
who wants to apply a patch against their local workspace).

Notable changes:
1. Deprecation of org.apache.tools.ant.BuildFileTest
and org.apache.tools.ant.types.selectors.BaseSelectorTest
2. Introduction of org.apache.tools.ant.BuildFileRule and
org.apache.tools.ant.types.selectors.BaseSelectorRule to replace deprecated
classes, but with the removal of methods directly relating to asserting
values
3. Introduction of org.apache.tools.ant.AntAssert to provide additional
Asserts beyond the default JUnit ones, and thecreation of
org.apache.tools.ant.FileUtilities to provide common file utilities used in
many tests
4. Addition of @Test annotation to all Test methods, and addition or
@Ignore annotations to methods that had previously been commented out or
named in a way that prevented JUnit 3 seeing/running them.
5. Use of JUnit's Assume to dynamically skip tests that previously silently
returned if certain conditions weren't met (e.g. the Symlink tests not
running on Windows)
6. TODO markers added to tests that previously used exception handling
checks but didn't check the value of the exception being returned. I'll
look at coming back to these in the future to add proper asserts and remove
the TODOs.
7. Removal of Thread.sleep in tests, and the sleep command in associated
XML build files where this has been used to force a difference in file
creation timestamps, and the use of File.setLastModified() instead. This
has knocked 1 minute 30 seconds off the JUnit execution time using
Cloudbees Buildhive Jenkins instance, although I've not looked at whether
similar can be done for the AntUnit tests.
8. Updated the documentation for writing tests to refer to the new 'Rule'
classes rather than the previous Test classes

I'll hold of committing these changes to SVN for a couple of days to give
people a chance to comment. Unless I hear any significant objections to
these changes by the middle of Wednesday, I'll look commit to SVN on
Wednesday night (UK time).

Thanks,
Michael

Re: svn commit: r1580520 - in /ant/core/trunk: ./ manual/Tasks/ src/main/org/apache/tools/ant/taskdefs/optional/junit/

[Michael Clarke]

I had started this a few months back (
https://github.com/mc1arke/ant/tree/JUnit4Conversion) but got side-tracked
due to a job change. I'd be happy to go back and continue/finish the work
if there's a general demand for it.


On 31 March 2014 01:14, Matt Sicker  wrote:

> I'd be a willing volunteer to help port the unit tests to JUnit 4. There
> are various methods to using JUnit 4 with JUnit 3 test cases, suites, etc.,
> that allow for easier migration as well. I do know that JUnit 4 has a
> minimum requirement of Java 1.5 at least due to annotations.
>
>
> On 30 March 2014 18:53, Antoine Levy Lambert  wrote:
>
> > Hello Matt,
> >
> > thanks for this suggestion.
> >
> > I have not used the JUnit TemporaryFolder rule because it is introduced
> in
> > JUnit 4 and the Ant test cases are extending
> > a class of JUnit 3.
> >
> > The policy of the Ant project is usually to keep everything binary
> > compatible ...
> >
> > If there is interest and willing volunteers and a consensus we could
> > change that, at least in the case of BuildFileTest and JUnit 3/4 and base
> > "BuildFileTest" on JUnit 4.
> >
> > Regards,
> >
> > Antoine
> > On Mar 23, 2014, at 1:50 PM, Matt Sicker  wrote:
> >
> > > Could you use the JUnit TemporaryFolder rule? That appears to be rather
> > > threadsafe.
> > >
> > >
> > > On 23 March 2014 11:28, Antoine Levy Lambert  wrote:
> > >
> > >> Hi,
> > >>
> > >> Thanks to John Elion for this contribution.
> > >>
> > >> I have tried it on the Ant test cases. This makes the execution of the
> > >> test cases shorter by 3 minutes with 2 threads [ not sure what is the
> > total
> > >> time because I also run the antunit tests ].
> > >>
> > >> Some of our test cases do not support parallelism because they are
> > >> creating and dropping temporary directories and files which have the
> > same
> > >> names.
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Charles Duffy as a committer

[Michael Clarke]

+1

Thanks,
Michael

> On 22 Nov 2013, at 17:08, Antoine Levy-Lambert  wrote:
>
> I would like to nominate Charles Duffy as a committer. Charles has proposed
> a number of patches to Ivy such as IVY-1421, IVY-1423, IVY-1424 and
> recently a patch concerning the useorigin attribute for the case of URL
> resources which happen to be files.
>
> Let's vote on it.
>
> [  ] +1 to add Charles Duffy as a committer
> [ ] -1 to disagree
> [ ] +0 means "I don't care"
>
> Here is my +1.
>
> Antoine
>
>
>
> Envoyé avec AquaMail pour Android
> http://www.aqua-mail.com
>
>
>
> -
> 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] Ant 1.9.1 Release

[Michael Clarke]

+1 from me too


On 19 May 2013 13:22, Jean-Louis Boudart wrote:

> +1
>
>
> 2013/5/16 Antoine Levy Lambert 
>
> > Hi,
> >
> > I have uploaded candidate artefacts for an ant 1.9.1 release to :
> > http://people.apache.org/~antoine/dist
> >
> > Let's vote on releasing these.
> >
> >
> > Let's start with my own +1.
> >
> > Regards,
> >
> > Antoine
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://ant.apache.org/easyant/
>

Re: JUnit4 requirement (was Re: svn commit: r1460264)

[Michael Clarke]

Ant 1.9.0 contained 2 issues relating to JUnit 4:
1. Ant not compiling if only JUnit 3 was on the classpath. This was
discussed as part of this mail thread and resolved with SVN commit
1471109. There shouldn't have been any direct impact on users as it
wasn't possible to invoke any of the code that would have thrown class
not found exceptions without a unit tests having thrown an
AssumptionViolatedException from the JUnit 4 JAR.
2. NoClassDefFoundError if attempting to use a JUnit JAR outside of
the Ant lib directory (Bug 54835). This would impact any user who is
defining the JUnit JAR in the classpath property for the JUnit task
but not having the JAR in Ant's classpath (any user using Ant without
adding additional JARs to ANTLIB and using Ivy or Maven tasks to
download the JUnit JAR). This was fixed in SVN commit 1470668 by
updating the list of classes to be handled by the split class loader.

The basic outcome of this is that there is no requirement for a
specific version of JUnit for anyone running the JUnit task, but
version 1.9.0 of Ant does require JUnit (the version shouldn't matter)
to be on the core classpath. We could update the documentation to
specify that any version of JUnit 3 or 4 could be placed on the
classpath, providing it satisfies the dependencies in the user's code,
but there is no need to specify a specific version of JUnit in our
documentation.

Thanks,
Michael

On 6 May 2013, at 10:01, Antoine Levy Lambert  wrote:

> Hi,
>
> I have noticed a bug report CASSANDRA-5388  concerning Ant 1.9.0 and JUnit 
> library dependencies.
>
> Maybe this bug report can help to clarify the exact dependencies of Ant 
> concerning JUnit.
>
> The current "install.html" in svn says that Ant is dependent upon junit.jar 
> without specifying minimal versions and without differentiating between 
> junit3 and junit4.
>
> It would help if someone would explain the dependency in more detail.
>
> Regards,
>
> Antoine
>
> On Mar 30, 2013, at 2:44 PM, Stefan Bodewig wrote:
>
>> On 2013-03-28, Stefan Bodewig wrote:
>>
>>> On 2013-03-27, Michael Clarke wrote:
>>
>>>>>> * the optional ant-junit4.jar has been merged into ant-junit.jar
>>>>>> as Ant now requires JUnit4.
>>
>>>> Is it really the case that Ant requires JUnit4? The changes I
>>>> introduced for @Ignore annotations in Ant 1.9.0 shouldn't impact
>>>> backwards compatibility with JUnit3 and I don't believe any other
>>>> changes in the 1.9.0 release force users to need the JUnit4 jar whilst
>>>> running tests.
>>
>>> Some classes in the junit package didn't seem to compile in Gump, I
>>> think BriefJUnitFormatter was one of them.
>>
>> The formatter all now import org.junit.Ignore so require JUnit 4 at
>> compile time.  It may stil be possible to use JUnit 3 at runtime.
>>
>> 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
>

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

Re: Adding if/unless conditions on commandline args

[Michael Clarke]

+1 from me too

On 3 May 2013, at 09:37, Jean-Louis Boudart  wrote:

> +1
>
>
> 2013/5/3 Antoine Levy Lambert 
>
>> I wonder whether we could not add if an unless on all nested elements in
>> the framework ?
>>
>>
>> Regards,
>>
>> Antoine
>> On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
>>
>>> Hi,
>>>
>>> It's currently difficult to make reusable script when using  task
>> or
>>> any other task using commandline args.
>>> We oftenly need some "dynamic arguments" and this can be complicated.
>>>
>>> Therefor, i suggest to introduce if/unless conditions on comand line
>> args :
>>>
>>> 
>>>  
>>>  
>>>  
>>>  
>>> 
>>>
>>> I have a working implementation  with related tests and documentation.
>>> Commandline.Arg class now extends ProjectComponent, and expose accessors
>>> for if/unless condition, and rely on PropertyHelper to check conditions.
>>>
>>> Is this sufficient ? From what i have seen, it doesn't break backward
>>> compatibility at least all tests are green :p.
>>>
>>> The setProject(Project p) method should be invoked "automatically" by
>>> ProjectHelper isn't it ?
>>>
>>> If ant is used in pure java and we ommited invoking setProject(Project p)
>>> method, it should also works as PropertyHelper seems null safe.
>>>
>>> If there is no objection i will commit this this week end.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://ant.apache.org/easyant/

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

Gump Ant Build - JUnit3/JUnit4 changes

[Michael Clarke]

I've fixed the JUnit task to repair the JUnit3/JUnit4 split. Could the Gump
config changes [1] be reversed so Gump reverts to loading ant-junit4.jar as
part of its tests?

Thanks,
Michael

[1] http://svn.apache.org/viewvc?view=revision&revision=1460263

Re: JUnit4 requirement

[Michael Clarke]

https://github.com/mc1arke/ant/commit/63251494ed70b7694305e43c9cc37879ca3bd5adfixes
this, providing CustomJUnit4AdapterCache is moved into the ant-junit4
JAR. I can make a further commit to reverse the removal of the JUnit4 JAR
and add the CustomJUnit4AdapterCache to the JAR then bundle it up into a
patch if wanted?

Thanks,
Michael


On 30 March 2013 18:44, Stefan Bodewig  wrote:

> On 2013-03-28, Stefan Bodewig wrote:
>
> > On 2013-03-27, Michael Clarke wrote:
>
> >>>> * the optional ant-junit4.jar has been merged into ant-junit.jar
> >>>>  as Ant now requires JUnit4.
>
> >> Is it really the case that Ant requires JUnit4? The changes I
> >> introduced for @Ignore annotations in Ant 1.9.0 shouldn't impact
> >> backwards compatibility with JUnit3 and I don't believe any other
> >> changes in the 1.9.0 release force users to need the JUnit4 jar whilst
> >> running tests.
>
> > Some classes in the junit package didn't seem to compile in Gump, I
> > think BriefJUnitFormatter was one of them.
>
> The formatter all now import org.junit.Ignore so require JUnit 4 at
> compile time.  It may stil be possible to use JUnit 3 at runtime.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: svn commit: r1460264 - in /ant/core/trunk: WHATSNEW build.xml src/etc/poms/ant-junit/pom.xml src/etc/poms/ant-junit4/ src/etc/poms/pom.xml

[Michael Clarke]

> +* the optional ant-junit4.jar has been merged into ant-junit.jar
> +  as Ant now requires JUnit4.

Is it really the case that Ant requires JUnit4? The changes I
introduced for @Ignore annotations in Ant 1.9.0 shouldn't impact
backwards compatibility with JUnit3 and I don't believe any other
changes in the 1.9.0 release force users to need the JUnit4 jar whilst
running tests.

JUnit3 is still available for downloading from various sites and users
working against older codebases may still have it bundled in their
workspace so it's not infeasible that someone way want to run tests
using JUnit3 and Ant 1.9.0 or above.

That being said, it should be possible for users to drop the JUnit4
jar in as a direct replacement to the JUnit3 jar in these cases; so we
wouldn't be forcing users wanting to upgrade Ant to perform
particularly high risk tasks. The real question is: was there a
technical reason for making this change or are we just looking to
limit limit the dependency on older libraries?

If the switch to JUnit4 is intentional then the JUnit task could do
with some tidying up to remove Java 1.4 checks, remove the reflection
used to guard against JUnit4 not being on the classpath, and merge the
split of code used to protect JUnit3 backwards compatibility. I
currently have changes pending (for once I get commit access) which
will allow the JUnit task to be 'intelligent' about which classes it
passes to the JUnit core [1] and am happy to perform a bit of tidy
up/refactor of the existing JUnit task code at the same time if we're
guaranteeing JUnit4 is on the classpath when the JUnit task if called.

Thanks,Michael


[1] https://github.com/mc1arke/ant/commits/JUnitNonTestsSkipped

Re: getting List of modified files in CVS

[Michael Clarke]

This can be done using the CvsChangeLog task [1].

Thanks
Michael

[1] http://ant.apache.org/manual/Tasks/changelog.html

On 11 Mar 2013, at 07:32, salt2012  wrote:

> Hi All,
>
> Please let us know how to get the list of modified files in CVS using ant.
>
>
> Thanks
> Salt
>
>
>
> --
> View this message in context: 
> http://ant.1045680.n5.nabble.com/getting-List-of-modified-files-in-CVS-tp5713935.html
> Sent from the Ant - Dev mailing list archive at Nabble.com.
>
> -
> 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: [ANNOUNCE] Apache Ant 1.9.0 Released

[Michael Clarke]

>From the release notes:
> - support for @Ignore annotation and requirement of JUnit 4.11

This isn't quite true: we now support @Ignore in JUnit4 but should be
able to support all JUnit versions. The change in JUnit JAR in the
optional directory was to allow testing of Assume failures with a
specified message so only impacts Ant's unit tests, not tests executed
by Ant. I've been using the Nightly Build version of the JUnit task to
execute tests running with JUnit 4.2 for the past week without issue.
Could we therefore update the homepage key features note to make this
clear. I'd suggest just removing the bullet point about JUnit
versions.

Thanks
Michael

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

Re: Contributions (was: Re: Suggestion - JUnit4 tests for Ant)

[Michael Clarke]

I'm not sure why my patch didn't make it onto the list so I've cloned the
Ant Github repository to my account [1] and applied my example changes [2].

I'll leave the discussion around Git versus Subversion for others to debate
(Git would get my vote for what it's worth). I'm happy to either contribute
my unit testing changes as a patch (although this could get very complex to
review given the number of tests available for change) or to commit changes
myself if the project wants me on-board as a committer.

Either way, feel free to comment on my changes either directly in Github or
on email. The only impact my changes should have on external code would be
compile failures for anyone extending an existing tests and expecting to
have methods like JUnit3's TestCase#assert...() or anything other than a
no-args constructor still available; or users having tests not running
since they're not marked with @Test and no longer implicitly extends
TestCase. I would expect such situations are limited and can be covered in
a release note, as well as leaving the current BuildFileTest in place (but
deprecated) for anyone who doesn't want to migrate fully.

Thanks,
Michael

[1] https://github.com/mc1arke/ant
[2]
https://github.com/mc1arke/ant/commit/a04fd9ad0cec576b55a119d2e846329a3ae36e91


On 8 March 2013 14:48, Jesse Glick  wrote:

> First, BuildFileRule sounds like a great idea; do not see a patch so
> cannot comment further.


> Second, should Michael just be nominated as a committer? The @Ignore
> change was complex and valuable, and refactoring unit tests demonstrates
> serious intent.
>
> Third, why are we still using Subversion when we could be using Git [1]?
> Apache makes us keep the “official” repo on git.apache.org. That is lame,
> especially given the existence of CLAHub [2]; but with Git you can still do
> your real work on GitHub, whose crown jewel is of course the pull request
> system. PRs make it much, much easier to evaluate, comment on, iterate, and
> accept contributions than patches attached to Bugzilla—and make the
> distinction between “committer” and “frequent contributor” only a matter of
> whether you have the permission to click the “Merge” button at the end.
>
> That said, Antoine is doing most of the work these days so whatever
> environment he is most comfortable in wins. Just thought I would put out a
> probe.
>
>
> [1] 
> http://www.apache.org/dev/**writable-git
> [2] http://www.clahub.com/
>
>
> --**--**-
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Suggestion - JUnit4 tests for Ant

[Michael Clarke]

I'd like to make a proposal around unit testing the Ant core.

Whilst Ant has support for JUnit4, most of the unit tests are written
against JUnit 3. This itself isn't an issue, although some of the existing
test structures prevent new test being written in JUnit4.

I'd like to propose introducing some JUnit4 support into Ant's tests. One
big possibility is in BuildFileTest, which currently extends TestCase so
limits any extending class to JUnit 3. In my attached patch I've split this
into a Junit4 rule - BuildFileRule - and a class to provide Assert
functions not currently in Junit's bundled Asserts. I've also migrated a
couple of existing tests as an example of using these new classes.

Aside from other features available under JUnit4, this change allows
reporting of which tests are skipped per configuration on the CI  builds
(for tests that use JUnit's Assume class rather than just return). This
should make it easy to tell what features are actually being checked on
each build.

Does anyone have any objection to such a change and, if no objections,
should I look to migrate more classes? I don't have commit access to Ant so
would need someone to apply any patches for me - I'm happy to email them to
this list or put the changes into Github (or similar) for someone to pull
if wanted.

Any comments or suggestions appreciated.

Thanks,
Michael

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

Broken build in Java 1.5

[Michael Clarke]

It looks like my patch to fix JUnit Ignore notifications has broken
compilation on Java 1.5 machines. I've fixed this in the attached patch by
replacing !String#isEmpty() calls with String#length() !=0 and removing
@Override annotations on implementations of interface methods.

Sorry for breaking the build, hope the attached helps.

Thanks,
Michael

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