Re: [PATCH] IVY-1436
Could you please attach your patch to the JIRA issue? Thanks! Maarten Van: Jerry Maloney gpjerrymalo...@gmail.com Aan: dev@ant.apache.org Verzonden: woensdag 28 augustus 3:37 2013 Onderwerp: [PATCH] IVY-1436 This patch fixes the issue I described in https://issues.apache.org/jira/browse/IVY-1436 . Thanks, Jerry Maloney - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Easyant - Plugin conflict management
My answers below 2013/8/26 Dridi Boukelmoune dridi.boukelmo...@zenika.com Point 2 : Even if there is no much activity, i suggest to keep backward compatibility fine for me. Not necessary from my point of view. My only advice is to avoid legacy (or technical debt ;) at such early time. I was suggesting to keep backward compatibility mainly because easyant is build by easyant :). Though we need older plugins to build the new easyant and vice et versa. Point 3 : By two steps i meant running a global resolve (for all plugins and buildtypes including transitive ones). And then have a second class invoked to perform individual import of ant build file by picking them from the ResolveReport. ok I see. This make totally sense. This is where I'm lost. Actually the whole issue of dependencies conflicts between plugins. Here is the behavior I think I've observed with Maven: - maven resolves project dependencies and does a shitty job at conflicts resolution - maven resolves plugins dependencies one by one and downloads them lazily - each plugin is executed with its own classloader, and doesn't care about other plugins dependencies - I can get a dozen versions of the infamous[1] plexus-utils in a single build My point is, given proper isolation, is it a real issue to have different plugins depending on different versions of the same modules ? The main point is to avoid having dozen version of jars :). But we also have a internal limitation, ant doesn't load a buildfile two times. So if we have many plugins relying on abstract ones, abstract ones must be uniquely resolved. -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/
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: [PATCH] IVY-1436
Thanks, Maarten. I've attached it and the other patch I wrote (about the URLResolver unit test) to https://issues.apache.org/jira/browse/IVY-1436. Jerry -- View this message in context: http://ant.1045680.n5.nabble.com/PATCH-IVY-1436-tp5714410p5714414.html Sent from the Ant - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Easyant - Plugin conflict management
On Wed, Aug 28, 2013 at 11:19 AM, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: My answers below 2013/8/26 Dridi Boukelmoune dridi.boukelmo...@zenika.com Point 2 : Even if there is no much activity, i suggest to keep backward compatibility fine for me. Not necessary from my point of view. My only advice is to avoid legacy (or technical debt ;) at such early time. I was suggesting to keep backward compatibility mainly because easyant is build by easyant :). Though we need older plugins to build the new easyant and vice et versa. Forgot about that. Point 3 : By two steps i meant running a global resolve (for all plugins and buildtypes including transitive ones). And then have a second class invoked to perform individual import of ant build file by picking them from the ResolveReport. ok I see. This make totally sense. This is where I'm lost. Actually the whole issue of dependencies conflicts between plugins. Here is the behavior I think I've observed with Maven: - maven resolves project dependencies and does a shitty job at conflicts resolution - maven resolves plugins dependencies one by one and downloads them lazily - each plugin is executed with its own classloader, and doesn't care about other plugins dependencies - I can get a dozen versions of the infamous[1] plexus-utils in a single build My point is, given proper isolation, is it a real issue to have different plugins depending on different versions of the same modules ? The main point is to avoid having dozen version of jars :). I agree on the fact this can easily become a classloader hell, but my concern is the dependency hell. Again, I have no answer to your question, I'm just asking more questions :) But we also have a internal limitation, ant doesn't load a buildfile two times. So if we have many plugins relying on abstract ones, abstract ones must be uniquely resolved. I think I lack context to understand this one. -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/ Best Regards, Dridi - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [PATCH] fixing unit tests related to URLResolver
Actually the right way is to submit a report through Ivy's issue tracker. Thanks, Matt On Aug 27, 2013 8:35 PM, Jerry Maloney gpjerrymalo...@gmail.com wrote: Hi, I was doing some work on https://issues.apache.org/jira/browse/IVY-1436 and I think I found some unit tests that are broken due to some changed URLs and structure at http://repo1.maven.org/ I haven't submitted to this code base before; could someone in the know please let me know if this is still the right way? Thanks, Jerry Maloney - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
