Re: compatibility matrix
I think that should be fine. Thanks Sent from my tablet > On Mar 26, 2016, at 06:16, Stefan Bodewig wrote: > >> On 2016-03-25, André-John Mas wrote: >> >> Missed this. Must admit I had forgotten it was there and it hadn't >> occurred to me to check there. At the same time was thinking something >> on the main page would draw more attention? > > André-John, do you think what I've published for the front page is > sufficient? > > 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: Drop Support for Java5, Move on to Ant 1.10.0?
Consider Enterprise is often 2 versions (maybe 3 versions) behind latest JDK, at lease based on my own experience, so 7 should still be included? Sent from my tablet > On Mar 6, 2016, at 10:31, Fernando Cassia wrote: > >> On 3/6/16, Stefan Bodewig wrote: >> I think it's time to drop support for Java5 and - as we've done in the >> past - bump the second part of Ant's version number to reflect the >> change. > > +1 > >> I'm not sure whether moving to Java6 is worth the effort since it has >> been EOLed as well, even Java7 is no longer officially supported by >> Oracle > > Isn't Java 6 the baseline API for Android development? Do Android IDEs use > ant? > Just thinking aloud... > >> but personally I wouldn't want to require Java8 right now. > > Why? OpenJDK 8 is included in most Linux distros. > >> So do we want to move on and if so, what should become our new baseline? > > That's a timely and relevant discussion, as just an ant user, and a > lurker on this list, I'm all ears. :) > > FC > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AW: Repository access
Can we not work with pull requests, in Git? At least this is an approach when working in GitHub. André-John Sent from my phone. Envoyé depuis mon téléphone. > On 6 Jun 2014, at 12:19, Antoine Levy-Lambert wrote: > > 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 > - 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/
Hi, Would it not be better simply to specify UTF-8 for all generated HTML documents, rather than relying on platform defaults? André-John Sent from my phone. Envoyé depuis mon téléphone. > On 14 May 2014, at 22:29, Antoine Levy Lambert wrote: > > 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 > - 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
Fair point. My experience has been the same. Was a little stubborn at first, but once I made the move from Subversion I haven't looked back. One thing that I found it fixed, in my environment, is avoiding devs using the main source control as a form of backup. André-John Sent from my phone. Envoyé depuis mon téléphone. > On 30 Apr 2014, at 18:48, Josh Suereth wrote: > > I'd argue that the convenience of pull requests in ASF should be a fixable > problem. If ASF is running repositories, Gerrit would be a great way to > set up an elegant ASF workflow... > > In any case, I applaud the effort to migrate to get and understand the > concerns. My experience has been truly great moving to git. > > > On Wed, Apr 30, 2014 at 6:33 PM, Andre-John Mas > wrote: > >> Could we conceive of having a GitHub project, that serves as a point for >> pull-requests and other community work and at the same time have a git repo >> at Apache that syncs with this? >> >> >> André-John >> >> Sent from my phone. Envoyé depuis mon téléphone. >> >>>> On 30 Apr 2014, at 17:33, Nicolas Lalevée >>> wrote: >>> >>> Even if I share some of your enthusiasm with git, don't forget that git >> at the ASF isn't like git in github. Pull request, code review and so on is >> not as integrated as in github. >>> >>> Nicolas >>> >>>> Le 30 avr. 2014 à 16:01, Josh Suereth a >> écrit : >>>> >>>> If you don't mind some recommendations from the peanut gallery (been >> using >>>> git for 5 years now) >>>> >>>> >>>>> On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert >>> wrote: >>>> >>>>> >>>>> 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. >>>> This is pretty huge. The cost of contributions is a lot lower *and* you >> can >>>> perform magic on branches (git rebase) before submitting to upstream >>>> projects. We (sbt + Scala) generally have a workflow of: >>>> >>>> 1. hack, hack, hack on our own clone/branch with a name "wip" >>>> 2. When done (across the group working on it), rebase the commits and >> clean >>>> up the commit messages to be as useful as possible >>>> 3. Submit a pull request, code review, go back to #1 as necessary >>>> 4. Merge into master, delete local branch, continue work. >>>> >>>> Not only that, we're already using the git Ivy mirror to collaborate >>>> between sbt devs and outside ivy contributors. It's a very good model >> for >>>> highly distributed (i.e. OSS) teams where coordination of contributions >> is >>>> hard. >>>> >>>> >>>>> - 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. >>>> I often run 3-5 branches of code for OSS projects. 1-2 of "itch >>>> scratching" and 1-3 of "bug fixing". It's a great thing. >>>> >>>> >>>>> - because of the popularity of git I imagine that the change is good >> for >>>>> the long run but this is speculation >>>> Popularity definitely puts it above something like mercurial. It also >>>> means the tooling for git has become pretty good over the past few >> years. >>>> JGit even provides really good Git support for programatic access. >>>&g
Re: Hoped for advantages of migrating to git
Could we conceive of having a GitHub project, that serves as a point for pull-requests and other community work and at the same time have a git repo at Apache that syncs with this? André-John Sent from my phone. Envoyé depuis mon téléphone. > On 30 Apr 2014, at 17:33, Nicolas Lalevée wrote: > > Even if I share some of your enthusiasm with git, don't forget that git at > the ASF isn't like git in github. Pull request, code review and so on is not > as integrated as in github. > > Nicolas > >> Le 30 avr. 2014 à 16:01, Josh Suereth a écrit : >> >> If you don't mind some recommendations from the peanut gallery (been using >> git for 5 years now) >> >> >> On Wed, Apr 30, 2014 at 9:53 AM, Antoine Levy-Lambert wrote: >> >>> >>> 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. >> This is pretty huge. The cost of contributions is a lot lower *and* you can >> perform magic on branches (git rebase) before submitting to upstream >> projects. We (sbt + Scala) generally have a workflow of: >> >> 1. hack, hack, hack on our own clone/branch with a name "wip" >> 2. When done (across the group working on it), rebase the commits and clean >> up the commit messages to be as useful as possible >> 3. Submit a pull request, code review, go back to #1 as necessary >> 4. Merge into master, delete local branch, continue work. >> >> Not only that, we're already using the git Ivy mirror to collaborate >> between sbt devs and outside ivy contributors. It's a very good model for >> highly distributed (i.e. OSS) teams where coordination of contributions is >> hard. >> >> >>> - 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. >> I often run 3-5 branches of code for OSS projects. 1-2 of "itch >> scratching" and 1-3 of "bug fixing". It's a great thing. >> >> >>> - because of the popularity of git I imagine that the change is good for >>> the long run but this is speculation >> Popularity definitely puts it above something like mercurial. It also >> means the tooling for git has become pretty good over the past few years. >> JGit even provides really good Git support for programatic access. >> >> >> >>> 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. >> From an sbt perspective, you'd see us attempting to contribute things back >> far more often than we do now. If you'd like an example project that >> contains website assets in it, feel free to checkout github.com/sbt/sbt and >> see how long it takes to switch branches / load the repository initially. >> >> - The Peanut Gallery (Josh) > > > - > 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: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)
Hi, I think this may be the simplest approach, since invariably most people using Ant will probably interact with the command line at some point? Andre Sent from my tablet On 2013-12-23, at 11:05, Nicolas Lalevée wrote: > > Le 23 déc. 2013 à 13:47, Antoine Levy Lambert a écrit : > >> Hello Stefan, >> >> the python script to create the MacOSX installer relies on a utility >> pkgbuild which I suppose locks it to MacOSX. >> True we do not ship Windows Installers, Debian packages, so maybe we should >> hold off on shipping the MacOSX installer. >> Especially since there is no guarantee that future builds will be done on >> Macs. > > BTW, I am using macports to install Ant on my mac, works like a charm, and > updated frequently. And I know it is possible to do it via homebrew or fink > too. > > 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: [Bug 55899] [PATCH] Distribute Mac OS X .pkg installer of Ant (patch included)
On 2013-12-23, at 1:01, Stefan Bodewig wrote: > On 2013-12-23, wrote: > >> Do we want to distribute the installer systematically with new >> versions of Ant ? > > I wouldn't mind much if it can be created outside of a Mac. Then again > we don't ship Windows installers, Debian packages, RPMs ... either. That would be cool, though for that to happen we would need to find some library or tool that can do that. Does anyone know if the FreeBSD pkg_create tool creates compatible files? Andre - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant Version
On 2013-12-10, at 0:18, Stefan Bodewig wrote: > On 2013-12-09, Andre-John Mas wrote: > >> It is what I used and how the patch was accepted, but since I was told >> it wasn't ideal I wanted to see if there were ways to deal with this >> going forward. > > It was me who said it wasn't ideal. My concern is IDE integration which > might start Ant differently and bypass Main so the static methods on > Main don't work properly. > > Andre-John's contribution made me look at the implementation again and > since the methods are static and only rely on ther version.txt file > being present, I no longer see a problem. An implementation outside of > Main wouldn't look any different and I highly doubt an IDE integration > would remove the Main class completely. > > Stefan Thanks for the insight. At the same time your original comment got me thinking about class dependencies on whether it would make better architectural sense to have a class that represents the application's environment, to avoid any potential two way dependencies with Main? Andre-John - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant Version
Covered in this ticket: https://issues.apache.org/bugzilla/show_bug.cgi?id=55489 On 9-Dec-2013, at 17:00, Matt Benson wrote: > Do you have a link to that discussion? I'd be interested to catch up the > context here. > > Thanks, > Matt > > > On Mon, Dec 9, 2013 at 3:01 PM, Andre-John Mas wrote: > >> It is what I used and how the patch was accepted, but since I was told it >> wasn't ideal I wanted to see if there were ways to deal with this going >> forward. >> >> André-John >> >> Sent from my phone. Envoyé depuis mon téléphone. >> >>> On Dec 9, 2013, at 15:56, Matt Benson wrote: >>> >>> Looks like Main.getAntVersion() is your friend. >>> >>> Matt >>> >>> >>> On Mon, Dec 9, 2013 at 2:50 PM, Andre-John Mas >> wrote: >>> >>>> Hi, >>>> >>>> This was the Get Task, whereby I was getting the ant version for use in >>>> the user-agent response. I am using the value uninterpreted. >>>> >>>> André-John >>>> >>>> Sent from my phone. Envoyé depuis mon téléphone. >>>> >>>>> On Dec 9, 2013, at 14:23, Matt Benson wrote: >>>>> >>>>> Are you looking for compatibility with the version? I.e., this task >> will >>>>> work on versions >= n? A commonly taken approach there is to use the >>>>> presence of some particular class introduced in the target version, >>>> rather >>>>> than fiddling with version numbers per se. >>>>> >>>>> HTH, >>>>> Matt >>>>> >>>>> >>>>> On Mon, Dec 9, 2013 at 1:08 PM, Andre-John Mas < >> andrejohn@gmail.com >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I recently made a code contribution and had the task get the version >>>> from >>>>>> the Main class. I appreciate this probably want the best approach and >> I >>>> am >>>>>> trying to consider options going forward. I had looked at the >>>> ant.version >>>>>> property, but the is only available in the project scope and also >>>> limited >>>>>> to the 'long' version. >>>>>> >>>>>> Some possibilities I am thinking of going forward: >>>>>> - Version class >>>>>> - AntRuntime class >>>>>> >>>>>> Does anyone else have suggestions or preferences as to the best way >>>> going >>>>>> forward? >>>>>> >>>>>> André-John >>>>>> >>>>>> Sent from my phone. Envoyé depuis mon téléphone. >>>>>> - >>>>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>> For additional commands, e-mail: dev-h...@ant.apache.org >>>> >>>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant Version
It is what I used and how the patch was accepted, but since I was told it wasn't ideal I wanted to see if there were ways to deal with this going forward. André-John Sent from my phone. Envoyé depuis mon téléphone. > On Dec 9, 2013, at 15:56, Matt Benson wrote: > > Looks like Main.getAntVersion() is your friend. > > Matt > > > On Mon, Dec 9, 2013 at 2:50 PM, Andre-John Mas wrote: > >> Hi, >> >> This was the Get Task, whereby I was getting the ant version for use in >> the user-agent response. I am using the value uninterpreted. >> >> André-John >> >> Sent from my phone. Envoyé depuis mon téléphone. >> >>> On Dec 9, 2013, at 14:23, Matt Benson wrote: >>> >>> Are you looking for compatibility with the version? I.e., this task will >>> work on versions >= n? A commonly taken approach there is to use the >>> presence of some particular class introduced in the target version, >> rather >>> than fiddling with version numbers per se. >>> >>> HTH, >>> Matt >>> >>> >>> On Mon, Dec 9, 2013 at 1:08 PM, Andre-John Mas >> wrote: >>> >>>> Hi, >>>> >>>> I recently made a code contribution and had the task get the version >> from >>>> the Main class. I appreciate this probably want the best approach and I >> am >>>> trying to consider options going forward. I had looked at the >> ant.version >>>> property, but the is only available in the project scope and also >> limited >>>> to the 'long' version. >>>> >>>> Some possibilities I am thinking of going forward: >>>> - Version class >>>> - AntRuntime class >>>> >>>> Does anyone else have suggestions or preferences as to the best way >> going >>>> forward? >>>> >>>> André-John >>>> >>>> Sent from my phone. Envoyé depuis mon téléphone. >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >>>> For additional commands, e-mail: dev-h...@ant.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant Version
Hi, This was the Get Task, whereby I was getting the ant version for use in the user-agent response. I am using the value uninterpreted. André-John Sent from my phone. Envoyé depuis mon téléphone. > On Dec 9, 2013, at 14:23, Matt Benson wrote: > > Are you looking for compatibility with the version? I.e., this task will > work on versions >= n? A commonly taken approach there is to use the > presence of some particular class introduced in the target version, rather > than fiddling with version numbers per se. > > HTH, > Matt > > > On Mon, Dec 9, 2013 at 1:08 PM, Andre-John Mas wrote: > >> Hi, >> >> I recently made a code contribution and had the task get the version from >> the Main class. I appreciate this probably want the best approach and I am >> trying to consider options going forward. I had looked at the ant.version >> property, but the is only available in the project scope and also limited >> to the 'long' version. >> >> Some possibilities I am thinking of going forward: >> - Version class >> - AntRuntime class >> >> Does anyone else have suggestions or preferences as to the best way going >> forward? >> >> André-John >> >> Sent from my phone. Envoyé depuis mon téléphone. >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Ant Version
Hi, I recently made a code contribution and had the task get the version from the Main class. I appreciate this probably want the best approach and I am trying to consider options going forward. I had looked at the ant.version property, but the is only available in the project scope and also limited to the 'long' version. Some possibilities I am thinking of going forward: - Version class - AntRuntime class Does anyone else have suggestions or preferences as to the best way going forward? André-John Sent from my phone. Envoyé depuis mon téléphone. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Short version of the ant version string?
Hi, As part of my work on issue 55489, "Allow specifying of alternative user agent for the 'get' task", I need to be able to include the Ant version string in the user-agent (Apache Ant/0.0), but using the following: getProject().getProperty(MagicNames.ANT_VERSION) or Main.getVersion() both returning a long version string of them form: "Apache Ant(TM) version 1.9.3alpha compiled on November 22 2013" From what I can see there is no method to get a 'short' version, unless I am not looking in the right place. If there isn't already something, would adding a Main.getShortVersion() be acceptable? Regards Andre - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java version of Ivy/IvyDE
I would vote for supporting Java 6 and then indicating on the website which ant + ivy/ivyDE version combination is needed to support pre-JDK 1.6 environments, especially given the argument about Ant requiring more recent JDK version. JDK 1.6 has been out long enough that it should probably be considered well established and suitable as the current baseline. At the same time it would be interesting to know from anyone who votes for continued support for java 1.4, why they are unable to use 1.6 as a their tooling environment, noting that you can still target 1.4 with 1.6 based build tools. André-John Sent from my phone. Envoyé depuis mon téléphone. On 2013-09-02, at 9:37, Nicolas Lalevée wrote: > Ivy and IvyDE are still supporting Java 1.4. > > Java 1.4 is starting to be very old. And I am missing generics (I need them > so much that I do some generic-commenting [1]). So I suggest to require at > least Java 5. > > As discussed with the Java requirement of Ant, Java 5 is deprecated too, and > I for instance cannot run it anymore on my machine. So I would suggest to > jump directly to require Java 6. > > So what do you think ? > [ ] we should continue to support Java 1.4 > [ ] we should make Ivy and IvyDE require Java 5 > [ ] we should make Ivy and IvyDE require Java 6 > > Nicolas > > [1] > http://svn.apache.org/repos/asf/ant/ivy/core/trunk/src/java/org/apache/ivy/osgi/repo/ArtifactReportManifestIterable.java > > > - > 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
Allowing over-riding of user-agent
Hi, I have created a patch for 'Bug 55489' (https://issues.apache.org/bugzilla/show_bug.cgi?id=55489), which allows specifying of the user agent in the 'get' task and also changes the code to specify a new default value. This was created based on https://issues.apache.org/jira/browse/IVY-1435 . While this later one was for Ivy, this current ticket is intended to ensure we aren't using the default Java user-agent. Can anyone tell me whether the patch in the ticket looks fine and whether this is something that can be accepted? Thanks Andre - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: cannot find symbol: Assume.assumeFalse() - bad junit 4.11 jar in repo?
Hi,
Not a problem in the repo - sorry for this. Feeling a little red in the face
here.
Looks like I jumped the gun. I suspected it was probably an environment issue
and I didn't dig enough. It turns out I had an old version in my Java extensions
folder, which on removing resolved the issue.
Andre
On 28-Aug-2013, at 00:05, Andre-John Mas wrote:
> Hi,
>
> I am building Ant from source for the first time, using the SVN tree, at
> revision 1517854.
>
> When I try to build the project I get the following error:
>
> compile-tests:
>[javac] Compiling 9 source files to
> /Users/ajmas/Development/third-party/ant/ant-core/build/testcases
>[javac]
> /Users/ajmas/Development/third-party/ant/ant-core/src/tests/junit/org/example/junit/JUnit4Skippable.java:43:
> cannot find symbol
>[javac] symbol : method assumeFalse(java.lang.String,boolean)
>[javac] location: class org.junit.Assume
>[javac] Assume.assumeFalse("This test will be ignored", true);
>[javac] ^
>[javac]
> /Users/ajmas/Development/third-party/ant/ant-core/src/tests/junit/org/example/junit/JUnit4Skippable.java:55:
> cannot find symbol
>[javac] symbol : method assumeFalse(boolean)
>[javac] location: class org.junit.Assume
>[javac] Assume.assumeFalse(true);
>[javac] ^
>[javac] 2 errors
>
> Running: javap -classpath lib/optional/junit-4.11.jar org.junit.Assume, I get:
>
> Compiled from "Assume.java"
> public class org.junit.Assume extends java.lang.Object{
>public org.junit.Assume();
>public static void assumeTrue(boolean);
>public static void assumeNotNull(java.lang.Object[]);
>public static void assumeThat(java.lang.Object, org.hamcrest.Matcher);
>public static void assumeNoException(java.lang.Throwable);
> }
>
> Looking at the junit 4.11 at https://github.com/junit-team/junit it shows
> that method should be there.
>
> Just to be sure I download junit 4.11 from:
>
> http://search.maven.org/#search|gav|1|g%3A%22junit%22%20AND%20a%3A%22junit%22
>
> and this shows the expected contents:
>
> public class org.junit.Assume extends java.lang.Object{
>public org.junit.Assume();
>public static void assumeTrue(boolean);
>public static void assumeFalse(boolean);
>public static void assumeTrue(java.lang.String, boolean);
>public static void assumeFalse(java.lang.String, boolean);
>public static void assumeNotNull(java.lang.Object[]);
>public static void assumeThat(java.lang.Object, org.hamcrest.Matcher);
>public static void assumeThat(java.lang.String, java.lang.Object,
> org.hamcrest.Matcher);
>public static void assumeNoException(java.lang.Throwable);
>public static void assumeNoException(java.lang.String,
> java.lang.Throwable);
> }
>
> It looks like the junit jar in the repo needs updating?
>
> Andre
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
cannot find symbol: Assume.assumeFalse() - bad junit 4.11 jar in repo?
Hi,
I am building Ant from source for the first time, using the SVN tree, at
revision 1517854.
When I try to build the project I get the following error:
compile-tests:
[javac] Compiling 9 source files to
/Users/ajmas/Development/third-party/ant/ant-core/build/testcases
[javac]
/Users/ajmas/Development/third-party/ant/ant-core/src/tests/junit/org/example/junit/JUnit4Skippable.java:43:
cannot find symbol
[javac] symbol : method assumeFalse(java.lang.String,boolean)
[javac] location: class org.junit.Assume
[javac] Assume.assumeFalse("This test will be ignored", true);
[javac] ^
[javac]
/Users/ajmas/Development/third-party/ant/ant-core/src/tests/junit/org/example/junit/JUnit4Skippable.java:55:
cannot find symbol
[javac] symbol : method assumeFalse(boolean)
[javac] location: class org.junit.Assume
[javac] Assume.assumeFalse(true);
[javac] ^
[javac] 2 errors
Running: javap -classpath lib/optional/junit-4.11.jar org.junit.Assume, I get:
Compiled from "Assume.java"
public class org.junit.Assume extends java.lang.Object{
public org.junit.Assume();
public static void assumeTrue(boolean);
public static void assumeNotNull(java.lang.Object[]);
public static void assumeThat(java.lang.Object, org.hamcrest.Matcher);
public static void assumeNoException(java.lang.Throwable);
}
Looking at the junit 4.11 at https://github.com/junit-team/junit it shows that
method should be there.
Just to be sure I download junit 4.11 from:
http://search.maven.org/#search|gav|1|g%3A%22junit%22%20AND%20a%3A%22junit%22
and this shows the expected contents:
public class org.junit.Assume extends java.lang.Object{
public org.junit.Assume();
public static void assumeTrue(boolean);
public static void assumeFalse(boolean);
public static void assumeTrue(java.lang.String, boolean);
public static void assumeFalse(java.lang.String, boolean);
public static void assumeNotNull(java.lang.Object[]);
public static void assumeThat(java.lang.Object, org.hamcrest.Matcher);
public static void assumeThat(java.lang.String, java.lang.Object,
org.hamcrest.Matcher);
public static void assumeNoException(java.lang.Throwable);
public static void assumeNoException(java.lang.String, java.lang.Throwable);
}
It looks like the junit jar in the repo needs updating?
Andre
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
