On 02/13/2013 12:48 PM, Fred Ollinger wrote:
Relying on jars, IMHO, is not bad, but it depends on your goals.
The point of compiling from source is that it's a first step to
actually being a developer which is why I do it. Compiling problems
aren't problems for us new developers they are puzzles to solve to
help people out.
If there are changes needed to the jars, we need to recompile. For a
build where I don't modify the jar, I'd prefer to just fetch it b/c
it's way faster. Also, where does compiling from source end. That is,
we all rely on someone else's compiling some of our software (unless
our name is Theo, I guess). :)
Fred
On Tue, Feb 12, 2013 at 7:28 PM, Ariel Constenla-Haile
<arie...@apache.org> wrote:
Hi Michael,
On Tue, Feb 12, 2013 at 09:59:02PM -0500, Michael Lam wrote:
On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote:
On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:
I have updated the external_deps.lst with the updated hsqldb
information. If someone can give me some pointer into how to just
retrieve the jar instead of the source
You don't retrieve precompiled stuff. The logic is:
a) don't include the dependency at all
b) include the dependency
b.1) build it from source
b.2) use the precompiled version in the system (this switch is only for
external packagers, the builds are release with no system [configurable]
dependencies).
Regards
I am still a little confused. Obviously it is possible to build from
source but as a lot of email on the list have shown it could cause
issues with the build that is not directly related to the AOO code.
Why not just retrieve the jar so the build is inclusive?
I don't know what motivated these rules, but I guess it was something in
the lines of having control about what is being compiled and how it is
being compiled (the use of the compiler, the Java base line, etc.).
35 million of downloads are worth not relaying on a jar built by someone
else and, instead, build it from sources.
I am used to retrieving compiled jars on the projects I worked on, in
Java there is maven and ivy to retrieve specific version of the jar
that the project is tested on along with the dependencies.
But it is still trusting in a binary built by someone else. Every
project is free to trust or build from sources. Historically, OpenOffice
builds from external sources and includes these binaries in its
releases, it has no external dependencies (other than the system
libraries). The configure switches that allow building with system
libraries/jars are only supported on *nix, and even there they are not
relaying on a jar built by someone else: Linux distributions, for
example, build all their jars; why do they build all by themselves
instead of fetching compiled jars? I've no idea, but I guess they follow
the same criteria mentioned above (as a Linux user you can use Maven in
your projects, but it won't modify the system's jars).
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Thank you for the explanation. For now I will stick to the current setup
and make couple more changes but I would like my idea to be consider in
the future. It is true for most long running system that some of the why
certain decisions were made is lost and I am quite sure there were/are
legitimate reasons. It would just helpful to know instead of doing the
same thing just because. As far as trust, that is interesting in this
context since I would be fetching from the source and given that the
project is using the third party code in such a integral way that I
would think the trust is implicit.
