If there's a chance the package is unavailable, we probably should bundle it.
That's what we're doing with the ashwood graph library, right?
I still am pretty ignorant about maven, but I'd say that a first pass
of a buildable source distribution would be to take the svn checkout
of the project, and then somehow point all non-ASF jar file references
to a local lib directory containing jar files that aren't under ASF
maintenance, and build from that.
Again, I haven't looked at Cayenne 3, so I don't know just how many
files we're talking about at this point, but our list of licensed jar
files doesn't seem like it's that large.
On Mon, Aug 16, 2010 at 2:43 PM, Andrus Adamchik <andru..bjectstyle.org> 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:05:03 UTC