Re: [VOTE] move over to gitbox.apache.org
+1 Antoine > On Dec 10, 2018, at 7:23 AM, Jan Matèrne (jhm) wrote: > > +1 We are neither the first nor the only project which should migrate, so it > should work smoothly. ;-) TODOs: change local remote urls, update Jenkins > jobs, update homepage > > Jan > > >> -Ursprüngliche Nachricht- >> Von: Jaikiran Pai [mailto:jaiki...@apache.org] >> Gesendet: Samstag, 8. Dezember 2018 02:13 >> An: dev@ant.apache.org >> Betreff: Re: [VOTE] move over to gitbox.apache.org >> >> +1 for the move. >> >> -Jaikiran >> >> >> On 07/12/18 10:29 PM, Stefan Bodewig wrote: >>> Hi all >>> >>> as indicated by Daniel we'll have to mover over sooner rather than >>> later anyway. So we may better do so now with no release in sight. >>> >>> Any objections or do we want to go ahead? >>> >>> 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: [VOTE] Release Ant 1.9.9 based on RC1
+ 1 Antoine > On Feb 2, 2017, at 2:30 PM, Stefan Bodewig wrote: > > Hi all > > I've created a release candidate for 1.9.9: > > git tag: ANT_199_RC1 > on commit: d5bd3b4 > tarballs: https://dist.apache.org/repos/dist/dev/ant/ > revision: 18085 > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapacheant-1012/org/apache/ant/ > > This Vote will be open at least for 72 hours and close no earlier than > 2017-02-05 19:30UTC. > > Cheers > >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.1 based on RC1
+1 Antoine > On Feb 2, 2017, at 2:33 PM, Stefan Bodewig wrote: > > Hi all > > I've created a release candidate for 1.10.1: > > git tag: ANT_1.10.1_RC1 > on commit: 530e59d > tarballs: https://dist.apache.org/repos/dist/dev/ant/ >revision: 18086 > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapacheant-1013/org/apache/ant/ > > This Vote will be open at least for 72 hours and close no earlier than > 2017-02-05 19:30UTC. > > 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: Jenkins build became unstable: Ant-Build-Matrix-master » Open JDK 1.8 (Only on ubuntu nodes),Ubuntu #851
I will take a look too. Antoine On Apr 17, 2016, at 1:44 PM, Stefan Bodewig wrote: > On 2016-04-17, Apache Jenkins Server wrote: > >> See >> <https://builds.apache.org/job/Ant-Build-Matrix-master/jdk=Open%20JDK%201.8%20(Only%20on%20ubuntu%20nodes),label=Ubuntu/851/changes> > > That's pretty frustrating. SetPermissions doesn't work on Windows (and > the ownedby tests are failing as well). Obviously the nio.file.attribute > package sounded too good to be true. > > I'll improve upon what is there, but not now. > > Cheers > >Stefan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [2/2] ant git commit: symlink and executable file selectors
Hello Stefan, there is a command mklink on Windows [1] which is described as being able to create symbolic links. There is also an API function CreateSymbolicLink [2]. Concerning executable files, it seems that the executable nature of a file depends upon its extension, see [3]. So maybe if we create a file xyz.bat the file should be found executable. What I do not understand is that I have practical remembrances of changing the executable flag of a file under cygwin and this “chmod” command allowing dll s to actually work on Windows after they were untarred or copied with cygwin utilities. I hope this helps. Using a library called jna (java native access) [4] we could call system level methods from java and make them available within ant tasks for testing or production purposes. Regards, Antoine [1] https://technet.microsoft.com/en-us/library/cc753194.aspx [2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363878%28v=vs.85%29.aspx [3] https://msdn.microsoft.com/en-us/library/windows/desktop/ms722429%28v=vs.85%29.aspx [4] https://github.com/java-native-access/jna On Apr 9, 2016, at 11:07 AM, Stefan Bodewig wrote: > On 2016-04-09, wrote: > >> symlink and executable file selectors > > Two questions: > > (1) does anybody know how to write tests for either on Windows? I've > currently only enabled antunit tests on Unix (at least that's what I > wanted to do). > > (2) do we want to port it as optional task depending on Java7 for 1.9.8? > This would only benefit people who can use Java7 but not Java8. > > 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.9.7 based on RC1
+1, Antoine On Apr 9, 2016, at 6:03 AM, Stefan Bodewig wrote: > Hi all > > I've created a release candidate for 1.9.7: > > git tag: ANT_197_RC1 > on commit: cecbf5c > tarballs: https://dist.apache.org/repos/dist/dev/ant/ > revision: 13103 > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapacheant-1009/org/apache/ant/ > > Vote will be open at least for 72 hours and close no earlier than 2016-04-12 > 10:00UTC. > > Cheers > >Stefan > > - - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: IntelliJ Idea licenses
There is a form to fill. Michael let me send you the URL directly. Regards, Antoine On Mar 7, 2016, at 1:57 PM, Michael Clarke wrote: > 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 >> >> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
IntelliJ Idea licenses
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?
I like the idea of Michael to develop on the master branch against Java 1.8 and to have a long term support branch for Java 1.6 or Java 1.7. Yes that would increase the amount of time needed to make releases. We might not necessarily release both builds at the same time every time since the Java 1.6 branch might get less work done on it, and quickly it would become a pain to maintain the backport branch based on the master branch if we start taking advantage of java 1.8 features. I would be happy too with just upgrading the required version to Java 1.7 for now after Ant 1.9.7 and starting to take advantage of Java API’s introduced in Java 1.7. Regards, Antoine On Mar 6, 2016, at 1:56 PM, Michael Clarke wrote: > 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 >> >> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Ant builds in Jenkins
Hi, first I have not been working on Ant at all in the last 12 months or more, I recently changed job and my current work has been very involving. I would like to catch up and make a few contributions to Ant and Ivy. I noticed that the Jenkins builds in JDK 1.5 on Ubuntu are failing [1] , this is due to a patch recently committed by Stefan [2]. The particular reason why this is failing is that the @Override annotation was not accepted for interface methods in Java 1.5, see [3]. Let me remove this @Override annotation for now, but maybe we should start discussing about moving Ant to build only on Java 1.6 and upwards. (and this is being conservative, we could also consider moving to Java 1.7). Regards, Antoine [1] https://builds.apache.org/job/Ant-Build-Matrix/ [2] https://git1-us-west.apache.org/repos/asf?p=ant.git;a=commitdiff;h=4d0bbb44049a6add8043859c67253545e74c0c3a [3] http://dertompson.com/2008/01/25/override-specification-changes-in-java-6/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Need feedback for Bugzilla 58555
Hello Stefan,
I have had a look at the code. Is the bit of code which is responsible for the
behavior described in Bugzilla 58555 this one :
in org.apache.tools.ant.taskdefs.Execute :
public void setWorkingDirectory(File wd) {
workingDirectory =
(wd == null || wd.getAbsolutePath().equals(antWorkingDirectory))
? null : wd;
}
Would your change essentially be to simplify this setter to
public void setWorkingDirectory(File wd) {
workingDirectory = wd;
}
?
Regards,
Antoine
On Oct 27, 2015, at 2:29 PM, Stefan Bodewig wrote:
> Hi all
>
> <https://bz.apache.org/bugzilla/show_bug.cgi?id=58555>
>
> I'd rather not repeat what I've typed there. The tldr version:
> without dir defaults to executing in the current directory if
> vmlauncher="true" and the project's basedir if vmlauncher="false" - and
> has done so ever since we introduced vmlauncher back in Ant 1.4.
>
> I think we can fix the immediate problem of the bug report (dir is
> ignored if it happens to be the CWD) but don't dare to change the split
> logic WRT no dir attribute at all. I'm afraid there will be build files
> that rely on either behavior, so the best we can likely do, is to
> document the difference.
>
> Am I overlooking anything?
>
> Stefan
>
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Stephen Haberman as a committer
+1 Antoine On Oct 5, 2015, at 7:37 AM, Stefan Bodewig wrote: > On 2015-10-05, Conor MacNeill wrote: > >> I would like to nominate Stephen Haberman as a committer. Stephen has >> submitted a number of well tested patches to the Ivy codebase. I >> believe adding Stephen would strengthen the committer-base, >> particularly for the Ivy Sub-project. > > +1 > > Stefan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: browsing ant source code with eclipse and Netbeans
Hi, there is a file “fetch.xml” with which you can get Ant’s library dependencies. fetch.xml requires a prebuilt version of Ant. Once you have downloaded the library dependencies, which should go into /lib/optional, you can set your classpath in eclipse and netbeans and you should be able to compile all the code. see [1] Best regards, Antoine [1] http://ant.apache.org/manual/install.html#buildingant Antoine On Jul 15, 2015, at 9:54 AM, mohamed chebbi wrote: > Hi, > > i cloned the ant repository and try to browse the source code with eclipse > but i still getting some error, i think many of them are example of bad code. > > so i want steps to import ant source code into eclipse and Netbeans. > > If you have any link about it will be nice. > - 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.6 based on RC1
+1 for the release, Antoine On Jun 29, 2015, at 5:32 AM, Stefan Bodewig wrote: > Hi all > > I've created a release candidate for 1.9.6: > > git tag: ANT_196_RC1 > hash: a143e2d3a > on commit: b09976c > tarballs: https://dist.apache.org/repos/dist/dev/ant/ > revision: 9551 > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapacheant-1008/org/apache/ant/ > > Vote will be open at least for 72 hours and close no earlier than Thu > 2nd July 2015 9:30UTC. > > Cheers > >Stefan >
Re: [ANN] Apache Ant 1.9.5 Released
Thanks very much for the hard work Stefan ! Antoine On Jun 4, 2015, at 12:16 AM, Stefan Bodewig wrote: > Signed PGP part > The Apache Ant Team is pleased to announce the release of Apache Ant > 1.9.5. > > Version 1.9.5 is mostly a bug fix release but adds a few new features > like new resource collections allbutlast/allbutfirst that complement the > existing first/last collections. > > Apache Ant is a Java library and command-line tool that helps building > software. > > Source and binary distributions are available for download from the > Apache Ant download site: > > http://ant.apache.org/bindownload.cgi > http://ant.apache.org/srcdownload.cgi > > When downloading, please verify signatures using the KEYS file available > at the above location when downloading the release. > > Changes in this version include: > > Changes that could break older environments: > --- > > * The ReplaceTokens filter can now use token-separators longer than >one character. >Bugzilla Report 56584 > > * The changes that added 's support for gzip encoding >automatically uncompressed content that would not have been touched >before - like when downloading .tar.gz files. A new flag has >been added to control the behavior and its default will make >work as it did in 1.9.3. >Bugzilla Report 57048 > > Fixed bugs: > --- > > * TarArchiveInputStream failed to read archives with empty gid/uid >fields. >Bugzilla Report 56641 > > * TarArchiveInputStream could throw IOException when reading PAX >headers from a "slow" InputStream. > > * XMLJunitResultFormatter could throw NullPointerException if Java >cannot determine the local hostname. >Bugzilla Report 56593 > > * URLResource#getLastModified tried to access the connection to the >URL without making sure it was established, potentially leading to >a NullPointerException when using FTP. >Bugzilla Report 56873 > > * Long-Name and -link or PAX-header entries in TAR archives >always had the current time as last modfication time, creating >archives that are different at the byte level each time an >archive was built. > > * runant.py should now work as well when the path of the Java >executable contains spaces. >github pull request #1 > > * now supports nested and elements. >Bugzilla Report 47002 > > * complete-ant-cmd.pl now also knows about the -file option. >Bugzilla Report 57371 > > * the br-replace template inside the XSLT stylesheets used by > could cause stack overflows or out-of-memory errors >when applied to big outputs. >Bugzilla Report 57341 > > * removed spurious warning about unclosed ZipFiles when reading the >archive failed. >Port of https://issues.apache.org/jira/browse/COMPRESS-297 > > * FileUtils.rename which is used by several tasks can throw a >NullPointerException if the "normal" renameTo operation fails and >an exception occurs while rename falls back to copying and >deleting the file. >Bugzilla Report 57533 > > * complete-ant-cmd.pl would incorrectly suggest words from the build >file description. >Bugzilla Report 51931 > > * complete-ant-cmd.pl now also completes tasks without a description. >Bugzilla Report 57542 > > * LocalPropertyStack could run into ConcurrentModificationException >when tasks spawned new child threads that accessed the properties. >Bugzilla Report 55074 > > * TarEntry's constructor with a File and a String arg didn't >normalize the name. > > * Between 1.8.4 and 1.9.0 TarInputStream started to parse file >names using the platform's default encoding rather than as ASCII. >This has been a breaking change that has never been marked as such >(in fact it went unnoticed). In order to allow and > to work on platforms who's encoding doesn't match >the encoding of file names inside the archive, both now support >encoding attributes. >The attribute has also been added to for symmetry. >Bugzilla Report 57822 > > Other changes: > -- > > * it is now possible to provide proxy configuration to signjar >when using the timestamped authority. >Bugzilla Report 56678 > > * complete-ant-cmd.pl now also analyzes the ANT_ARGS environment >variable. >Bugzilla Report 57371 > > * ported some of the write-optimization of Commons Compress 1.10 to >the ZIP package > > * adapted unit tests to Java9 and added "javac1.9" as valid option >for javac&
Re: [VOTE] Release Ant 1.9.5 based on RC1
+1 Antoine On May 31, 2015, at 10: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 > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Planning 1.9.5
Thanks Stefan for volunteering, I do not have anything special to add. Best regards, Antoine On May 23, 2015, at 1:58 PM, Stefan Bodewig wrote: > Hi all > > I plan to cut Ant 1.9.5 [1] on Sun May 31 unless anybody objects. > > Given this is going to be our first release using git I intend to create > a branch for preparations that may get deleted after the release. I > don't think we need a long-term branch. > > Personally I don't intend to make any changes before creating the > release but wanted to give everybody else a chance to add things - or > stop me. > > Cheers > >Stefan > > [1] actually or a release candidate that shall become 1.9.5 > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: stuck with site generation issue for ivy
Done, this page http://ant.apache.org/ivy/choose-distrib.html is updated. Antoine On May 14, 2015, at 9:50 PM, Antoine Levy Lambert wrote: > Thanks Nicolas, > > I will use this information as soon as I have some time to work on ivy, maybe > this week-end. > > Regards, > > Antoine > On May 11, 2015, at 5:08 AM, Nicolas Lalevée > wrote: > >> Hi Antoine, >> >> Sorry I forgot to respond to your mail. >> >> The latest milestone folder used to be a external svn dependency. Since >> we’re using git now, I had to work around it. As my previous email about >> that, you need to checkout it manually, with the help of an Ant target. >> >>> svn:external have disappeared, they are now replaced with manual git >>> checkout. I have made an ant target to handle it properly. >>> >>> For instance, the trunk version (trunk as the name used in the path of the >>> url) correspond to the master branch. Here are the command to checkout, >>> then to generate: >>> ant checkout-history -Dhistory.version=master -Dtarget.history.folder=trunk >>> ant generate-history -Dhistory.version=trunk >>> >>> If the name of the tag is the same as the version in the url, then no need >>> to specify an ‘history folder’: >>> ant checkout-history -Dhistory.version=2.4.0 >>> ant generate-history -Dhistory.version=2.4.0 >> >> >> So you’ll have to run: >> ant checkout-history -Dhistory.version=2.4.0 >> -Dtarget.history.folder=latest-milestone >> >> Nicolas >> >>> Le 16 avr. 2015 à 04:34, Antoine Levy Lambert a écrit : >>> >>> Hi, >>> >>> Reposting previous message with a different subject. >>> >>> I did a change to >>> https://svn.apache.org/repos/asf/ant/site/ivy/sources/choose-distrib.html >>> in order to document better the fact that the ivy distribution without >>> dependencies is not suitable for large uploads. >>> >>> But I am stuck with the site generation. >>> >>> When I run “ant generate-site” I see this : >>> >>> bash-3.2$ ant generate-site /all >>> Buildfile: /Users/antoine/dev/asf/ant-site/ivy/build.xml >>> >>> generate-site: >>> [xooki:generate] processing 22 source files... >>> processing 19 source files... >>> [generate] processing >>> /Users/antoine/dev/asf/ant-site/ivy/sources/choose-distrib.html... >>> [generate] generating to >>> /Users/antoine/dev/asf/ant-site/ivy/production//choose-distrib.html >>> [print] processing >>> /Users/antoine/dev/asf/ant-site/ivy/sources/history/latest-milestone/index.html... >>> [print] index.html is not a valid xooki source. ignored. >>> >>> /all: >>> >>> Where do I find ant-site/ivy/sources/history/latest-milestone/index.html >>> for this code generation ? >>> >>> Is it possible that this index.html exists in the working copy of one of us >>> but has not been added to subversion ? >>> >>> Or do I misunderstand the build process for the doc ? >>> >>> I am still thinking that we build the doc of ivy from a working copy pulled >>> from subversion. >>> >>> Correct me if I am wrong. >>> >>> I am looking at this file >>> ttps://svn.apache.org/repos/asf/ant/site/README.txt for guidance. >>> >>> Regards, >>> >>> Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: stuck with site generation issue for ivy
Thanks Nicolas, I will use this information as soon as I have some time to work on ivy, maybe this week-end. Regards, Antoine On May 11, 2015, at 5:08 AM, Nicolas Lalevée wrote: > Hi Antoine, > > Sorry I forgot to respond to your mail. > > The latest milestone folder used to be a external svn dependency. Since we’re > using git now, I had to work around it. As my previous email about that, you > need to checkout it manually, with the help of an Ant target. > >> svn:external have disappeared, they are now replaced with manual git >> checkout. I have made an ant target to handle it properly. >> >> For instance, the trunk version (trunk as the name used in the path of the >> url) correspond to the master branch. Here are the command to checkout, then >> to generate: >> ant checkout-history -Dhistory.version=master -Dtarget.history.folder=trunk >> ant generate-history -Dhistory.version=trunk >> >> If the name of the tag is the same as the version in the url, then no need >> to specify an ‘history folder’: >> ant checkout-history -Dhistory.version=2.4.0 >> ant generate-history -Dhistory.version=2.4.0 > > > So you’ll have to run: > ant checkout-history -Dhistory.version=2.4.0 > -Dtarget.history.folder=latest-milestone > > Nicolas > >> Le 16 avr. 2015 à 04:34, Antoine Levy Lambert a écrit : >> >> Hi, >> >> Reposting previous message with a different subject. >> >> I did a change to >> https://svn.apache.org/repos/asf/ant/site/ivy/sources/choose-distrib.html in >> order to document better the fact that the ivy distribution without >> dependencies is not suitable for large uploads. >> >> But I am stuck with the site generation. >> >> When I run “ant generate-site” I see this : >> >> bash-3.2$ ant generate-site /all >> Buildfile: /Users/antoine/dev/asf/ant-site/ivy/build.xml >> >> generate-site: >> [xooki:generate] processing 22 source files... >> processing 19 source files... >> [generate] processing >> /Users/antoine/dev/asf/ant-site/ivy/sources/choose-distrib.html... >> [generate] generating to >> /Users/antoine/dev/asf/ant-site/ivy/production//choose-distrib.html >> [print] processing >> /Users/antoine/dev/asf/ant-site/ivy/sources/history/latest-milestone/index.html... >> [print] index.html is not a valid xooki source. ignored. >> >> /all: >> >> Where do I find ant-site/ivy/sources/history/latest-milestone/index.html for >> this code generation ? >> >> Is it possible that this index.html exists in the working copy of one of us >> but has not been added to subversion ? >> >> Or do I misunderstand the build process for the doc ? >> >> I am still thinking that we build the doc of ivy from a working copy pulled >> from subversion. >> >> Correct me if I am wrong. >> >> I am looking at this file >> ttps://svn.apache.org/repos/asf/ant/site/README.txt for guidance. >> >> 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
stuck with site generation issue for ivy
Hi, Reposting previous message with a different subject. I did a change to https://svn.apache.org/repos/asf/ant/site/ivy/sources/choose-distrib.html in order to document better the fact that the ivy distribution without dependencies is not suitable for large uploads. But I am stuck with the site generation. When I run “ant generate-site” I see this : bash-3.2$ ant generate-site /all Buildfile: /Users/antoine/dev/asf/ant-site/ivy/build.xml generate-site: [xooki:generate] processing 22 source files... processing 19 source files... [generate] processing /Users/antoine/dev/asf/ant-site/ivy/sources/choose-distrib.html... [generate] generating to /Users/antoine/dev/asf/ant-site/ivy/production//choose-distrib.html [print] processing /Users/antoine/dev/asf/ant-site/ivy/sources/history/latest-milestone/index.html... [print] index.html is not a valid xooki source. ignored. /all: Where do I find ant-site/ivy/sources/history/latest-milestone/index.html for this code generation ? Is it possible that this index.html exists in the working copy of one of us but has not been added to subversion ? Or do I misunderstand the build process for the doc ? I am still thinking that we build the doc of ivy from a working copy pulled from subversion. Correct me if I am wrong. I am looking at this file ttps://svn.apache.org/repos/asf/ant/site/README.txt for guidance. Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [jira] (IVY-1197) OutOfMemoryError during ivy:publish
Hello, thanks to every one involved for your input on this discussion. So I will not attempt to make the use of http-client compulsory. I have just changed a file in the ant-site http repository under ivy/sources/choose-distrib.html [1] Afterwards, I tried to run the build file located here : [2] I am getting an error : bash-3.2$ ant generate-site Buildfile: /Users/antoine/dev/asf/ant-site/ivy/build.xml generate-site: [xooki:generate] processing 22 source files... processing 19 source files... [generate] processing /Users/antoine/dev/asf/ant-site/ivy/sources/choose-distrib.html... [generate] script error in file /Users/antoine/dev/asf/ant-site/xooki/xooki.js : sun.org.mozilla.javascript.internal.EcmaError: TypeError: Cannot read property "id" from null (/Users/antoine/dev/asf/ant-site/xooki/xooki.js#1041) in /Users/antoine/dev/asf/ant-site/xooki/xooki.js at line number 1041 [generate] Result: 10 [print] processing /Users/antoine/dev/asf/ant-site/ivy/sources/history/latest-milestone/index.html... [print] index.html is not a valid xooki source. ignored. BUILD SUCCESSFUL Total time: 7 seconds I notice that choose-distrib is not regenerated. Also this choose-distrib.html had long lines, is it due to a constraint of xooki ? Regards, Antoine [1] http://svn.apache.org/viewvc/ant/site/ivy/sources/choose-distrib.html?view=log [2] http://svn.apache.org/viewvc/ant/site/ivy/build.xml?view=co&revision=1635330&content-type=text%2Fplain On Apr 9, 2015, at 11:20 AM, Loren Kratzke wrote: > The short term fix would be documentation. Say it in clear language right > next to the download link - > >"If you publish large artifacts then you must download Ivy+deps. >Install commons httpclient, codec, and logging jars into ant/lib next to > ivy jar." > > Note that you need all three jars, not just httpclient. That detail is not > documented anywhere that I know of. > > That is what can be done now. Going forward the options are as follows: > >1. Keep everything the same, consider the documentation as the solution. >2. Require httpclient jars to be installed. >3. Find a work around for the buffering/authentication issues of > HttpURLConnection. >4. Include necessary httpclient classes inside ivy.jar. > > Several options available. Each has its own merits. > > L.K. > > -Original Message- > From: Maarten Coene [mailto:maarten_co...@yahoo.com.INVALID] > Sent: Thursday, April 09, 2015 7:51 AM > To: Ant Developers List > Subject: Re: [jira] (IVY-1197) OutOfMemoryError during ivy:publish > > I'm not a fan of this proposal, I like it that Ivy doesn't has any > dependencies when using standard resolvers. > Perhaps it could be added to the documentation that if you use the > URLresolver for large uploads you'll have to add httpclient to the classpath? > > > Maarten > > > > > - Oorspronkelijk bericht - > Van: Antoine Levy Lambert > Aan: Ant Developers List > Cc: > Verzonden: donderdag 9 april 3:50 2015 > Onderwerp: Re: [jira] (IVY-1197) OutOfMemoryError during ivy:publish > > Also, I wonder whether we should not make the use of httpclient with ivy > compulsory, since Loren says that the HttpUrlConnection of the JDK is always > copying the full file into a ByteArray when authentication is performed. > > That would make the code more simple. > > Regards, > > Antoine > > On Apr 7, 2015, at 9:22 PM, Antoine Levy Lambert wrote: > >> Hi, >> >> I wonder whether we should not upgrade ivy to use the latest http client >> library too ? >> >> Regards, >> >> Antoine >> >> On Apr 7, 2015, at 12:46 PM, Loren Kratzke (JIRA) wrote: >> >>> >>> [ >>> https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jir >>> a.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1448 >>> 3468#comment-14483468 ] >>> >>> Loren Kratzke edited comment on IVY-1197 at 4/7/15 4:45 PM: >>> >>> >>> I would be happy to provide you with a project that will reproduce the >>> issue. I can and will do that. >>> >>> Generally speaking from a high level, the utility classes are calling >>> convenience methods and writing to streams that ultimately buffer the data >>> being written. There is buffering, then more buffering, and even more >>> buffering until you have multiple copies of the entire content of the >>> stream stored in over sized buffers (because they double in size when they >>> fill up). Oddly, the twist is that the J
Re: [jira] (IVY-1197) OutOfMemoryError during ivy:publish
Also, I wonder whether we should not make the use of httpclient with ivy compulsory, since Loren says that the HttpUrlConnection of the JDK is always copying the full file into a ByteArray when authentication is performed. That would make the code more simple. Regards, Antoine On Apr 7, 2015, at 9:22 PM, Antoine Levy Lambert wrote: > Hi, > > I wonder whether we should not upgrade ivy to use the latest http client > library too ? > > Regards, > > Antoine > > On Apr 7, 2015, at 12:46 PM, Loren Kratzke (JIRA) wrote: > >> >> [ >> https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483468#comment-14483468 >> ] >> >> Loren Kratzke edited comment on IVY-1197 at 4/7/15 4:45 PM: >> >> >> I would be happy to provide you with a project that will reproduce the >> issue. I can and will do that. >> >> Generally speaking from a high level, the utility classes are calling >> convenience methods and writing to streams that ultimately buffer the data >> being written. There is buffering, then more buffering, and even more >> buffering until you have multiple copies of the entire content of the stream >> stored in over sized buffers (because they double in size when they fill >> up). Oddly, the twist is that the JVM hits a limit no matter how much RAM >> you allocate. Once the buffers total more than about ~1GB (which is what >> happens with a 100-200MB upload) the JVM refuses to allocate more buffer >> space (even if you jack up the RAM to 20GB, no cigar). Honestly, there is no >> benefit in buffering any of this data to begin with, it is just a side >> effect of using high level copy methods. There is no memory ballooning at >> all when the content is written directly to the network. >> >> I will provide a test project and note the break points where you can debug >> and watch the process walk all the way down the isle to an OOME. I will have >> this for you asap. >> >> >> was (Author: qphase): >> I would be happy to provide you with a project that will reproduce the >> issue. I can and will do that. >> >> Generally speaking from a high level, the utility classes are calling >> convenience methods and writing to streams that ultimately buffer the data >> being written. There is buffering, then more buffering, and even more >> buffering until you have multiple copies of the entire content of the stream >> stored in over sized buffers (because they double in size when they fill >> up). Oddly, the twist is that the JVM hits a limit no matter how much RAM >> you allocate. Once the buffers total more than about ~1GB (which is what >> happens with a 100-200MB upload) the JVM refuses to allocate more buffer >> space (even is you jack up the RAM to 20GB, no cigar). Honestly, there is no >> benefit in buffering any of this data to begin with, it is just a side >> effect of using high level copy methods. There is no memory ballooning at >> all when the content is written directly to the network. >> >> I will provide a test project and note the break points where you can debug >> and watch the process walk all the way down the isle to an OOME. I will have >> this for you asap. >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org
Re: [jira] (IVY-1197) OutOfMemoryError during ivy:publish
Hi, I wonder whether we should not upgrade ivy to use the latest http client library too ? Regards, Antoine On Apr 7, 2015, at 12:46 PM, Loren Kratzke (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483468#comment-14483468 > ] > > Loren Kratzke edited comment on IVY-1197 at 4/7/15 4:45 PM: > > > I would be happy to provide you with a project that will reproduce the issue. > I can and will do that. > > Generally speaking from a high level, the utility classes are calling > convenience methods and writing to streams that ultimately buffer the data > being written. There is buffering, then more buffering, and even more > buffering until you have multiple copies of the entire content of the stream > stored in over sized buffers (because they double in size when they fill up). > Oddly, the twist is that the JVM hits a limit no matter how much RAM you > allocate. Once the buffers total more than about ~1GB (which is what happens > with a 100-200MB upload) the JVM refuses to allocate more buffer space (even > if you jack up the RAM to 20GB, no cigar). Honestly, there is no benefit in > buffering any of this data to begin with, it is just a side effect of using > high level copy methods. There is no memory ballooning at all when the > content is written directly to the network. > > I will provide a test project and note the break points where you can debug > and watch the process walk all the way down the isle to an OOME. I will have > this for you asap. > > > was (Author: qphase): > I would be happy to provide you with a project that will reproduce the issue. > I can and will do that. > > Generally speaking from a high level, the utility classes are calling > convenience methods and writing to streams that ultimately buffer the data > being written. There is buffering, then more buffering, and even more > buffering until you have multiple copies of the entire content of the stream > stored in over sized buffers (because they double in size when they fill up). > Oddly, the twist is that the JVM hits a limit no matter how much RAM you > allocate. Once the buffers total more than about ~1GB (which is what happens > with a 100-200MB upload) the JVM refuses to allocate more buffer space (even > is you jack up the RAM to 20GB, no cigar). Honestly, there is no benefit in > buffering any of this data to begin with, it is just a side effect of using > high level copy methods. There is no memory ballooning at all when the > content is written directly to the network. > > I will provide a test project and note the break points where you can debug > and watch the process walk all the way down the isle to an OOME. I will have > this for you asap. > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Possible Ivy bug (and suggested fix) in ChainResolver
Hello Loren, thanks for digging into all this. It might not be a good thing for softwares like ivy which have a lot of users in the wild to change defaults - because people like to be able to upgrade and still have an old behavior, but making the needed behaviors possible at least should be done. Your point 2 makes sense to me though, if two artifacts have as version 1.0-SNAPSHOT we should compare their timestamp. Point 3 your help will be welcome. Best regards, Antoine On Mar 25, 2015, at 3:00 PM, Martin Gainty wrote: > > > >> From: lkrat...@blueorigin.com >> To: dev@ant.apache.org >> Subject: RE: Possible Ivy bug (and suggested fix) in ChainResolver >> Date: Wed, 25 Mar 2015 18:16:08 + >> >> I found the root cause of the fishiness. It was not a bug (and was not >> actually in ChainResolver) but is in my opinion a rather unfortunate and >> poorly chosen default setting that is to blame (the latest-strategy). >> >> During resolution in the chain resolver, the current sub-resolver tries to >> determine whether it should be skipped and the previous artifact be selected >> over the current artifact. Assuming that the "force" and "dynamic" tests do >> not result in an early rejection of the current artifact, the "latest" of >> the two artifacts is selected by sorting the artifacts in a List using a >> Comparator suited to the current latest-strategy (latest-revision, >> latest-time, etc). >> >> The problem here is quite simple. The default latest-strategy is >> "latest-revision". So when a second artifact has been resolved, and it is of >> the same revision as the first, nothing gets sorted. The result is that you >> will get the first artifact found based upon the ordering of your >> repositories in the chain instead of the newer of the two artifacts. >> >> I think that either latest-time needs to be the default strategy or the >> latest revision comparator needs to do a secondary sort to sort by >> lastModified time. >> >> Possibly allow configuration of this behavior (should there be a secondary >> sort by time to avoid stale artifacts, or not so that repository order >> breaks the tie). This is important (critical) behavior and should be >> configurable. >> >> Defaulting to latest-revision will not only deliver undesired stale >> artifacts, but it is unclear to the user why they are getting stale >> artifacts or how to make it stop happening. The latest-time strategy will >> give you the latest revision 99% of the time and the latest artifact 100% of >> the time. But the latest-revision strategy will give you the latest artifact >> 100%, 50%, 33%, or 25% of the time when the revision numbers are the same, >> depending upon how many resolvers you have (1/n), and assuming that any >> repository may contain the latest artifact. >> >> Furthermore, the docs do not give a great description of "force". I learned >> much about the actual behavior of this attribute while debugging. First >> thing I learned was that it is not a good name. >> >> What force actually does is it allows a resolver to be considered when a >> previous resolver has found an artifact. After the first artifact has been >> found, only repositories with force=true will have a chance of competing >> (for instance, they might have a newer version of 1.0.0-SNAPSHOT). >> Otherwise, they are discarded immediately and no date comparison is >> attempted. >> >> Force should actually be named "considerAlways" or "considerAnyway". That >> seems to be a more suitable name. No action requested here, but pointing out >> that this attribute has a misleading name. >> >> Summary: >> 1 - Please reconsider changing the default latest-strategy to be latest-time. >> >> 2 - Please consider adding a secondary "lastModified" sort to >> LatestRevisionStrategy.ArtifactInfoComparator whether or not you change the >> default latest-strategy to latest-time or not. >> >> 3 - Please document, illustrate, and demonstrate in one place the behaviors >> of chain resolver in combination with force, returnFirst, >> defaultLatestStrategy, ivy.resolver.default.check.modified, useOrigin, and >> other settings and attributes that affect resolution behavior. (I am working >> on this document now.) >> >> 4 - Please consider creating independent caches by default for each >> repository. I have not drilled down on this issue yet, but I suspect that it >> fixes serious cache collision issues that I
Re: question about an IDE
Hello Benjamin, this is perfectly OK to ask about which IDE to use. Different people have different preferences, I use Jetbrain’s IntelliJ, some people use Emacs, … I have used Eclipse too. Best regards, Antoine On Mar 29, 2015, at 7:53 PM, Benjamin Spero wrote: > I’m new to the mailing list and I have something to ask. When developing > java programs what do you think is a better IDE to use, Eclipse or Netbeans? > I read somewhere on a website that Netbeans is developed from the Ant > project. Is this true? I used jGrasp to develop my programs when I studied > the basic java course. I notice that jGrasp is not used beyond the > classroom. Why? I know my questions may seem fundamental but I’m just > learning the ropes. I appreciate your help. > > Thank you, > Ben > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: issue with IBiblioResolverTest.testErrorReport
Hello Nicolas,
unfortunately the status is 200 in BasicURLHandler checkStatus.
Looks like my proxy is not behaving in a standard, decent way.
My ISP is Verizon - it would be an uphill battle to make them change the
behavior of the proxy.
Antoine
I have looked at the HTTP error status
On Jan 26, 2015, at 4:59 AM, Nicolas Lalevée wrote:
>>
>> Le 26 janv. 2015 à 00:56, Antoine Levy Lambert a écrit :
>>
>> Hi,
>>
>> when I run the ivy test suite on my computer at home, the
>> iBiblioResolverTest.testErrorReport errors.
>>
>> The error happens on line 251 :
>>
>> ResolvedModuleRevision rmr = resolver.getDependency(new
>> DefaultDependencyDescriptor(mrid,
>> false), _data);
>>
>> What happens on that line is that :
>>
>> - the proxy that I use at home produces an HTML5 error report about the
>> http://unknown.host.comx
>> - this error report is consumed by ivy as if it was a POM file and generates
>> this exception :
>>
>> java.text.ParseException: Already seen doctype.
>> at
>> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.newParserException(PomModuleDescriptorParser.java:375)
>>
>> One workaround to deal with that is to surround the call to
>> resolver.getDependency with try/catch and also to remove the last assertion :
>> assertLogContains("tried
>> http://unknown.host.comx/org/apache/commons-fileupload/1.0/commons-fileupload-1.0.jar”)
>>
>> This of course is a workaround.
>>
>> Is it also an intelligent solution ?
>>
>> Is the normal behavior when trying to access a non existent host name to get
>> an UnknownHostException ?
>
> I don’t know much about proxy, but considering the IP stack, I would
> understand that the IP is resolved, thus to be the IP of the proxy. But then
> I don’t understand why Ivy is not properly failing. I would expect the proxy
> to at least return a 404. Could you confirm the HTTP status ? You can put a
> break point in BasicURLHandler#checkStatusCode.
>
> Nicolas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
issue with IBiblioResolverTest.testErrorReport
Hi,
when I run the ivy test suite on my computer at home, the
iBiblioResolverTest.testErrorReport errors.
The error happens on line 251 :
ResolvedModuleRevision rmr = resolver.getDependency(new
DefaultDependencyDescriptor(mrid,
false), _data);
What happens on that line is that :
- the proxy that I use at home produces an HTML5 error report about the
http://unknown.host.comx
- this error report is consumed by ivy as if it was a POM file and generates
this exception :
java.text.ParseException: Already seen doctype.
at
org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.newParserException(PomModuleDescriptorParser.java:375)
One workaround to deal with that is to surround the call to
resolver.getDependency with try/catch and also to remove the last assertion :
assertLogContains("tried
http://unknown.host.comx/org/apache/commons-fileupload/1.0/commons-fileupload-1.0.jar”)
This of course is a workaround.
Is it also an intelligent solution ?
Is the normal behavior when trying to access a non existent host name to get an
UnknownHostException ?
Regards,
Antoine
Re: [Ivy] A workspace resolver for Ant
Hello Nicolas, I am trying to understand in which use case I would need this resolver. It seems to be in the case that you want to build using Ant a stack of modules in a directory tree, and use the target/classes folder of each module as a dependency. Does this workspace resolver also has something for test classes which usually are output to a different root folder (for instance target/test-classes). Best regards Nicolas, great to see all the work you do for ivy. Antoine On Jan 25, 2015, at 4:51 PM, Nicolas Lalevée wrote: > Hi, > > We’ve been wondering if the workspace resolver which exists for IvyDE could > be transposed to the Ant world. I think I have made a working one. And I just > pushed it. > > The main issue in the design was about how Ant would be able to describe to > Ivy the projects to take into account, and which would then be their > artifacts. As a principle, I didn’t want to declare the workspace resolver in > the ivysettings. Because the settings, for me, should be quite independent of > the environment is it used. For instance I want it to work both within an Ant > build file and in Eclipse with IvyDE. And IvyDE’s workspace resolver doesn’t > need a modification of the end user's ivysettings in order to properly work. > > To describe the modules, I just used a fileset of the ivy.xml files of the > projects. Then everything would be relative to them, just like the buildlist > ant task is working. > > Then about declaring the artifacts, I have made them explicit. This might not > be the most flexible. I’m not sure how to do better though. > > Then the integration with Ant would be done via the configure task. Here an > exemple. > > > > > > > > > > I have only did some small unit tests for now. This need some proper > integration test to be fully validated. > > Any comment is welcomed. > > 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: Ivy problem with substituting version from pom in url
Hello Travis,
if you alter a POM file in your repository without altering its checksums such
as the .sha1 file, this triggers this error.
I am not using ivy very much myself these days, I wonder whether you can define
the variable kie.version in your ivy settings file, or pass it as a system
property in your build ?
Regards,
Antoine
On Jan 16, 2015, at 1:20 PM, Travis Schmidt wrote:
> Thanks for your response. Any help with is appreciated. I tried altering
> the parent pom in our repo just removing the placeholder with the specific
> version we expect. That caused this error though now
>
> invalid sha1: expected=bdacec5c2aff452637f14e46fdbce15e7395323b
> computed=603ebaf68ad72cc1343d2caf215c73a53138d1e5 (597ms)
>
> Thanks
> Travis
>
> On Fri Jan 16 2015 at 12:04:28 PM Matignon, Patrice <
> patrice.matig...@sap.com> wrote:
>
>> It would appear that the parent pom for JBoss 6.1.0.Final, can't be
>> located. You should inspect that pom and try to see why the parent can't be
>> located.
>> [ivy:resolve] io problem while parsing ivy file:
>> http://ap-serv-j:8081/nexus/content/groups/public/org/
>> drools/drools-multiproject/6.1.0.Final/drools-multiproject-6.1.0.Final.pom
>> (java.io.IOException: Impossible to load parent for
>> file:/home/tschmidt/.ivy2/cache/org.drools/drools-
>> multiproject/ivy-6.1.0.Final.xml.original.
>> Parent=org.kie#kie-parent-with-dependencies;6.1.0.Final)
>> [ivy:resolve] io problem while parsing ivy file:
>> http://ap-serv-j:8081/nexus/content/groups/public/org/
>> drools/drools-core/6.1.0.Final/drools-core-6.1.0.Final.pom
>> (java.io.IOException: Impossible to load parent for
>> file:/home/tschmidt/.ivy2/cache/org.drools/drools-core/
>> ivy-6.1.0.Final.xml.original.
>> Parent=org.drools#drools-multiproject;6.1.0.Final)
>>
>> So the problem is not so much with locating JBoss than its parent pom.
>> More specifically, there seems to be a missing property:
>> [ivy:resolve]
>> http://ap-serv-j:8081/nexus/content/groups/public/org/kie/
>> kie-bom/${kie.version}/kie-bom-${kie.version}.pom
>> [ivy:resolve] -- artifact org.kie#kie-bom;${kie.version}!kie-bom.jar:
>> [ivy:resolve]
>> http://ap-serv-j:8081/nexus/content/groups/public/org/kie/
>> kie-bom/${kie.version}/kie-bom-${kie.version}.jar
>>
>> Normally you wouldn't expect published pom's to have property placeholders
>> unless the property value is also provided in the pom. Not sure why that is
>> not the case here, but it's possibly a publishing error.
>> Maybe you could try setting that property if you know the value and can
>> alter the published pom's in your repo.
>>
>> - P.
>>
>> -Original Message-
>> From: Travis Schmidt [mailto:]
>> Sent: Friday, January 16, 2015 10:48 AM
>> To: dev@ant.apache.org
>> Subject: Ivy problem with substituting version from pom in url
>>
>> I am running into this issue and I am not sure if it is a problem in Ivy or
>> an issue in the projects pom in Maven repo
>>
>> [ivy:resolve] io problem while parsing ivy file:
>> http://ap-serv-j:8081/nexus/content/groups/public/org/kie/
>> kie-parent-with-dependencies/6.1.0.Final/kie-parent-with-
>> dependencies-6.1.0.Final.pom
>> (java.io.IOException: Impossible to import module for
>> file:/home/tschmidt/.ivy2/cache/org.kie/kie-parent-with-
>> dependencies/ivy-6.1.0.Final.xml.original.
>> Import=org.kie#kie-bom;${kie.version})
>> [ivy:resolve] io problem while parsing ivy file:
>> http://ap-serv-j:8081/nexus/content/groups/public/org/
>> drools/drools-multiproject/6.1.0.Final/drools-multiproject-6.1.0.Final.pom
>> (java.io.IOException: Impossible to load parent for
>> file:/home/tschmidt/.ivy2/cache/org.drools/drools-
>> multiproject/ivy-6.1.0.Final.xml.original.
>> Parent=org.kie#kie-parent-with-dependencies;6.1.0.Final)
>> [ivy:resolve] io problem while parsing ivy file:
>> http://ap-serv-j:8081/nexus/content/groups/public/org/
>> drools/drools-core/6.1.0.Final/drools-core-6.1.0.Final.pom
>> (java.io.IOException: Impossible to load parent for
>> file:/home/tschmidt/.ivy2/cache/org.drools/drools-core/
>> ivy-6.1.0.Final.xml.original.
>> Parent=org.drools#drools-multiproject;6.1.0.Final)
>> [ivy:resolve] module not found: org.drools#drools-core;6.1.0.Final
>> [ivy:resolve] nexus: tried
>> [ivy:resolve]
>> http://ap-serv-j:8081/nexus/content/groups/public/org/kie/
>> kie-bom/${kie.version}/kie-bom-${kie.version}.pom
>> [ivy:resolve] -- artifact org.kie#kie-bom;${kie.version}!ki
Re: [VOTE] Ivy 2.4.0 Release - take 2
Nicolas, Jean-Louis, what are your thoughts ? The problem reported by Stefan with the ivy.xml in the source archive must be caused by something in the build process replacing the ivy.xml of the source tree with an expanded version of the same file generated when the task runs ? I guess a minor edit in the build file to make this modified version of ivy.xml go somewhere under the build folder should address this issue for this release and the next ones. I have not spent myself a lot of time on ivy yet but I would like to spend some in 2015 - or maybe even next week if my kids are busy out of the house … I also know how it feels when one creates a release candidate and some minor problems are found and one has to again go through 20 steps in a ReleaseInstructions document … But I am sure we will get there finally. Best regards, Antoine On Dec 14, 2014, at 5:43 AM, Stefan Bodewig wrote: > On 2014-12-13, Nicolas Lalevée wrote: > >> I have built a second release candidate for Ivy 2.4.0 > >> The svn tag of this release is: >> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=0b9db35ee7a94a719e538b04122b86cb997f3a17 > > We should be using signed tags (git tag -s or -u) rather than > lightweight tags for releases. I know we haven't cut any releases from > git so far, so we'll be learning as we go along. > >> The artifacts has been published to: >> https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7405 > > Signatures and licenses look good, RAT is as happy as always (i.e. a few > test files lack licenses). > > As usual the doc folders are different between the source archive and > the git repo and I still can't say I like it. It is kind of difficult > to tell whether they contain the same information. > > And there is one thing that really bothers me and makes me vote -1 > unless anybody can explian it to me: ivy.xml on the tag is different > from the one in the source archive. There are a few whitespace > differences and the one inside the source archive has an XML declaration > (which is good and should also be in the repo, IMHO). More important to > me is the difference of the info tag, though. > >revision="2.4.0" status="release" > publication="20141213170938"> > > in the archive vs > >status="integration"> > > on the tag. As you can see the status, revision and publication > attributes are different. > > As it stands, this is a -1, which is not a veto (releases cannot be > vetoed), it just means you still need three +1s. > > 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] Ivy 2.4.0 Release - take 2
So the first error is due to XmlModuleDescriptorWriterTest maybe making a too
strong assertion concerning the order of XML elements in an info tag which is
probably irrelevant.
Should we be using XMLUnit to compare the XML files ?
The second error is in org.apache.ivy.plugins.resolver.IBiblioResolverTest. The
testcase which fails - testErrorReport - is attempting to resolve an ivy
dependency against an inexistent repository unknown.host.comx. What happens in
this case on my computer is that I am getting this :
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://searchassist.verizon.com/main?InterceptSource=0&ClientLocation=us&ParticipantID=euekiz39ksg8nwp7iqj2fp5wzfwi5q76&FailureMode=1&SearchQuery=&FailedURI=http%3A%2F%2Funknown.host.comx%2Forg%2Fapache%2Fcommons-fileupload%2F1.0%2Fcommons-fileupload-1.0.pom&AddInType=4&Version=2.1.8-1.90base&Referer=&Implementation=0&method=GET"/>
url="<a rel="nofollow" href="http://searchassist.verizon.com/main?InterceptSource=0&ClientLocation=us&ParticipantID=euekiz39ksg8nwp7iqj2fp5wzfwi5q76&FailureMode=1&SearchQuery=&FailedURI=http%3A%2F%2Funknown.host.comx%2Forg%2Fapache%2Fcommons-fileupload%2F1.0%2Fcommons-fileupload-1.0.pom&AddInType=4&Version=2.1.8-1.90base&Referer=&Implementation=0&method=GET";if">http://searchassist.verizon.com/main?InterceptSource=0&ClientLocation=us&ParticipantID=euekiz39ksg8nwp7iqj2fp5wzfwi5q76&FailureMode=1&SearchQuery=&FailedURI=http%3A%2F%2Funknown.host.comx%2Forg%2Fapache%2Fcommons-fileupload%2F1.0%2Fcommons-fileupload-1.0.pom&AddInType=4&Version=2.1.8-1.90base&Referer=&Implementation=0&method=GET";if</a>(top.location!=location){var
w=window,d=document,e=d.documentElement,b=d.body,x=w.innerWidth||e.clientWidth||b.clientWidth,y=w.innerHeight||e.clientHeight||b.clientHeight;url+="&w="+x+"&h="+y;}window.location.replace(url);
in
file:/Users/antoine/dev/asf/ant-core/build/cache/org.apache/commons-fileupload/ivy-1.0.xml.original
which is an error message in HTML from my ISP.
Should testErrrorReport be written differently and maybe use a checked in
ivy.xml for the org.apache / commons-fileupload / 1.0 module that it is trying
to download from unknown.host.comx ?
Also should PomModuleDescriptorParser#parseDescriptor not rethrow a more
informative exception than this SAX Exception “ErrorAlreay seen doctype” ? Do
we have an IvyException class ?
For the vote I am on the edge. On one side I see that these test 2 test
failures/errors do not indicate real serious problems, on the other hand I am
afraid of delaying the release still by more time.
Thoughts ?
Antoin
On Dec 13, 2014, at 1:59 PM, Antoine Levy Lambert wrote:
> Hi,
>
> I just checked out the 2.4.0 tag from git and I ran the build.
>
> I am getting 2 errors :
>
> XmlModuleDescriptorWriterTest testExtraInfosFromMaven Failure
> expected:<...properties__commons.[collections.version>1.0.5
>
> 1.0.4
> but
> was:<...properties__commons.[logging.version>1.0.4
>
> 1.0.5
>
>
> junit.framework.ComparisonFailure:
> expected:<...properties__commons.[collections.version>1.0.5
> 1.0.4
> but
> was:<...properties__commons.[logging.version>1.0.4
> 1.0.5
>
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorWriterTest.testExtraInfosFromMaven(XmlModuleDescriptorWriterTest.java:158)
>
> testErrorReport Error Already seen doctype.
>
> java.text.ParseException: Already seen doctype.
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.newParserException(PomModuleDescriptorParser.java:375)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:297)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:108)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:817)
> at
> org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:834)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:1326)
> at org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:538)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:273)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:506)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolverTest.
Re: [VOTE] Ivy 2.4.0 Release - take 2
Hi, I just checked out the 2.4.0 tag from git and I ran the build. I am getting 2 errors : XmlModuleDescriptorWriterTest testExtraInfosFromMaven Failure expected:<...properties__commons.[collections.version>1.0.5 1.0.4 but was:<...properties__commons.[logging.version>1.0.4 1.0.5 junit.framework.ComparisonFailure: expected:<...properties__commons.[collections.version>1.0.5 1.0.4 but was:<...properties__commons.[logging.version>1.0.4 1.0.5 at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorWriterTest.testExtraInfosFromMaven(XmlModuleDescriptorWriterTest.java:158) testErrorReport Error Already seen doctype. java.text.ParseException: Already seen doctype. at org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.newParserException(PomModuleDescriptorParser.java:375) at org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:297) at org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:108) at org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:817) at org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68) at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:834) at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:1326) at org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:538) at org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:273) at org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:506) at org.apache.ivy.plugins.resolver.IBiblioResolverTest.testErrorReport(IBiblioResolverTest.java:251) Caused by: org.xml.sax.SAXParseException; systemId: file:/Users/antoine/dev/asf/ant-ivy/build/cache/org.apache/commons-fileupload/ivy-1.0.xml.original; lineNumber: 2; columnNumber: 10; Already seen doctype. at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.apache.ivy.util.XMLHelper.parseToDom(XMLHelper.java:223) at org.apache.ivy.plugins.parser.m2.PomReader.(PomReader.java:122) at org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:118) This is running the build with Java 1.7 on Mac OS 10.9.5 Regards, Antoine On Dec 13, 2014, at 1:28 PM, Antoine Levy Lambert wrote: > Hello Nicolas, > > is the actual link for the binaries this one : > > https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0/ > > Antoine > On Dec 13, 2014, at 11:45 AM, Nicolas Lalevée > wrote: > >> I have built a second release candidate for Ivy 2.4.0 >> >> The svn tag of this release is: >> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=0b9db35ee7a94a719e538b04122b86cb997f3a17 >> >> The artifacts has been published to: >> https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7405 >> >> Do you vote for the release of these binaries? >> >> [ ] Yes >> [ ] No >> >> Regards, >> > > > - > 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] Ivy 2.4.0 Release - take 2
Hello Nicolas, is the actual link for the binaries this one : https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0/ Antoine On Dec 13, 2014, at 11:45 AM, Nicolas Lalevée wrote: > I have built a second release candidate for Ivy 2.4.0 > > The svn tag of this release is: > https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=0b9db35ee7a94a719e538b04122b86cb997f3a17 > > The artifacts has been published to: > https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7405 > > Do you vote for the release of these binaries? > > [ ] Yes > [ ] No > > Regards, > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELED][VOTE] Release Ivy 2.4.0
Yes !!! Antoine On Dec 9, 2014, at 9:36 AM, Stefan Bodewig wrote: > On 2014-12-09, Jean-Louis Boudart wrote: > >> This directory containing styles (css,etc...) is used by both website >> (which is still in svn and published via svnpubsub) and project >> documentation (which is in ivy's git repository). As infra was proposing >> git-svn mirror it was a good compromise. Website could live using >> svn:externals to fetch appropriate files, and project documentation could >> use git submodules. > >> Considering we're talking about a few files that doesn't move too often i >> was suggesting duplicating them by hand and/or automating it via a script >> during the release process. > > OK, I think I understand. If this is really only needed for a release > build, having the build process fetch them from svn (which I think you > are suggesting) seems to be a good choice. > > Stefan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [CANCELED][VOTE] Release Ivy 2.4.0
On the infrastructure list Gavin wrote that infra is not able to create the mirror of the styles folder of the ivy doc that has been requested by Jean-Louis. The reason being that infra can only create a mirror from a structure having tags and trunk. @Jean-Louis, would creating a new git repository that we would populate manually work ? Regards, Antoine On Dec 3, 2014, at 5:05 PM, JBaruch wrote: > documentation added. > > Baruch. > > -- > JFrog Developer Advocate > www.jfrog.com > +972544954353 > @jbaruch <https://twitter.com/jbaruch/> > http://linkd.in/jbaruch > > On Wed, Dec 3, 2014 at 1:37 PM, JBaruch wrote: > >> Perfect, we are on it. >> On 3 Dec 2014 12:29, "Nicolas Lalevée" wrote: >> >>> I would still would like some doc. >>> >>> The doc in the code source is still broken and it make it difficult to >>> know how it is rendered. >>> In the mean time time, you could write a page. I will then ensure myself >>> that is proper included in the doc and rendered when the build will be >>> fixed. You can take this file as an exemple: >>> >>> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD >>> < >>> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD >>>> >>> >>> Nicolas >>> >>>> Le 2 déc. 2014 à 22:56, JBaruch a écrit : >>>> >>>> Can we use this opportunity to sneak IVY-1474 in? >>>> >>>> Baruch. >>>> >>>> -- >>>> JFrog Developer Advocate >>>> www.jfrog.com >>>> +972544954353 >>>> @jbaruch <https://twitter.com/jbaruch/> >>>> http://linkd.in/jbaruch >>>> >>>> On Tue, Dec 2, 2014 at 6:19 PM, Nicolas Lalevée < >>> nicolas.lale...@hibnet.org> >>>> wrote: >>>> >>>>> It was so obvious that this release candidate should be canceled that I >>>>> forgot to officially set it. Here it is. >>>>> >>>>> I see that the infra ticket is resolved. Jean-Louis spotted some issues >>>>> with it though. But I guess we will retry very soon. >>>>> >>>>> Nicolas >>>>> >>>>>> Le 9 nov. 2014 à 17:56, Nicolas Lalevée >>> a >>>>> écrit : >>>>>> >>>>>> I have built a release candidate for Ivy 2.4.0 >>>>>> >>>>>> The git tag of this release is: >>>>> >>> https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=b7f132a46601cdecfc631052818cab7f498078d2 >>>>>> >>>>>> The artifacts has been published to: >>>>> https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7093 >>>>>> >>>>>> Do you vote for the release of these binaries? >>>>>> >>>>>> [ ] Yes >>>>>> [ ] No >>>>>> >>>>>> Regards, >>>>>> Nicolas >>>>>> >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>>>> >>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>>> >>>>> >>> >>> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Jenkins
Thanks Jan, Antoine On Dec 2, 2014, at 3:57 PM, Jan Matèrne (jhm) wrote: > I changed the used Java version for the Jenkins job from 1.5 to 1.6 because > the last few builds failed due a UnsupportedClassVersion error. > > https://builds.apache.org/job/Ant_BuildFromPOMs > > > > This was easier than searching which of the jars was 1.6+ based ;) > > /home/jenkins/tools/java/latest1.6/bin/java -Xmx2g -Xms256m > -XX:MaxPermSize=512m -cp > /home/jenkins/jenkins-slave/maven3-agent.jar:/home/jenkins/jenkins-slave/too > ls/hudson.tasks.Maven_MavenInstallation/Maven_3.0.5/boot/plexus-classworlds- > 2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main > /home/jenkins/jenkins-slave/tools/hudson.tasks.Maven_MavenInstallation/Maven > _3.0.5 /x1/jenkins/jenkins-slave/slave.jar > /home/jenkins/jenkins-slave/maven3-interceptor.jar > /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 47896 > > > > > > Jan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Fisheye displaying Ant/Ivy/IvyDe' git repositories
Hi, An Atlassian Fisheye instance is now tracking Ant/Ivy/Ivyde ’s git repositories. I have added pointers to that in http://ant.apache.org/git.html Best regards, Antoine see http://fisheye6.atlassian.com/browse/ant-git http://fisheye6.atlassian.com/browse/ant-ivy http://fisheye6.atlassian.com/browse/ant-ivyde - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Updating Ivy's trunk doc in the site
Hi, as far as I know there is no gitpubsub for the web sites so far. At least that was the case when we migrated to git. I had a look at the gitpubsub link that you mention Nicolas, I think this functionality is only available to setup some automation around git commits, for instance for event driven continuous integration servers. Regards, Antoine On Oct 27, 2014, at 7:10 PM, Nicolas Lalevée wrote: > Le 26 oct. 2014 à 20:16, Jean-Louis Boudart a > écrit : > >> Would it be possible to have everything on git ? >> Looks like there is a gitpubsub feature available[1] > > I don’t know either what is possible, I am not familiar with gitpubsub and > submodule. That’s why I am asking here. > >> Another option could be to use svn client for github (but this relies on >> github infra not ASF one :/) [2]. >> >> A "manual" solution could be to have website + released documentation on >> svn. Git could still contains the trunk/master documentation (we only >> publish it on the website when releasing). >> During a release we could zip/export documentation and put it on svn. >> Ideally all this could be probably done by an ant target. >> >> We can ask infra to have svn read only mirror on our git repo but this >> would make release process i think more complicated. > > The solution of replacing the svn:external by the copy of the files from git > is indeed a quite manual process. I’ll do that if nothing better is suggested. > > Nicolas > >> >> WDYT ? >> >> >> [1] http://www.apache.org/dev/gitpubsub.html >> [2] https://help.github.com/articles/support-for-subversion-clients/ >> >> >> >> 2014-10-26 19:49 GMT+01:00 Nicolas Lalevée : >> >>> Now that the Ivy’s code source is in git, but the site is still managed in >>> svn, how do we update the doc of Ivy trunk in the site ? >>> How can I update this : http://ant.apache.org/ivy/history/trunk/index.html >>> >>> We’ll have a similar issue when we will release, we will need to publish >>> the released doc. >>> >>> Nicolas >>> >>> >>> - >>> 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
Re: Release of Ivy 2.4.0
Hi, I have been inactive on ant and ivy since a few months, but I hope to resume work on ivy in 2 weeks from now. Regards, Antoine On Oct 17, 2014, at 2:29 AM, Jean-Louis Boudart wrote: > Hi Josh, > > This issue is supposed to be fixed on master branch could you take a > nightly build and give a try ? > You can find the latest nightly build here : > https://builds.apache.org/view/All/job/Ivy/lastStableBuild/ > > 2014-10-16 22:00 GMT+02:00 Josh Suereth : > >> If It helps, we had to move back to 2.3 because parent-pom-properties don't >> resolve correctly in 2.4.0-rc1 which broke a lot of our users. >> On Oct 15, 2014 6:28 PM, "Maarten Coene" >> wrote: >> >>> If I remember correctly, the 2.4.0-RC1 also introduced some other very >>> annoying bugs, these fixes should be included in the 2.4.0 release as >> well >>> imho. >>> >>> I whish I could help you with it Nicolas, but I also have too little time >>> which will be needed for the first release on git. >>> (In fact, my very very low activity is also caused by the fact that we >> are >>> on git now in combination with the lack of time to learn how to use it >>> properly) >>> >>> >>> Maarten >>> >>> >>> >>> >>> Van: Nicolas Lalevée >>> Aan: Ant Developers List >>> Verzonden: woensdag 15 oktober 18:31 2014 >>> Onderwerp: Release of Ivy 2.4.0 >>> >>> >>> The last release of Eclipse has introduced a nasty bug [2], IvyDE is >>> impacted, and the fix/work-around is in Ivy [2]. I think we should get a >>> fix out very soon. >>> >>> And Ivy has been in RC for quite some time, I suggest we release it with >>> also that fix, as the 2.4.0. >>> >>> This would be the first release done from git, my free time is quite >>> limited, so don’t freak if I take some time to get out a release to be >>> voted upon. >>> >>> Nicolas >>> >>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=445122 >>> [2] https://issues.apache.org/jira/browse/IVY-1487 >>> >>> >>> - >>> 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
Re: [1/8] make it compile under Java5 (1.5.0_22-b03)
Hello Jan,
I was wondering why you are interested into make it compile under Java5
(1.5.0_22-b03) ?
Note, I am just curious, not critical.
It looks like this particular Java version is very demanding concerning the
presence of the final keyword next to method parameters or maybe also for
variables which are in the scope of nested classes.
I am programming in scala these days with its insistence on using val
(immutable variables) wherever possible so I see a connection.
Antoine
On Jul 4, 2014, at 9:15 AM, j...@apache.org wrote:
> Repository: ant
> Updated Branches:
> refs/heads/master 1b76f1b6d -> 789422e13
>
>
> http://git-wip-us.apache.org/repos/asf/ant/blob/13f6d98c/src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java
> --
> diff --git a/src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java
> b/src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java
> index 36024ec..e8df272 100644
> --- a/src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java
> +++ b/src/main/org/apache/tools/ant/util/SymbolicLinkUtils.java
> @@ -70,7 +70,7 @@ public class SymbolicLinkUtils {
> * @return true if the file is a symbolic link.
> * @throws IOException on error.
> */
> -public boolean isSymbolicLink(File file) throws IOException {
> +public boolean isSymbolicLink(final File file) throws IOException {
> return isSymbolicLink(file.getParentFile(), file.getName());
> }
>
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: https://issues.apache.org/jira/browse/INFRA-7913
Now the two g...@git.apache.org and asf...@urd.zones.apache.org are subscribed to our dev list. Antoine On Jun 26, 2014, at 1:14 AM, Jan Matèrne (jhm) wrote: > Regarding GitHub integration: > > https://issues.apache.org/jira/browse/INFRA-7913 > Jake Farrell added a comment - 17/Jun/14 14:23 > Please have a mailing list moderator send an email to the following two > addresses to subscribe them to you dev list > dev-subscribe-allow-git=git.apache@ant.apache.org > dev-subscribe-asfbot=urd.zones.apache@ant.apache.org > > > Is this done? > > Jan > > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: https://issues.apache.org/jira/browse/INFRA-7913
Jan, I do not know who is a mailing list moderator for ant. I just entered another JIRA https://issues.apache.org/jira/browse/INFRA-7972 to be added as a moderator on ant’s lists. Antoine Antoine On Jun 26, 2014, at 1:14 AM, Jan Matèrne (jhm) wrote: > Regarding GitHub integration: > > https://issues.apache.org/jira/browse/INFRA-7913 > Jake Farrell added a comment - 17/Jun/14 14:23 > Please have a mailing list moderator send an email to the following two > addresses to subscribe them to you dev list > dev-subscribe-allow-git=git.apache@ant.apache.org > dev-subscribe-asfbot=urd.zones.apache@ant.apache.org > > > Is this done? > > Jan > > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Depedency to tools.jar
Hello Olivier,
your wish makes sense. You are right, only the specific ant tasks such as
javac/javadoc/javah which use java command line tools should worry about
tools.jar being around.
Before you open a bug report, let’s see whether other Ant committers have
opinions on this topic.
Regards,
Antoine
On Jun 11, 2014, at 3:36 AM, Olivier Croquette wrote:
> Hello,
>
> when using Ant with a JRE (instead of the JDK), the following message appears:
>
> Unable to locate tools.jar. Expected to find it in C:\Program
> Files\Java\jre7\lib\tools.jar
>
> It comes from getToolsJar() in
> "ant/src/main/org/apache/tools/ant/launch/Locator.java", which is called
> independently of the real need for the classes provided by tools.jar. They
> seem to be used only when building a Java application (see details below).
> However, Ant is also used for non Java builds, for instance DITA uses Ant,
> and seems to work just fine with a JRE. The only inconvenience is the message
> that appears in the logs.
>
> It would be great to get rid of the message in this case. What do you think ?
> Shall I open a bug report ?
>
>
> Here are the references to the classes contained in tools.jar, for the record:
>
> ant/build.xml:
> ant/build.xml:
> ant/manual/Tasks/javadoc.html:
> com.sun.tools.doclets.ToDoTaglet)
> ant/manual/Tasks/javadoc.html:you maybe get a
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl.
> ant/src/etc/testcases/taskdefs/rmic/rmic.xml: property="rmic.present" classname="sun.rmi.rmic.Main"/>
> ant/src/main/org/apache/tools/ant/launch/Locator.java:
> Class.forName("sun.tools.javac.Main");
> ant/src/main/org/apache/tools/ant/launch/Locator.java:
> Class.forName("com.sun.tools.javac.Main");
> ant/src/main/org/apache/tools/ant/taskdefs/compilers/AptCompilerAdapter.java:
>public static final String APT_ENTRY_POINT = "com.sun.tools.apt.Main";
> ant/src/main/org/apache/tools/ant/taskdefs/compilers/CompilerAdapterFactory.java:
> private static final String MODERN_COMPILER = "com.sun.tools.javac.Main";
> ant/src/main/org/apache/tools/ant/taskdefs/compilers/Javac12.java:
> protected static final String CLASSIC_COMPILER_CLASSNAME =
> "sun.tools.javac.Main";
> ant/src/main/org/apache/tools/ant/taskdefs/compilers/Javac13.java:
> Class c = Class.forName ("com.sun.tools.javac.Main");
> ant/src/main/org/apache/tools/ant/taskdefs/optional/javah/SunJavah.java:
> c = Class.forName("com.sun.tools.javah.Main");
> ant/src/main/org/apache/tools/ant/taskdefs/optional/javah/SunJavah.java:
> c = Class.forName("com.sun.tools.javah.oldjavah.Main");
> ant/src/main/org/apache/tools/ant/taskdefs/optional/javah/SunJavah.java: *
> Adapter to com.sun.tools.javah.oldjavah.Main or com.sun.tools.javah.Main.
> ant/src/main/org/apache/tools/ant/taskdefs/optional/jsp/WLJspc.java:
> args[j++] = "sun.tools.javac.Main";
> ant/src/main/org/apache/tools/ant/taskdefs/optional/native2ascii/SunNative2Ascii.java:
> + "sun.tools.native2ascii.Main");
> ant/src/main/org/apache/tools/ant/taskdefs/optional/native2ascii/SunNative2Ascii.java:
> Class n2aMain = Class.forName("sun.tools.native2ascii.Main");
> ant/src/main/org/apache/tools/ant/taskdefs/optional/native2ascii/SunNative2Ascii.java:
> * Adapter to sun.tools.native2ascii.Main.
> ant/src/main/org/apache/tools/ant/taskdefs/rmic/SunRmic.java:public
> static final String RMIC_CLASSNAME = "sun.rmi.rmic.Main";
>
>
> Olivier
>
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] GitHub integration
Here is my vote, On Jun 8, 2014, at 5:08 AM, Jan Matèrne (jhm) wrote: > After some out-of-vote +1, I'll start a formal vote (oh, my 1st one ;) > > > > Apache Infra supplies a variety of GitHub integrations [1]. > > As specified there, it is an "opt in", so we must decide which of these > services we want to have. > > > > Supported integrations are: > > 1. Any Pull Request that gets opened, closed, reopened or commented on now > gets recorded on the project's mailing list +1 > > 2. If a project has a JIRA instance, any PRs or comments on PRs that include > a JIRA ticket ID will trigger an update on that specific ticket > +0 > 3. Replying to a GitHub comment on the dev@ mailing list will trigger a > comment being placed on GitHub (yes, it works both ways!) > +1 > 4. GitHub activity can now be relayed to IRC channels on the Freenode > network. > +0 > > > Vote is open until 15.June [2]. I'll create the INFRA-Ticket on Monday 16th > if vote would pass. > > > > > > Jan > > Antoine > > [1] > https://blogs.apache.org/infra/entry/improved_integration_between_apache_and > > [2] http://ant.apache.org/bylaws.html > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: GitHub integration
Hello Jan, I agree that 1 and 3 sound interesting. Regards, Antoine On Jun 7, 2014, at 6:20 AM, Jan Matèrne (jhm) wrote: > https://blogs.apache.org/infra/entry/improved_integration_between_apache_and > "To be more precise, these new features allows for the following: > > 1. Any Pull Request that gets opened, closed, reopened or commented on now > gets recorded on the project's mailing list > 2. If a project has a JIRA instance, any PRs or comments on PRs that include > a JIRA ticket ID will trigger an update on that specific ticket > 3. Replying to a GitHub comment on the dev@ mailing list will trigger a > comment being placed on GitHub (yes, it works both ways!) > 4. GitHub activity can now be relayed to IRC channels on the Freenode > network. > > As with most of our things, this is an opt-in feature." > > > > I suggest adding GitHub-support#1 and #3. > #2 could be interesting für EasyAnt and Ivy, as they are using JIRA (Ant > uses Bugzilla). > Not sure about #4. What's the activity on freenode? > > > Jan > > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AW: Repository access
I do not think each commiter needs to do that but if you and Jean-Louis go through this exercise and create an INFRA ticket that would be very nice. As for me I have a lot of work in my day job and on top of that I have caught an out of season cold, with the temperature in New York going up and down and too much air conditioning at some places. Regards, Antoine Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?= a écrit : > > Should we (each committer) try to commit/push to each repo before creating > the issue? > Maybe creating one file/repo (./git-access-test) where each committer places > his name. > Retest after the issue is resolved and finally delete that file. > > In that way INFRA doesnt need to act multiple times ... > > Jan > > > -Ursprüngliche Nachricht- > > Von: Antoine Levy Lambert [mailto:anto...@gmx.de] > > Gesendet: Freitag, 6. Juni 2014 03:21 > > An: Ant Developers List > > Betreff: Re: Repository access > > > > Hello Jean-Louis, > > > > please create the JIRA, > > > > Antoine > > On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart > > wrote: > > > > > Same for me is there other repos having same issue? > > > > > > We need to create a INFRA jira for this. > > > > > > > > > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée > > : > > > > > >> I couldn't commit the patch you suggested for the ivyde updatesite > > in > > >> svn either. It must be read only. > > >> > > >> Nicolas > > >> > > >> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm) a > > écrit : > > >> > > >>> After ivyde-updatesite (svn) this is the 2nd repo where I can't > > >> commit/push > > >>> > > >>> https://git-wip-us.apache.org/repos/asf/easyant-core.git > > >>> > > >>> > > >>> > > >>> Is there any reason? > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Jan > > >>> > > >> > > >> > > >> > > - > > >> 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 > > > > - > 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: Repository access
Hello Jean-Louis, please create the JIRA, Antoine On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart wrote: > Same for me is there other repos having same issue? > > We need to create a INFRA jira for this. > > > 2014-06-05 18:08 GMT+02:00 Nicolas Lalevée : > >> I couldn't commit the patch you suggested for the ivyde updatesite in svn >> either. It must be read only. >> >> Nicolas >> >> Le 5 juin 2014 à 07:57, Jan Matèrne (jhm) a écrit : >> >>> After ivyde-updatesite (svn) this is the 2nd repo where I can't >> commit/push >>> >>> https://git-wip-us.apache.org/repos/asf/easyant-core.git >>> >>> >>> >>> Is there any reason? >>> >>> >>> >>> >>> >>> Jan >>> >> >> >> - >> 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
Re: description of git repos
Hi, this is done now. https://issues.apache.org/jira/browse/INFRA-7858 Antoine On May 31, 2014, at 10:35 AM, Antoine Levy Lambert wrote: > Hello Stefan, > > I noticed this too but did not report it. > > We need help from infra for that. > > I will enter a ticket later today. Thanks for pointing that out. > > Regards, > > Antoine > On May 31, 2014, at 5:38 AM, Stefan Bodewig wrote: > >> Hi >> >> the description column on https://git-wip-us.apache.org/repos/asf says >> "Apache Ivy" for most of the Antlibs and IvyDE and "Apache Ant" for all >> the EasyAnt repos. Is this somethong we can fix ourselves or do we need >> help by infra? >> >> 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: description of git repos
Hello Stefan, I noticed this too but did not report it. We need help from infra for that. I will enter a ticket later today. Thanks for pointing that out. Regards, Antoine On May 31, 2014, at 5:38 AM, Stefan Bodewig wrote: > Hi > > the description column on https://git-wip-us.apache.org/repos/asf says > "Apache Ivy" for most of the Antlibs and IvyDE and "Apache Ant" for all > the EasyAnt repos. Is this somethong we can fix ourselves or do we need > help by infra? > > Stefan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Fwd: [jira] [Commented] (INFRA-7759) Migrate the Ant family of projects to Git
Hi, I have written on the JIRA ticket that we are happy with the Git migration, so Jake is proceeding with the setup of Github mirrors. Antoine Begin forwarded message: > From: "Jake Farrell (JIRA)" > Subject: [jira] [Commented] (INFRA-7759) Migrate the Ant family of projects > to Git > Date: May 27, 2014 at 11:20:02 PM EDT > To: anto...@apache.org > > >[ > https://issues.apache.org/jira/browse/INFRA-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010709#comment-14010709 > ] > > Jake Farrell commented on INFRA-7759: > - > > Our official mirror is at git.apache.org and Github mirrors off from that > > git-wip (https://) --> git.apache.org (ro mirror)(git://) -> Github (ro > mirror) > > Will remove the old svn mirrors and setup the new mirrors. Can take anywhere > up to 24hrs for Github to pick up the new mirrors once created. i'll post > back on this ticket when they have been setup on git.apache.org. If you want > to setup the Github integrations [1] then please create a separate ticket > once all the repositories have been picked up by Github. if you have any > questions please let me know > > [1]: > https://blogs.apache.org/infra/entry/improved_integration_between_apache_and >
Re: migration to git : next steps - Jenkins
On May 27, 2014, at 8:53 AM, Jan Matèrne (jhm) wrote: > Here is an intermediate result and my opinion on that: > > > > Open problems > > = > > Ant-Build-Matrix has problems on Ubuntu and on Windows. > > On Windows it seems (to me) that there is no git installed or not on the > PATH. > > --> open an INFRA-Ticket? sure > > > Regards / Gruesse Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: migration to git : next steps
I found an article mentioning something similar to what we would need : http://www.leewillis.co.uk/including-git-repo-svn-external/ Antoine On May 26, 2014, at 9:51 PM, Jean-Louis Boudart wrote: > The only "broken stuff" is easyant / ivy documentations as we were using > lot of svn:externals (to retrieve latest xooki version for example). > svn:externals are not migrated so we need to find a solution for this. > > > > > 2014-05-25 20:55 GMT+02:00 Stefan Bodewig : > >> On 2014-05-23, anto...@gmx.de wrote: >> >>> Jake Farrell has finished the migration, we are asked to verify. Right >>> now I am at work so cannot verify but will look during the weekend. >> >> I had a quick look at Ant core, seems to work reasonably. >> >> One thing though, the github mirror is now trying to track the no longer >> existing tunk branch rather than the new master branch. >> >> Stefan >> >> - >> 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: migration to git : next steps
Hello Jean Louis, if you have some cycles for that, you can join infra on IRC ( #asfinfra ) and ask to see whether someone has an idea. Antoine On May 26, 2014, at 9:51 PM, Jean-Louis Boudart wrote: > The only "broken stuff" is easyant / ivy documentations as we were using > lot of svn:externals (to retrieve latest xooki version for example). > svn:externals are not migrated so we need to find a solution for this. > > > > > 2014-05-25 20:55 GMT+02:00 Stefan Bodewig : > >> On 2014-05-23, anto...@gmx.de wrote: >> >>> Jake Farrell has finished the migration, we are asked to verify. Right >>> now I am at work so cannot verify but will look during the weekend. >> >> I had a quick look at Ant core, seems to work reasonably. >> >> One thing though, the github mirror is now trying to track the no longer >> existing tunk branch rather than the new master branch. >> >> Stefan >> >> - >> 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
Re: git commit: upgrade AntUnit
Hello Stefan, looks like you have inaugurated actually committing using git. Cool :-) We will need to thank Jake Farrell who did all the migration work. Antoine On May 25, 2014, at 2:23 PM, bode...@apache.org wrote: > Repository: ant > Updated Branches: > refs/heads/master 806749177 -> 39ad231a2 > > > upgrade AntUnit > > > Project: http://git-wip-us.apache.org/repos/asf/ant/repo > Commit: http://git-wip-us.apache.org/repos/asf/ant/commit/39ad231a > Tree: http://git-wip-us.apache.org/repos/asf/ant/tree/39ad231a > Diff: http://git-wip-us.apache.org/repos/asf/ant/diff/39ad231a > > Branch: refs/heads/master > Commit: 39ad231a2e3186adaa64412849de1d406409389c > Parents: 8067491 > Author: Stefan Bodewig > Authored: Sun May 25 20:21:07 2014 +0200 > Committer: Stefan Bodewig > Committed: Sun May 25 20:21:07 2014 +0200 > > -- > lib/optional/ant-antunit-1.2.jar | Bin 57822 -> 0 bytes > lib/optional/ant-antunit-1.3.jar | Bin 0 -> 60911 bytes > 2 files changed, 0 insertions(+), 0 deletions(-) > -- > > > http://git-wip-us.apache.org/repos/asf/ant/blob/39ad231a/lib/optional/ant-antunit-1.2.jar > -- > diff --git a/lib/optional/ant-antunit-1.2.jar > b/lib/optional/ant-antunit-1.2.jar > deleted file mode 100644 > index 1b3d76e..000 > Binary files a/lib/optional/ant-antunit-1.2.jar and /dev/null differ > > http://git-wip-us.apache.org/repos/asf/ant/blob/39ad231a/lib/optional/ant-antunit-1.3.jar > -- > diff --git a/lib/optional/ant-antunit-1.3.jar > b/lib/optional/ant-antunit-1.3.jar > new file mode 100644 > index 000..34241b8 > Binary files /dev/null and b/lib/optional/ant-antunit-1.3.jar differ > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: migration to git : next steps
Hi, moving to actual action. jfarrell from infra is setting our svn repo http://svn.apache.org/repos/asf/ant read-only to prepare for the import. The ant site will remain in svn and stay RW during the process. Antoine On May 20, 2014, at 10:25 PM, Matt Sicker wrote: > I'm going to have to look into subtree as I've been using submodule at work > lately and it's becoming a huge mess. > > > On 20 May 2014 13:39, Charles Duffy wrote: > >> I'd suggest looking into git-subtree as well, if we wanted to maintain a >> single-development-tree experience. Submodules have a reputation >> (well-deserved, IMHO) of being somewhat unwieldy to work with; using >> git-subtree to manage linked trees can be a bit more automation/setup work, >> but can also provide a much smoother user experience. >> >> >> On Mon, May 12, 2014 at 8:03 PM, Matt Sicker wrote: >> >>> Something I've been experimenting with is using git submodules. You >>> basically have a repository for each "submodule", then you can have >> another >>> repository that groups them all together for convenience. It's handy for >>> making a sort of stable master that points to the latest tag or something >>> similar. It's kind of confusing, but I think it works well for when >> people >>> want to check out a project corresponding to the latest stable rather >> than >>> the trunk (which would normally be stable anyway). >>> >>> >>> On 12 May 2014 21:19, Antoine Levy Lambert wrote: >>> >>>> >>>> Hi, >>>> >>>> resending a message which I sent on May 7th but might have been lost >>>> completely due to our infrastructure problems last week : >>>> >>>>> >>>>> >>>>> To actually migrate to git, we could either make one INFRA JIRA for >> all >>>> the ant family of projects, or do this one step at a time. >>>>> >>>>> Concerning the antlibs, I suppose we want one git module for each >>> antlib >>>> - we have 6 of them (antunit, compress, dotnet, props, svn, vss) plus a >>>> common folder which ought to be on its own. >>>>> >>>>> If we do it one step at a time we could start with ant proper, then >>> move >>>> to ivy, ivyde, easyant and the antlibs. >>>>> >>>>> What do you think ? >>>>> >>>>> Antoine >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>> >>>> >>> >>> >>> -- >>> Matt Sicker >>> >> > > > > -- > Matt Sicker
Re: migration to git : next steps
Hi, if someone has some spare cycles, you can contact infra to see whether people have questions about the jira and whether they need help. Apache infra has a chat channel on freenode.net called #asfinfra where committers can join. Antoine On May 19, 2014, at 12:34 AM, Antoine Levy Lambert wrote: > I just created an issue in JIRA : > https://issues.apache.org/jira/browse/INFRA-7759 > > Antoine > On May 14, 2014, at 10:54 PM, Antoine Levy Lambert wrote: > >> Migration of the Ant project and subprojects to Git >> >> vote : >> http://ant.1045680.n5.nabble.com/VOTE-migration-to-git-tt5715081.html#none >> >> vote-result : >> http://ant.1045680.n5.nabble.com/migration-to-git-intermediate-summary-tc5715104.html#none >> >> here are the GIT Modules that we need to create >> >> ant : http://svn.apache.org/repos/asf/ant/core/ >> ivy : http://svn.apache.org/repos/asf/ant/ivy/core/ >> ivyde : http://svn.apache.org/repos/asf/ant/ivy/ivyde/ >> easyant-buildtypes : http://svn.apache.org/repos/asf/ant/easyant/buildtypes/ >> easyant-core : http://svn.apache.org/repos/asf/ant/easyant/core/ >> easyant-easyant4e : http://svn.apache.org/repos/asf/ant/easyant/easyant4e/ >> easyant-plugins : http://svn.apache.org/repos/asf/ant/easyant/plugins/ >> easyant-skeletons : http://svn.apache.org/repos/asf/ant/easyant/skeletons/ >> easyant-tasks : http://svn.apache.org/repos/asf/ant/easyant/tasks/ >> antlibs-antunit : http://svn.apache.org/repos/asf/ant/antlibs/antunit/ >> antlibs-common : http://svn.apache.org/repos/asf/ant/antlibs/common/ >> antlibs-compress : http://svn.apache.org/repos/asf/ant/antlibs/compress/ >> antlibs-dotnet : http://svn.apache.org/repos/asf/ant/antlibs/dotnet/ >> antlibs-props : http://svn.apache.org/repos/asf/ant/antlibs/props/ >> antlibs-svn : http://svn.apache.org/repos/asf/ant/antlibs/svn/ >> antlibs-vss : http://svn.apache.org/repos/asf/ant/antlibs/vss/ > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: migration to git : next steps
I just created an issue in JIRA : https://issues.apache.org/jira/browse/INFRA-7759 Antoine On May 14, 2014, at 10:54 PM, Antoine Levy Lambert wrote: > Migration of the Ant project and subprojects to Git > > vote : > http://ant.1045680.n5.nabble.com/VOTE-migration-to-git-tt5715081.html#none > > vote-result : > http://ant.1045680.n5.nabble.com/migration-to-git-intermediate-summary-tc5715104.html#none > > here are the GIT Modules that we need to create > > ant : http://svn.apache.org/repos/asf/ant/core/ > ivy : http://svn.apache.org/repos/asf/ant/ivy/core/ > ivyde : http://svn.apache.org/repos/asf/ant/ivy/ivyde/ > easyant-buildtypes : http://svn.apache.org/repos/asf/ant/easyant/buildtypes/ > easyant-core : http://svn.apache.org/repos/asf/ant/easyant/core/ > easyant-easyant4e : http://svn.apache.org/repos/asf/ant/easyant/easyant4e/ > easyant-plugins : http://svn.apache.org/repos/asf/ant/easyant/plugins/ > easyant-skeletons : http://svn.apache.org/repos/asf/ant/easyant/skeletons/ > easyant-tasks : http://svn.apache.org/repos/asf/ant/easyant/tasks/ > antlibs-antunit : http://svn.apache.org/repos/asf/ant/antlibs/antunit/ > antlibs-common : http://svn.apache.org/repos/asf/ant/antlibs/common/ > antlibs-compress : http://svn.apache.org/repos/asf/ant/antlibs/compress/ > antlibs-dotnet : http://svn.apache.org/repos/asf/ant/antlibs/dotnet/ > antlibs-props : http://svn.apache.org/repos/asf/ant/antlibs/props/ > antlibs-svn : http://svn.apache.org/repos/asf/ant/antlibs/svn/ > antlibs-vss : http://svn.apache.org/repos/asf/ant/antlibs/vss/
migration to git : next steps
To actually migrate to git, we could either make one INFRA JIRA for all the ant family of projects, or do this one step at a time. Concerning the antlibs, I suppose we want one git module for each antlib - we have 6 of them (antunit, compress, dotnet, props, svn, vss) plus a common folder which ought to be on its own. If we do it one step at a time we could start with ant proper, then move to ivy, ivyde, easyant and the antlibs. What do you think ? Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: migration to git : next steps
I was about to enter an INFRA JIRA for the migration. see below the suggested text. Let me know your thoughts. ——— Migration of the Ant project and subprojects to Git vote : http://ant.1045680.n5.nabble.com/VOTE-migration-to-git-tt5715081.html#none vote-result : http://ant.1045680.n5.nabble.com/migration-to-git-intermediate-summary-tc5715104.html#none here are the GIT Modules that we need to create ant : http://svn.apache.org/repos/asf/ant/core/ ivy : http://svn.apache.org/repos/asf/ant/ivy/core/ ivyde : http://svn.apache.org/repos/asf/ant/ivy/ivyde/ easyant-buildtypes : http://svn.apache.org/repos/asf/ant/easyant/buildtypes/ easyant-core : http://svn.apache.org/repos/asf/ant/easyant/core/ easyant-easyant4e : http://svn.apache.org/repos/asf/ant/easyant/easyant4e/ easyant-plugins : http://svn.apache.org/repos/asf/ant/easyant/plugins/ easyant-skeletons : http://svn.apache.org/repos/asf/ant/easyant/skeletons/ easyant-tasks : http://svn.apache.org/repos/asf/ant/easyant/tasks/ antlibs-antunit : http://svn.apache.org/repos/asf/ant/antlibs/antunit/ antlibs-common : http://svn.apache.org/repos/asf/ant/antlibs/common/ antlibs-compress : http://svn.apache.org/repos/asf/ant/antlibs/compress/ antlibs-dotnet : http://svn.apache.org/repos/asf/ant/antlibs/dotnet/ antlibs-props : http://svn.apache.org/repos/asf/ant/antlibs/props/ antlibs-svn : http://svn.apache.org/repos/asf/ant/antlibs/svn/ antlibs-vss : http://svn.apache.org/repos/asf/ant/antlibs/vss/ ——— Regards, Antoine On May 13, 2014, at 9:17 AM, Matt Sicker wrote: > On Tuesday, 13 May 2014, Antoine Levy Lambert wrote: > >> Hello Matt, >> >> this is interesting - thanks for pointing this out since I am a newbie in >> git land. >> >> does one need to do some advance planning to make a module become a >> submodule of >> another repository aggregating the submodules ? >> >> Nope! You use it somewhat like svn:external, but you manually keep the > commit ID in sync to whatever you want. I find it useful to use a tag for > that commit. Otherwise you end up with a history like "update submodule" > over and over again. > > >> there would be a use case for an aggregation of the complete ant family, >> maybe for an aggregation of the antlibs too … >> >> If there's a master build.xml or similar that can just iterate through all > the projects and build them in order, that's a neat use case. > > > -- > Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1594598 - in /ant/site/ant: production/ sources/
Hello Stefan, I have had the same problem on MacOS. I remember vaguely that I found out while fixing unit tests that different JDK versions do not have the same value for default encoding. I am not sure how I addressed the problem when I regenerated the site, I might have just fixed the html by hand. A shame that I do not remember more. Antoine On May 14, 2014, at 11:29 AM, Stefan Bodewig wrote: > >> try to zap some gremlins, but problems still exist > >> > valign="top" align="left"> >> - mailto:rene_gh...@yahoo.com";>René Ghosh >> + mailto:rene_gh...@yahoo.com";>RenÃÂé Ghosh > > it seems as if my machine (svn 1.8, Ubuntu 14.04, OpenJDK 7) insists on > breaking the encoding of the generated site. It would be nice if > anybody with a working setup could recreate it. > > It looks as if Velocity and not svn is playing tricks on me since the > files are already broken on my disk. > > Stefan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: migration to git : next steps
Hello Matt, this is interesting - thanks for pointing this out since I am a newbie in git land. does one need to do some advance planning to make a module become a submodule of another repository aggregating the submodules ? there would be a use case for an aggregation of the complete ant family, maybe for an aggregation of the antlibs too … Antoine On May 12, 2014, at 11:03 PM, Matt Sicker wrote: > Something I've been experimenting with is using git submodules. You > basically have a repository for each "submodule", then you can have another > repository that groups them all together for convenience. It's handy for > making a sort of stable master that points to the latest tag or something > similar. It's kind of confusing, but I think it works well for when people > want to check out a project corresponding to the latest stable rather than > the trunk (which would normally be stable anyway). > > > On 12 May 2014 21:19, Antoine Levy Lambert wrote: > >> >> Hi, >> >> resending a message which I sent on May 7th but might have been lost >> completely due to our infrastructure problems last week : >> >>> >>> >>> To actually migrate to git, we could either make one INFRA JIRA for all >> the ant family of projects, or do this one step at a time. >>> >>> Concerning the antlibs, I suppose we want one git module for each antlib >> - we have 6 of them (antunit, compress, dotnet, props, svn, vss) plus a >> common folder which ought to be on its own. >>> >>> If we do it one step at a time we could start with ant proper, then move >> to ivy, ivyde, easyant and the antlibs. >>> >>> What do you think ? >>> >>> Antoine >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> > > > -- > Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
migration to git : next steps
Hi, resending a message which I sent on May 7th but might have been lost completely due to our infrastructure problems last week : > > > To actually migrate to git, we could either make one INFRA JIRA for all the > ant family of projects, or do this one step at a time. > > Concerning the antlibs, I suppose we want one git module for each antlib - we > have 6 of them (antunit, compress, dotnet, props, svn, vss) plus a common > folder which ought to be on its own. > > If we do it one step at a time we could start with ant proper, then move to > ivy, ivyde, easyant and the antlibs. > > What do you think ? > > Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Classloading issue
Hello Nicolas, I have tried your test case and it is failing as you except : BUILD FAILED /Users/antoine/dev/asf/ivyde-trunk/test/ssh-resolver/build.xml:27: java.lang.NoClassDefFoundError: com/jcraft/jsch/agentproxy/AgentProxyException at org.apache.ivy.plugins.repository.ssh.AbstractSshBasedRepository.getSession(AbstractSshBasedRepository.java:108) at org.apache.ivy.plugins.repository.ssh.SshRepository.resolveResource(SshRepository.java:82) at org.apache.ivy.plugins.repository.ssh.SshResource.resolve(SshResource.java:101) The line 108 in AbstractSsshBasedRepository contains this : return SshCache.getInstance().getSession(host, port, user, userPassword, getKeyFile(), getKeyFilePassword(), getPassFile(), isAllowedAgentUse()); getSession is a method which calls attemptAgentUse. Does this explain why an attempt to load AgentProxyException happens at that time ? Regards, Antoine On May 11, 2014, at 5:41 PM, Nicolas Lalevée wrote: > Hi, > > I need some help to understand a bug around classloading (nothing that > particular to Ivy). > > I was looking into IVY-1471 [1] and I don't understand why it is failing that > way. In the classpath there are both Ivy and Jsch, but not the optional jar > related to managing the ssh agent via jsch. And it is failing because a class > in that optional jar is not found. But I don't understand why the classloader > is looking for it in the first place. > > The error is raised is AbstractSshBasedRepository, on the call of > SshCache.getInstance() [2]. But as far as I can tell, nothing in the loading > of the SshCache [3] class requires AgentProxyException. The class is only > needed by the function SshCache#attemptAgentUse() [4], which will be called > at runtime, if the end user actually want ssh agent support, in which case it > would naturally fail. But here it fails very earlier. > > I have made a test case you can test with its build.xml, no IvyDE required > there [5]. > > Am I missing something ? Is there a special treatment for the loading of > Exception classes ? > > Nicolas > > [1] https://issues.apache.org/jira/browse/IVY-1471 > [2] > https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/AbstractSshBasedRepository.java?hb=true#to108 > [3] > https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true > [4] > https://fisheye6.atlassian.com/browse/ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/repository/ssh/SshCache.java?hb=true#to300 > [5] http://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/test/ssh-resolver/ > > > - > 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
On May 8, 2014, at 3:41 AM, Jan Matèrne (jhm) wrote: > Both Windows nodes are offline and therefore the matrix job is in trouble. > Should we "disable" the win systems? sure Antoine > > https://builds.apache.org/computer/windows1/ > ping error / timeout > > https://builds.apache.org/computer/windows2/ > cut: olamy : It sucks!! > > While the latter seems running the OS > https://builds.apache.org/computer/ > - time is 13sec behind > - ping=158ms > > > Jan > > > >> -Ursprüngliche Nachricht- >> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de] >> Gesendet: Donnerstag, 8. Mai 2014 07:56 >> An: 'Ant Developers List' >> Betreff: AW: Ant-Matrix-Job >> >> The job is back again >> 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
Re: [VOTE] Release AntUnit 1.3 based on RC1
+1 for me Antoine On May 11, 2014, at 11:07 AM, Nicolas Lalevée wrote: > +1 for me > > Nicolas > > Le 11 mai 2014 à 12:42, Stefan Bodewig a écrit : > >> Hi all, >> >> delayed because I wanted to wait for mails to arrive again. >> >> Antunit 1.3 RC1 is available for review here: >> https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/ >> (svn revision 5298) >> >> Maven artifacts are here: >> >> https://repository.apache.org/content/repositories/orgapacheant-1005/org/apache/ant/ant-antunit/1.3/ >> >> Details of changes since 1.2 are in the release notes: >> >> https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/RELEASE-NOTES-1.3.html >> >> The tag is here: >> http://svn.apache.org/repos/asf/ant/antlibs/antunit/tags/1.3RC1/ >> (svn revision 1593382) >> >> KEYS: >> http://www.apache.org/dist/ant/KEYS >> >> Please review the release candidate and vote. >> This vote will close no sooner that 72 hours from now, i.e. after 1100 >> GMT 14-May 2014. Should we get hit by a mail-outage again I'll defer >> counting the votes as well. >> >> [ ] +1 Release these artifacts >> [ ] +0 OK, but... >> [ ] -0 OK, but really should fix... >> [ ] -1 I oppose this release because... >> >> Thanks! >> >> 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: Ant-Matrix-Job
On May 8, 2014, at 3:41 AM, Jan Matèrne (jhm) wrote: > Both Windows nodes are offline and therefore the matrix job is in trouble. > Should we "disable" the win systems? sure Antoine > > https://builds.apache.org/computer/windows1/ > ping error / timeout > > https://builds.apache.org/computer/windows2/ > cut: olamy : It sucks!! > > While the latter seems running the OS > https://builds.apache.org/computer/ > - time is 13sec behind > - ping=158ms > > > Jan > > > >> -Ursprüngliche Nachricht- >> Von: Jan Matèrne (jhm) [mailto:apa...@materne.de] >> Gesendet: Donnerstag, 8. Mai 2014 07:56 >> An: 'Ant Developers List' >> Betreff: AW: Ant-Matrix-Job >> >> The job is back again >> 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
Re: Ant-Matrix-Job
Thanks very much Michael and Jesse, That’s great that you were able to turnaround this issue so quickly. I will contact infra to see when they can upgrade the Jenkins Matrix plugin. Regards, Antoine On May 6, 2014, at 5:57 PM, Michael Clarke wrote: > 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 >>> >> >> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Hoped for advantages of migrating to git
Matt, Jesse, I think that both of you are basically saying that accepting pull requests entered in github is going to be more manual work, including more command line work, in the case of a migration to git-wip-us.apache.org as opposed to migrating to use only github. I don’t know whether an option of using only github and not the ASF hosted git is acceptable for the ASF ? for the Ant committers ? Personally I am already glad to have seen support to migrate to git, and I would not want to push something more controversial. While github today is a very attractive platform, it could one day diverge from ASF policies or make other changes in their terms and conditions that we would dislike and not be able to influence. There is a file https://svn.apache.org/repos/private/committers/docs/github_team.txt which links the apache user ids of committers with their github ids, I wonder whether this linkage gives write access to the github mirrors of Apache projects ? Also, while researching this I found an interesting presentation by Jukka Zitting [1] and a mail message concerning Apache and Github [2] and also a wiki page from the Apache Cordova project [3] Best regards, Antoine [1] http://www.slideshare.net/jukka/apache-development-with-github-and-travis-ci [2] http://mail-archives.apache.org/mod_mbox/lucene-dev/201401.mbox/%3c596fff55-6e33-4451-93d4-75add6cad...@gmail.com%3E [3] http://wiki.apache.org/cordova/GitWorkflow On May 6, 2014, at 6:33 PM, Matt Sicker wrote: > I mean how do you accept pull requests? You wouldn't be able to do it > through GitHub. You'd have to manually pull the branch from GitHub like the > name "pull request" implies. If you could commit to GitHub, then you could > add a remote besides origin for GitHub, then pull from the GitHub remote, > then push to the ASF remote (origin). > > > On 6 May 2014 01:45, Stefan Bodewig wrote: > >> On 2014-05-06, Matt Sicker wrote: >> >>> Git allows you to do both. You can auto-merge from GH, but I'm not >>> sure how you can even get write access to ASF GH repos. >> >> You don't, you commit to the ASF repo and it gets mirrored. >> >> IIRC some projects have their own forks of the ASF mirror and accept >> pull request on this fork. They then merge changes from their fork to >> the ASF repo. >> >> I'm not conviced I'd want to work that way, applying PRs without the >> Web-UI on a local checkout of the ASF git repo works fine for me. >> >> Stefan >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> > > > -- > Matt Sicker - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant-Matrix-Job
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 >
[VOTE-RESULT] Release Apache Ant 1.9.4
Hi, here are the vote results, I sent them by mistake to Maarten only yesterday. Regards, Antoine Begin forwarded message: > From: Antoine Levy Lambert > Subject: [VOTE-RESULT] Release Apache Ant 1.9.4 > Date: May 5, 2014 at 6:36:03 PM EDT > To: Maarten Coene > > > The vote has passed with 6 +1 (Maarten, Jean-Louis, Stefan, Nicolas, Jan, and > myself). > > I will proceed with the release later today. > > Regards, > > Antoine >> >> Van: Antoine Levy Lambert >> Aan: Ant Developers List >> Verzonden: woensdag 30 april 5:46 2014 >> Onderwerp: [VOTE] Release Ant 1.9.4 (second attempt) >> >> Hi all, >> >> restarting the vote thread after having fixed the pom of ant-testutil and >> rebuilt >> >> a release with many bug fixes and improvements, including the initial >> support for Java 1.9, >> the possibility to run JUnit tests in multiple threads (when they are forked) >> and the refactoring of Ant's own test suite which is now based on JUnit 4. >> >> I propose to adopt the following as Ant 1.9.4 >> >> SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_194/ >> revision 1591180 >> Tarballs: https://dist.apache.org/repos/dist/dev/ant/ >> revision 5204 >> Maven Artifacts: >> >> https://repository.apache.org/content/repositories/orgapacheant-1004/org/apache/ant/ >> >> Vote will be open until Monday, May 5 due to upcoming May 1st holiday >> >> Cheers >> >> Antoine >> >
Re: Cutting AntUnit 1.3
Agreed, Antoine On May 6, 2014, at 3:13 AM, Jan Matèrne (jhm) wrote: > I couldn't find any Jira issues [1] related to the migration, > so I think cutting the release before migration would be faster ;) > > Jan > > [1] > https://issues.apache.org/jira/browse/INFRA-1983?jql=project%20%3D%20INFRA%2 > 0AND%20text%20~%20%22ant%20git%22 > > >> -Ursprüngliche Nachricht- >> Von: Stefan Bodewig [mailto:bode...@apache.org] >> Gesendet: Dienstag, 6. Mai 2014 08:55 >> An: dev@ant.apache.org >> Betreff: Cutting AntUnit 1.3 >> >> Hi all >> >> after a few years (really) of dormancy I've applied a few patches to >> AntUnit and would like to cut a new release. I still need to fix the >> code introduced in 56470 since at least one test in Ant's testsuite >> relies on the old behavior, so breaking BWC is a problem here. >> >> How soon do we expect to transition to git? I don't think it would be >> a good idea to have a pending release process during the migration, I'm >> willing to cut the release before or right after the migration. >> >> 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
[ANNOUNCE] Apache Ant 1.9.4 released
The Apache Ant Team is proud to announce the 1.9.4 release of Ant. Apache Ant is a Java based build tool. Apache Ant 1.9.4 is a release with many bug fixes and improvements, including : - the initial support for Java 1.9, - the possibility to run JUnit tests in multiple threads (when they are forked) - and the refactoring of Ant's own test suite which is now based on JUnit 4. Source and binary distributions are available from the Apache Ant download site: http://ant.apache.org/bindownload.cgi and http://ant.apache.org/srcdownload.cgi Please verify signatures using the KEYS file available at the above location when downloading the release. For complete information on Ant, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Ant website: http://ant.apache.org/index.html Antoine Levy-Lambert, on behalf of the Apache Ant community
Re: Ant-Matrix-Job
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
[VOTE-RESULT] migration to git
Hi, see below the detailed results of the vote. I have looked at our bylaws [1]. The Code Change category seems to be the one which corresponds most and requires “Lazy Approval and then Lazy Consensus” There are at least 3 binding +1s to migrate to git each of the Ant subprojects - Ant core, Ivy, Ivyde, EasyAnt and Antlibs. So the vote result is to migrate everything - except the sandbox which was excluded from the scope of the vote, and the web site which cannot be migrated. Antoine [1] http://ant.apache.org/bylaws.html update on the summary of Jan, without the non-binding votes On Apr 29, 2014, at 2:00 AM, Jan Matèrne (jhm) wrote: > My summary of this intermediate time for the migration-to-git-thread (not > dividing into binding/non-binding votes): > > > > Ant > > +1: antoine, jhm, bodewig, boudart, conor, Michael > Clarke, Charles Duffy, Nicolas Lalevée (8) > > +0: ddevienne, Nicolas Lalevee, Matt, Maarten (4) > > > > Ivy > > +1: antoine, boudart, conor, Charles Duffy (4) > > +0: jhm, bodewig, ddevienne, Nicolas Lalevee, Michael Clarke, Matt,Nicolas > Lalevée (7) > -0 : Maarten (1) > > > IvyDE > > +1: antoine, boudart, conor (3) > > +0: jhm, bodewig, ddevienne, Nicolas Lalevee, Michael Clarke, Matt, Charles > Duffy,Nicolas Lalevée (8) > -0 : Maarten (1) > > > > EasyAnt > > +1: antoine, boudart, conor (3) > > +0: jhm, bodewig, ddevienne, Nicolas Lalevee, Michael Clarke, Matt, Charles > Duffy,Nicolas Lalevée (7) > -0 : Maarten (1) > > > > Antlibs > > +1: antoine, jhm, bodewig, boudart, conor,Nicolas Lalevée (5) > > +0: ddevienne, Nicolas Lalevee, Michael Clarke, Matt, Charles Duffy, Maarten > (5) > > > > Sandbox > > Keeps in SVN for saving the work of migration and because there were only a > few projects in the past which promoted to "real projects". > > Migration to git will be done when the project is promoted. > > Having on git repo for the whole sandbox will be difficult if one project > will be promoted: "extract only a part of the project with its history". > > > > Homepage > > Keeps in SVN as svnpubsub is the only supported mechanism (besides CMS). > > gitpubsub is not supported. > > > > Help > > Michael Clarke would be "happy to help with any migration or post migration > cleanup of docs/processes, but is 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." > > Infra is providing their own migration tool. > > > > > > Jan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Hoped for advantages of migrating to git
Hello Maarten, I do not know a lot about git either. Here are the advantages I see in migrating to git : - git allows third-parties to clone an original repository and in fact to create a fork while keeping the possibility of contributing back what they have created if they want to, and also importantly to incorporate inside their branches changes done elsewhere including in the reference repository. So I see git as having the same strategic importance for the source code like the fact of uploading the ant jars to maven central is for the use of the binaries. - for the developers of the Apache project - us - the small advantages are to be able to commit stuff locally on our computers before pushing when we are happy with our changes. Also one can switch branch very quickly within the same workspace when using git, this might be an advantage. - because of the popularity of git I imagine that the change is good for the long run but this is speculation I imagine that some corporations, individuals,or other open source organizations will take advantage of our projects moving to git to create these forks, either because the contribution process via JIRA is too slow, or because they want to create proprietary enhancements, or because they are not sure that the changes that they do match the views /plans... of our the Ant/Ivy/Ivyde/Easyant Apache project. Regards, Antoine Le 30 avr. 2014 01:57, Maarten Coene a écrit : > > Probably because I don't know much about git, but I don't see the real > advantage of the switch from SVN to git. > In addition, I don't have the time to help adapting the Ivy release > process/scripts. > But I don't want to stand in the way if everyone thinks this should be done. > > So, my vote is: > for Ivy: -0 > for the rest: +0 > > Maarten
Re: svn commit: r1591187 - in /ant/core/trunk: build.xml release.sh
Hi, in order to avoid finding issues with ant’s pom files after the fact, I have added a step of building ant using maven in our release script. This is just to check that the compilation and building of jars work using maven, the target folder gets deleted in the next line. and also created a TeamCity build configuration on teamcity.jetbrains.com to build ant using maven with -DskipTests If someone has the time to create also such a build in builds.apache.org to add another check that would be great. Antoine On Apr 30, 2014, at 12:05 AM, anto...@apache.org wrote: > Author: antoine > Date: Wed Apr 30 04:05:58 2014 > New Revision: 1591187 > > URL: http://svn.apache.org/r1591187 > --- ant/core/trunk/release.sh (original) > +++ ant/core/trunk/release.sh Wed Apr 30 04:05:58 2014 > +# check that one can build under maven > +mvn -f src/etc/poms/pom.xml -DskipTests package > +rm -rf target > > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Release Ant 1.9.4 (second attempt)
Hi all, restarting the vote thread after having fixed the pom of ant-testutil and rebuilt a release with many bug fixes and improvements, including the initial support for Java 1.9, the possibility to run JUnit tests in multiple threads (when they are forked) and the refactoring of Ant's own test suite which is now based on JUnit 4. I propose to adopt the following as Ant 1.9.4 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_194/ revision 1591180 Tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision 5204 Maven Artifacts: https://repository.apache.org/content/repositories/orgapacheant-1004/org/apache/ant/ Vote will be open until Monday, May 5 due to upcoming May 1st holiday Cheers Antoine
Re: [VOTE] Release Ant 1.9.4
Canceling this vote thread, I have just found a bug, the pom.xml of ant-testutil references still JUnit 3.8 and not JUnit 4.11 I will make another build with this error fixed. Antoine On Apr 29, 2014, at 10:34 PM, Antoine Levy Lambert wrote: > Hi all, > > a release with many bug fixes and improvements, including the initial support > for Java 1.9, > the possibility to run JUnit tests in multiple threads (when they are forked) > and the refactoring of Ant's own test suite which is now based on JUnit 4. > > I propose to adopt the following as Ant 1.9.4 > > SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_194/ > revision 1591171 > Tarballs: https://dist.apache.org/repos/dist/dev/ant/ > revision 5200 > Maven Artifacts: > > https://repository.apache.org/content/repositories/orgapacheant-1003/org/apache/ant/ > > Vote will be open until Monday, May 5 due to upcoming May 1st holiday > > Cheers > > 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
[VOTE] Release Ant 1.9.4
Hi all, a release with many bug fixes and improvements, including the initial support for Java 1.9, the possibility to run JUnit tests in multiple threads (when they are forked) and the refactoring of Ant's own test suite which is now based on JUnit 4. I propose to adopt the following as Ant 1.9.4 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_194/ revision 1591171 Tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision 5200 Maven Artifacts: https://repository.apache.org/content/repositories/orgapacheant-1003/org/apache/ant/ Vote will be open until Monday, May 5 due to upcoming May 1st holiday Cheers Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: migration to git and web site publication
Hello Dominique, On Apr 29, 2014, at 3:32 AM, Dominique Devienne wrote: > On Tue, Apr 29, 2014 at 5:00 AM, Antoine Levy Lambert wrote: >> git is not the tool of choice to deal with large files such as the ones on >> dist.apache.org. >> That might be part of the reason why infra supports only svn for the web >> site. > > Just for info, what makes you say that? Why would git be worse than > SVN for large files? > > Is that because all clones must "copy" all versions (compressed deltas > I guess) of those large files? —D > D > Below see some references found in google, the first one says that each version of a large file is stored (or maybe each version with a different md5). So cloning a plain vanilla git repository containing several versions of a large file would fill up one’s disk. That makes me think that the Ant git module will be a bit fat already from all the versions of xercesImpl and of jUnit that we have checked in over the years. The stack overflow article mentions add-ons to git to manage large files. Antoine http://www.altdevblogaday.com/2013/09/05/git-off-my-lawn-large-and-unmergable-assets/ http://stackoverflow.com/questions/540535/managing-large-binary-files-with-git https://help.github.com/articles/working-with-large-files - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: How to submit a change for AntUnit?
Hello Chris, I wonder whether the current behavior of the LogCapturer has a rationale and whether a backward compatibility needs to be preserved for this aspect. To submit a patch, the best is to create a bugzilla issue on http://issues.apache.org/bugzilla and to attach the output of svn diff -u . Regards, Antoine On Apr 28, 2014, at 4:05 PM, chris.hol...@awltux.com wrote: > Hi, > > I realise the AntUnit project is pretty quiet, but I have a fix I'd like to > submit. > > The LogCapturer currently concatenates all messages onto the same line. Not > very readable when you send the log to file. > > I've added an EOL to each append in method: > LogCapturer.messageLogged(BuildEvent event) > > How do I go about submitting this fix? > > Regards, > Chris Holman > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
In fact I have to correct this. I just contacted infra via freenode and I was told that they have their own migration tools and that they do not need subgit. There will certainly be other pre or post migration tasks :-) Antoine On Apr 28, 2014, at 10:46 PM, Antoine Levy Lambert wrote: > Hello Charles, > > On Apr 28, 2014, at 11:07 AM, Charles Duffy wrote: > >> +1 for Ant and Ivy, +0 elsewhere. >> >> If we wanted to do a history-preserving transform (with branches, merges >> &c. faithfully preserved), I'd be happy to help with the configuration and >> use of SubGit (which, while typically a commercially-licensed tool, has >> zero-cost licenses available for OSS projects) for this purpose; in my >> experience, it results in a considerably higher-quality transform than the >> competing git-svn tooling. (SubGit also offers bidirectional translation >> support, but I'm wary of the deployment requirements of same, and have >> concerns as to whether making proprietary tooling a dependency of Apache's >> ongoing infrastructure would be acceptable or wise). > nice to offer that sure, we will certainly be interested. > > Antoine >> > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
migration to git and web site publication
Hello Jan, On Apr 28, 2014, at 1:29 AM, Jan Matèrne (jhm) wrote: > > > >> The web sites will remain in svn in any event because svnpubsub is the >> only supported mechanism to maintain web sites AFAIK. > > I havent looked at the current svnpubsub, but there is also one with that > name for git > https://www.apache.org/dev/gitpubsub.html > > I would appreciate to have the same scm. > Could we start a new git repo for tests and vote later after the > git/gitpubsub is working? Apache Infra does not support gitpubsub for the purpose of maintaining an Apache web site. I asked confirmation of that on the #asfinfra All Apache web sites are in svn and use svnpubsub. git is not the tool of choice to deal with large files such as the ones on dist.apache.org. That might be part of the reason why infra supports only svn for the web site. > > > Jan > > Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
Hello Charles, On Apr 28, 2014, at 11:07 AM, Charles Duffy wrote: > +1 for Ant and Ivy, +0 elsewhere. > > If we wanted to do a history-preserving transform (with branches, merges > &c. faithfully preserved), I'd be happy to help with the configuration and > use of SubGit (which, while typically a commercially-licensed tool, has > zero-cost licenses available for OSS projects) for this purpose; in my > experience, it results in a considerably higher-quality transform than the > competing git-svn tooling. (SubGit also offers bidirectional translation > support, but I'm wary of the deployment requirements of same, and have > concerns as to whether making proprietary tooling a dependency of Apache's > ongoing infrastructure would be acceptable or wise). nice to offer that sure, we will certainly be interested. Antoine > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Ant 1.9.4 ?
Hi, a heads up to say that I plan to build a release candidate for Ant 1.9.4 this week, maybe as early as Monday or Tuesday evening. Unless someone needs absolutely to sneak in some new feature or bug fix. Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] migration to git
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 Let me start with my +1 Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Migrating to Git
Hi, like Michael one of my hopes in migrating to git is that it will allow non ASF committers to create their own forks of projects and be able to keep them (or not) up to date with the master branch. I have also done a little bit of investigation to see how other projects have migrated to GIT (by looking in the INFRA JIRA). Here some examples : Migration of Wicket to Git [1] Migration of Maven to Git [2] Migration of Cayenne to Git [3] and a document about switching to git [4] list of ASF GIT repos [5] Do we need to make a formal vote before requesting the migration to git ? Regards, Antoine [1] https://issues.apache.org/jira/browse/INFRA-4204 [2] https://issues.apache.org/jira/browse/INFRA-5390 [3] https://issues.apache.org/jira/browse/INFRA-5936 [4] https://git-wip-us.apache.org/docs/switching-to-git.html [5] https://git-wip-us.apache.org/repos/asf On Apr 20, 2014, at 5:46 AM, Michael Clarke wrote: > 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 Lic
Re: Build failed in Jenkins: Ant-Build-Matrix » JDK 1.6 (latest),Windows #697
On Apr 19, 2014, at 6:05 PM, Michael Clarke wrote:
>
> 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?)
I got access to the configuration and entered a combination filter
!(label.startsWith("Windows") && jdk.startsWith("Open JDK 1.8”))
That does not have a visible effect on the grid, we will soon see whether
jenkins tries to build this combo again.
Antoine
>
>
> Thanks,
>
> Michael
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
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
Thanks for the great work Michael,
On Apr 19, 2014, at 1:51 PM, Matt Sicker wrote:
> You can use the ExpectedException rule exactly where you expect the
> exception to be thrown. Using the @Test(expected = foo.class) (or whatever
> the attribute name was) is for the whole method. Unless you're talking
> about larger methods being tested that can throw multiple exceptions, then
> that's a different story altogether.
>
>
> On 19 April 2014 04:59, Michael Clarke wrote:
>
>>>
>>> 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.
>>
I am fine the way the BuidFileRule currently works, I do not see the need to
introduce new conventions.
>>
>>> //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
>>
>
>
>
> --
> Matt Sicker
Antoine
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Build failed in Jenkins: Ant-Build-Matrix » JDK 1.6 (latest),Windows #697
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 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Migrating to Git
On Apr 14, 2014, at 7:17 AM, Stefan Bodewig wrote: > On 2014-04-14, Nicolas Lalevée wrote: > >> But what about the publication of the doc on the website ? Today we >> rely on svn:externals for the doc of each release. How would it be >> managed if it's migrated to git ? > > We'd likely need to copy stuff around. TBH I'm not too sure we're still > using externals, I think we had some sort of problems when changing them > and fell back to copies/merges - at least for Ant. I may be wrong. Yes, we had the problem that if you change the destination of a svn:externals it is not detected as a modification by svnpubsub and the website is not republished, so we have had to do copy merges for the Ant web site. The ant manual used to be an external but this does not work. Antoine > > > Stefan > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Migration of Ant test to JUnit4
Hi,
I sent my email too fast, it looks like your antjunit4 fork is already
incorporating my changes.
All is well then.
Antoine
On Apr 13, 2014, at 9:20 PM, Antoine Levy Lambert wrote:
> Hello Michael,
>
> this is great.
>
> Since you started your fork, there have been changes done by Jan Matèrne to
> detect Java 9 and by myself to use separate folders for each test - all under
> subfolders of ${java.io.tmpdir}
>
> Is it possible to rebase your fork first from https://github.com/apache/ant
> ? Or what is the best way to reconcile the Svn head and your work ?
>
> If you do not have the time to rebase yourself I can help you do it, but I am
> not sure what would be the best way.
>
> Also I wonder whether Ant and Ivy should not migrate to GIT.
>
> Antoine
> On Apr 12, 2014, at 4:35 PM, Matt Sicker wrote:
>
>> This is pretty awesome!
>>
>>
>> On 12 April 2014 07:37, Michael Clarke wrote:
>>
>>> 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
>>>
>>
>>
>>
>> --
>> Matt Sicker
>
>
> -
> 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: Migration of Ant test to JUnit4
Hello Michael,
this is great.
Since you started your fork, there have been changes done by Jan Matèrne to
detect Java 9 and by myself to use separate folders for each test - all under
subfolders of ${java.io.tmpdir}
Is it possible to rebase your fork first from https://github.com/apache/ant ?
Or what is the best way to reconcile the Svn head and your work ?
If you do not have the time to rebase yourself I can help you do it, but I am
not sure what would be the best way.
Also I wonder whether Ant and Ivy should not migrate to GIT.
Antoine
On Apr 12, 2014, at 4:35 PM, Matt Sicker wrote:
> This is pretty awesome!
>
>
> On 12 April 2014 07:37, Michael Clarke wrote:
>
>> 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
>>
>
>
>
> --
> Matt Sicker
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant @ Jenkins
On Apr 11, 2014, at 2:46 AM, Jan Matèrne (jhm) wrote: > > No we have several Java8 installations available on the matrix: Open JDK 1.8 > (Only on ubuntu nodes) + jdk-1.8.0 > > > > Should we > > - add these two to the build matrix? sure > > - change the openJDK8 job to use Java9? +1 > > > > > > There is a timeout of 30min. Three of six (sounds like a Borg name ;) took > over 20min: > > - JDK 1.6 @ Windows [2] > > - JDK 1.7 @ Windows [3] > > - JDK 1.5 @ Windows [4] > > Should we increase that timeout? > +0 - I am not sure > > The build is started via Ant 1.8.2 (launch-build.xml), which launches > build.[sh|bat]. > > Just for that operation 1.8.2 is fine, but we could update the Ant version. > > Or separate the process in two steps, bootstrap run by a shell script and then running ant test with ANT_HOME set to bootstrap ? I have done that on TeamCity and that works fine. > > > I also see some builds failing because JUnit tests XML are not available, I do not know why. for instance the build 689 on JDK 1.5 ubuntu [5] > > Jan > > > Antoine [5] https://builds.apache.org/job/Ant-Build-Matrix/689/jdk=JDK%201.5%20%28latest%29,label=Ubuntu/console - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant @ Jenkins
Sounds good, Antoine On Apr 11, 2014, at 3:03 AM, Jan Matèrne (jhm) wrote: > update > * no Java9 available at Jenkins. So would have to create an JIRA like > https://issues.apache.org/jira/browse/INFRA-7485 > > Jan > > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 9 build 06 is available on java.net
Hi, On Apr 9, 2014, at 9:55 AM, Jan Matèrne (jhm) wrote: > I am trying to add the Java9 support. > First try is building on Java9, which fails due stricter javadoc checks. > > Yup, I think Stefan had reported too that generating the Javadoc of Ant also fails under Java 1.8 > Jan > > > > > svn-rev 1.585.946 > Working on Windows 7 > No optional libs (which doesnt exist in svn) > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03) > Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode, sharing) > > > …. pruning the detailed failures > ==> not fine, but I dont see a problem for trying Java9 > > Can you download the optional libs using fetch.xml ? and rerun the tests. If we have failures due to the absence of the optional libs it should be possible to correct that. Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 9 build 06 is available on java.net
Jan, On Apr 9, 2014, at 10:20 AM, Jan Matèrne (jhm) wrote: >>>>> JDK 9 Build 06 Early Access Build is now available for download >>>>> <https://jdk9.java.net/download> & test. >>>> >>>> Might be a good idea to make Ant detect Java9 > > > should be done with svn-1585981 > (Java9-detection should be changed to "usual algorithm" when there is a "new > introduced" class …) looks fine also to detect a new constant - that’s also pretty neat. > > >>>> and allow javac's >>>> target/source attribute values of "9" and "1.9" before we cut Ant >>>> 1.9.4 > > Haven't seen a constraint here ... > Must dive deeper ;) I did not see a constraint either in the source code of the javac tasks, did you try actually compiling under Java 1.9 ? > > > Jan > Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JDK 9 build 06 is available on java.net
Hi, I am still finishing up my work to make our unit tests use unique temporary directories. When I am finished I will look into that, although I am also interested in working on Ivy - especially the bug with the OutOfMemory exception on large zip files and the issue raised by Josh Suereth concerning performance. Regards, Antoine On Apr 8, 2014, at 6:47 AM, Stefan Bodewig wrote: > On 2014-04-08, Rory O'Donnell Oracle, Dublin Ireland wrote: > >> JDK 9 Build 06 Early Access Build is now available for download >> <https://jdk9.java.net/download> & test. > > Might be a good idea to make Ant detect Java9 and allow javac's > target/source attribute values of "9" and "1.9" before we cut Ant 1.9.4 > - I probably won't find time to look into it before the weekend, though. > > 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: [ANNOUNCE] Apache Ivy 2.4.0-RC1 released
Hello Maarten, please add this to http://ant.apache.org/index.html Regards, Antoine On Apr 1, 2014, at 4:46 PM, Maarten Coene wrote: > Should I add this release to http://ant.apache.org/index.html? > Or is that only reserved for final releases? > > Maarten > > > > > > Van: Maarten Coene > Aan: ant-dev > Verzonden: dinsdag 1 april 22:43 2014 > Onderwerp: [ANNOUNCE] Apache Ivy 2.4.0-RC1 released > > > The Apache Ivy project is pleased to announce its 2.4.0-RC1 release. > > Apache Ivy is a tool for managing (recording, tracking, resolving and > reporting) project dependencies, characterized by flexibility, > configurability, and tight integration with Apache Ant. > > Key features of this 2.4.0-RC1 release are > * some new Ant tasks > * improved OSGI support > * numerous bug fixes as documented in Jira and in the release notes > > As a release candidate version, we strongly encourage the use of this version > for > testing and validation. From now on, features are frozen until final 2.4.0 > version, > only bug fixes will be applied before 2.4.0. If no outstanding bugs are > reported > with this release candidate, it will promoted to 2.4.0 about three weeks > after this > release candidate. > > Issues should be reported to: > https://issues.apache.org/jira/browse/IVY > > Download the 2.4.0-RC1 release at: > http://ant.apache.org/ivy/download.cgi > > More information can be found on the Ivy website: > http://ant.apache.org/ivy/ > > Regards, > Maarten Coene - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ivy performance fix
Hello Josh, thanks for contacting the Ant/Ivy community. I think we can work with pull requests on github, as long as we see clearly the diffs with the code in the svn repository we should be fine. @Maarten, Nicolas, and others in the Ivy community, do you think we can merge this before building the ivy 2.4.0 final ? Regards, Antoine On Mar 31, 2014, at 4:15 PM, Josh Suereth wrote: > So, for the sbt project we noticed significant resolution time improvements > with the following patch: > > https://github.com/sbt/ivy/pull/1 > > The reasoning: > > > - A lot of artifacts being resolved use Maven's "dependencyManagement" > conventions > - Ivy appears to turn these into "exact matcher" rules > - A ton of resolution time is spent filtering through these rules > - The existing solution is O(n) for all overrides > > > What the patch does: > > > - Creates a key'd store for all "exact matcher" rules > - When executing rules, ensure that we only traverse what we have to > (non-exact, exact specific to our key and "default"). > > > As I said, this represents a significant speed bump for sbt builds using > Ivy. All existing tests pass, and I think they cover this aspect of ivy > pretty well, from what I could see. > > What's the best mechanism to submit this back? Do you accept pull requests > on github? > > Thanks! > - Josh Suereth > Tools Lead > Typesafe, Inc. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
