[VOTE-RESULT] Adopt Java 1.4 as a minimum requirement for core/trunk
On Thu, 30 Oct 2008, Stefan Bodewig [EMAIL PROTECTED] wrote: This is not that much based on features available (although I consider using NIO in StreamPumper) but more on where do we test. This vote has passed and I'll modifiy the WHATSNEW and FAQ parts accordingly. Unless anybody else pushes for an even stronger move, this means trunk and Ant 1.8.0 will require Java 1.4. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
On Wed, 5 Nov 2008, Dominique Devienne [EMAIL PROTECTED] wrote: On Wed, Nov 5, 2008 at 9:59 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: IIUC EasyAnt solits the two use-cases found for import into two logical tasks. * you never want to override a target, you just want to reuse them: use That's an include to me. Rename use into include, and I'm +1, I'm not bound to names. EasyAnt also adds an as-attribute to use where the writer of the importing build file can control the prefix of the used targets and overrules the used project's name. This makes sense IMHO. It does to me too :) I'm not totally sure whether the as-attribute would make sense for extends as well, EasyAnt currently silently ignores it in that case. It makes as much sense in import as it does in include to me, i.e. to restore proper compartmentalization of the builds. I'd probably want to allow it for symmetry as well, but I haven't thought through all implications. I don't think we should invent new terminology (use/extends) for something that already exists (import) and it's natural equivalent to use (include, which doesn't exist). Then we need to stretch the difference. Two new names would increas awareness that import does something special. What's missing from the above is the notion of TargetGroup to implement the phase concept of EasyAnt (and Maven I guess). True. To me those concepts are orthogonal and I'd like to have separate discussions on them (and picked this topic to be first). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Apache Ivy 2.0.0-rc2 released
Congrats, you may want to announce this on the ant.apache.org homepage as well. Let us know if you need a hand. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EasyAnt use/extends vs import
IIUC EasyAnt solits the two use-cases found for import into two logical tasks. * you never want to override a target, you just want to reuse them: use That's an include to me. Rename use into include, and I'm +1, I'm not bound to names. +1 =) I'm not totally sure whether the as-attribute would make sense for extends as well, EasyAnt currently silently ignores it in that case. It makes as much sense in import as it does in include to me, i.e. to restore proper compartmentalization of the builds. I'd probably want to allow it for symmetry as well, but I haven't thought through all implications. I'm not sure that adding an as-attribute make sense for extends. In our POC you can import with use mode the same file with different prefix. exemple : project name=Abstract-Module ... /project project name=Concret-Module1 use file=Abstract-Module as AbstractModuleConcret1/ ... /project project name=Concret-Module2 use file=Abstract-Module as AbstractModuleConcret2/ ... /project project name=genericBuild extends file=Concret-Module1/ extends file=Concret-Module2/ /project I guess adding an as attribute on extends is like having only one import mode where we can add prefix, and i'm not sure this is the solution. IMHO we need those two kind of import: - extends similar to the actual import - use is like a Rich import that support namespace and that allow you to import many time the same build script with different namespace. That's why i think as attribute should be used only with use. What do you think about it? I don't think we should invent new terminology (use/extends) for something that already exists (import) and it's natural equivalent to use (include, which doesn't exist). Then we need to stretch the difference. Two new names would increas awareness that import does something special. What's missing from the above is the notion of TargetGroup to implement the phase concept of EasyAnt (and Maven I guess). True. To me those concepts are orthogonal and I'd like to have separate discussions on them (and picked this topic to be first). Nice :)
Re: EasyAnt use/extends vs import
On Thu, Nov 6, 2008 at 4:42 AM, Jean-Louis BOUDART [EMAIL PROTECTED] wrote: I'm not sure that adding an as-attribute make sense for extends. In our POC you can import with use mode the same file with different prefix. exemple : project name=Abstract-Module ... /project project name=Concret-Module1 use file=Abstract-Module as AbstractModuleConcret1/ ... /project project name=Concret-Module2 use file=Abstract-Module as AbstractModuleConcret2/ ... /project project name=genericBuild extends file=Concret-Module1/ extends file=Concret-Module2/ /project What I've argued before is that the 'as' attribute used by a build should only be visible to that build. Any other build that uses it (English meaning of use :) should not be aware of this attribute. This way both Concrete-Model1 and 2 can use the same as, and it's genericBuild that's then forced to use two different 'as' attributes for them to be able to distinguish them. It's analogs to Java's inheritance, where a derived class can only refer explicitly to its direct parent's methods, and not any of its ancestors (like in C++). In other words, you can only bypass the normal virtual dispatch of method if it's a method of your parent. There's no reason for genericBuild to directly reference Abstract-Module. Abstract-Module basically became part-of Concret-Module1 and 2, and is invisible to genericBuild, unless genericBuild also directly import/includes it. Failing to do this, you couldn't safely refactor Concrete-Module1 and 2, without possibly breaking genericBuild. Ah, it looks to me that I'm again failing to get my view across. Since I'm no longer actively using Ant like I used to, I'll take a step back and stop arguing the above points, which are probably incompatible with the (simplistic?) way Ant deals with import and target addressing (by simple prefixing). - use is like a Rich import that support namespace and that allow you to import many time the same build script with different namespace. And I thought use was like an include ;) i.e. less than import, while it's actually more. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Jesse Glick wrote: Jess Holle wrote: We've seen this before where A depends on B which /internally/ depends upon C and then suddenly one has to have C around to compile A. Although this is not forbidden by the JLS (as far as I know), it does seem undesirable. If you know of particular examples which can be expressed as minimal test cases, I would encourage you to file bug reports for the compiler. Not ever seen that. I have just been burned today by the fact that Java6 lets you do an @Overrides on any method that implements an interface; I'd been using that to indicate which methods were interface implementations. Java5 says @Overrides is only for non-abstract methods, hence breaks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Steve Loughran wrote: Jesse Glick wrote: Jess Holle wrote: We've seen this before where A depends on B which /internally/ depends upon C and then suddenly one has to have C around to compile A. Although this is not forbidden by the JLS (as far as I know), it does seem undesirable. If you know of particular examples which can be expressed as minimal test cases, I would encourage you to file bug reports for the compiler. Not ever seen that. I have just been burned today by the fact that Java6 lets you do an @Overrides on any method that implements an interface; I'd been using that to indicate which methods were interface implementations. Java5 says @Overrides is only for non-abstract methods, hence breaks. Yes, that's a really obnoxious failing in Java 5. It's good that it was fixed in Java 6. It would have been even better if it had been fixed in a Java 5 update. -- Jess Holle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Apache Ivy 2.0.0-rc2 released
that would be cool indeed... But I think we can release Ivy-2.0 final within 2 or 3 weeks if no serious bugs are reported against RC2. Maybe we should only announce the final release on ant.apache.org ? WDYT? Maarten - Original Message From: Stefan Bodewig [EMAIL PROTECTED] To: dev@ant.apache.org Sent: Thursday, November 6, 2008 11:06:36 AM Subject: Re: [ANNOUNCE] Apache Ivy 2.0.0-rc2 released Congrats, you may want to announce this on the ant.apache.org homepage as well. Let us know if you need a hand. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Apache Ivy 2.0.0-rc2 released
On Thu, 6 Nov 2008, Maarten Coene [EMAIL PROTECTED] wrote: But I think we can release Ivy-2.0 final within 2 or 3 weeks if no serious bugs are reported against RC2. Maybe we should only announce the final release on ant.apache.org ? Your call. I wouldn't see any problem with an announcement for the RC that is replaced by the final announcement two weeks later. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
