Ignoring the problem of 3rd party jar files, I think we can make a
huge step forward by sticking the svn checkout contents into the src
directory -- at that point, we have "buildable" (at least today)
source.
On Mon, Aug 16, 2010 at 3:14 PM, Mike Kienenberger <mkienen..mail.com> wrote:
> So what do we need to do?
>
> Fix it for this point release? Make an exception for old point
> releases, and only fix it for 3.1?
>
> Fix our latest point releases for each currently maintained branch?
>
> My opinion is that we should fix all of the latest point releases, but
> I personally won't be able to do the work -- as I mentioned a couple
> months back, I'm in the middle of a go-live deployment of a three-year
> project for the next month or two, and I'm maven-ignorant.
>
> Second best would be to fix the 3.x branches.
>
> Third best would be to fix only 3.1.
>
> On Mon, Aug 16, 2010 at 3:04 PM, Andrus Adamchik <andru..bjectstyle.org> wrote:
>> So again, I am convinced by your argument and the history trail of reasoning
>> behind it. Just feels that the solution that we might use (and that others
>> are using) and the desired ideal are pretty far apart from each other.
>>
>> Andrus
>>
>>
>> On Aug 16, 2010, at 9:43 PM, Andrus Adamchik wrote:
>>
>>> Yeah I vaguely remember this discussion -
>>> http://markmail.org/thread/njray5dbazwcdcts and I have to agree with Roy's
>>> logic, which convinces me better than a mention of "policy" :-)
>>>
>>> Ok, so say we have a Maven build system that exports buildable source with
>>> poms... which, considering the reliance on a public Maven repo for
>>> dependencies may not be that "buildable" 6 months from now :-/ Even
>>> open-source Apache-licensed (but not ASF-managed) packages may disappear.
>>> How far can we go with that? (a good experiment would be to take a year old
>>> existing ASF package and trying to build it, say Geronimo or something of
>>> that level of complexity..)
>>>
>>> Andrus
>>>
>>>
>>> On Aug 16, 2010, at 9:28 PM, Mike Kienenberger wrote:
>>>>
>>>> It's one thing to state that it may not be a requirement to provide
>>>> buildable source, but it's quite a stretch to claim that we do provide
>>>> buildable source immediately after a message stating "It is
>>>> practically impossible to do that as the build system is ... well,
>>>> complex" Taken to extremes, you could say that a jar file full of
>>>> classes is buildable source, since, with the right tools, you can
>>>> decompile the class files back to java code.
>>>>
>>>> But if you want to say that we're meeting the source build
>>>> requirement, consider this. It would mean that everyone voting +1 on a
>>>> release has somehow thrown a home-grown build-system on top of the
>>>> source release and successfully built it. Because that's the only
>>>> way an evaluator can be sure that the release has met the condition
>>>> and the release manager hasn't accidentally left out some required
>>>> piece of source. We wouldn't say that we know that the release has a
>>>> valid checksum without checking it ourselves or that the release has a
>>>> valid signature without checking it ourselves. Same goes for
>>>> building it.
>>>>
>>>>
>>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andru..bjectstyle.org>
>>>> wrote:
>>>>>
>>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>>>>
>>>>>> Every ASF release must contain a source package, which must be
>>>>>> sufficient for a user to build and test the release provided they have
>>>>>> access to the appropriate platform and tools. The source package must
>>>>>> be cryptographically signed by the Release Manager with a detached
>>>>>> signature; and that package together with its signature must be tested
>>>>>> prior to voting +1 for release. Folks who vote +1 for release may
>>>>>> offer their own cryptographic signature to be concatenated with the
>>>>>> detached signature file (at the Release Manager's discretion) prior to
>>>>>> release.
>>>>>
>>>>> Actually, re-reading the above and it doesn't state a need of a working
>>>>> pom.xml or build.xml, just the source that is matching the binaries. In
>>>>> this
>>>>> respect we don't violate this. We do not provide a buildfile, but a Java
>>>>> developer will be able to build the source regardless (e.g. by writing
>>>>> build.xml himself, or importing sources in Eclipse).
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andru..bjectstyle.org>
>>>> wrote:
>>>>>
>>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>>>>
>>>>>> Every ASF release must contain a source package, which must be
>>>>>> sufficient for a user to build and test the release provided they have
>>>>>> access to the appropriate platform and tools. The source package must
>>>>>> be cryptographically signed by the Release Manager with a detached
>>>>>> signature; and that package together with its signature must be tested
>>>>>> prior to voting +1 for release. Folks who vote +1 for release may
>>>>>> offer their own cryptographic signature to be concatenated with the
>>>>>> detached signature file (at the Release Manager's discretion) prior to
>>>>>> release.
>>>>>
>>>>> Actually, re-reading the above and it doesn't state a need of a working
>>>>> pom.xml or build.xml, just the source that is matching the binaries. In
>>>>> this
>>>>> respect we don't violate this. We do not provide a buildfile, but a Java
>>>>> developer will be able to build the source regardless (e.g. by writing
>>>>> build.xml himself, or importing sources in Eclipse).
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Aug 16 2010 - 19:20:18 UTC