I think my argument is need vs require. Basically with this policy, we
would be telling people there are certain tools you may not use.
John
On Tue, Jan 24, 2017 at 5:04 PM Ted Dunning wrote:
> The single case that I can see for mystery jars in binary form is when a
> test case needs to cover
The single case that I can see for mystery jars in binary form is when a
test case needs to cover malformed binaries or binaries produced on
obsolete platforms (does anybody have a Java 1.3 compiler handy).
(don't answer that, I wouldn't be surprised if a fair number of people
still require 1.3 c
Yeah, Paul makes a very good point. When you're new to a platform and
trying to debug tests, trying to find out whats hidden inside mysterious
test jars etc is often tedious at best. Build at test time is ideal.
Tom
On Tue, Jan 24, 2017 at 9:16 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch
On Tue, Jan 24, 2017 at 6:48 AM, Paul King wrote:
> ...I actually think what we ended up with does make it clearer
> exactly what is going on
Definitely - what Groovy did avoids having Mysterious Binaries in
their releases, which we don't want.
-Bertrand
Just FYI, Groovy had numerous such "test" jars and wrapper files and
such initially. It turned out to only be a couple of hours work to
remove them and build them on the fly within the build files. While I
certainly see both sides of the argument about whether some
"binary-like" artifacts might be
On 1/23/17, 9:51 AM, "John D. Ament" wrote:
>>
>> The gradle wrapper and similar are also not permitted. Build processes
>> need to bootstrap it.
>>
>>
>I would like to understand why, from a legal standpoint, these are not
>allowed.
I don't think it is a legal issue. It is an ASF policy that
On Mon, Jan 23, 2017 at 8:04 AM Marvin Humphrey
wrote:
> On Mon, Jan 23, 2017 at 4:35 AM, John D. Ament
> wrote:
>
> > What I'm trying to make sure we're agreeing to is
> > that the problem isn't that there is a JAR to .tar.gz file in the
> > distribution. Its that the original source is missin
On Mon, Jan 23, 2017 at 4:35 AM, John D. Ament wrote:
> What I'm trying to make sure we're agreeing to is
> that the problem isn't that there is a JAR to .tar.gz file in the
> distribution. Its that the original source is missing.
No. Bundling jar files is not OK in general and it is definitel
On Mon, Jan 23, 2017 at 3:19 AM Justin Mclean
wrote:
> Hi,
>
> > My interpretation of the term "compiled code" means compiled versions of
> the source code within the package.
>
> So how is including a jar in a source release to which there is no source
> code included (or even a pointer to that
Hi,
> My interpretation of the term "compiled code" means compiled versions of the
> source code within the package.
So how is including a jar in a source release to which there is no source code
included (or even a pointer to that code that I can see) actually open source
software?
Given thi
On Sun, Jan 22, 2017 at 10:24 PM Marvin Humphrey
wrote:
> On Sat, Jan 21, 2017 at 9:34 AM, John D. Ament
> wrote:
> > On Sat, Jan 21, 2017 at 12:19 PM Marvin Humphrey >
> > wrote:
> >
> >> On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament
> >> wrote:
> >> > However, regarding the
> >> > binaries.
On Sat, Jan 21, 2017 at 9:34 AM, John D. Ament wrote:
> On Sat, Jan 21, 2017 at 12:19 PM Marvin Humphrey
> wrote:
>
>> On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament
>> wrote:
>> > However, regarding the
>> > binaries. In a recent discussion (on legal-discuss) it was decided that
>> > this was
On Sun, Jan 22, 2017 at 8:58 PM Marvin Humphrey
wrote:
> On Sun, Jan 22, 2017 at 5:47 PM, John D. Ament
> wrote:
>
> > [3]:
> http://www.apache.org/dev/release.html#what-must-every-release-contain
>
> That document has been superseded. Official Release Policy, curated
> by VP Legal, is here:
>
Sorry, I'll clarify.
On Sun, Jan 22, 2017 at 9:01 PM Justin Mclean
wrote:
> Hi,
>
> > If you look in the tar.gz you'll see that it's R source code, and a JAR
> for
> > testing. Its not compiled code.
>
> Looks like the jars contain compiled code to me:
> ./sparkr-interpreter/src/main/resources/
Hi,
> If you look in the tar.gz you'll see that it's R source code, and a JAR for
> testing. Its not compiled code.
Looks like the jars contain compiled code to me:
./sparkr-interpreter/src/main/resources/sparkr_bundle.tar.gz - Contains R code
and a jar that contains class files.
./sparkr-inter
On Sun, Jan 22, 2017 at 5:47 PM, John D. Ament wrote:
> [3]: http://www.apache.org/dev/release.html#what-must-every-release-contain
That document has been superseded. Official Release Policy, curated
by VP Legal, is here:
http://www.apache.org/legal/release-policy
Marvin Humphrey
---
On Sun, Jan 22, 2017 at 4:59 PM Justin Mclean
wrote:
> Hi,
>
> > Same thread. Specifically Mark T's response [1] and Craig's affirmation
> [2]
>
> Not sure that applies here as I think we have compiled code without the
> corresponding source. Can someone on the project confirm?
>
>
If you look i
Hi,
> Same thread. Specifically Mark T's response [1] and Craig's affirmation [2]
Not sure that applies here as I think we have compiled code without the
corresponding source. Can someone on the project confirm?
Even then I would expect that to be an unusual exception where there was no
other
On Sat, Jan 21, 2017 at 12:19 PM Marvin Humphrey
wrote:
> On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament
> wrote:
> > However, regarding the
> > binaries. In a recent discussion (on legal-discuss) it was decided that
> > this was OK. Ideally the NOTICE would include the information on the
> >
19 matches
Mail list logo