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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 >>> >>> >> > >
