Hi Jacques,
I agree there are minor problems when libraries are downloaded form
different repositories. I had been in similar situation couple of time
in the past. But again, source repository is not really to store the
binary contents. We cant main any versioning information of the jars in
the source repository.
Regarding binary release, almost every project in open source I came
across have an Ant target or Maven goal some thing like dist to create
the binary distribution. Generally, the structure of the distribution is
not same as source tree. Binary releases, re-organise the code with a
directory structure like bin, conf, lib etc. I feel this is one of the
reason we had the problem with the bin folder colliding with the Eclipse
bin folder. Bin folder suppose to exist only in the binary release and
not in the source tree.
Thanks,
Raj
On Thursday 12 April 2012 04:46 PM, Jacques Le Roux wrote:
Hi Raj,
From: "Rajbir Saini" <rajbsa...@yahoo.com>
BTW, how to you checkout OFBiz or download the source if there is no
Internet connection. I know we can build with Maven without
Internect connection once you have downloaded the dependencies when
you build first time.
A real important issue with Ivy: it would be much slower to check out
the whole (I do that often, not always from ASF repo, but
clients's, etc.). And we will still need to do it for each release to
package (minor).
There are other minor problems like sometimes you need to extract a
temporary snapshoots from an attachment somewhere (ie you can't
find it in a repo). I have been in such a situation in the past,
notably with Geronimo (actually it was WASCE 2.0.0.1
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045153).
Ivy would get stuck in such cases. OK, this is is out of
OFBiz, but we have also snapshots or modifed version of libs (I did,
or used, one for DBCP years ago).
If we find good solutions for these issues (and some others we may
come with) then we should discuss it. But the slowness is a
bummer IMO.
Also, OFBiz similar to other should have a different binary release
and generally binary releases have all the dependencies
bundled. Binary releases are for the end users and not developers.
You mean we don't have binary relases right and users still need to
build? But all our dependencies are bundled, what's the problem?
I think we already discussed about binary relases. Users would still
have to load data. We could also package them. But is it not
easy to simply follow the Quick start here
http://ofbiz.apache.org/download.html?
Jacques
Thanks,
Raj
On Thursday 12 April 2012 02:14 AM, Jacques Le Roux wrote:
The problem with this approach: it does not work if you don't have
an Internet connection: blocking
-1
Jacques
From: "Pierre Smits" <pierre.sm...@gmail.com>
Hi Jacopo,
How about using Apache Ivy more to manage dependencies. That way OFBiz
should reduce in size dramatically and the modifications of the
licence and
notice file are trimmed down considerably.
Regards,
Pierre
Op 11 april 2012 18:49 schreef Jacopo Cappellato <
jacopo.cappell...@hotwaxmedia.com> het volgende:
Hi all,
the following are housekeeping tasks that could be part of the
"SlimDown"
roadmap we could do (help from the community would be highly
appreciated)
related to the big number of jar files bundled with OFBiz:
* making sure all jar files are marked as binary
* making sure they are listed properly in LICENSE (and if required
NOTICE)
file
* making sure we are running stable versions and not snapshots
(whenever
possible)
* upgrade jars to use latest versions (whenever possible)
* remove jars no more needed
* rename old jars to add release numbers in the file name
Any ideas on how to document compilation and runtime dependencies,
purpose
and versions of each jars bundled in OFBiz?
A useful (but outdated/incomplete) source of information is this
page:
https://cwiki.apache.org/confluence/display/OFBADMIN/Libraries+Included+in+OFBiz
You may have noticed that in the last few days I already started
the work
of upgrading some jars, setting the file properties to binary etc..
I have also identified a few jars that may not be needed anymore,
but I
would like your help/input in figuring out if we can actually
remove them;
in fact, even if I was able to compile and run successfully all
tests it is
still not guaranteed that some of them may be used under special
conditions
at runtime (this is true for all jars):
framework/base/lib/ant/ant-nodeps-1.8.1.jar
framework/base/lib/Tidy.jar
framework/base/lib/ant-trax-1.8.0.jar
framework/base/lib/commons/commons-vfs-20070730.jar
There may be other files in the same condition.
Kind regards,
Jacopo
