RE: Ivy svn breaks ant-contrib svn
quote We warned the users about that in the release notes, and changing code in Ivy for backward compatibility with a beta version (which in Ivy language is not a release candidate) sounds not like a good idea to me. That is more tha fine with me. But once again I'm alone to decide, and if more people think it makes sense, I won't object. There is no reason to change anything for me. /quote Agreed, but it would be nice to -either warn users that this specific change in beta-2 has been reverted, so that new adopters of beta-2 are explicitly aware of this -or make a new beta release with the original behaviour. Regards, Erik-Berndt Van: Stefan Bodewig [mailto:[EMAIL PROTECTED] Verzonden: vr 18-7-2008 17:33 Aan: dev@ant.apache.org Onderwerp: Re: Ivy svn breaks ant-contrib svn On Thu, 17 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 10:00 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: I don't really have an opinion on the particular change but am a strong proponent of not breaking APIs in general (at least not without a deprecation period). I agree in general, but Ivy 2 has been going in a deep code change, and we decided to keep backward compatibility with 1.4 at ant tasks level, but not at API level. Understood. We warned the users about that in the release notes, and changing code in Ivy for backward compatibility with a beta version (which in Ivy language is not a release candidate) sounds not like a good idea to me. That is more tha fine with me. But once again I'm alone to decide, and if more people think it makes sense, I won't object. There is no reason to change anything for me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy svn breaks ant-contrib svn
On Thu, 17 Jul 2008, Maarten Coene [EMAIL PROTECTED] wrote: Just a wild guess, but maybe you could use IvyAntSettings again (like your original code was), I thought so myself and had a quick look, but I'm neither familiar enough with Ivy nor what the ant-contrib task is trying to do that I dared to change anything. I might give it a try sometime later in August. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy svn breaks ant-contrib svn
On Thu, 17 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 10:00 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: I don't really have an opinion on the particular change but am a strong proponent of not breaking APIs in general (at least not without a deprecation period). I agree in general, but Ivy 2 has been going in a deep code change, and we decided to keep backward compatibility with 1.4 at ant tasks level, but not at API level. Understood. We warned the users about that in the release notes, and changing code in Ivy for backward compatibility with a beta version (which in Ivy language is not a release candidate) sounds not like a good idea to me. That is more tha fine with me. But once again I'm alone to decide, and if more people think it makes sense, I won't object. There is no reason to change anything for me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy svn breaks ant-contrib svn
On Wed, 16 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: Yes, I think setSettingsId is the good method to call, 2.0.0-beta2 was broken in that sense. Introducing a setId method for backward compatiblity with something broken in concept doesn't sound really nice IMO. We will probably forget to remove it after, I don't like it too much. IMO antcontrib should be built either against trunk, or against beta2, but not both. But maybe others have a different opinion? This is exactly the kind of change that Gump was designed to catch and I'm glad it did. I don't really have an opinion on the particular change but am a strong proponent of not breaking APIs in general (at least not without a deprecation period). Right now ant-contrib doesn't have anything but beta2 to build against, so it must use setId. Once the next Ivy release is available they (we, sometimes it's hard to wear different hats) can switch to setSettingsId - or more precisely must. This forces ant-contrib to lock step its release plan with Ivy's - if there was such a plan. I'd avoid using reflection and in this particular case don't really care too much, so I will simply keep Gump broken until Ivy has a new artifact ant-contrib can build against. It may be something you should keep in mind when preparing the release notes of the next Ivy release, though. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy svn breaks ant-contrib svn
On Thu, Jul 17, 2008 at 10:00 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Wed, 16 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: Yes, I think setSettingsId is the good method to call, 2.0.0-beta2 was broken in that sense. Introducing a setId method for backward compatiblity with something broken in concept doesn't sound really nice IMO. We will probably forget to remove it after, I don't like it too much. IMO antcontrib should be built either against trunk, or against beta2, but not both. But maybe others have a different opinion? This is exactly the kind of change that Gump was designed to catch and I'm glad it did. I don't really have an opinion on the particular change but am a strong proponent of not breaking APIs in general (at least not without a deprecation period). I agree in general, but Ivy 2 has been going in a deep code change, and we decided to keep backward compatibility with 1.4 at ant tasks level, but not at API level. We warned the users about that in the release notes, and changing code in Ivy for backward compatibility with a beta version (which in Ivy language is not a release candidate) sounds not like a good idea to me. But once again I'm alone to decide, and if more people think it makes sense, I won't object. Right now ant-contrib doesn't have anything but beta2 to build against, so it must use setId. Indeed. Once the next Ivy release is available they (we, sometimes it's hard to wear different hats) can switch to setSettingsId - or more precisely must. This forces ant-contrib to lock step its release plan with Ivy's - if there was such a plan. Yes, in a way. That's the problem of using a beta version as a dependency. And that's also a problem of long release cycles, I'd really like to get Ivy 2 final released asap to avoid or at least reduce this kind of problem in the future. I'd avoid using reflection and in this particular case don't really care too much, so I will simply keep Gump broken until Ivy has a new artifact ant-contrib can build against. It may be something you should keep in mind when preparing the release notes of the next Ivy release, though. This sounds like a good option. Xavier Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Ivy svn breaks ant-contrib svn
Just a wild guess, but maybe you could use IvyAntSettings again (like your original code was), but instead of calling the execute method you can register it yourself as Reference in the Project, something like: IvyAntSettings settings = new IvyAntSettings(); settings.setXXX... getProject().addReference(settingsId, settings); Maarten - Original Message From: Stefan Bodewig [EMAIL PROTECTED] To: dev@ant.apache.org Sent: Tuesday, July 15, 2008 2:13:10 PM Subject: Re: Ivy svn breaks ant-contrib svn On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 9:23 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. OK, what can ant-contrib do if it wants to compile against Ivy 2.0.0beta2 and trunk with the same codebase? This is not straightforward, since we broke the API. Right, that's why Gump finds it 8-) Maybe you could throw in a deprecated setId() method that delegated to setSettingsId()? At least for the next beta so ant-contrib has a stable base to work from without resorting to reflection. I looked into the code to see what the id is used for. It is later used as the argument for IvyCacheFileset.setSettingsRef - this wouldn't work with a reference to the task but would require a reference to the settings, which now would exactly be what setSettingsId creates, right? 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: [SPAM] Re: Ivy svn breaks ant-contrib svn
I've been thinking about suggesting this before, but now that the trunk has broken (undesired) changes that worked fine in beta-2, it might be a good idea to postpone most of the outstanding issues for RC1 to a RC2 and release RC1 asap. That would promote better testing of the 100+ bug-fixes and changes since beta-2. Incidentally, beta-2 is now 4 months old, which was also the timeframe between beta-1 and beta-2. Erik-Berndt Van: Maarten Coene [mailto:[EMAIL PROTECTED] Verzonden: do 17-7-2008 11:45 Aan: Ant Developers List Onderwerp: [SPAM] Re: Ivy svn breaks ant-contrib svn Just a wild guess, but maybe you could use IvyAntSettings again (like your original code was), but instead of calling the execute method you can register it yourself as Reference in the Project, something like: IvyAntSettings settings = new IvyAntSettings(); settings.setXXX... getProject().addReference(settingsId, settings); Maarten - Original Message From: Stefan Bodewig [EMAIL PROTECTED] To: dev@ant.apache.org Sent: Tuesday, July 15, 2008 2:13:10 PM Subject: Re: Ivy svn breaks ant-contrib svn On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 9:23 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. OK, what can ant-contrib do if it wants to compile against Ivy 2.0.0beta2 and trunk with the same codebase? This is not straightforward, since we broke the API. Right, that's why Gump finds it 8-) Maybe you could throw in a deprecated setId() method that delegated to setSettingsId()? At least for the next beta so ant-contrib has a stable base to work from without resorting to reflection. I looked into the code to see what the id is used for. It is later used as the argument for IvyCacheFileset.setSettingsRef - this wouldn't work with a reference to the task but would require a reference to the settings, which now would exactly be what setSettingsId creates, right? 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] Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SPAM] Re: Ivy svn breaks ant-contrib svn
On Thu, Jul 17, 2008 at 4:16 PM, Scheper, Erik-Berndt [EMAIL PROTECTED] wrote: I've been thinking about suggesting this before, but now that the trunk has broken (undesired) changes that worked fine in beta-2, it might be a good idea to postpone most of the outstanding issues for RC1 to a RC2 and release RC1 asap. Well, IMO a RC should be, well, a release candidate. If you are sure it won't become a release because there are bugs you absolutely want to get fixed before the final release, I wouldn't call this a RC. That being said, maybe we should release a beta 3 now, and still make the best efforts to get rc1 out with the 18 corresponding issues fixed asap. The only problem I see is that some committers are currently in vacation, so it will be more difficult to get the votes for the release. But if enough committers (well, even PMC members) answer they are ok, I'll try to cut a beta 3 next week (despite my overloaded planning). Xavier That would promote better testing of the 100+ bug-fixes and changes since beta-2. Incidentally, beta-2 is now 4 months old, which was also the timeframe between beta-1 and beta-2. Erik-Berndt Van: Maarten Coene [mailto:[EMAIL PROTECTED] Verzonden: do 17-7-2008 11:45 Aan: Ant Developers List Onderwerp: [SPAM] Re: Ivy svn breaks ant-contrib svn Just a wild guess, but maybe you could use IvyAntSettings again (like your original code was), but instead of calling the execute method you can register it yourself as Reference in the Project, something like: IvyAntSettings settings = new IvyAntSettings(); settings.setXXX... getProject().addReference(settingsId, settings); Maarten - Original Message From: Stefan Bodewig [EMAIL PROTECTED] To: dev@ant.apache.org Sent: Tuesday, July 15, 2008 2:13:10 PM Subject: Re: Ivy svn breaks ant-contrib svn On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 9:23 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. OK, what can ant-contrib do if it wants to compile against Ivy 2.0.0beta2 and trunk with the same codebase? This is not straightforward, since we broke the API. Right, that's why Gump finds it 8-) Maybe you could throw in a deprecated setId() method that delegated to setSettingsId()? At least for the next beta so ant-contrib has a stable base to work from without resorting to reflection. I looked into the code to see what the id is used for. It is later used as the argument for IvyCacheFileset.setSettingsRef - this wouldn't work with a reference to the task but would require a reference to the settings, which now would exactly be what setSettingsId creates, right? 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] Disclaimer: This message contains information that may be privileged or confidential and is the property of Sogeti Nederland B.V. or its Group members. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Ivy svn breaks ant-contrib svn
On Tue, Jul 15, 2008 at 2:13 PM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 9:23 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. OK, what can ant-contrib do if it wants to compile against Ivy 2.0.0beta2 and trunk with the same codebase? This is not straightforward, since we broke the API. Right, that's why Gump finds it 8-) Maybe you could throw in a deprecated setId() method that delegated to setSettingsId()? At least for the next beta so ant-contrib has a stable base to work from without resorting to reflection. I looked into the code to see what the id is used for. It is later used as the argument for IvyCacheFileset.setSettingsRef - this wouldn't work with a reference to the task but would require a reference to the settings, which now would exactly be what setSettingsId creates, right? Yes, I think setSettingsId is the good method to call, 2.0.0-beta2 was broken in that sense. Introducing a setId method for backward compatiblity with something broken in concept doesn't sound really nice IMO. We will probably forget to remove it after, I don't like it too much. IMO antcontrib should be built either against trunk, or against beta2, but not both. But maybe others have a different opinion? Xavier Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Ivy svn breaks ant-contrib svn
On Mon, 14 Jul 2008, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Maarten Coene [EMAIL PROTECTED] wrote: I changed that recently. IvyAntSettings is now a DataType again... They should use the IvyConfigure task instead. OK, thanks. Looked straight forward so I just committed the necessary patch. Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy svn breaks ant-contrib svn
On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Maarten Coene [EMAIL PROTECTED] wrote: I changed that recently. IvyAntSettings is now a DataType again... They should use the IvyConfigure task instead. OK, thanks. Looked straight forward so I just committed the necessary patch. Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. Xavier Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Ivy svn breaks ant-contrib svn
On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Maarten Coene [EMAIL PROTECTED] wrote: I changed that recently. IvyAntSettings is now a DataType again... They should use the IvyConfigure task instead. OK, thanks. Looked straight forward so I just committed the necessary patch. Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. OK, what can ant-contrib do if it wants to compile against Ivy 2.0.0beta2 and trunk with the same codebase? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy svn breaks ant-contrib svn
On Tue, Jul 15, 2008 at 9:23 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 14 Jul 2008, Maarten Coene [EMAIL PROTECTED] wrote: I changed that recently. IvyAntSettings is now a DataType again... They should use the IvyConfigure task instead. OK, thanks. Looked straight forward so I just committed the necessary patch. Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. OK, what can ant-contrib do if it wants to compile against Ivy 2.0.0beta2 and trunk with the same codebase? This is not straightforward, since we broke the API. I guess the solution is to use java reflection API to detect if there is a setId or a setSettingsId method, and call it via reflection. Xavier Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
Re: Ivy svn breaks ant-contrib svn
On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 9:23 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 8:53 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Ant-contrib also invokes setId() on the task, which works fine with Ivy 2.0.0beta2 but fails with trunk. Could you please re-add the setid method? setId is now setSettingsId on IvyConfigure, which is more in conformance with Ant, since we are not setting the id of the task, but of the underneath datatype. OK, what can ant-contrib do if it wants to compile against Ivy 2.0.0beta2 and trunk with the same codebase? This is not straightforward, since we broke the API. Right, that's why Gump finds it 8-) Maybe you could throw in a deprecated setId() method that delegated to setSettingsId()? At least for the next beta so ant-contrib has a stable base to work from without resorting to reflection. I looked into the code to see what the id is used for. It is later used as the argument for IvyCacheFileset.setSettingsRef - this wouldn't work with a reference to the task but would require a reference to the settings, which now would exactly be what setSettingsId creates, right? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy svn breaks ant-contrib svn
Yes, I changed that recently. IvyAntSettings is now a DataType again... They should use the IvyConfigure task instead. Maarten - Original Message From: Stefan Bodewig [EMAIL PROTECTED] To: dev@ant.apache.org Sent: Monday, July 14, 2008 9:37:03 AM Subject: Ivy svn breaks ant-contrib svn Hi, just a quick note from Gump http://vmgump.apache.org/gump/public/ant-contrib/ant-contrib/gump_work/build_ant-contrib_ant-contrib.html Since I'm not familiar enough with either Ivy or ant-contrib's usage of it, I can't say who's wrong. It looks as if ant-contrib expects IvyAntSettings to extends Task. 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: Ivy svn breaks ant-contrib svn
On Mon, 14 Jul 2008, Maarten Coene [EMAIL PROTECTED] wrote: I changed that recently. IvyAntSettings is now a DataType again... They should use the IvyConfigure task instead. OK, thanks. Looked straight forward so I just committed the necessary patch. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
