Martin Cooper wrote: > > > On Fri, 24 Jun 2005, Oliver Rossmueller wrote: > >> 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? > > > You don't have much patience, do you? ;-) Personally, I would look for > an answer before just throwing it in the trash, and I suspect most > people would do the same.
Well, there is the JSF RI I can get from Sun without any problems, so why would I care for fixing a broken MyFaces build if I just want to give it a try? If the first impression you get from an open-source product is a broken build what will you think? To provide convidence does look different. > > >> 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. > > > Come on, Oliver, nobody has said anything about needing to be an Ant > or SVN guru. Unless you count typing 'ant' as being an Ant guru. ;-) > > OK, so what do you do when not all your dependencies have licenses > that allow you to store them in the SVN repo? All it takes is one. > That will immediately and permanently break your nice clean "pull > everything from the repo and go" model. That's the first argument so far that makes kind of sense. But do we have this problem the moment? As far as I know that's not the case. So why are we trying to fix a problem that does not exist? Oliver > > -- > Martin Cooper > > >> 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
