Thanks for your support BJ :o) Jacques
De : "BJ Freeman" <[EMAIL PROTECTED]> > Jonathon: > I believe the original context was the manpower to do this. > it sounds like you experiencing the same problem and want to shift it to > the ofbiz svn. > Still though it is a manpower problem even if the ideas put forth are > good ones. > > > Jonathon -- Improov sent the following on 10/1/2007 11:24 PM: > > Jacques, > > > >>> Our script will simply untar the tarball, and deploy the library files > >>> automatically into the correct locations in the OFBiz file structure, > > plus > >>> verify the library files. You can easily imagine how SIMPLE this > > script is! > >> > >> Yes, we should have a windows batch usint zip format (or like) too (7zip > >> maybe a good tool for that ) > > > > 7zip is great, strong compressor. > > > >> But we can't hide the fact that this will need more work on the server > >> side... It's easier to have all in one place. > > > > Easier, yes, I agree. Just like it's easier to put everything on the > > desktop, until we reach a point where we can't find anything on it. > > Maybe OFBiz hasn't reached that point yet? If so, there's really no > > point cleaning up the SVN now. > > > > But then, some people might like to download a compact OFBiz without > > 3rd-party binaries, and then to download those 35+MB binaries via a > > resumable FTP connection. You think we can provide that? > > > > Yes, it's true that each OFBiz SVN checkout takes merely 20-30 minutes, > > I have broadband. However, the number of clients complaining about SVN > > checkouts is rising! Or maybe I'm just getting more and more clients who > > don't like or don't do SVN. I keep having to send them a tarball of a > > checked out OFBiz (SVN workspace, with .svn folders), so they can do > > updates (smaller than checkout from scratch). I'm feeling like an FTP > > server. > > > >> And even this means updating more than binaries files with the version > > number > >> in its name (LICENSE in root, when adding NOTICE, > >> http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz). > > > > Documentation of which libraries go where in the OFBiz structure will > > always be needed. If the version numbers of each library is clearly > > documented in a text file, and the text file committed, we won't ever > > need to change the library's file names to reflect the version number! > > > > The MD5 manifest of all OFBiz's libraries can also serve as > > documentation of which libraries go where in the OFBiz structure. Very > > convenient. > > > > A separate text file, conveniently copied and modified from the MD5 > > manifest, will serve as documentation of the version and source of the > > libraries, much like at > > http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz . > > > > Jonathon > > > > Jacques Le Roux wrote: > >> Jonathon > >> > >> De : "Jonathon -- Improov" <[EMAIL PROTECTED]> > >> > >>> JLR, > >>> > >>> > If it's only a matter of providing the "apt-get" like ant script, > >>> are you ready to do so ? > >>> > >>> Yes, but not really like apt-get. Our script won't go to the internet > >>> and grab library files such > >>> as Log4J, FOP, etc. > >>> > >>> Have a tarball containing all of the library files. And label it as > >>> being used from which > >>> revision, the "supported-from revision" number. Folks using OFBiz > >>> revisions after that > >>> "supported-from revision" will download that tarball of library > >>> files. This downloading will not > >>> go through SVN, will not put any load on SVN server. It'll just put a > >>> load on an FTP server, > >>> that's all. And this FTP server can have mirrors. > >>> > >>> That'll keep your SVN server lighter and trimmer, containing only > >>> files that it needs to track. > >>> Files for which changes are actually trackable. You can't track > >>> changes to compiled binaries! > >>> > >>> Consider another benefit here. Suppose the 35-40MB of library files > >>> (binaries) is simply too large > >>> for some to download. You can even let users download individuals > >>> files (jars) manually. There'll > >>> be a single md5sum script that will check that all needed library > >>> files are present and of correct > >>> version. > >>> > >>> Our script will simply untar the tarball, and deploy the library > >>> files automatically into the > >>> correct locations in the OFBiz file structure, plus verify the > >>> library files. You can easily > >>> imagine how SIMPLE this script is! > >> > >> Yes, we should have a windows batch usint zip format (or like) too > >> (7zip maybe a good tool for that ) > >> > >>> > Then Maybe it could be possible to have a repository duplicate > >>> (symlinked) > >>> > without any jars (or other such binaries, images and such being > >>> kept) in it. > >>> > >>> As a migration effort, possibly? Ultimately, you may want to make > >>> your SVN repos clean and trim. > >> > >> The idea is to keep both possiblity, but let's see what other think... > >> > >>> In any case, you still need to package the library files into a > >>> separate download, a download > >>> served via FTP. Much like the "external download for Eclipse-related > >>> files" suggested by Jacopo. > >>> (By the way, I really liked Jacopo's organization work with the > >>> /runtime folder.) > >> > >> Yes I see, for the Netbeans project too. > >> > >>> Binary images, I think are fine. The point is to avoid keeping a > >>> whopping 35+MB of binaries > >>> (compiled codes) in SVN. Files for which we cannot track changes. > >>> Files that have no business > >>> residing in a version-control system! > >>> > >>> Still, the symlinked duplicate may work, I think. Either as an > >>> interim measure, or as a permanent > >>> one if some folks somehow want to continue using an SVN with the > >>> 35+MB of binaries stuffed in. > >>> > >>> > Mmm... I guess we will not only need a client script but also a > >>> server script > >>> > to create new symlinks when needed (when files are added thru svn) > >>> > >>> Then that will add complexities! I still believe that ultimately, you > >>> may want to make your SVN > >>> repos clean and trim, and remove files that really have no business > >>> residing in a version-control > >>> system. > >> > >> But we can't hide the fact that this will need more work on the server > >> side... It's easier to have all in one place. And even this > >> means updating more than binaries files with the version number in its > >> name (LICENSE in root, when adding NOTICE, > >> http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz). > >> This maybe seems a light job but a lot of light jobs finish by > >> being not so light... Hence maybe David's previous answer, he has a > >> large experience on this ... > >> > >> Jacques > >> > >>> Jonathon > >>> > >>> Jacques Le Roux wrote: > >>>> Jonathon, > >>>> > >>>> If it's only a matter of providing the "apt-get" like ant script, > >>>> are you ready to do so ? Then Maybe it could be possible to > >> have a > >>>> repository duplicate (symlinked) without any jars (or other such > >>>> binaries, images and such being kept) in it. Also I'm not sure > >>>> that Apache infrastruture team will agree to do so, or if it's our > >>>> own responsibility to do it (being > >>>> allowed by infra). > >>>> > >>>> Mmm... I guess we will not only need a client script but also a > >>>> server script to create new symlinks when needed (when files are > >>>> added thru svn) > >>>> > >>>> What do you think folks ? > >>>> > >>>> Jacques > >>>> > >>>> ----- Message d'origine ----- De : "Jonathon -- Improov" > >>>> <[EMAIL PROTECTED]> > >>>> À : <[email protected]> > >>>> Envoyé : samedi 15 septembre 2007 17:46 > >>>> Objet : Re: Users of the release4.0 branch? > >>>> > >>>> > >>>>>> You either manually manage it > >>>>> There's nothing for users or downloaders to manage. If there's a > >>>>> problem with doing a complete SVN > >>>>> checkout, there's nothing to manage in the first place! No OFBiz > >>>>> SVN workspace to begin with! > >>>>> > >>>>> It's also tough for someone who has somehow lost his OFBiz SVN > >>>>> workspace, and has to SVN co the > >>>>> whole thing again. > >>>>> > >>>>> > or let a system do it. > >>>>> > >>>>> What kind of system will: > >>>>> > >>>>> 1. Speed up SVN over http (before it times out), OR > >>>>> > >>>>> 2. Prevent a SVN co from being disrupted, OR > >>>>> > >>>>> 3. Resume a disrupted SVN co? > >>>>> > >>>>> I'd like to know. That kind of system will really help a lot! > >>>>> > >>>>> > Manual things cause huge problems for complex systems. > >>>>> > >>>>> The deployment script (that deploys binaries into OFBiz file > >>>>> structure) isn't complex at all. It's > >>>>> nowhere near Redhat's RPM, Debian's apt-get, etc! > >>>>> > >>>>> As for verifying that OFBiz workspace has all necessary binaries, > >>>>> the single MD5 manifest can > >>>>> easily be processed with a single click (or even as part of the > >>>>> deployment script). And that will > >>>>> tell the developer exactly which binaries are missing or different > >>>>> from expected. > >>>>> > >>>>> So, the process for a new user is: > >>>>> > >>>>> 1. Download SVN. > >>>>> > >>>>> 2. SVN checkout OFBiz. > >>>>> > >>>>> 3. Download libraries (binaries). > >>>>> > >>>>> 4. Click to install libraries (and to verify). > >>>>> > >>>>> 5. Configure OFBiz. > >>>>> > >>>>> 6. Install OFBiz (run-install) > >>>>> > >>>>> 7. Start OFBiz. > >>>>> > >>>>> Note how only 2 of the 7 steps are extra. > >>>>> > >>>>> Currently, many users (including some of my clients) can't even get > >>>>> past step 2! Many won't even > >>>>> consider step 1, to begin with. > >>>>> > >>>>> > The extra effort require to normally do it is a small issue, the > >>>>> huge time > >>>>> > wasting caused by small errors in these manual processes makes > >>>>> them worth all > >>>>> > the effort and downside necessary to avoid them. > >>>>> > >>>>> Well, apt-get isn't so difficult to use, right? And the > >>>>> deploy/clean scripts I am talking about is > >>>>> nowhere near as difficult to develop as apt-get! > >>>>> > >>>>> > I totally agree with David, really easier for us. > >>>>> > >>>>> But have you tried doing things in another way, so you know for > >>>>> sure that other way doesn't work > >>>>> for you? > >>>>> > >>>>> Anyway, if you're happy with the current setup, I rest my case. > >>>>> > >>>>> Jonathon > >>>>> > >>>>> Jacques Le Roux wrote: > >>>>>> I totally agree with David, really easier for us. > >>>>>> > >>>>>> Jacques > >>>>>> > >>>>>> De : "David E Jones" <[EMAIL PROTECTED]> > >>>>>>> Jonathon -- Improov wrote: > >>>>>>>> For some time now, I had been suggesting that we DO NOT include the > >>>>>>>> 35+MB binaries in the SVN. SVN is used to track CHANGES to > >>>>>>>> files. Since > >>>>>>>> we cannot change binaries (only source codes), binaries have no > >>>>>>>> business > >>>>>>>> residing in SVN. In fact, a guy who claimed he knows SVN, but > >>>>>>>> who later > >>>>>>>> proceeded to check in version after version of his project > >>>>>>>> binaries, got > >>>>>>>> fired. Yeah, it's that scary to see someone use version control > >>>>>>>> app to > >>>>>>>> maintain software binaries (pic binaries are fine). > >>>>>>>> > >>>>>>>> There's this argument put forth that "it's more convenient if we > >>>>>>>> bundle > >>>>>>>> the binaries in, so that new users can get up to speed quickly". > >>>>>>>> However, new users who bother to use SVN should already be quite > >>>>>>>> technically inclined, and will be able to run a script to "install" > >>>>>>>> 3rd-party binaries into a deployment. > >>>>>>>> > >>>>>>>> As it is now, with the 35+MB (or more?) binaries in SVN, it > >>>>>>>> simply makes > >>>>>>>> it somewhat harder even for experienced SVN or OFBiz users to > >>>>>>>> download > >>>>>>>> OFBiz. > >>>>>>> This really isn't so much for new users, it's for all users of > >>>>>>> OFBiz, and IMO mostly for the regular and highly involved > >> users. > >>>>>> You either manually manage it or let a system do it. There is no > >>>>>> way, period, I'd personally go for this because it would > >> cause > >>>>>> significant problems without any real upside for 99% of OFBiz > >>>>>> users and developers, most importantly the contributing > >> developers > >>>>>> that SVN is meant for. > >>>>>>> Manual things cause huge problems for complex systems. The extra > >>>>>>> effort require to normally do it is a small issue, the huge > >>>> time > >>>>>> wasting caused by small errors in these manual processes makes > >>>>>> them worth all the effort and downside necessary to avoid them. > >>>>>>> -David > >>>>>>> > >>>> > >> > >> > > > > > > > > > >
