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
