Re: Users of the release4.0 branch?

[Jonathon -- Improov <jo...@improov.com>]

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" <jo...@improov.com>
> 
>> 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" <jo...@improov.com>
>>> À : <us...@ofbiz.apache.org>
>>> 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" <jo...@hotwaxmedia.com>
>>>>>> 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
>>>>>>
>>>
> 
> 

Re: Users of the release4.0 branch?

[Jacques Le Roux <ja...@les7arts.com>]

Hi Jonathon,

De : "Jonathon -- Improov" <jo...@improov.com>
> 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.

This is not my own decision but PMC anyway (or simple ML vote as we do for most things, because Apache way is not to hide things)

> 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?

Always the HR ressource pb...

> 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.

It seems that you have also an HR ressource issue :o)

>  > 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!

True, but I guess there are some reasons we do that (more work, we are not fools). Sorry I can't remember why. Jacopo (who usualy is
the person who deals the most with this aspect) or David might explain if they read this message.

> 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 .

Waiting for an answer see above...

Thanks for your ideas (reality pressure gives us a lot of ideas ;o)

Jacques

> Jonathon
>
> Jacques Le Roux wrote:
> > Jonathon
> >
> > De : "Jonathon -- Improov" <jo...@improov.com>
> >
> >> 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" <jo...@improov.com>
> >>> À : <us...@ofbiz.apache.org>
> >>> 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" <jo...@hotwaxmedia.com>
> >>>>>> 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
> >>>>>>
> >>>
> >
> >
>

Re: Users of the release4.0 branch?

[Jonathon -- Improov <jo...@improov.com>]

BJ,

Yup yup. It's either the lack of manpower on my side, or on OFBiz SVN's side. :)

Still, as I originally said, I'll be happy to do this whole seemingly complex SVN trim up. This 
particular issue is close to my heart (and I've done it umpteen times for my customized OFBiz 
instances, practiced).

However, it's not just about me having the time to do this. There will be so many OFBiz users who 
will need to get used to the sudden change.

Maybe later, when I put down the SVN move in detail in writing, including migration procedures, 
then I'll repost this.

Jonathon

BJ Freeman wrote:
> 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" <jo...@improov.com>
>>>
>>>> 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"
>>>>> <jo...@improov.com>
>>>>> À : <us...@ofbiz.apache.org>
>>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>>> 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
>>>>>>>>
>>>
>>
>>
>>
> 
> 
> 

Re: Users of the release4.0 branch?

[Jacques Le Roux <ja...@les7arts.com>]

Thanks for your support BJ :o)

Jacques

De : "BJ Freeman" <bj...@free-man.net>
> 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" <jo...@improov.com>
> >>
> >>> 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"
> >>>> <jo...@improov.com>
> >>>> À : <us...@ofbiz.apache.org>
> >>>> 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" <jo...@hotwaxmedia.com>
> >>>>>>> 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
> >>>>>>>
> >>>>
> >>
> >>
> >
> >
> >
> >
>
>

Re: Users of the release4.0 branch?

[BJ Freeman <bj...@free-man.net>]

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" <jo...@improov.com>
>>
>>> 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"
>>>> <jo...@improov.com>
>>>> À : <us...@ofbiz.apache.org>
>>>> 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" <jo...@hotwaxmedia.com>
>>>>>>> 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
>>>>>>>
>>>>
>>
>>
> 
> 
> 
>