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