You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Willem Jiang <wi...@gmail.com> on 2019/02/23 06:18:00 UTC
Binary jars in the source release which are only for testing
Hi,
I just have a question about the Binary jars in the source release.
According the Apache release policy, I cannot find any rule about the
binary jars cannot be in the source release[1]. If we just have jars
for testing purposes and those jar won't be a part of convenience
binary release, I think it doesn't break the rule below:
"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.".
Is it OK to ship those test binary jars in the source release kit?
[1]http://www.apache.org/legal/release-policy.html#what
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Willem Jiang <wi...@gmail.com>.
Thanks all the help from IPMC. I'm sorry I didn't make it clear enough earlier.
Actually, this question is related to recently release check of Apache
Camel[1]. I just found there are some tests jar in the source kit by
applying what I learned from IPMC. I already submit a quick fix to
eliminate those jars.
[1]https://issues.apache.org/jira/browse/CAMEL-13240
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Tue, Feb 26, 2019 at 12:19 AM Craig Russell <ap...@gmail.com> wrote:
>
> Hi Willem,
>
> It will help focus this discussion if you tell us what the binary artifacts are and why your normal build process doesn't already build them.
>
> Mark and Christopher described a couple of possible binary files and how to handle them.
>
> But it would be really useful for you to tell us what these files are.
>
> Regards,
>
> Craig
>
> > On Feb 23, 2019, at 11:06 PM, Willem Jiang <wi...@gmail.com> wrote:
> >
> > Hi Ted,
> >
> > You made a good point, I think my solution could be building the jars
> > from source and then using it for testing.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning <te...@gmail.com> wrote:
> >>
> >> Willem,
> >>
> >> This issue of embedded binaries for testing purposes has come up before.
> >> Examples include network intercepts for testing malware detection or class
> >> files for a byte code manipulator. The network files can't easily be
> >> recreated since they were observed in the wild and the class files might
> >> have been produced by a specific (possibly broken) compiler version that
> >> isn't widely available.
> >>
> >> The key question is whether these binaries are derived from some source
> >> that could be compiled instead of distributing the binary objects. Failing
> >> that, can the provenance and justification for the binary object be
> >> described?
> >>
> >>
> >>
> >>
> >> On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com> wrote:
> >>
> >>> Hi
> >>>
> >>> Thanks Justin for the clarification. I guess the policy imply the
> >>> source materials cannot have any binary.
> >>> But what if the binary is only for testing, which cannot be part of
> >>> the released software.
> >>> From my point of view, we don't need to modify the source materials
> >>> testing binary to do the software release as it is not a part of the
> >>> binary release of the software.
> >>>
> >>> Any thoughts?
> >>>
> >>> Regards,
> >>>
> >>> Willem Jiang
> >>>
> >>> Twitter: willemjiang
> >>> Weibo: 姜宁willem
> >>>
> >>> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <ju...@classsoftware.com>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>> [1]http://www.apache.org/legal/release-policy.html#what
> >>>>
> >>>> It’s explained in that link there i.e. "The Apache Software Foundation
> >>> produces open source software. All releases are in the form of the source
> >>> materials needed to make changes to the software being released”.
> >>>>
> >>>> Thanks,
> >>>> Justin
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I can also point to a few podlings that have jars in their source releases but these don’t have any real code in them.The exceptions mentioned in this thread are rare across the 250 top level and incubating projects we have and have been carefully considered. There’s not a single instance of a 3rd party jars, which I think is what you are asking about, that I can recall.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Craig Russell <ap...@gmail.com>.
Hi Willem,
It will help focus this discussion if you tell us what the binary artifacts are and why your normal build process doesn't already build them.
Mark and Christopher described a couple of possible binary files and how to handle them.
But it would be really useful for you to tell us what these files are.
Regards,
Craig
> On Feb 23, 2019, at 11:06 PM, Willem Jiang <wi...@gmail.com> wrote:
>
> Hi Ted,
>
> You made a good point, I think my solution could be building the jars
> from source and then using it for testing.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning <te...@gmail.com> wrote:
>>
>> Willem,
>>
>> This issue of embedded binaries for testing purposes has come up before.
>> Examples include network intercepts for testing malware detection or class
>> files for a byte code manipulator. The network files can't easily be
>> recreated since they were observed in the wild and the class files might
>> have been produced by a specific (possibly broken) compiler version that
>> isn't widely available.
>>
>> The key question is whether these binaries are derived from some source
>> that could be compiled instead of distributing the binary objects. Failing
>> that, can the provenance and justification for the binary object be
>> described?
>>
>>
>>
>>
>> On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Thanks Justin for the clarification. I guess the policy imply the
>>> source materials cannot have any binary.
>>> But what if the binary is only for testing, which cannot be part of
>>> the released software.
>>> From my point of view, we don't need to modify the source materials
>>> testing binary to do the software release as it is not a part of the
>>> binary release of the software.
>>>
>>> Any thoughts?
>>>
>>> Regards,
>>>
>>> Willem Jiang
>>>
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>>
>>> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <ju...@classsoftware.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> [1]http://www.apache.org/legal/release-policy.html#what
>>>>
>>>> It’s explained in that link there i.e. "The Apache Software Foundation
>>> produces open source software. All releases are in the form of the source
>>> materials needed to make changes to the software being released”.
>>>>
>>>> Thanks,
>>>> Justin
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>
Re: Binary jars in the source release which are only for testing
Posted by Christofer Dutz <ch...@c-ware.de>.
If you are taking about the Maven wrapper. I did that for you guys. A PR I submitted a year or two ago does exactly this. It checks if the jar is there, if not it tries to download via wget and similar, if that falls it comes that little Java program (the one that started this whole discussion) executes this and downloads the jar that way.
I did that prior to starting Plc4x cause I knew jars in repos are big nonos.
Chris
Outlook fur Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Vinayakumar B <vi...@apache.org>
Sent: Sunday, February 24, 2019 8:38:39 AM
To: general@incubator.apache.org
Subject: Re: Binary jars in the source release which are only for testing
Hi,
For testing purpose.. why cant provide bin artifacts in a separate
convenience binary package as its being done in many other projects.. why
it should be part of source package.?
For the easy detection.. bin artifacts can have same version number as
source.
Again.. Official voting is on source package as per policy.
-Vinay
On Sun, 24 Feb 2019, 12:44 pm Willem Jiang, <wi...@gmail.com> wrote:
> Hi Ted,
>
> You made a good point, I think my solution could be building the jars
> from source and then using it for testing.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning <te...@gmail.com>
> wrote:
> >
> > Willem,
> >
> > This issue of embedded binaries for testing purposes has come up before.
> > Examples include network intercepts for testing malware detection or
> class
> > files for a byte code manipulator. The network files can't easily be
> > recreated since they were observed in the wild and the class files might
> > have been produced by a specific (possibly broken) compiler version that
> > isn't widely available.
> >
> > The key question is whether these binaries are derived from some source
> > that could be compiled instead of distributing the binary objects.
> Failing
> > that, can the provenance and justification for the binary object be
> > described?
> >
> >
> >
> >
> > On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com>
> wrote:
> >
> > > Hi
> > >
> > > Thanks Justin for the clarification. I guess the policy imply the
> > > source materials cannot have any binary.
> > > But what if the binary is only for testing, which cannot be part of
> > > the released software.
> > > From my point of view, we don't need to modify the source materials
> > > testing binary to do the software release as it is not a part of the
> > > binary release of the software.
> > >
> > > Any thoughts?
> > >
> > > Regards,
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <
> justin@classsoftware.com>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > [1]http://www.apache.org/legal/release-policy.html#what
> > > >
> > > > It’s explained in that link there i.e. "The Apache Software
> Foundation
> > > produces open source software. All releases are in the form of the
> source
> > > materials needed to make changes to the software being released”.
> > > >
> > > > Thanks,
> > > > Justin
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Binary jars in the source release which are only for testing
Posted by Vinayakumar B <vi...@apache.org>.
Hi,
For testing purpose.. why cant provide bin artifacts in a separate
convenience binary package as its being done in many other projects.. why
it should be part of source package.?
For the easy detection.. bin artifacts can have same version number as
source.
Again.. Official voting is on source package as per policy.
-Vinay
On Sun, 24 Feb 2019, 12:44 pm Willem Jiang, <wi...@gmail.com> wrote:
> Hi Ted,
>
> You made a good point, I think my solution could be building the jars
> from source and then using it for testing.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning <te...@gmail.com>
> wrote:
> >
> > Willem,
> >
> > This issue of embedded binaries for testing purposes has come up before.
> > Examples include network intercepts for testing malware detection or
> class
> > files for a byte code manipulator. The network files can't easily be
> > recreated since they were observed in the wild and the class files might
> > have been produced by a specific (possibly broken) compiler version that
> > isn't widely available.
> >
> > The key question is whether these binaries are derived from some source
> > that could be compiled instead of distributing the binary objects.
> Failing
> > that, can the provenance and justification for the binary object be
> > described?
> >
> >
> >
> >
> > On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com>
> wrote:
> >
> > > Hi
> > >
> > > Thanks Justin for the clarification. I guess the policy imply the
> > > source materials cannot have any binary.
> > > But what if the binary is only for testing, which cannot be part of
> > > the released software.
> > > From my point of view, we don't need to modify the source materials
> > > testing binary to do the software release as it is not a part of the
> > > binary release of the software.
> > >
> > > Any thoughts?
> > >
> > > Regards,
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <
> justin@classsoftware.com>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > [1]http://www.apache.org/legal/release-policy.html#what
> > > >
> > > > It’s explained in that link there i.e. "The Apache Software
> Foundation
> > > produces open source software. All releases are in the form of the
> source
> > > materials needed to make changes to the software being released”.
> > > >
> > > > Thanks,
> > > > Justin
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Binary jars in the source release which are only for testing
Posted by Willem Jiang <wi...@gmail.com>.
Hi Ted,
You made a good point, I think my solution could be building the jars
from source and then using it for testing.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Sun, Feb 24, 2019 at 10:02 AM Ted Dunning <te...@gmail.com> wrote:
>
> Willem,
>
> This issue of embedded binaries for testing purposes has come up before.
> Examples include network intercepts for testing malware detection or class
> files for a byte code manipulator. The network files can't easily be
> recreated since they were observed in the wild and the class files might
> have been produced by a specific (possibly broken) compiler version that
> isn't widely available.
>
> The key question is whether these binaries are derived from some source
> that could be compiled instead of distributing the binary objects. Failing
> that, can the provenance and justification for the binary object be
> described?
>
>
>
>
> On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com> wrote:
>
> > Hi
> >
> > Thanks Justin for the clarification. I guess the policy imply the
> > source materials cannot have any binary.
> > But what if the binary is only for testing, which cannot be part of
> > the released software.
> > From my point of view, we don't need to modify the source materials
> > testing binary to do the software release as it is not a part of the
> > binary release of the software.
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > > [1]http://www.apache.org/legal/release-policy.html#what
> > >
> > > It’s explained in that link there i.e. "The Apache Software Foundation
> > produces open source software. All releases are in the form of the source
> > materials needed to make changes to the software being released”.
> > >
> > > Thanks,
> > > Justin
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Willem Jiang <wi...@gmail.com>.
Normally we don't distribute the test jar outside, I'm not sure if I
can find a good place to host these jars.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Sun, Feb 24, 2019 at 2:47 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
> Or, can you change your build script to download the jar instead of packaging it in the source release?
>
> On 2/23/19, 6:02 PM, "Ted Dunning" <te...@gmail.com> wrote:
>
> Willem,
>
> This issue of embedded binaries for testing purposes has come up before.
> Examples include network intercepts for testing malware detection or class
> files for a byte code manipulator. The network files can't easily be
> recreated since they were observed in the wild and the class files might
> have been produced by a specific (possibly broken) compiler version that
> isn't widely available.
>
> The key question is whether these binaries are derived from some source
> that could be compiled instead of distributing the binary objects. Failing
> that, can the provenance and justification for the binary object be
> described?
>
>
>
>
> On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com> wrote:
>
> > Hi
> >
> > Thanks Justin for the clarification. I guess the policy imply the
> > source materials cannot have any binary.
> > But what if the binary is only for testing, which cannot be part of
> > the released software.
> > From my point of view, we don't need to modify the source materials
> > testing binary to do the software release as it is not a part of the
> > binary release of the software.
> >
> > Any thoughts?
> >
> > Regards,
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <ju...@classsoftware.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > > [1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23what&data=02%7C01%7Caharui%40adobe.com%7Cf5a610c610a847bf492408d699fc1ad8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636865705492422828&sdata=aLOPz6UB1Fz4oNJYUYf6LZKwNeTkGhfNC1Q9Nmq6vok%3D&reserved=0
> > >
> > > It’s explained in that link there i.e. "The Apache Software Foundation
> > produces open source software. All releases are in the form of the source
> > materials needed to make changes to the software being released”.
> > >
> > > Thanks,
> > > Justin
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Or, can you change your build script to download the jar instead of packaging it in the source release?
On 2/23/19, 6:02 PM, "Ted Dunning" <te...@gmail.com> wrote:
Willem,
This issue of embedded binaries for testing purposes has come up before.
Examples include network intercepts for testing malware detection or class
files for a byte code manipulator. The network files can't easily be
recreated since they were observed in the wild and the class files might
have been produced by a specific (possibly broken) compiler version that
isn't widely available.
The key question is whether these binaries are derived from some source
that could be compiled instead of distributing the binary objects. Failing
that, can the provenance and justification for the binary object be
described?
On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com> wrote:
> Hi
>
> Thanks Justin for the clarification. I guess the policy imply the
> source materials cannot have any binary.
> But what if the binary is only for testing, which cannot be part of
> the released software.
> From my point of view, we don't need to modify the source materials
> testing binary to do the software release as it is not a part of the
> binary release of the software.
>
> Any thoughts?
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
> >
> > Hi,
> >
> > > [1]https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23what&data=02%7C01%7Caharui%40adobe.com%7Cf5a610c610a847bf492408d699fc1ad8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636865705492422828&sdata=aLOPz6UB1Fz4oNJYUYf6LZKwNeTkGhfNC1Q9Nmq6vok%3D&reserved=0
> >
> > It’s explained in that link there i.e. "The Apache Software Foundation
> produces open source software. All releases are in the form of the source
> materials needed to make changes to the software being released”.
> >
> > Thanks,
> > Justin
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Binary jars in the source release which are only for testing
Posted by Ted Dunning <te...@gmail.com>.
Willem,
This issue of embedded binaries for testing purposes has come up before.
Examples include network intercepts for testing malware detection or class
files for a byte code manipulator. The network files can't easily be
recreated since they were observed in the wild and the class files might
have been produced by a specific (possibly broken) compiler version that
isn't widely available.
The key question is whether these binaries are derived from some source
that could be compiled instead of distributing the binary objects. Failing
that, can the provenance and justification for the binary object be
described?
On Sat, Feb 23, 2019 at 6:49 PM Willem Jiang <wi...@gmail.com> wrote:
> Hi
>
> Thanks Justin for the clarification. I guess the policy imply the
> source materials cannot have any binary.
> But what if the binary is only for testing, which cannot be part of
> the released software.
> From my point of view, we don't need to modify the source materials
> testing binary to do the software release as it is not a part of the
> binary release of the software.
>
> Any thoughts?
>
> Regards,
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <ju...@classsoftware.com>
> wrote:
> >
> > Hi,
> >
> > > [1]http://www.apache.org/legal/release-policy.html#what
> >
> > It’s explained in that link there i.e. "The Apache Software Foundation
> produces open source software. All releases are in the form of the source
> materials needed to make changes to the software being released”.
> >
> > Thanks,
> > Justin
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Binary jars in the source release which are only for testing
Posted by Willem Jiang <wi...@gmail.com>.
Hi
Thanks Justin for the clarification. I guess the policy imply the
source materials cannot have any binary.
But what if the binary is only for testing, which cannot be part of
the released software.
From my point of view, we don't need to modify the source materials
testing binary to do the software release as it is not a part of the
binary release of the software.
Any thoughts?
Regards,
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Sat, Feb 23, 2019 at 2:41 PM Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> > [1]http://www.apache.org/legal/release-policy.html#what
>
> It’s explained in that link there i.e. "The Apache Software Foundation produces open source software. All releases are in the form of the source materials needed to make changes to the software being released”.
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> [1]http://www.apache.org/legal/release-policy.html#what
It’s explained in that link there i.e. "The Apache Software Foundation produces open source software. All releases are in the form of the source materials needed to make changes to the software being released”.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Feb 25, 2019 at 3:28 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 25/02/2019 14:15, Roman Shaposhnik wrote:
> > On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas <ma...@apache.org> wrote:
> >>
> >> On 23/02/2019 06:18, Willem Jiang wrote:
> >>> Hi,
> >>>
> >>> I just have a question about the Binary jars in the source release.
> >>> According the Apache release policy, I cannot find any rule about the
> >>> binary jars cannot be in the source release[1]. If we just have jars
> >>> for testing purposes and those jar won't be a part of convenience
> >>> binary release, I think it doesn't break the rule below:
> >>>
> >>> "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.".
> >>>
> >>> Is it OK to ship those test binary jars in the source release kit?
> >>
> >> It depends ;)
> >>
> >> Generally, source releases should contain exactly that - source code. So
> >> the aim should always be to not include compiled code - like JARs - in a
> >> source release.
> >>
> >> That said, I have always been a little more relaxed about test code.
> >> Sometimes you need to use class files and/or JARs in your testing. The
> >> minimum - in my view - is that:
> >> - it MUST be possible to produce a fully working binary from the source
> >> distribution
> >
> > Big +1 to the above.
> >
> >> - the source for any compiled files included in the source MUST be
> >> provided alongside the compiled files
> >
> > Is this really a MUST in all situations? Sometimes a JAR file truly is a test
> > artifact (like for negative testcases for example) and it may not even be
> > possible to "compile it" -- its purpose in fact, may be to test something like
> > a classloader for tripping up on "incorrect" JARs, etc.
> >
> > Or did I misunderstand your MUST?
>
> The view I was trying (and failing) to convey is that we don't want any
> binary "magic" files in the release.
By and large -- yes. IOW, for every magic binary there has to be a good reason.
Sometimes that reason actually exists (like my handcrafted JAR example
or an image file that was created in Gimp but its not like there's a
"source" for it).
> The "source" may be the source as
> in the input to a compiler.
Which is covered by your point #1 -- you disable tests -- you should be able
to build the release purely from source.
> It might be a more complex recipe. Either
> way it needs to carry sufficient information to enable other community
> members to understand how the binary file was created and what they
> would need to do if they wanted/needed to re-create the binary file at
> some point in the future.
>
> HTH,
>
> Mark
>
> >
> > Thanks,
> > Roman.
> >
> >> Ideally, class files, JAR files etc. would be constructed as required
> >> when the tests are run. However, there are cases when it makes sense to
> >> include the binary - e.g. the file needs to be compiled with a very
> >> specific version of the compiler because it is testing something that
> >> depends on a specific behaviour of that compiler version. It is arguably
> >> better for users to provide the compiled file rather than requiring them
> >> to obtain the specific compiler version required.
> >>
> >> For the record, Apache Tomcat has a small number of JAR and class files
> >> in its source distribution. All related to testing and the source is
> >> there for all of them. We could probably generate some of those at build
> >> time. But, given the very small number of files concerned and the
> >> complexity it adds to the build process, it isn't an itch any of the
> >> community has felt the need to scratch. Yet.
> >>
> >> I also recall an instance - I think in Apache Commons BCEL - where we
> >> needed to test with a faulty class file. From memory, we shipped the
> >> class file in the source along with instructions on how to recreate it.
> >> I don't recall exactly why but creating it at build time was problematic.
> >>
> >> In summary, I think you are fine as long as you meet the MUSTs I listed
> >> above. Whether the project should look to generate those files at
> >> build/testing time depends on circumstances. In most cases I would
> >> expect them to be generated during building/testing but there can be
> >> valid reasons for not doing so.
> >>
> >> Mark
> >>
> >>
> >>
> >>
> >>>
> >>> [1]http://www.apache.org/legal/release-policy.html#what
> >>>
> >>> Willem Jiang
> >>>
> >>> Twitter: willemjiang
> >>> Weibo: 姜宁willem
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Mark Thomas <ma...@apache.org>.
On 25/02/2019 14:15, Roman Shaposhnik wrote:
> On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas <ma...@apache.org> wrote:
>>
>> On 23/02/2019 06:18, Willem Jiang wrote:
>>> Hi,
>>>
>>> I just have a question about the Binary jars in the source release.
>>> According the Apache release policy, I cannot find any rule about the
>>> binary jars cannot be in the source release[1]. If we just have jars
>>> for testing purposes and those jar won't be a part of convenience
>>> binary release, I think it doesn't break the rule below:
>>>
>>> "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.".
>>>
>>> Is it OK to ship those test binary jars in the source release kit?
>>
>> It depends ;)
>>
>> Generally, source releases should contain exactly that - source code. So
>> the aim should always be to not include compiled code - like JARs - in a
>> source release.
>>
>> That said, I have always been a little more relaxed about test code.
>> Sometimes you need to use class files and/or JARs in your testing. The
>> minimum - in my view - is that:
>> - it MUST be possible to produce a fully working binary from the source
>> distribution
>
> Big +1 to the above.
>
>> - the source for any compiled files included in the source MUST be
>> provided alongside the compiled files
>
> Is this really a MUST in all situations? Sometimes a JAR file truly is a test
> artifact (like for negative testcases for example) and it may not even be
> possible to "compile it" -- its purpose in fact, may be to test something like
> a classloader for tripping up on "incorrect" JARs, etc.
>
> Or did I misunderstand your MUST?
The view I was trying (and failing) to convey is that we don't want any
binary "magic" files in the release. The "source" may be the source as
in the input to a compiler. It might be a more complex recipe. Either
way it needs to carry sufficient information to enable other community
members to understand how the binary file was created and what they
would need to do if they wanted/needed to re-create the binary file at
some point in the future.
HTH,
Mark
>
> Thanks,
> Roman.
>
>> Ideally, class files, JAR files etc. would be constructed as required
>> when the tests are run. However, there are cases when it makes sense to
>> include the binary - e.g. the file needs to be compiled with a very
>> specific version of the compiler because it is testing something that
>> depends on a specific behaviour of that compiler version. It is arguably
>> better for users to provide the compiled file rather than requiring them
>> to obtain the specific compiler version required.
>>
>> For the record, Apache Tomcat has a small number of JAR and class files
>> in its source distribution. All related to testing and the source is
>> there for all of them. We could probably generate some of those at build
>> time. But, given the very small number of files concerned and the
>> complexity it adds to the build process, it isn't an itch any of the
>> community has felt the need to scratch. Yet.
>>
>> I also recall an instance - I think in Apache Commons BCEL - where we
>> needed to test with a faulty class file. From memory, we shipped the
>> class file in the source along with instructions on how to recreate it.
>> I don't recall exactly why but creating it at build time was problematic.
>>
>> In summary, I think you are fine as long as you meet the MUSTs I listed
>> above. Whether the project should look to generate those files at
>> build/testing time depends on circumstances. In most cases I would
>> expect them to be generated during building/testing but there can be
>> valid reasons for not doing so.
>>
>> Mark
>>
>>
>>
>>
>>>
>>> [1]http://www.apache.org/legal/release-policy.html#what
>>>
>>> Willem Jiang
>>>
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas <ma...@apache.org> wrote:
>
> On 23/02/2019 06:18, Willem Jiang wrote:
> > Hi,
> >
> > I just have a question about the Binary jars in the source release.
> > According the Apache release policy, I cannot find any rule about the
> > binary jars cannot be in the source release[1]. If we just have jars
> > for testing purposes and those jar won't be a part of convenience
> > binary release, I think it doesn't break the rule below:
> >
> > "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.".
> >
> > Is it OK to ship those test binary jars in the source release kit?
>
> It depends ;)
>
> Generally, source releases should contain exactly that - source code. So
> the aim should always be to not include compiled code - like JARs - in a
> source release.
>
> That said, I have always been a little more relaxed about test code.
> Sometimes you need to use class files and/or JARs in your testing. The
> minimum - in my view - is that:
> - it MUST be possible to produce a fully working binary from the source
> distribution
Big +1 to the above.
> - the source for any compiled files included in the source MUST be
> provided alongside the compiled files
Is this really a MUST in all situations? Sometimes a JAR file truly is a test
artifact (like for negative testcases for example) and it may not even be
possible to "compile it" -- its purpose in fact, may be to test something like
a classloader for tripping up on "incorrect" JARs, etc.
Or did I misunderstand your MUST?
Thanks,
Roman.
> Ideally, class files, JAR files etc. would be constructed as required
> when the tests are run. However, there are cases when it makes sense to
> include the binary - e.g. the file needs to be compiled with a very
> specific version of the compiler because it is testing something that
> depends on a specific behaviour of that compiler version. It is arguably
> better for users to provide the compiled file rather than requiring them
> to obtain the specific compiler version required.
>
> For the record, Apache Tomcat has a small number of JAR and class files
> in its source distribution. All related to testing and the source is
> there for all of them. We could probably generate some of those at build
> time. But, given the very small number of files concerned and the
> complexity it adds to the build process, it isn't an itch any of the
> community has felt the need to scratch. Yet.
>
> I also recall an instance - I think in Apache Commons BCEL - where we
> needed to test with a faulty class file. From memory, we shipped the
> class file in the source along with instructions on how to recreate it.
> I don't recall exactly why but creating it at build time was problematic.
>
> In summary, I think you are fine as long as you meet the MUSTs I listed
> above. Whether the project should look to generate those files at
> build/testing time depends on circumstances. In most cases I would
> expect them to be generated during building/testing but there can be
> valid reasons for not doing so.
>
> Mark
>
>
>
>
> >
> > [1]http://www.apache.org/legal/release-policy.html#what
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Binary jars in the source release which are only for testing
Posted by Mark Thomas <ma...@apache.org>.
On 23/02/2019 06:18, Willem Jiang wrote:
> Hi,
>
> I just have a question about the Binary jars in the source release.
> According the Apache release policy, I cannot find any rule about the
> binary jars cannot be in the source release[1]. If we just have jars
> for testing purposes and those jar won't be a part of convenience
> binary release, I think it doesn't break the rule below:
>
> "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.".
>
> Is it OK to ship those test binary jars in the source release kit?
It depends ;)
Generally, source releases should contain exactly that - source code. So
the aim should always be to not include compiled code - like JARs - in a
source release.
That said, I have always been a little more relaxed about test code.
Sometimes you need to use class files and/or JARs in your testing. The
minimum - in my view - is that:
- it MUST be possible to produce a fully working binary from the source
distribution
- the source for any compiled files included in the source MUST be
provided alongside the compiled files
Ideally, class files, JAR files etc. would be constructed as required
when the tests are run. However, there are cases when it makes sense to
include the binary - e.g. the file needs to be compiled with a very
specific version of the compiler because it is testing something that
depends on a specific behaviour of that compiler version. It is arguably
better for users to provide the compiled file rather than requiring them
to obtain the specific compiler version required.
For the record, Apache Tomcat has a small number of JAR and class files
in its source distribution. All related to testing and the source is
there for all of them. We could probably generate some of those at build
time. But, given the very small number of files concerned and the
complexity it adds to the build process, it isn't an itch any of the
community has felt the need to scratch. Yet.
I also recall an instance - I think in Apache Commons BCEL - where we
needed to test with a faulty class file. From memory, we shipped the
class file in the source along with instructions on how to recreate it.
I don't recall exactly why but creating it at build time was problematic.
In summary, I think you are fine as long as you meet the MUSTs I listed
above. Whether the project should look to generate those files at
build/testing time depends on circumstances. In most cases I would
expect them to be generated during building/testing but there can be
valid reasons for not doing so.
Mark
>
> [1]http://www.apache.org/legal/release-policy.html#what
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org