Maven plugins was: [httpclient] Jars in the repository
Here is the list of updated core plugins since maven 1.0.2 was released : Maven Ant Plugin1.9 2005-04-09 Maven Dashboard Plugin 1.7 2005-03-05 Maven Clover Plugin 1.8 2005-03-04 Maven Hibernate Plug-in 1.3 2005-02-10 Maven Site Plugin 1.6 2005-01-18 Maven Changelog Plugin 1.7.2 2005-01-08 Maven Gump Plug-in 2.0 2005-01-08 Maven EAR Plugin1.6.1 2004-12-10 Arnaud -Message d'origine- De : Arnaud HERITIER [mailto:[EMAIL PROTECTED] Envoyé : dimanche 10 avril 2005 15:45 À : 'Jakarta Commons Developers List' Objet : RE: [httpclient] Jars in the repository Hi Dion, I just published the maven-plugins site. You'll find the list of plugins released after maven 1.0.2 (7th December) in this page in some hours (depending of the sync between www.apache.org and people.apache.org): http://maven.apache.org/reference/plugins/multichanges-report.html We didn't yet publish a new maven release with this new plugins set. I think it'll be done with maven 1.1 Arnaud -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 10 avril 2005 12:27 À : Jakarta Commons Developers List Objet : Re: [httpclient] Jars in the repository Arnaud, is there an up to date list of released plugins for maven 1.0.2? Maybe a bundle with the latest of each released since the 1.0.2 release? On Apr 10, 2005 7:58 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi guys, [SNIP] I'll ask the maintainer of the plugin, if it is possible to get an official release of it. It's done. You can download it (maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.9) and use it (maven ant). From now, you can use external properties to configure the generated ant script (to override dependencies for example) : http://maven.apache.org/reference/plugins/ant/ant-settings.html If you already have an handwritten ant script, be careful to use the property 'maven.ant.generatebuild.file' to change the name of the generated one (http://maven.apache.org/reference/plugins/ant/properties.html) We hope that this new release will help you. Do not hesitate to open issues if needed : http://jira.codehaus.org/browse/MPANT Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Jars in the repository
Hi guys, [SNIP] I'll ask the maintainer of the plugin, if it is possible to get an official release of it. It's done. You can download it (maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.9) and use it (maven ant). From now, you can use external properties to configure the generated ant script (to override dependencies for example) : http://maven.apache.org/reference/plugins/ant/ant-settings.html If you already have an handwritten ant script, be careful to use the property 'maven.ant.generatebuild.file' to change the name of the generated one (http://maven.apache.org/reference/plugins/ant/properties.html) We hope that this new release will help you. Do not hesitate to open issues if needed : http://jira.codehaus.org/browse/MPANT Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Arnaud, is there an up to date list of released plugins for maven 1.0.2? Maybe a bundle with the latest of each released since the 1.0.2 release? On Apr 10, 2005 7:58 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi guys, [SNIP] I'll ask the maintainer of the plugin, if it is possible to get an official release of it. It's done. You can download it (maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.9) and use it (maven ant). From now, you can use external properties to configure the generated ant script (to override dependencies for example) : http://maven.apache.org/reference/plugins/ant/ant-settings.html If you already have an handwritten ant script, be careful to use the property 'maven.ant.generatebuild.file' to change the name of the generated one (http://maven.apache.org/reference/plugins/ant/properties.html) We hope that this new release will help you. Do not hesitate to open issues if needed : http://jira.codehaus.org/browse/MPANT Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [httpclient] Jars in the repository
Hi Dion, I just published the maven-plugins site. You'll find the list of plugins released after maven 1.0.2 (7th December) in this page in some hours (depending of the sync between www.apache.org and people.apache.org): http://maven.apache.org/reference/plugins/multichanges-report.html We didn't yet publish a new maven release with this new plugins set. I think it'll be done with maven 1.1 Arnaud -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 10 avril 2005 12:27 À : Jakarta Commons Developers List Objet : Re: [httpclient] Jars in the repository Arnaud, is there an up to date list of released plugins for maven 1.0.2? Maybe a bundle with the latest of each released since the 1.0.2 release? On Apr 10, 2005 7:58 PM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi guys, [SNIP] I'll ask the maintainer of the plugin, if it is possible to get an official release of it. It's done. You can download it (maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.9) and use it (maven ant). From now, you can use external properties to configure the generated ant script (to override dependencies for example) : http://maven.apache.org/reference/plugins/ant/ant-settings.html If you already have an handwritten ant script, be careful to use the property 'maven.ant.generatebuild.file' to change the name of the generated one (http://maven.apache.org/reference/plugins/ant/properties.html) We hope that this new release will help you. Do not hesitate to open issues if needed : http://jira.codehaus.org/browse/MPANT Cheers, Arnaud - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ - 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: [httpclient] Jars in the repository
Ortwin Glück wrote: Nobody needs Ant when there is Maven. Ant is legacy. Lots of people, including me, disagree with this. Lots of people, including me, find maven a pain to work with. Ant support needs to be maintained Its also the case that not all commons projects use maven for everything. On [collections] I use maven for the website, but recommend and fully maintain ant for building. It would simply not be practical to attempt to do some of the things I do with ant in maven. Maven is not up to the task. My point is that simply because something new exists, does not necessarily mean that it is better or should be used for everything. IMHO, maven is great at building websites, and lousy at building jars and distributions (in the way I want them to be built). For httpclient, I don't mind if you use the maven ant plugin, or you hand code the ant script (as collections does). Just don't store the jars in the SVN. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Martin Cooper wrote: Let's suppose for a minute that all Commons components stored their dependencies in SVN. And let's also suppose that they all required Commons Logging. We would have almost 90 copies of Commons Logging taking up space in the SVN repository. Even if only half of them use Commons Logging, that's still 45 copies. What's more, someone who checks out all of Commons is going to get all those copies of all those components taking up all their disk space, when all they really need is one copy of each. I don't know about you, but that seems like a really bad idea to me, and it's not going to make people happy when they discover they lost half their disk to dozens of copies of the same thing. -- Martin Cooper Martin, I agree that having several copies of the supposed same library can be painful for someone who loves order, piece and happiness. Personally I don't have a problem with those copies as they are all managed by someone else and I don't need to worry about them. Space is not an issue. Java code is small (Commons Logging is 31KB) and hard drives are cheap. What you are talking about is just a matter of taste. Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Mark, You are making some interesting points. First, I hear that ibiblio is supposed to be *stable*. That is good to hear (any guarantees about this, btw?). So this eliminates my reasoning and I am happy to remove the deps from SVN. Second, I understand that using Ant or Maven is a matter of personal preference. While Maven may be difficult to use in some projects it does a perfect job for HttpClient. People like Oleg seem to find Maven more difficult than Ant, which I can understand given the sheer zoo of plugins available for it. Personally I have gotten very familiar with Maven and have used and liked it since. You mentioned the maven ant goal. I had never tried it before and I just gave it a spin. The result is not really usable though. The build.xml starts off with all kind of properties that contain local path names and there is no property file tag before those definitions! Checking in such a build.xml would not help anybody. Dennis mentioned a patch for the ant plugin. As long as it is not in the standard Maven distribution this is no option either. Oleg, for the moment I take the freedom to veto against including dependency management into the build.xml, because it can not be done automatically. I am happy to provide more xdocs on how to deal with Maven if necessary (just referring to the right places in the Maven docs) and try my best to be a good replacement for Dion. I am convinced though, that it is right to remove the deps from SVN. And, yes I also think time is better spent on the new architecture. I will Mavenize the new code base as well, of course. I hope this serves everybody. Ortwin Glück Mark Diggory wrote: Martin Cooper wrote: On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. First, its important to point out that the ASF and Maven jar repositories (http://www.ibiblio.org/maven and http://apache_mirror/dist/java-repository) represent a stable tool for the development community to resolve dependencies against, ibiblio and ASF mirror servers are certainly stable enough to maintain this. If your a project developer you have to be more intelligent than your users, its important that you know how to manage your dependencies appropriately. The SRC/BIN distributions of your project are the appropriate places to include these dependencies, not the CMS. Those who make points on the list about replication of dependencies in the repo are correct in their argument, this is why we don't recommend it. I think you'll find the ant scripts generated by maven are reliable and not stupid at all in resolving this issue. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. Its there to provide the same functionality for developers who prefer to work directly with Ant and not Maven. Yes, its a duplication of the maven project xml. But you can regenerate it at any time using the 'maven ant' goal. Thus, you do not have to maintain both an ant build.xml and a project.xml. The ant build.xml is a derivative product of Maven that you store in your svn project (instead of megabytes of dependency jars). I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. As I said above, this is already is available in Maven, you don't need to write anything. Just call maven ant anytime you've altered the project.xml and commit the two together. Any error in our group have been minimal. Ant may be legacy, but Ant and Maven have a good relationship and incredibly, much of what Maven does is actually based on Ant Tasks. Ant is by no means past is prime. The entire rest of jakarta commons (among many other apache projects) have relied on this dualistic model without complaint. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) I think it totally defeats the general policy of external dependency resolution to allow jars into svn just because you want them to show up in your lib dir. -My $0.02 Mark Diggory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --
Re: [httpclient] Jars in the repository
Ortwin Glück [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Mark, You mentioned the maven ant goal. I had never tried it before and I just gave it a spin. The result is not really usable though. The build.xml starts off with all kind of properties that contain local path names and there is no property file tag before those definitions! Checking in such a build.xml would not help anybody. Dennis mentioned a patch for the ant plugin. As long as it is not in the standard Maven distribution this is no option either. As of Maven 1.0, the plugins have releases independent of the Maven core. To patch the ant plugin, you simply need to update that plugin. This can easily be accomplished by executing the following maven command: maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.8.1 Brent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Brent Worden wrote: Ortwin Glück [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Mark, You mentioned the maven ant goal. I had never tried it before and I just gave it a spin. The result is not really usable though. The build.xml starts off with all kind of properties that contain local path names and there is no property file tag before those definitions! Checking in such a build.xml would not help anybody. Dennis mentioned a patch for the ant plugin. As long as it is not in the standard Maven distribution this is no option either. As of Maven 1.0, the plugins have releases independent of the Maven core. To patch the ant plugin, you simply need to update that plugin. This can easily be accomplished by executing the following maven command: maven plugin:download -DartifactId=maven-ant-plugin -DgroupId=maven -Dversion=1.8.1 Brent Actually that needs to be this command to get the patched version: maven plugin:download -Dmaven.repo.remote=http://cvs.apache.org/repository -DgroupId=maven -DartifactId=maven-ant-plugin -Dversion=SNAPSHOT I'll ask the maintainer of the plugin, if it is possible to get an official release of it. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient] Jars in the repository
Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
James, we keep those dependencies in the repository to make them easily available. So users that want to check out and compile HttpClient don't have to worry about getting them from somewhere. Yes, there is Maven. That's fine as long as it works, but we do not like to be dependent on the availability of the Maven remote repository. I figure the JAR names should reflect the actual version of the component, however. James, could you point me to any ASF document that regulates storage of dependencies in the repository, please? TIA Ortwin Glck, HttpClient project James Mitchell wrote: Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. -- _ NOSE applied intelligence ag ortwin glck [www] http://www.nose.ch software engineer hardturmstrasse 171 [pgp id] 0x81CF3416 8005 zrich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
James, could you point me to any ASF document that regulates storage of dependencies in the repository, please? There may or may not be such a document. I'm not really interested in trying to be the binary police. I just noticed it while adding that project into my latest Eclipse development environment. we keep those dependencies in the repository to make them easily available. So users that want to check out and compile HttpClient don't have to worry about getting them from somewhere. I don't really understand what you are saying here. How can someone be smart enough to either download a source distribution or checkout the project via svn, but too dumb or lazy to just download the dependent jars seperately. Sorry, that just doesn't make a lot of sense to me. Yes, there is Maven. That's fine as long as it works, but we do not like to be dependent on the availability of the Maven remote repository. You don't need Maven to use jars on ibiblio (or any one of the other repositories). In fact, I just modified the Ant build script that builds the Struts 1.2.x nightlies. The existing build.xml requires you to download and setup a build.properties that points to all the dependencies. For me, it is a waste of my time. Ant should be smart enough to do it for me. So that's what I did: http://svn.apache.org/viewcvs.cgi/struts/core/branches/STRUTS_1_2_BRANCH/build.xml?rev=160185view=markup Scroll down to the download-dependencies target. I figure the JAR names should reflect the actual version of the component, however. I agree. TIA Ortwin Glck, HttpClient project If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. If not, then sorry to bother you. Have a good one. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] James Mitchell wrote: Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
James Mitchell wrote: There may or may not be such a document. I'm not really interested in trying to be the binary police. I just noticed it while adding that project into my latest Eclipse development environment. Asking questions is not a crime, fortunately. Not even in any US state so far :-) If you come over one, just let me know. I don't really understand what you are saying here. How can someone be smart enough to either download a source distribution or checkout the project via svn, but too dumb or lazy to just download the dependent jars seperately. Sorry, that just doesn't make a lot of sense to me. It's not about smartness. But what are you gonna do if the dependend file on ibilio is removed or ibiblio is having a downtime? Your stuffed unless you have a local copy. You don't need Maven to use jars on ibiblio (or any one of the other repositories). In fact, I just modified the Ant build script that builds the Struts 1.2.x nightlies. The existing build.xml requires you to download and setup a build.properties that points to all the dependencies. For me, it is a waste of my time. Ant should be smart enough to do it for me. I don't see the point. Maven can do that already perfectly. Copying the knowledge about deps to the build.xml I consider a pitfal. We have all learned in kindergarten to have knowledge in *one* place, haven't we :-0 I figure the JAR names should reflect the actual version of the component, however. I agree. Kind regards Ortwin Glck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
On Tue, Apr 05, 2005 at 11:46:49AM -0400, James Mitchell wrote: James, could you point me to any ASF document that regulates storage of dependencies in the repository, please? There may or may not be such a document. I'm not really interested in trying to be the binary police. I just noticed it while adding that project into my latest Eclipse development environment. James, Please correct me if I am wrong there's nothing wrong about keeping a copy of ASLv2 licenced library in the source code repository. It's just sloppy. snip If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg If not, then sorry to bother you. Have a good one. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] James Mitchell wrote: Sorry if this has already been brought up, but I noticed this a while back. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/lib/ I was under the impression that we are not supposed to keep this kind of stuff in svnbut I could be wrong. - 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: [httpclient] Jars in the repository
Oleg Kalnichevski wrote: If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg Is that *necessary* for GUMP or anything else, Oleg? If not then I prefer not to have that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg On Tue, Apr 05, 2005 at 06:25:42PM +0200, Ortwin Gl?ck wrote: Oleg Kalnichevski wrote: If you would like me to setup the same download-dependencies for httpclient, I'd be happy to help. The example above uses ibiblio, but you can use any url. We would very much appreciate it Cheers, Oleg Is that *necessary* for GUMP or anything else, Oleg? If not then I prefer not to have that. - 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: [httpclient] Jars in the repository
Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
On Tue, 2005-04-05 at 18:57 +0200, Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. Explicit dependency management for one (for those who prefer Ant to Maven, like myself). 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. I see it differently, but as far as I am concerned this whole thing is a non-issue. Should James decide to submit a patch, I _personally_ will be quite happy to vote +1 for it. At the same time, I'll have no problems of what so ever to move on, should you veto it with -1. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. [quietly and humbly] I do. For such a simple-minded person like me, every Maven deployment should come with Dion included. [ducking and hiding] Anyways, I would rather see all this time and efforts spent on Jakarta Http(Client) API redesign Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Ortwin Glück wrote: Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. The Maven Ant Plugin makes it easy to create an Ant build script from a project.xml file. I made a patch for it to solve a problem [1] that Craig had, that is somewhat related to this issue. A released version of the plugin is not yet available, but a SNAPSHOT version (1.9-SNAPSHOT) is available. The patch makes it possible to have local copies of select jar-files. All you need to do is create a build.properties file of your own and point it to the your local copies of jar-files. If you don't supply a build.properties file the jar-files will be downloaded from ibiblio or whatever repository you have configured Maven to use. I am not sure that this will work for httpclient, but it is a way to benefit from both Ant and Maven without the need to define dependencies twice. Installation instructions for the SNAPSHOT version of the Ant plugin are available [2] in the JIRA issue. [1] http://jira.codehaus.org/browse/MPANT-20 [2] http://jira.codehaus.org/browse/MPANT-20#action_28915 -- Dennis Lundberg 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) - 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: [httpclient] Jars in the repository
On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: Odi, I have not looked at the proposed solution, so I may be wrong here, but I think it _should_ simply prepopulate the HTTPCLIENT_HOME\lib from an external repository (such as ibiblio). If it is indeed the case I personally see no problem with removing dependencies from SVN. I will not insist, though Oleg Yes, that's what it does. Maybe that I am missing something, but I have no idea what should be the benefit of that. Let's suppose for a minute that all Commons components stored their dependencies in SVN. And let's also suppose that they all required Commons Logging. We would have almost 90 copies of Commons Logging taking up space in the SVN repository. Even if only half of them use Commons Logging, that's still 45 copies. What's more, someone who checks out all of Commons is going to get all those copies of all those components taking up all their disk space, when all they really need is one copy of each. I don't know about you, but that seems like a really bad idea to me, and it's not going to make people happy when they discover they lost half their disk to dozens of copies of the same thing. -- Martin Cooper 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) - 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: [httpclient] Jars in the repository
Martin Cooper wrote: On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. First, its important to point out that the ASF and Maven jar repositories (http://www.ibiblio.org/maven and http://apache_mirror/dist/java-repository) represent a stable tool for the development community to resolve dependencies against, ibiblio and ASF mirror servers are certainly stable enough to maintain this. If your a project developer you have to be more intelligent than your users, its important that you know how to manage your dependencies appropriately. The SRC/BIN distributions of your project are the appropriate places to include these dependencies, not the CMS. Those who make points on the list about replication of dependencies in the repo are correct in their argument, this is why we don't recommend it. I think you'll find the ant scripts generated by maven are reliable and not stupid at all in resolving this issue. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. Its there to provide the same functionality for developers who prefer to work directly with Ant and not Maven. Yes, its a duplication of the maven project xml. But you can regenerate it at any time using the 'maven ant' goal. Thus, you do not have to maintain both an ant build.xml and a project.xml. The ant build.xml is a derivative product of Maven that you store in your svn project (instead of megabytes of dependency jars). I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. As I said above, this is already is available in Maven, you don't need to write anything. Just call maven ant anytime you've altered the project.xml and commit the two together. Any error in our group have been minimal. Ant may be legacy, but Ant and Maven have a good relationship and incredibly, much of what Maven does is actually based on Ant Tasks. Ant is by no means past is prime. The entire rest of jakarta commons (among many other apache projects) have relied on this dualistic model without complaint. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) I think it totally defeats the general policy of external dependency resolution to allow jars into svn just because you want them to show up in your lib dir. -My $0.02 Mark Diggory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Jars in the repository
Martin Cooper wrote: On Apr 5, 2005 9:57 AM, Ortwin Glück [EMAIL PROTECTED] wrote: Oleg Kalnichevski wrote: 1. The libs are in the repo for a *reason*: availability and convenience. If you remove them we loose this availability and convenience. Replacing them with a stupid download script makes thinks worse, not better. First, its important to point out that the ASF and Maven jar repositories (http://www.ibiblio.org/maven and http://apache_mirror/dist/java-repository) represent a stable tool for the development community to resolve dependencies against, ibiblio and ASF mirror servers are certainly stable enough to maintain this. If your a project developer you have to be more intelligent than your users, its important that you know how to manage your dependencies appropriately. The SRC/BIN distributions of your project are the appropriate places to include these dependencies, not the CMS. Those who make points on the list about replication of dependencies in the repo are correct in their argument, this is why we don't recommend it. I think you'll find the ant scripts generated by maven are reliable and not stupid at all in resolving this issue. 2. We don't need an additional Ant target to download deps. It duplicates knowledge from the project.xml. Its there to provide the same functionality for developers who prefer to work directly with Ant and not Maven. Yes, its a duplication of the maven project xml. But you can regenerate it at any time using the 'maven ant' goal. Thus, you do not have to maintain both an ant build.xml and a project.xml. The ant build.xml is a derivative product of Maven that you store in your svn project (instead of megabytes of dependency jars). I don't want to maintain knowledge twice. This is error prone. Remember we had out-of-date docs regarding deps recently? Maven can download the deps that are listed in project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You could write a Maven goal to generate the Ant script from the project.xml. But this is stupid as can be, isn't it? As I said, all we need is Maven, not Ant. As I said above, this is already is available in Maven, you don't need to write anything. Just call maven ant anytime you've altered the project.xml and commit the two together. Any error in our group have been minimal. Ant may be legacy, but Ant and Maven have a good relationship and incredibly, much of what Maven does is actually based on Ant Tasks. Ant is by no means past is prime. The entire rest of jakarta commons (among many other apache projects) have relied on this dualistic model without complaint. 3. If anybody of ASF has a problem with the libs being in the repo, we can remove them today. Fine with me. There is no absolute need they are there. (If you though they need to be there because your IDE requires them in the project directory, you are wrong: Just look at Maven's eclipse goal.) I think it totally defeats the general policy of external dependency resolution to allow jars into svn just because you want them to show up in your lib dir. -My $0.02 Mark Diggory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
