Taher,
Wait, either Tomcat, Ant and JMeter are doing it wrong or we don't understand
this sentence (I agree with you) or it's incomplete.
Because if you download each of their binary releases you will find in them "binary/bytecode files" which are not the "result of compiling that
version of the source code release"
Tomcat: ecj
Ant: ivy (+ 3 optionals)
JMeter: ~50 externals libs
I just checked Wicket: only own binaries, not even optionals like Ant.
For Tomcat and Ivy it's maybe optional, but for JMeter it's not it seems. I mean JMeter seems to depends on these external libs and they are delivered
in the binary. To be confirmed because I did not dig deeper.
It's even more obvious on Geronimo download page:
http://geronimo.apache.org/apache-geronimo-v301-release.html
<<Following distributions use Tomcat as the Web container and Axis2 as the Web
Services engine.>>
I did download the 91 MB, and can confirm it has a total of 346 jars, most not being
"result of compiling that version of the source code release"
I guess the external libraries are runtime dependencies, in certain cases only
optional.
I also read at http://www.apache.org/legal/resolved.html#category-b
<<software under the following licenses may be included in binary form within an
Apache product if the inclusion is appropriately labeled (see below):>>
So I don't think we can say "In other words we *cannot* include the dependencies in the binary releases anyway. So people *must* use Gradle to
download the dependencies"
Jacques
Le 24/08/2016 à 17:12, Taher Alkhateeb a écrit :
Hi Jacques,
The discussion we had in OFBIZ-7783 was basically around whether or not we
should have a task to copy the gradle dependencies into a certain
directory. We went through many discussions, the last one being that this
task might be needed for binary releases.
However, if you look at the reference that _you_ provided you will notice
that is says that you "may only add binary/bytecode files that are the
result of compiling that version of the source code release"
We are _NOT_ compiling any of the dependencies, instead, the build system
downloads them from jcenter in a precompiled form. In other words we cannot
include the dependencies in the binary releases anyway. So people must use
Gradle to download the dependencies, and so the whole purpose of the binary
release becomes unnecessary as you must have gradle and java installed on
your computer.
Taher Alkhateeb
On Wed, Aug 24, 2016 at 5:36 PM, Jacques Le Roux <
[email protected]> wrote:
Hi,
At https://issues.apache.org/jira/browse/OFBIZ-7783 we recently had a
discussion with Taher about doing or not binary releases.
This is how the ASF defines a binary release (
http://www.apache.org/dev/release.html#what)
<<All releases are in the form of the source materials needed to make
changes to the software being released. In some cases, binary/bytecode
packages are also produced as a convenience to users that might not have
the appropriate tools to build a compiled version of the source. In all
such cases, the binary/bytecode package must have the same version number
as the source release and may only add binary/bytecode files that are the
result of compiling that version of the source code release.>>
So the question is simple (not the answer, you need to think ahead): do we
want to do binary releases? It comes with some burden, does it worth it? No
needs to rush an answer :)
If you want more information you can already look at the conversation we
had Pierre, Taher and I at OFBIZ-7783
Thanks
Jacques
