You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by David E Jones <jo...@hotwaxmedia.com> on 2007/09/14 09:50:14 UTC
Users of the release4.0 branch?
It has been nearly 5 months since we created the release4.0 branch (late April). The hope for these release branches is that they will stabilize within about 3 months and be ready for an initial binary release. In order for this to happen effectively each branch needs a reasonably sized subset of the OFBiz community doing real-world work based on it. So...
1. Are there any users of the release4.0 branch with projects in production or moving in that direction?
2. For anyone in that group, could you share your thoughts on the current state of the branch?
At the minute the initial binary release has been delayed because committers and the PMC have been very busy on other projects (quite a summer!), but mostly because there just don't seem to be many issues files specifically for release4.0 and because there hasn't been much feedback from users grouping around that branch. Hence this email...
Because of the passing of time we will release a binary version in the near future (perhaps a couple of weeks or so) regardless of the responses in this thread or other relevant threads. If nothing else that may help attract end-users to the branch.
Thanks,
-David
Re: Users of the release4.0 branch?
Posted by BJ Freeman <bj...@free-man.net>.
normally I get a client up and running with OOTB, like today.
then i add in the modules as they are needed.
in this case I will be adding in the Yahoo store interface later this month.
This lets the client start to get some familiarity and use, instead of
waiting till the project is complete.
I have found it also generated more customization as they see what they
want.
Jacques Le Roux sent the following on 9/14/2007 10:17 AM:
> Out Of The Box,
>
> Great anyway !
>
> Jacques
>
> De : "BJ Freeman" <bj...@free-man.net>
>> I am not sure what OOTB means. (blushing)
>> I have decided to use the pos in ofbiz so will be providing code on the
>> additions I will be implementing.
>>
>>
>> Jacques Le Roux sent the following on 9/14/2007 5:18 AM:
>>> BJ,
>>>
>>> Do you use the POS OOTB ?
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> De : "BJ Freeman" <bj...@free-man.net>
>>>> one in production as we speak but won't have much use till Oct.
>>>> another about to go into production (installing today) with tier
>>>> communications and POS
>>>>
>>>>
>>>> David E Jones sent the following on 9/14/2007 12:50 AM:
>>>>> It has been nearly 5 months since we created the release4.0 branch (late
>>>>> April). The hope for these release branches is that they will stabilize
>>>>> within about 3 months and be ready for an initial binary release. In
>>>>> order for this to happen effectively each branch needs a reasonably
>>>>> sized subset of the OFBiz community doing real-world work based on it.
>>>>> So...
>>>>>
>>>>> 1. Are there any users of the release4.0 branch with projects in
>>>>> production or moving in that direction?
>>>>>
>>>>> 2. For anyone in that group, could you share your thoughts on the
>>>>> current state of the branch?
>>>>>
>>>>> At the minute the initial binary release has been delayed because
>>>>> committers and the PMC have been very busy on other projects (quite a
>>>>> summer!), but mostly because there just don't seem to be many issues
>>>>> files specifically for release4.0 and because there hasn't been much
>>>>> feedback from users grouping around that branch. Hence this email...
>>>>>
>>>>> Because of the passing of time we will release a binary version in the
>>>>> near future (perhaps a couple of weeks or so) regardless of the
>>>>> responses in this thread or other relevant threads. If nothing else that
>>>>> may help attract end-users to the branch.
>>>>>
>>>>> Thanks,
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
>
Re: Users of the release4.0 branch?
Posted by Jacques Le Roux <ja...@les7arts.com>.
Out Of The Box,
Great anyway !
Jacques
De : "BJ Freeman" <bj...@free-man.net>
> I am not sure what OOTB means. (blushing)
> I have decided to use the pos in ofbiz so will be providing code on the
> additions I will be implementing.
>
>
> Jacques Le Roux sent the following on 9/14/2007 5:18 AM:
> > BJ,
> >
> > Do you use the POS OOTB ?
> >
> > Thanks
> >
> > Jacques
> >
> > De : "BJ Freeman" <bj...@free-man.net>
> >> one in production as we speak but won't have much use till Oct.
> >> another about to go into production (installing today) with tier
> >> communications and POS
> >>
> >>
> >> David E Jones sent the following on 9/14/2007 12:50 AM:
> >>> It has been nearly 5 months since we created the release4.0 branch (late
> >>> April). The hope for these release branches is that they will stabilize
> >>> within about 3 months and be ready for an initial binary release. In
> >>> order for this to happen effectively each branch needs a reasonably
> >>> sized subset of the OFBiz community doing real-world work based on it.
> >>> So...
> >>>
> >>> 1. Are there any users of the release4.0 branch with projects in
> >>> production or moving in that direction?
> >>>
> >>> 2. For anyone in that group, could you share your thoughts on the
> >>> current state of the branch?
> >>>
> >>> At the minute the initial binary release has been delayed because
> >>> committers and the PMC have been very busy on other projects (quite a
> >>> summer!), but mostly because there just don't seem to be many issues
> >>> files specifically for release4.0 and because there hasn't been much
> >>> feedback from users grouping around that branch. Hence this email...
> >>>
> >>> Because of the passing of time we will release a binary version in the
> >>> near future (perhaps a couple of weeks or so) regardless of the
> >>> responses in this thread or other relevant threads. If nothing else that
> >>> may help attract end-users to the branch.
> >>>
> >>> Thanks,
> >>> -David
> >>>
> >>>
> >>>
> >
> >
> >
>
RE: Users of the release4.0 branch?
Posted by "skip@theDevers" <sk...@thedevers.org>.
OOTB = Out of the Box, e.g. unchanged.
-----Original Message-----
From: BJ Freeman [mailto:bjfree@free-man.net]
Sent: Friday, September 14, 2007 9:04 AM
To: user@ofbiz.apache.org
Subject: Re: Users of the release4.0 branch?
I am not sure what OOTB means. (blushing)
I have decided to use the pos in ofbiz so will be providing code on the
additions I will be implementing.
Jacques Le Roux sent the following on 9/14/2007 5:18 AM:
> BJ,
>
> Do you use the POS OOTB ?
>
> Thanks
>
> Jacques
>
> De : "BJ Freeman" <bj...@free-man.net>
>> one in production as we speak but won't have much use till Oct.
>> another about to go into production (installing today) with tier
>> communications and POS
>>
>>
>> David E Jones sent the following on 9/14/2007 12:50 AM:
>>> It has been nearly 5 months since we created the release4.0 branch (late
>>> April). The hope for these release branches is that they will stabilize
>>> within about 3 months and be ready for an initial binary release. In
>>> order for this to happen effectively each branch needs a reasonably
>>> sized subset of the OFBiz community doing real-world work based on it.
>>> So...
>>>
>>> 1. Are there any users of the release4.0 branch with projects in
>>> production or moving in that direction?
>>>
>>> 2. For anyone in that group, could you share your thoughts on the
>>> current state of the branch?
>>>
>>> At the minute the initial binary release has been delayed because
>>> committers and the PMC have been very busy on other projects (quite a
>>> summer!), but mostly because there just don't seem to be many issues
>>> files specifically for release4.0 and because there hasn't been much
>>> feedback from users grouping around that branch. Hence this email...
>>>
>>> Because of the passing of time we will release a binary version in the
>>> near future (perhaps a couple of weeks or so) regardless of the
>>> responses in this thread or other relevant threads. If nothing else that
>>> may help attract end-users to the branch.
>>>
>>> Thanks,
>>> -David
>>>
>>>
>>>
>
>
>
Re: Users of the release4.0 branch?
Posted by BJ Freeman <bj...@free-man.net>.
I am not sure what OOTB means. (blushing)
I have decided to use the pos in ofbiz so will be providing code on the
additions I will be implementing.
Jacques Le Roux sent the following on 9/14/2007 5:18 AM:
> BJ,
>
> Do you use the POS OOTB ?
>
> Thanks
>
> Jacques
>
> De : "BJ Freeman" <bj...@free-man.net>
>> one in production as we speak but won't have much use till Oct.
>> another about to go into production (installing today) with tier
>> communications and POS
>>
>>
>> David E Jones sent the following on 9/14/2007 12:50 AM:
>>> It has been nearly 5 months since we created the release4.0 branch (late
>>> April). The hope for these release branches is that they will stabilize
>>> within about 3 months and be ready for an initial binary release. In
>>> order for this to happen effectively each branch needs a reasonably
>>> sized subset of the OFBiz community doing real-world work based on it.
>>> So...
>>>
>>> 1. Are there any users of the release4.0 branch with projects in
>>> production or moving in that direction?
>>>
>>> 2. For anyone in that group, could you share your thoughts on the
>>> current state of the branch?
>>>
>>> At the minute the initial binary release has been delayed because
>>> committers and the PMC have been very busy on other projects (quite a
>>> summer!), but mostly because there just don't seem to be many issues
>>> files specifically for release4.0 and because there hasn't been much
>>> feedback from users grouping around that branch. Hence this email...
>>>
>>> Because of the passing of time we will release a binary version in the
>>> near future (perhaps a couple of weeks or so) regardless of the
>>> responses in this thread or other relevant threads. If nothing else that
>>> may help attract end-users to the branch.
>>>
>>> Thanks,
>>> -David
>>>
>>>
>>>
>
>
>
Re: Users of the release4.0 branch?
Posted by Jacques Le Roux <ja...@les7arts.com>.
BJ,
Do you use the POS OOTB ?
Thanks
Jacques
De : "BJ Freeman" <bj...@free-man.net>
> one in production as we speak but won't have much use till Oct.
> another about to go into production (installing today) with tier
> communications and POS
>
>
> David E Jones sent the following on 9/14/2007 12:50 AM:
> >
> > It has been nearly 5 months since we created the release4.0 branch (late
> > April). The hope for these release branches is that they will stabilize
> > within about 3 months and be ready for an initial binary release. In
> > order for this to happen effectively each branch needs a reasonably
> > sized subset of the OFBiz community doing real-world work based on it.
> > So...
> >
> > 1. Are there any users of the release4.0 branch with projects in
> > production or moving in that direction?
> >
> > 2. For anyone in that group, could you share your thoughts on the
> > current state of the branch?
> >
> > At the minute the initial binary release has been delayed because
> > committers and the PMC have been very busy on other projects (quite a
> > summer!), but mostly because there just don't seem to be many issues
> > files specifically for release4.0 and because there hasn't been much
> > feedback from users grouping around that branch. Hence this email...
> >
> > Because of the passing of time we will release a binary version in the
> > near future (perhaps a couple of weeks or so) regardless of the
> > responses in this thread or other relevant threads. If nothing else that
> > may help attract end-users to the branch.
> >
> > Thanks,
> > -David
> >
> >
> >
>
Re: Users of the release4.0 branch?
Posted by BJ Freeman <bj...@free-man.net>.
one in production as we speak but won't have much use till Oct.
another about to go into production (installing today) with tier
communications and POS
David E Jones sent the following on 9/14/2007 12:50 AM:
>
> It has been nearly 5 months since we created the release4.0 branch (late
> April). The hope for these release branches is that they will stabilize
> within about 3 months and be ready for an initial binary release. In
> order for this to happen effectively each branch needs a reasonably
> sized subset of the OFBiz community doing real-world work based on it.
> So...
>
> 1. Are there any users of the release4.0 branch with projects in
> production or moving in that direction?
>
> 2. For anyone in that group, could you share your thoughts on the
> current state of the branch?
>
> At the minute the initial binary release has been delayed because
> committers and the PMC have been very busy on other projects (quite a
> summer!), but mostly because there just don't seem to be many issues
> files specifically for release4.0 and because there hasn't been much
> feedback from users grouping around that branch. Hence this email...
>
> Because of the passing of time we will release a binary version in the
> near future (perhaps a couple of weeks or so) regardless of the
> responses in this thread or other relevant threads. If nothing else that
> may help attract end-users to the branch.
>
> Thanks,
> -David
>
>
>
Re: Users of the release4.0 branch?
Posted by Jonathon -- Improov <jo...@improov.com>.
I've done about 3-4 projects using release4.0 by now. Seems ok. Many features are incomplete, but
one could label those as "to be customized". Bugs are still around, some even show-stopping ones.
I'm still trying to gift-wrap OFBiz, so that I can finish up some docs I had been writing, and to
publish them somehow.
But... I think you should roll out a binary release soon, given how bugfixes have been applied to
the branch over past months, and how no new features/bugs have been added to it.
Not everyone likes to download via SVN. A binary release may attract even more testers. You can
always roll out updated binary releases over the next few months, which may suggest progress and
attract even more interest.
Jonathon
David E Jones wrote:
>
> It has been nearly 5 months since we created the release4.0 branch (late
> April). The hope for these release branches is that they will stabilize
> within about 3 months and be ready for an initial binary release. In
> order for this to happen effectively each branch needs a reasonably
> sized subset of the OFBiz community doing real-world work based on it.
> So...
>
> 1. Are there any users of the release4.0 branch with projects in
> production or moving in that direction?
>
> 2. For anyone in that group, could you share your thoughts on the
> current state of the branch?
>
> At the minute the initial binary release has been delayed because
> committers and the PMC have been very busy on other projects (quite a
> summer!), but mostly because there just don't seem to be many issues
> files specifically for release4.0 and because there hasn't been much
> feedback from users grouping around that branch. Hence this email...
>
> Because of the passing of time we will release a binary version in the
> near future (perhaps a couple of weeks or so) regardless of the
> responses in this thread or other relevant threads. If nothing else that
> may help attract end-users to the branch.
>
> Thanks,
> -David
>
>
Re: Users of the release4.0 branch?
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> Because of the passing of time we will release a binary version in the
> near future (perhaps a couple of weeks or so) regardless of the
> responses in this thread or other relevant threads. If nothing else that
> may help attract end-users to the branch.
I agree. It's probably a good time to put the R4 binary out there to help encourage people to use it.
Re: Users of the release4.0 branch?
Posted by Jacques Le Roux <ja...@les7arts.com>.
+1 for all below
Montly would not be enough ?
Jacques
----- Message d'origine -----
De : "Jacopo Cappellato" <ti...@sastau.it>
À : <us...@ofbiz.apache.org>
Envoyé : vendredi 14 septembre 2007 11:38
Objet : Re: Users of the release4.0 branch?
> I agree,
>
> and I really think we should also provide official weekly snapshots from
> trunk.
>
> Jacopo
>
> Ray Barlow wrote:
> > I was just composing a similar message!
> >
> > The suggestion I was going to make is that we consider doing a release
> > candidate, making sure it is packaged for easy download and deployment
> > and importantly announced that it's around. SVN is not always the most
> > attractive for people looking to evaluate what the project is all about,
> > as I see Jonathon has just responded with the same thoughts.
> >
> > It might help to raise the interest and testing required to fix any
> > final issues, as there is a lot of good work going into patching bug
> > fixes in the release branch.
> >
> > Ray
> >
> >
> > David E Jones wrote:
> >> It has been nearly 5 months since we created the release4.0 branch
> >> (late April). The hope for these release branches is that they will
> >> stabilize within about 3 months and be ready for an initial binary
> >> release. In order for this to happen effectively each branch needs a
> >> reasonably sized subset of the OFBiz community doing real-world work
> >> based on it. So...
> >>
> >> 1. Are there any users of the release4.0 branch with projects in
> >> production or moving in that direction?
> >>
> >> 2. For anyone in that group, could you share your thoughts on the
> >> current state of the branch?
> >>
> >> At the minute the initial binary release has been delayed because
> >> committers and the PMC have been very busy on other projects (quite a
> >> summer!), but mostly because there just don't seem to be many issues
> >> files specifically for release4.0 and because there hasn't been much
> >> feedback from users grouping around that branch. Hence this email...
> >>
> >> Because of the passing of time we will release a binary version in the
> >> near future (perhaps a couple of weeks or so) regardless of the
> >> responses in this thread or other relevant threads. If nothing else
> >> that may help attract end-users to the branch.
> >>
> >> Thanks,
> >> -David
> >>
>
>
Re: Users of the release4.0 branch?
Posted by Jacopo Cappellato <ti...@sastau.it>.
I agree,
and I really think we should also provide official weekly snapshots from
trunk.
Jacopo
Ray Barlow wrote:
> I was just composing a similar message!
>
> The suggestion I was going to make is that we consider doing a release
> candidate, making sure it is packaged for easy download and deployment
> and importantly announced that it's around. SVN is not always the most
> attractive for people looking to evaluate what the project is all about,
> as I see Jonathon has just responded with the same thoughts.
>
> It might help to raise the interest and testing required to fix any
> final issues, as there is a lot of good work going into patching bug
> fixes in the release branch.
>
> Ray
>
>
> David E Jones wrote:
>> It has been nearly 5 months since we created the release4.0 branch
>> (late April). The hope for these release branches is that they will
>> stabilize within about 3 months and be ready for an initial binary
>> release. In order for this to happen effectively each branch needs a
>> reasonably sized subset of the OFBiz community doing real-world work
>> based on it. So...
>>
>> 1. Are there any users of the release4.0 branch with projects in
>> production or moving in that direction?
>>
>> 2. For anyone in that group, could you share your thoughts on the
>> current state of the branch?
>>
>> At the minute the initial binary release has been delayed because
>> committers and the PMC have been very busy on other projects (quite a
>> summer!), but mostly because there just don't seem to be many issues
>> files specifically for release4.0 and because there hasn't been much
>> feedback from users grouping around that branch. Hence this email...
>>
>> Because of the passing of time we will release a binary version in the
>> near future (perhaps a couple of weeks or so) regardless of the
>> responses in this thread or other relevant threads. If nothing else
>> that may help attract end-users to the branch.
>>
>> Thanks,
>> -David
>>
Re: Users of the release4.0 branch?
Posted by Ray Barlow <ra...@makeyour-point.com>.
I was just composing a similar message!
The suggestion I was going to make is that we consider doing a release
candidate, making sure it is packaged for easy download and deployment
and importantly announced that it's around. SVN is not always the most
attractive for people looking to evaluate what the project is all about,
as I see Jonathon has just responded with the same thoughts.
It might help to raise the interest and testing required to fix any
final issues, as there is a lot of good work going into patching bug
fixes in the release branch.
Ray
David E Jones wrote:
>
> It has been nearly 5 months since we created the release4.0 branch
> (late April). The hope for these release branches is that they will
> stabilize within about 3 months and be ready for an initial binary
> release. In order for this to happen effectively each branch needs a
> reasonably sized subset of the OFBiz community doing real-world work
> based on it. So...
>
> 1. Are there any users of the release4.0 branch with projects in
> production or moving in that direction?
>
> 2. For anyone in that group, could you share your thoughts on the
> current state of the branch?
>
> At the minute the initial binary release has been delayed because
> committers and the PMC have been very busy on other projects (quite a
> summer!), but mostly because there just don't seem to be many issues
> files specifically for release4.0 and because there hasn't been much
> feedback from users grouping around that branch. Hence this email...
>
> Because of the passing of time we will release a binary version in the
> near future (perhaps a couple of weeks or so) regardless of the
> responses in this thread or other relevant threads. If nothing else
> that may help attract end-users to the branch.
>
> Thanks,
> -David
>
Re: Users of the release4.0 branch?
Posted by Scott Gray <le...@gmail.com>.
Hi Mark
While I don't have any figures, the update should be pretty light especially
for the release branch which only sees bug fixing commits. It would depend
on how old your snapshot is but even if it were over a month old I wouldn't
expect the update to consume more a couple of MB.
Regards
Scott
On 15/09/2007, Mark Erbaugh <ma...@microenh.com> wrote:
>
> On Fri, 2007-09-14 at 01:50 -0600, David E Jones wrote:
> > It has been nearly 5 months since we created the release4.0 branch (late
> April). The hope for these release branches is that they will stabilize
> within about 3 months and be ready for an initial binary release. In order
> for this to happen effectively each branch needs a reasonably sized subset
> of the OFBiz community doing real-world work based on it. So...
> >
> > 1. Are there any users of the release4.0 branch with projects in
> production or moving in that direction?
> >
> > 2. For anyone in that group, could you share your thoughts on the
> current state of the branch?
> >
> > At the minute the initial binary release has been delayed because
> committers and the PMC have been very busy on other projects (quite a
> summer!), but mostly because there just don't seem to be many issues files
> specifically for release4.0 and because there hasn't been much feedback
> from users grouping around that branch. Hence this email...
> >
> > Because of the passing of time we will release a binary version in the
> near future (perhaps a couple of weeks or so) regardless of the responses in
> this thread or other relevant threads. If nothing else that may help attract
> end-users to the branch.
>
> What is the procedure for working with a release branch? I used
> Subclipse (in Eclipse) to checkout the release 4 branch and I have been
> working with a local copy thinking that the branch was frozen. The
> comments above sound like it is not.
>
> At this point, I'm trying to learn OfBiz and wanted to get a (more)
> solid footing before the code started changing underneath me.
>
> This question also goes to my lack of familiarity with Subversion. So
> far, I've only used it to track my own projects. Right now, what I did
> was checkout the release 4 branch. I then disconnected the project from
> the repository and re-created a project in my local repository. That
> way, as I'm learning, I can try code changes to see what happens, and
> still revert pieces.
>
> I have to add that I am using a satellite based ISP that while higher
> speed than dialup, limits the amount of data I can download (to 200 MB
> per day) except between 3am and 6am. I know this is not ideal, but
> traditional high speed choices aren't available to me.
>
> So I checked out the project early one morning and have been working
> with the local copy. Is there a way with Subclipse (or Subversion) to
> tell how much data needs to be transferred to sync up?
>
> Mark
>
>
Re: Users of the release4.0 branch?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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?
Posted by 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: Rich client: licensing and other features
Posted by "skip@theDevers" <sk...@thedevers.org>.
Cameron
Thanks for your insite. As I said, I agree with you completely. Those of
us who implement systems for our clients have to use the tools which make us
the most productive, and especially so here in the U.S. with programming
labor rates so high. My point about maximum usability was for community not
personal adoption.
You said, "I do feel that in what you say, there is an implicit, or perhaps
subconscious, moral judgement that anything which is not completely free for
anyone to use in commercial work, is bad." This was not my thoughts at all.
We all have to make a living and I think the ZK folks have found a splendid
way to do it. The issue here is not one of free/commercial. It is instead
the ability to have the community as a whole adopt a standard that everyone
can participate in.
I also agree that data consistancy and accuracy is of paramount importance.
I guess I just take that for granted in my arguments. On the other hand, if
a system is too difficult to use, people won't use it and so it doesn't then
matter much how robust your schema is.
Which brings me back to user friendly and intuitive UIs. I am about to head
down the same path you took in the past and write a semi-complete set of
user interfaces that the clerks employed by my clients can use without a lot
of training. I know I am not the first, and I bet I am not in the first
hundred.
Perhaps I'll set up a web site to collect Ofbiz add-ons that are outside the
Ofbiz mold and give the next guy a higher starting point. That way, the
licensing issues, version compatability, etc., become moot.
Skip
Re: Users of the release4.0 branch?
Posted by Jacques Le Roux <ja...@les7arts.com>.
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?
Posted by 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!
> 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.
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.)
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.
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?
Posted by Jacques Le Roux <ja...@les7arts.com>.
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?
Posted by Jonathon -- Improov <jo...@improov.com>.
> 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?
Posted by Jacques Le Roux <ja...@les7arts.com>.
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?
Posted by Raj Saini <ra...@gmail.com>.
David,
Maven 2 is the right solution to the problem. I know Maven has its own
problem but as long as separating the jars from source is concerned
Maven is a good choice. Almost all of the ASF projects use it.
Thanks,
Raj
David E Jones wrote:
>
>
> 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?
Posted by 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?
Posted by Jonathon -- Improov <jo...@improov.com>.
Hi Mark,
> I have to add that I am using a satellite based ISP that while
> higher speed than dialup, limits the amount of data I can download
> (to 200 MB per day) except between 3am and 6am. I know this is not
> ideal, but traditional high speed choices aren't available to me.
200MB isn't too little, unless you also have to download other stuff too. A usual update size is
about a few MB at most. HOWEVER, when there are changes to 3rd-party binaries, the update size can
go up quite a bit. Updating is usually not problematic (unless it gets disrupted, and the update
size is huge). It's the initial checking out that can kill you.
Even with high internet speeds, the http protocol for downloading via SVN can sometimes be
disrupted (and you have to start all over again). We have OFBiz students here in Singapore who
complain that they simply can't complete a checkout of OFBiz (we have high speed broadband). So,
we actually had to send them a tarball of a pre- checked out OFBiz (including .svn files). As I
said, updating (not checking out fresh) usually is fine.
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.
Maybe this wasn't taken up because I didn't completely describe my recommended solution. So, here
goes!
1. Check out the latest OFBiz
2. Create an MD5 signature of all 3rd-party binaries.
3. Take out all those binaries.
4. Commit the MD5 signature.
5. Bundle those binaries into a tarball to be downloaded separately,
outside of SVN.
6. Create script to deploy those binaries back into OFBiz file
structure.
7. Commit that script.
Something like that.
Even the 4+MB Dojo can be packaged separately, rather than stuffed into the SVN! That'll be about
40+MB less to download from SVN (http protocol)!
I've done that umpteen times already, so if the OFBiz team wants me to actually do it for them,
I'd be glad to help.
David Jones recently mentioned "drop-in or add-in components". That is a sweet ideal. Shouldn't we
attempt to component-ize OFBiz then? That way, we can drop in Dojo or Prototype, Log4J version x
or Log4J version y, etc.
If anyone wants to know how MD5 signatures can help in both decentralized software development
teams and in legal documents, maybe read up on MD5 in wikipedia or something.
Jonathon
Mark Erbaugh wrote:
> On Fri, 2007-09-14 at 01:50 -0600, David E Jones wrote:
>> It has been nearly 5 months since we created the release4.0 branch (late April). The hope for these release branches is that they will stabilize within about 3 months and be ready for an initial binary release. In order for this to happen effectively each branch needs a reasonably sized subset of the OFBiz community doing real-world work based on it. So...
>>
>> 1. Are there any users of the release4.0 branch with projects in production or moving in that direction?
>>
>> 2. For anyone in that group, could you share your thoughts on the current state of the branch?
>>
>> At the minute the initial binary release has been delayed because committers and the PMC have been very busy on other projects (quite a summer!), but mostly because there just don't seem to be many issues files specifically for release4.0 and because there hasn't been much feedback from users grouping around that branch. Hence this email...
>>
>> Because of the passing of time we will release a binary version in the near future (perhaps a couple of weeks or so) regardless of the responses in this thread or other relevant threads. If nothing else that may help attract end-users to the branch.
>
> What is the procedure for working with a release branch? I used
> Subclipse (in Eclipse) to checkout the release 4 branch and I have been
> working with a local copy thinking that the branch was frozen. The
> comments above sound like it is not.
>
> At this point, I'm trying to learn OfBiz and wanted to get a (more)
> solid footing before the code started changing underneath me.
>
> This question also goes to my lack of familiarity with Subversion. So
> far, I've only used it to track my own projects. Right now, what I did
> was checkout the release 4 branch. I then disconnected the project from
> the repository and re-created a project in my local repository. That
> way, as I'm learning, I can try code changes to see what happens, and
> still revert pieces.
>
> I have to add that I am using a satellite based ISP that while higher
> speed than dialup, limits the amount of data I can download (to 200 MB
> per day) except between 3am and 6am. I know this is not ideal, but
> traditional high speed choices aren't available to me.
>
> So I checked out the project early one morning and have been working
> with the local copy. Is there a way with Subclipse (or Subversion) to
> tell how much data needs to be transferred to sync up?
>
> Mark
>
>
Re: Users of the release4.0 branch?
Posted by Jacques Le Roux <ja...@les7arts.com>.
De : "Mark Erbaugh" <ma...@microenh.com>
> On Fri, 2007-09-14 at 01:50 -0600, David E Jones wrote:
> > It has been nearly 5 months since we created the release4.0 branch (late April). The hope for these release branches is that
they will stabilize within about 3 months and be ready for an initial binary release. In order for this to happen effectively each
branch needs a reasonably sized subset of the OFBiz community doing real-world work based on it. So...
> >
> > 1. Are there any users of the release4.0 branch with projects in production or moving in that direction?
> >
> > 2. For anyone in that group, could you share your thoughts on the current state of the branch?
> >
> > At the minute the initial binary release has been delayed because committers and the PMC have been very busy on other projects
(quite a summer!), but mostly because there just don't seem to be many issues files specifically for release4.0 and because there
hasn't been much feedback from users grouping around that branch. Hence this email...
> >
> > Because of the passing of time we will release a binary version in the near future (perhaps a couple of weeks or so) regardless
of the responses in this thread or other relevant threads. If nothing else that may help attract end-users to the branch.
>
> What is the procedure for working with a release branch? I used
> Subclipse (in Eclipse) to checkout the release 4 branch and I have been
> working with a local copy thinking that the branch was frozen. The
> comments above sound like it is not.
Don't know if it's of any use to you : http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
Jacques
Re: Users of the release4.0 branch?
Posted by Mark Erbaugh <ma...@microenh.com>.
On Fri, 2007-09-14 at 01:50 -0600, David E Jones wrote:
> It has been nearly 5 months since we created the release4.0 branch (late April). The hope for these release branches is that they will stabilize within about 3 months and be ready for an initial binary release. In order for this to happen effectively each branch needs a reasonably sized subset of the OFBiz community doing real-world work based on it. So...
>
> 1. Are there any users of the release4.0 branch with projects in production or moving in that direction?
>
> 2. For anyone in that group, could you share your thoughts on the current state of the branch?
>
> At the minute the initial binary release has been delayed because committers and the PMC have been very busy on other projects (quite a summer!), but mostly because there just don't seem to be many issues files specifically for release4.0 and because there hasn't been much feedback from users grouping around that branch. Hence this email...
>
> Because of the passing of time we will release a binary version in the near future (perhaps a couple of weeks or so) regardless of the responses in this thread or other relevant threads. If nothing else that may help attract end-users to the branch.
What is the procedure for working with a release branch? I used
Subclipse (in Eclipse) to checkout the release 4 branch and I have been
working with a local copy thinking that the branch was frozen. The
comments above sound like it is not.
At this point, I'm trying to learn OfBiz and wanted to get a (more)
solid footing before the code started changing underneath me.
This question also goes to my lack of familiarity with Subversion. So
far, I've only used it to track my own projects. Right now, what I did
was checkout the release 4 branch. I then disconnected the project from
the repository and re-created a project in my local repository. That
way, as I'm learning, I can try code changes to see what happens, and
still revert pieces.
I have to add that I am using a satellite based ISP that while higher
speed than dialup, limits the amount of data I can download (to 200 MB
per day) except between 3am and 6am. I know this is not ideal, but
traditional high speed choices aren't available to me.
So I checked out the project early one morning and have been working
with the local copy. Is there a way with Subclipse (or Subversion) to
tell how much data needs to be transferred to sync up?
Mark