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