James Mitchell wrote: > Unless I missed it somewhere, no one has mentioned the extra bloat in > your source distributions (if you include the binary dependencies).
James, you need the binary dependencies anyway to build the project, so what is your point? You download the source distribution with libs included or you download the source distribution without libs and ant does the lib download afterwards. The sum of required network traffic is the same. > > Oliver, I'm having a hard time understanding your point. > > I can see how one wouldn't care about disk space and bandwidth, > because you (nor I) currently pay for neither. But how much more > "simple" can building a project be then calling "ant". That's all you > should have to do to build the project. > > Please explain to me what makes it "not simple" if the ant script > automatically goes out and gets the dependencies the first time you > run the script (and never has to do it again unless a dependency is > added or changed) ?? It get's "not simple" as soon as the automatic download fails for whatever reason. I had problems in the past with maven-based builds because the attempt to download required libs ended up in corrupt jars in the local repository because ibiblio was not available and all the downloaded jars actually were http 404/500 error pages. The result is a long list of strange error messages talking about corrupt zip files and stuff like that. What you plan to do with ant is just another way to the same potential problem. I'm sure you are able to deal with problems like that. If you know the build mechanism it won't be a big deal. But there will always be users who checkout the MyFaces sources for the first time. Consider they want to get a fix before the next release is out. If automatic download does not work for them - I don't say this will happen every day, but it's a possible scenario - they are stuck. They just called ant, they don't know and don't want to know what's going on behind the scenes. What they want is a working MyFaces built from sources. I hope you got my point this time: it's the new users I care about. I don't see a reason to introduce a new potential source of failure just because others do so. So can you or anybody else please show me the problem we have at the moment with the libs in the repository which will be fixed by moving the libs to some other external location. Storage space does not matter (as far as I know subversion is a lot more efficent in storing binaries than CVS for example) - if that's the problem I'll donate a new hard disk. And "because struts and commons also do it" is no argument on it's own. So can you please show me what you are trying to fix as I'm sorry but I don't see it. Oliver > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > Yahoo: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > ----- Original Message ----- From: "Oliver Rossmueller" > <[EMAIL PROTECTED]> > To: "MyFaces Development" <[email protected]> > Sent: Friday, June 24, 2005 6:53 AM > Subject: Re: Proposal: Elimiante jar files from SVN > > >> Martin Cooper wrote: >> >>> I would strongly recommend that you not store your dependencies in the >>> SVN repo. Consider the consequences if every ASF project did the same >>> thing. There would be many dozens of copies of the exact same >>> libraries taking up space in the repo, one (or more) per project. The >>> repo would end up being clogged with binaries, many of them duplicates. >> >> >> Martin, >> >> if saving hard disk space is the main argument, than it's -1 again. Of >> course you end up with duplicates of the same jar in different projects >> in the repository, but that's not the point. The point is simplicity of >> the build process so it can be handled by any developer and not only the >> MyFaces core team. >> >>> >>> This is one reason that the ASF Java repo was created - so that there >>> is one place that libraries can be placed, so that they are available >>> to any project that needs them. This is a parallel to the Maven >>> repository at ibiblio, but neither of these require that Maven be used >>> for the builds. >>> >>> Also, as Sean points out, if you prefer not to make use of automatic >>> downloads, you are free to configure your system that way. But for >>> many, if not most, people, the automatic downloads give them a way to >>> get up and running much more quickly than a manual configuration. >> >> >> Of course I can configure anything manually, and I am also able to deal >> with problems caused by failed automatic downloads. But that's because I >> know how the build works. Consider somebody who just got the sources >> from svn. The first step then would be to check for the existence of >> build.xml and to run 'ant'. Now that first and straightforward attempt >> fails because the default ant target does not download required jars or >> the default target does download the jars but download fails for >> whatever reason. From the POV of named user what would you do? I would >> throw MyFaces to the trash can and don't have a look at it for at least >> half a year as those MyFaces guys seem to be not able to handle their >> build process so how good and stable can their software be? >> >> That's my point: ease of build for anybody. It should not be necessary >> to be an ant and subversion guru to handle the build. >> >> Oliver >> >>> >>> -- >>> Martin Cooper >>> >>> >>> On Thu, 23 Jun 2005, Oliver Rossmueller wrote: >>> >>>> -1 on that. Please don't make the build more complex than needed. Not >>>> any stuff that seems to be cool to implement should be implemented. >>>> >>>> What's your problem with having the required libs in the >>>> repository? For >>>> me there are advantages only: >>>> >>>> - one source fits it all: you check out the svn module and have >>>> everything you need to build >>>> - the libs are versioned with the code which depends on the libs >>>> - you have everything maintained in one place, the svn repository; no >>>> need for external jar repositories or stuff like that >>>> - no build is blocked because the download of a required lib is not >>>> working for whatever reason (firewalls, network failures, ...) >>>> >>>> If you ever had the html of a http 500 page as the contents of a jar >>>> file in your maven repository instead of the required jar itself you >>>> know what I'm talking about. So do not try to imitate maven just by >>>> other means but follow the KISS principle and keep it simple, please. >>>> >>>> Oliver >>>> >>>> >>>> Manfred Geiler wrote: >>>> >>>>> yes, looks good >>>>> +1 for automatic download of jars >>>>> >>>>> -Manfred >>>>> >>>>> >>>>> >>>>> 2005/6/21, Sean Schofield <[EMAIL PROTECTED]>: >>>>> >>>>> >>>>>> First off, thanks to James Mitchell (of the Struts team) who has >>>>>> been >>>>>> teaching me the wonders of svn:externals. I hope my SVN reorg will >>>>>> make him proud. :-) >>>>>> >>>>>> While James and I were discussing the Struts layout he also >>>>>> mentioned >>>>>> something interesting. They no longer keep any jar files in their >>>>>> repository. He has figured out a way to deal with the jar file >>>>>> dependencies that does *not* require Maven (ie. can be done from >>>>>> Ant.) >>>>>> >>>>>> I'm planning on doing something similar as part of the reorg. Check >>>>>> out the following steps that allow you to build struts 1.2 without >>>>>> specifying a single jar file in your properties ... >>>>>> >>>>>> $svn co >>>>>> https://svn.apache.org/repos/asf/struts/core/branches/STRUTS_1_2_BRANCH/ >>>>>> >>>>>> >>>>>> struts-1.2 >>>>>> $cd struts-1.2 >>>>>> $ant download-dependencies release >>>>>> >>>>>> Nice! I see no reason to deprive ourselves of the same cool build >>>>>> process ;-) Also, its possible to build using local jar files if >>>>>> that >>>>>> is your cup of tea (just don't run the download-dependencies target >>>>>> and specify the jar file locations in your local props file.) >>>>>> >>>>>> sean >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Oliver Rossmueller >>>> Software Engineer and IT-Consultant >>>> Hamburg, Germany >>>> http://www.rossmueller.com >>>> >>>> >> >> >> -- >> Oliver Rossmueller >> Software Engineer and IT-Consultant >> Hamburg, Germany >> http://www.rossmueller.com >> >> > > -- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com
